Internet-Draft T. Baba
-Expires: August 4, 2003 NTT Data
- February 4, 2003
+Expires: March 11, 2004 NTT Data
+ September 11, 2003
Requirements for Access Control in Domain Name Systems
- draft-baba-dnsext-acl-reqts-00.txt
+ draft-baba-dnsext-acl-reqts-01.txt
Status of this Memo
Distribution of this memo is unlimited.
- This Internet-Draft will expire on August 4, 2003.
+ This Internet-Draft will expire on March 11, 2004.
Abstract
-Baba Expires August 4, 2003 [Page 1]
+Baba Expires March 11, 2004 [Page 1]
\f
-Internet-Draft DNS Access Control Requirements February 2003
+Internet-Draft DNS Access Control Requirements September 2003
At the 28th IETF Meeting in Houston in 1993, DNS security design team
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. With DNS access control mechanism, access
- from unauthorized clients can be blocked when they perform DNS name
+ 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
responses. A client may be an end host or a cashing/recursive name
server.
- RRset
- All resource records (RRs) having the same NAME, CLASS and TYPE
- are called a Resource Record Set (RRset).
-
-
-Baba Expires August 4, 2003 [Page 2]
+Baba Expires March 11, 2004 [Page 2]
\f
-Internet-Draft DNS Access Control Requirements February 2003
+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
3.1 Authentication
-3.1.1 Client Identifier / Authentication Mechanism
+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
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
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.
-
-
-
-
-
-Baba Expires August 4, 2003 [Page 3]
-\f
-Internet-Draft DNS Access Control Requirements February 2003
-
-
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. Although IPsec can be used to encrypt DNS packets, it
- authenticates a peer based on IP address. Currently, no encryption
- mechanism is specified in DNS. Therefore, new RRs must be defined
- for DNS message encryption. In case encryption is applied, entire
- DNS message including DNS header must be encrypted to hide
- information including error code.
+ 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.
+ 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 must 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.
+ 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
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 August 4, 2003 [Page 4]
+Baba Expires March 11, 2004 [Page 4]
\f
-Internet-Draft DNS Access Control Requirements February 2003
+Internet-Draft DNS Access Control Requirements September 2003
3.3.2 ACL Representation
security team for their important contribution to this work.
-Baba Expires August 4, 2003 [Page 5]
+Baba Expires March 11, 2004 [Page 5]
\f
-Internet-Draft DNS Access Control Requirements February 2003
+Internet-Draft DNS Access Control Requirements September 2003
6. References
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
+ [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.
- [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.
+ [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.
+ [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.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 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
-
-
-
-
-
-
-
-
-
-
-Baba Expires August 4, 2003 [Page 6]
+Baba Expires March 11, 2004 [Page 6]
+++ /dev/null
-
-
-Network Working Group L. Daigle
-Internet-Draft A. Newton
-Expires: May 5, 2003 VeriSign, Inc.
- November 4, 2002
-
-
- Domain-based Application Service Location Using SRV RRs and the
- Dynamic Delegation Discovery Service (DDDS)
- draft-daigle-napstr-01.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 May 5, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This memo defines a Dynamic Delegation Discovery System (DDDS) [3]
- Application for domain name based discovery of application services.
- Essentially, this uses DNS NAPTR resource records [4] to provide one
- more layer of redirection for service lookup than is feasible with
- SRV ([2]) records. It is proposed because real-life use is
- demonstrating a need for something slightly more substantial than
- SRV, and alternatively SRV usage may become twisted out of its
- intended shape.
-
-
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 1]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
-1. Introduction
-
- Increasingly, application protocol standards are using domain names
- to identify server targets, and stipulating that clients should look
- up SRV ([2]) 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 -- the server may
- be operated by a completely different organization without having to
- delegate some portion of the zone, multiple instances can be set up
- (e.g., for load balancing or secondaries), it can be moved from time
- to time without disrupting clients' access, etc. This is quite
- useful, but Section 4 outlines some of the limitations inherent in
- the approach.
-
- To address some of the limitations, this document defines a DDDS [3]
- Application to map service+protocol+domain to specific server
- addresses using both NAPTR [4] and SRV 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.
-
- 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 (prefetchable, cachable) than with some uses of NAPTR
- records.
-
- This form of naming indirection (using just SRV records, or DDDS) has
- implications for application protocols attempting to validate
- security credentials. This is discussed in Section 6.
-
- For the purposes of this document:
-
- o an "application service" is a generic term for some generic type
- of application, independent of the protocol that may be used to
- offer it.
-
- o an "application protocol" is a standard protocol used to
- implementone or several services
-
- For example, "e-mail" is an application service; "SMTP" is the
- protocol that is used to implement it. "Instant Messaging" is an
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 2]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
- application service, for which there are several existing and
- proposed application protocols ("jabber", "simple", etc). "LDAP" is
- an application protocol which can be used to implement several
- different application services (e.g., a "whitepages" service,
- directory enabled networking service, etc).
-
-1.1 What this document means for application protocol developers
-
- The purpose of this document 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.
-
-2. Basic Proposal
-
- The precise details of the specification of this DDDS application are
- given in Appendix A. In general, the proposal is to store
- application service and protocol descriptions in NAPTR records for
- individual domains. This will enable domain administrators to
- provide redirection to other domains that provision individual
- services, with appropriate weightings and preferences.
-
- Each "application service" will be associated with an IANA-registered
- tag. For example, instant messaging is a type of application, which
- is 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 a standard protocol used to implement
- the application service (as defined... ??).
-
- The intention is that the combination of application service and
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 3]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
- protocol tags should be specific enough that finding a known pair
- (e.g., "IM+SIMPLE") is sufficient for a client to identify a server
- with which it can communicate.
-
-3. Examples
-
-3.1 Instant Messaging Services
-
- 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
- different domain than the instant messaging address, and servers
- of different protocols may be offered by independent
- organizations
-
- For example, "thinkingcat.com" may support its own servers for the
- "apex" instant messaging protocol, but rely on outsourcing from
- "example.com" for "simple" and "prim" servers.
-
- Using this DDDS-based approach, thinkingcat.com 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.com, the NAPTR records
- for thinkingcat.com are retrieved:
-
- thinkingcat.com.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM+apex" "" _apex._tcp.thinkingcat.com.
- IN NAPTR 100 20 "s" "IM+prim" "" _prim._tcp.example.com.
- IN NAPTR 100 30 "s" "IM+simple" "" _simple._tcp.example.com.
-
- and then the administrators at example.com can manage the preference
- rankings of the servers they use to support the prim service:
-
-
-
-
-
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 4]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
- _prim._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.example.com.au
-
-
-3.2 Application Key Storage
-
- 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 AppKey service has
- been defined to be a leaf node service holding the keys/certs for the
- servers operated by (or for) the domain. This DDDS-based approach is
- used to find the AppKey server that holds the information.
-
- thinkingcat.com.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "AppKey+LDAP" "" _ldap._tcp.thinkingcat.com
- IN NAPTR 100 20 "s" "AppKey+LDAP" "" _ldap._tcp.example.com
-
-
-4. 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 [2] "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
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 5]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
- 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. So, why not just NAPTR records?
-
- That's a trick question. NAPTR records cannot appear in the wild --
- see [3]. 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
- unintelligle, 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
- expressions".
-
-6. Transiting Trust
-
- One issue to be considered in the use of SRV records in general, and
- this proposal in particular, is the matter of trusting an end server
- once resolution of the end server's IP address is completed. This
- can pose a problem when used with the popular model of trusting an
- end server in use on the Internet today, TLS. Consider the following
- example of electronic commerce for which a user must make a trust
- association to an end server.
-
- 1. The end-user types into the browser the name of the server, for
- example "www.thinkingcat.com".
-
- 2. The server sends to the client its certificate and certificate
- chain information.
-
- 3. The client verifies the server's certificate via the certificate
- chain.
-
- 4. The client compares the domain name in the server's certificate
- to the domain name it was given.
-
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 6]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
- 5. The client sends the session key encrypted with the server's
- public key back to the server.
-
- 6. If the server is really the server it claims to be, then it will
- possess the corresponding private key to use in decrypting the
- session key.
-
- 7. The server and client communicate using encrypted means via the
- session key.
-
- However, the necessity for the client to compare the domain it was
- given with the domain name found in the certificate (step 4) can be
- problematic when the name resolution process changes the domain name
- being sought. This problem can be solved using one of the two
- methods outlined below. For full transition of trust using TLS, each
- method requires the use of DNSSEC [1] to insure the SRV and NAPTR
- records have not been compromised. Neither method requires any
- change to either the TLS or DNSSEC protocols.
-
-6.1 Using the Translated Name
-
- The first method is a simple modification of the client's use of the
- domain name in comparison with the name present in the certificate.
- The following is a modification of the process outlined above.
-
- 1. The end-user types into the client application the name of the
- server. For this example, the client application is a PRIM
- client and the name of the server is "thinkingcat.com".
-
- 2. During the name resolution process for the PRIM service of
- "thinkingcat.com", the NAPTR record will yield the name
- "_prim._tcp.example.com". The client must remember "example.com"
- (i.e., the label without the SRV-style service and protocol
- portions) as the translated name.
-
- 3. The server, bigiron.example.com, sends to the client its
- certificate for "example.com" and certificate chain information.
-
- 4. The client verifies the server's certificate via the certificate
- chain.
-
- 5. The client compares the translated name from the resolution
- process, "example.com", with the name found in the certificate,
- "example.com".
-
- 6. The client sends the session key encrypted with the server's
- public key back to the server.
-
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 7]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
- 7. If the server is really one of the servers for
- "_prim._tcp.example.com", then it will possess the corresponding
- private key to use in decrypting the session key.
-
- 8. The server and client communicate using encrypted means via the
- session key.
-
- Note that the translated name is taken from the NAPTR record and not
- the SRV record. This is done because the use-case is such that the
- user is interested in the PRIM service for "thinkingcat.com" and not
- the particular server where it is hosted.
-
- Note also that this requires that the operator of the service must
- have the certificate for the service's domain. This may cause
- problems when the final server is operated in a different realm of
- administrative control (for example, if it is outsourced to an ISP).
-
-6.2 Trusting the DNS Signer
-
- Due to the fact that DNSSEC must already be used to trust this name
- resolution process, another method is to simply use the certificate
- chain for the certificate that is present in DNS. The following
- steps illustrate this process.
-
- 1. The end-user types into the PRIM application the name
- "thinkingcat.com".
-
- 2. The final outcome of the name resolution process will yield an A
- record containing the IP address for "bigiron.example.com".
-
- 3. The server sends to the client its certificate. The certificate
- chain for this certificate leads to the signer for the A record
- (the certificate is signed using the same private key as the A
- record).
-
- 4. The client verifies the server's certificate using the same
- public key of the A record for "bigiron.example.com".
-
- 5. The client sends the session key encrypted with the server's
- public key back to the server.
-
- 6. If the server is really bigiron.example.com, then it will possess
- the corresponding private key to use in decrypting the session
- key.
-
- 7. The server and client communicate using encrypted means via the
- session key.
-
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 8]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
- The key premise in this case is that DNSSEC ensures the resolution
- yields trustable data in naming the final target server, and
- therefore only that server's named certificate must be validated
- (against the same chain of trust) in order to trust the server
- itself. This approach does not require that the final server have a
- certificate for the named service, and it works for NAPTR, NAPTR+SRV,
- or just SRV name redirection.
-
-7. IANA Considerations
-
- ?? Fill out with specifics for registering "application service" tags
- (and "application protocols", if this is something other than the
- existing port registry).
-
-8. Security Considerations
-
- This is primarily addressed in the "Transiting Trust" section,Section
- 6.
-
-9. Acknowledgements
-
- Many thanks to Patrik Faltstrom and Sally Floyd for discussion and
- input that has (hopefully!) provoked clarifying revisions of this
- document.
-
-References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
- [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- One: The Comprehe nsive DDDS", RFC 3401, October 2002.
-
- [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- Three: The Domain Name System (DNS) Database", RFC 3403, October
- 2002.
-
- [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
- 2002.
-
-
-
-
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 9]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
-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 [3].
-
-A.1 Application Unique String
-
- The Application Unique String is the name of the domain in 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 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 3 of the Flags defined for the
- URI/URN Resolution Application ([5]): "S", "A" and "U". No other
- Flags are valid.
-
- All three are for terminal lookups. This means that the Rule is the
- last one and that the flag determines what the next stage should be.
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 10]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
- The "S" flag means that the output of this Rule is a domain label for
- which one or more SRV [2] 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. "U" means that the output of the Rule is a
- URI which should be resolved.
-
-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 = ALPHA *31ALPHANUM
- app-protocol = ALPHA *31ALPHANUM
- ; The app-service and app-protocol fields are limited to 32
- ; characters and must start with an alphabetic character.
-
- 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.
-
-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].
-
-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.
- [4] 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
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 11]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
- 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 [4] for more
- information on NAPTR records and the Additional Information section
- of a DNS response packet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires May 5, 2003 [Page 12]
-\f
-Internet-Draft draft-daigle-napstr-01 November 2002
-
-
-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.
-
- 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 May 5, 2003 [Page 13]
-\f
--- /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 Jun 2003
-Expires: Dec 1, 2003
-
- A DNS RR for simple SMTP sender authentication
- draft-danisch-dns-rr-smtp-02.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 suggests a new DNS RR type to provide a very simple
- light-weight authentication scheme for the domain part of the
- sender address for SMTP mail transport. It is designed to be a
- simple and robust protection against e-mail fraud and especially
- spam. It is easy to implement and administer, compatible with all
- legislations known by the author, and cheap. It also focuses on
- security and privacy problems and requirements in context of spam
- defense, and touches non-technical problems of defense against
- spam.
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 1]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- Table of Contents
-
-
-1. Threat description . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4
- 1.2. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
-2. Problem analysis . . . . . . . . . . . . . . . . . . . . . . . . 4
-3. Shortcomings of strong authentication mechanisms . . . . . . . . 4
-4. DNS based sender address verification . . . . . . . . . . . . . 5
-5. RMX entry types . . . . . . . . . . . . . . . . . . . . . . . . 5
- 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 5
- 5.1.1 Description . . . . . . . . . . . . . . . . . . . . 6
- 5.1.2 Zone File Syntax . . . . . . . . . . . . . . . . . 6
- 5.1.3 Encoding . . . . . . . . . . . . . . . . . . . . . 6
- 5.2. IPv4 and IPv6 address ranges (Type1/2) . . . . . . . . . . 7
- 5.2.1 Description . . . . . . . . . . . . . . . . . . . . 7
- 5.2.2 Zone File Syntax . . . . . . . . . . . . . . . . . 7
- 5.2.3 Encoding . . . . . . . . . . . . . . . . . . . . . 7
- 5.3. Hostname (Type 3) . . . . . . . . . . . . . . . . . . . . 7
- 5.3.1 Description . . . . . . . . . . . . . . . . . . . . 7
- 5.3.2 Zone File Syntax . . . . . . . . . . . . . . . . . 8
- 5.3.3 Encoding . . . . . . . . . . . . . . . . . . . . . 8
- 5.3.4 Additional Records . . . . . . . . . . . . . . . . 8
- 5.4. APL Reference (Type 4) . . . . . . . . . . . . . . . . . . 8
- 5.4.1 Description . . . . . . . . . . . . . . . . . . . . 8
- 5.4.2 Zone File Syntax . . . . . . . . . . . . . . . . . 8
- 5.4.3 Encoding . . . . . . . . . . . . . . . . . . . . . 9
- 5.4.4 Additional Records . . . . . . . . . . . . . . . . 9
- 5.5. Future Entry Types . . . . . . . . . . . . . . . . . . . . 9
-6. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 9
-7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 7.1. Compatibility with old mail receivers . . . . . . . . . . 10
- 7.2. Compatibility with old mail senders . . . . . . . . . . . 10
- 7.3. Compatibility with old DNS clients . . . . . . . . . . . . 10
- 7.4. Compatibility with old DNS servers . . . . . . . . . . . . 10
-8. Message relaying and forwarding . . . . . . . . . . . . . . . . 10
- 8.1. Problem description . . . . . . . . . . . . . . . . . . . 10
- 8.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 11
- 8.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 11
-9. Enforcement policy . . . . . . . . . . . . . . . . . . . . . . . 12
-10. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
- 10.1. Draft specific considerations . . . . . . . . . . . . . . 12
- 10.1.1 Authentication strength . . . . . . . . . . . . . 12
- 10.1.2 Where Authentication and Authorization end . . . . 13
- 10.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 13
- 10.1.4 Additional data attack? . . . . . . . . . . . . . 15
- 10.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 15
- 10.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 16
-
-
-
-Hadmut Danisch Experimental [Page 2]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 10.1.7 Empty Sender address . . . . . . . . . . . . . . . 16
- 10.1.8 Reliability of Whois Entries . . . . . . . . . . . 16
- 10.1.9 Hazards for Freedom of Speech . . . . . . . . . . 17
- 10.2. General Considerations about spam defense . . . . . . . . 17
- 10.2.1 Action vs. reaction . . . . . . . . . . . . . . . 18
- 10.2.2 Content based Denial of Service attacks . . . . . 18
-11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 18
- 11.1. Draft specific considerations . . . . . . . . . . . . . . 18
- 11.1.1 No content leaking . . . . . . . . . . . . . . . . 19
- 11.1.2 Message reception and sender domain . . . . . . . 19
- 11.1.3 Network structure . . . . . . . . . . . . . . . . 19
- 11.1.4 Owner information distribution . . . . . . . . . . 19
- 11.2. General Considerations about spam defense . . . . . . . . 20
- 11.2.1 Content leaking of content filters . . . . . . . . 20
- 11.2.2 Black- and Whitelists . . . . . . . . . . . . . . 20
-12. Deployment Considerations . . . . . . . . . . . . . . . . . . . 20
- 12.1. The economical problem . . . . . . . . . . . . . . . . . 21
- 12.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 21
- 12.3. The network structure problem . . . . . . . . . . . . . . 22
- 12.4. The mentality problem . . . . . . . . . . . . . . . . . . 22
- 12.5. The identity problem . . . . . . . . . . . . . . . . . . 23
- 12.6. The multi-legislation problem . . . . . . . . . . . . . . 23
-Implementation and further Information . . . . . . . . . . . . . . . 23
-References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 3]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
-1. Threat description
-
-1.1. Mail sender forgery
-
- Security surveillances found a significant increase in the number
- of e-mails with forged sender addresses. As a consequence, damage
- 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.
-
-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.
-
-2. Problem analysis
-
- The real cause for forged e-mail is the lack of the Simple Mail
- Transfer Protocol SMTP[1] to provide any kind of sender
- authentication, authorisation, or verification. Efforts have been
- made to block such e-mails by requiring the sender address domain
- part to be resolvable (e.g. latest sendmail configurations). This
- method provides protection from 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.
-
-3. Shortcomings of strong authentication mechanisms
-
- Without any doubt, SMTP needs to be improved and reengineered in
- the future in order to resist against these kinds of threat.
- Cryptographical or organisational security mechanisms have to be
- designed an implemented for some sort of SMTPng.
-
- Unfortunately, it is impossible to seamlessly switch to a new
- protocol, since most of the SMTP servers and client programs can't
- be replaced or updated easily and quickly. Any kind of security
- mechanism has to be simple and backward compatible in order to be
- accepted. That's why extensions like SMTP with TLS are not widely
- spread.
-
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 4]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
-4. DNS based sender address verification
-
- To gain at least some improvement in e-mail authenticity while
- keeping as much SMTP compatibility as possible, a method is
- suggested which doesn't change SMTP at all.
-
- 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 which IP addresses are authorized to use
- the domain within a sender's address. After receiving the "MAIL
- FROM:" SMTP command, the receiving MTA can verify, whether the IP
- address of the sending MTA is authorized to send mails with this
- domain name. Therefore, a list of authorized IP addresses is
- provided by the authoritative DNS server of that domain.
-
- This version of the draft defines three distinct methods to
- describe IP address authorizations:
-
- - 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 could look like this:
-
- 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
- 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.
-
-5. RMX entry types
-
-5.1. Overall structure
-
-
-
-Hadmut Danisch Experimental [Page 5]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
-5.1.1. Description
-
- 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, 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.
- This method is known from many other rule based security
- mechanisms.
-
- For any domain name there should not exist more than a single RMX
- entry. Due to the structure of DNS, it is nevertheless possible to
- have more than a single RMX entry. Multiple RMX entries 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.
-
-5.1.2. Zone File Syntax
-
- An RMX record may consist of zero or more entries, where the
- entries are separated by whitespace. Each entry consists of a tag,
- determining the entry type, a colon, and the entry data.
-
- Example:
-
- danisch.de. IN RMX apl:relays.rackland.de ipv4:1.2.3.0/24
-
-5.1.3. Encoding
-
- Each entry starts with an octet containting the entry type and the
- negation flag:
-
- +---+---+---+---+---+---+---+---+
- | N | Entry Type Code |
- +---+---+---+---+---+---+---+---+
-
- 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
-
-
-
-Hadmut Danisch Experimental [Page 6]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 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.
-
-5.2. IPv4 and IPv6 address ranges (Type1/2)
-
-5.2.1. Description
-
- These entry types (IPv4 = Type 1, IPv6 = Type 2) contain a bit
- sequence representing a CIDR address part. If that bit sequence
- matches the given IP address, authorization is granted or denied,
- depending on the negation flag.
-
-5.2.2. Zone File Syntax
-
- 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. 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
-
-5.2.3. Encoding
-
- 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 /
- +---+---+---+---+---+---+---+---+
-
-
-5.3. Hostname (Type 3)
-
-5.3.1. Description
-
- 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.
-
-
-
-Hadmut Danisch Experimental [Page 7]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- It is still to be defined how to treat unresolvable entries.
-
-5.3.2. Zone File Syntax
-
- 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.3.3. Encoding
-
- After the entry type tag immediately follows a DNS encoded and
- compressed [2] domain name. Length is determined by called the
- decompression function of the resolver library.
-
- +---+---+---+---+---+---+---+---+
- | N | Entry Type Code (3) |
- +---+---+---+---+---+---+---+---+
- | Encoded and Compressed DNS |
- / Name as described in RFC1035 /
- +---+---+---+---+---+---+---+---+
-
-5.3.4. 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.
-
-5.4. APL Reference (Type 4)
-
-5.4.1. Description
-
- 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.
-
-5.4.2. Zone File Syntax
-
- The entry is prepended with the tag "host", followed by a colon and
- the hostname. Examples:
-
- danisch.de IN RMX apl:relays.rackland.de
-
-
-
-Hadmut Danisch Experimental [Page 8]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
-5.4.3. Encoding
-
- After the entry type tag immediately follows a DNS encoded and
- compressed domain name. Length is determined by called the
- decompression function of the resolver library.
-
- +---+---+---+---+---+---+---+---+
- | N | Entry Type Code (4) |
- +---+---+---+---+---+---+---+---+
- | Encoded and Compressed DNS |
- / Name as described in RFC1035 /
- +---+---+---+---+---+---+---+---+
-
-5.4.4. Additional Records
-
- 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.
-
-5.5. Future Entry Types
-
- In future, more entry type might be defined, e.g. data used for
- challenge response authentication, a URL or DNS name ponting to
- some kind of service for authentication and authorization, entries
- pointing to other directory services (e.g. LDAP), or public key
- informations to require signatures on the message header or body.
-
-6. 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.
-
- 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
-
- where
-
- RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
- "TempFail", "BadData", "Trusted".
-
-
-
-
-Hadmut Danisch Experimental [Page 9]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- ADDRESS is the IP address where the RMX query was based on.
-
- HOST is the name of the machine performing the RMX query.
-
- DATE is the date of the query.
-
-
-
-7. Compatibility
-
-7.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.
-
-7.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.
-
-7.3. Compatibility with old DNS clients
-
- Since the RMX is a new RR, the existing DNS protocol and zone
- informations remain completely untouched.
-
-7.4. Compatibility with old DNS servers
-
- If a server can't provide RMX records or a zone doesn't contain
- them, the check can't be performed, while compatibility is still
- guaranteed.
-
-8. Message relaying and forwarding
-
-8.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
-
-
-
-Hadmut Danisch Experimental [Page 10]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- - 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
- 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 that
- problem.
-
-8.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).
-
- When a relay forwards a message to a trusting machine, the envelope
- sender address should remain unchanged.
-
-8.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 11]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 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.
-
-9. 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.
-
-10. Security Considerations
-
-10.1. Draft specific considerations
-
-10.1.1. Authentication strength
-
- It is important to stress, that the suggested method does not
- provide high level security and does not completely block forged e-
- mails or spam. It is not a reliable and completely secure security
- mechanism. It 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.
-
-
-
-Hadmut Danisch Experimental [Page 12]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
-10.1.2. Where Authentication and Authorization end
-
- RMX records do not cover the local part of the e-mail address, i.e.
- what's on the left side of the @ sign. 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 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.
-
-10.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
-
-
-
-Hadmut Danisch Experimental [Page 13]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 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
- 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
-
-
-
-Hadmut Danisch Experimental [Page 14]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 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.
-
- As a consequence, e-mail delivery by SMTP requires a better DNS
- anyway. The requirements are not significantly expanded by RMX.
-
-10.1.4. Additional data 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.
-
-10.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
-
-
-
-Hadmut Danisch Experimental [Page 15]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- recipient's MTA to reject mails from domains with loose security
- policies.
-
-10.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
- 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.
-
-10.1.7. Empty Sender address
-
- There is a design flaw of current SMTP and SMTP programs: The empty
- sender envelope address. This is used for delivery of error
- messages, and most MTAs accept messages with an empty sender
- address. Obviously, RMX records can't be checked for empty sender
- addresses.
-
- It is a design flaw to inherently allow anonymous mails. This flaw
- must either be fixed, or other methods have to be developed. For
- example MTAs could accept such mails only if they reference the
- Message-ID of another e-mail which has recently been delivered.
-
-10.1.8. 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
-
-
-
-Hadmut Danisch Experimental [Page 16]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 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.
-
-10.1.9. Hazards for Freedom of Speech
-
- 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.
-
-10.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.
-
-
-
-Hadmut Danisch Experimental [Page 17]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 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.
-
-10.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.
-
-10.2.2. Content based Denial of Service attacks
-
- 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.
-
-11. Privacy Considerations
-
- (It was proposed on the 56th IETF meeting to have a privacy section
- in drafts and RFCs.)
-
-11.1. Draft specific considerations
-
-
-
-
-Hadmut Danisch Experimental [Page 18]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
-11.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.
-
-11.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.
-
- 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.
-
-11.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.
-
-11.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
-
-
-
-Hadmut Danisch Experimental [Page 19]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 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.
-
-11.2. General Considerations about spam defense
-
-11.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.
-
- 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".
-
-11.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.
-
-
-12. Deployment Considerations
-
- 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
-
-
-
-Hadmut Danisch Experimental [Page 20]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 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.
-
-12.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.
-
- 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.
-
-12.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[3] 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
-
-
-
-Hadmut Danisch Experimental [Page 21]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 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.
-
- 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.
-
-12.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.
-
-12.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
-
-
-
-Hadmut Danisch Experimental [Page 22]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
- 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.
-
-12.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
- 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.
-
-12.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
-
- and
-
- http://www.danisch.de/software/rmx/
-
-
-
-Hadmut Danisch Experimental [Page 23]
-\f
-INTERNET-DRAFT DNS RMX RR Jun 2003
-
-
-References
-
-
-
-1. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
-
-2. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
- RFC 1035 (November 1987).
-
-3. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
- (May 1996).
-
-
-Author's Address
-
- Hadmut Danisch
-
- Tennesseeallee 58
- 76149 Karlsruhe
- Germany
-
- Phone: ++49-721-843004
- E-Mail: rfc@danisch.de
-
-Comments
-
- Please send comments to rfc@danisch.de.
-
-Expiry
-
- This drafts expires on Dec 1, 2003
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 24]
-\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
-Internet Engineering Task Force Alain Durand
-INTERNET-DRAFT SUN Microsystem
-Oct 2, 2001
-Expires Apr. 3, 2002
-
-
-
- IPv6 DNS lookup proxy
-
- draft-durand-dns-proxy-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.
-
- 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 describe a DNS lookup proxy to enable IPv6 only
- resolver to query data on IPv4 only server.
-
-
-
-1. Introduction
-
-
- As analyzed in [DNSOPreq], the operation of DNS in a mixed
- environment IPv4 and IPv6 require Some bridging to happen to enable
- an IPv6 only system to query data on an IPv4 only server and vice-
- versa. However, such bridges do not need to be symmetrical, that is,
- it is OK, for the sake of efficiency, to design two different
- systems, one for each case. This document presents a scalable
- solution to enable IPv6 only systems to query IPv4 only servers. The
- case of an IPv4 only system querying an IPv6 only server is not
- discussed here.
-
-
-
-2. Recursive vs non recursive fallback system
-
-
- One of the approach suggested to solve the bridging problem was to
- use some kind of dual stack, general forwarder that will resolve the
- queries on behalf of the IPv6 only resolver. An IPv6 only resolver
- could either delegate all its queries to this forwarder or only use
- it in last resort mode, when IPv4 transport is needed to reach the
- desired DNS server.
-
- In the first mode of operation, the general forwarder may face
- massive scaling issues. In the second mode of operation, the
- forwarder will still have to operate in recursive mode because the
- information gathered previously by the IPv6 only resolver in its
- attempt to resolve the name will be lost. It is feared that such
- general forwarder will also face serious scaling issues once the IPv6
- traffic will increase.
-
-
- The lookup-proxy design is based upon the following observation:
- When a resolver is following a chain of referrals and cannot complete
- because it is referred to an address it lacks transport for, then it
- knows both the query and where to send it. It is just lacking
- transport. The solution presented here aims at bridging seamlessly
- the two transports by providing a new protocol that can send the
- tuple:
-
- {query, server}
-
- to a proxy, have the proxy send the query on (directly) to the
- server, collect the response and return it to the resolver. The
- proxy will be non-recursive, and thereby much more scalable.
- Furthermore, the proxy does not (or should not) know much about DNS,
- it should only know enough to repack the query and response in IPv4
- and IPv6 packets respectively.
-
-
-
-3. Lookup proxy architecture
-
-
-3.1 An IPv6 anycast prefix
-
- As an IPv6 address is much larger than an IPv4 address, it is
- possible to embed an IPv4 address within an IPv6 address. Proposal
- like [6to4] or [isatap] use this property to embed IPv4 tunnel
- endpoint within IPv6 addresses.
-
- This document suggest to use a well know, globally routable prefix P
- as an anycast DNS lookup proxy prefix. The prefix length of P MUST be
- shorter than 96 and SHOULD be small enough not to be filtered in
- common BGP announcement.
-
- A set of DNS lookup proxies MUST advertise this anycast prefix and
- MUST intercept any IPv6 packet whose destination address is of the
- form P::a.b.c.d (a.b.c.d represent the 32 bits of an IPv4 address)
- and UPD destination port is 53.
-
-
-3.2 DNS lookup proxy behavior
-
- A DNS lookup proxy SHOULD check the payload to make sure it really is
- a valid DNS query and then MUST forward it in a new IPv4 packet.
-
- The source address of this new packet is one of the proxy IPv4
- addresses. The destination address is taken from the 32 lowest bits
- of the destination address of the incoming IPv6 packet. The transport
- protocol MUST be set to UDP and destination port to 53. The payload
- of the new IPv4 packet MUST be directly copied from the one in the
- IPv6 packet.
-
-
-3.3 Fragmentation and MTU
-
- Simple UDP DNS queries and answers are expected to fit within 512
- bytes, fragmentation and MTU are not an issue for them. However,
- queries using EDNS 0 or falling back to TCP may have a larger
- payload. For DNS connections using TCP, MTU is not an issue, as TCP
- will adapt the correct MTU in each connection on both side of the
- proxy. Using EDNS 0, the client may specify a large packet size than
- 512. As an IPv6 header is longer than an IPv4 header (with no
- options), this mechanism will not results in fragmented UDP packets.
-
- However, if the DNS communication results in exchanging more than one
- packet, there is a theoretical chance that different packets will go
- through different proxies, defeating the mechanism. It is expected
- that the routing system will be stable enough to prevent this case to
- happen in reality.
-
-
-3.4 Mapping
-
- A DNS lookup proxy MUST maintain some kind of mapping between the
- incoming IPv6 query and the outgoing IPv4 packet so that when the
- answer will come back from the IPv4 DNS server, it will know where to
- sent it to in IPv6 land.
-
- A DNS lookup proxy MUST implement some time-outs on those mappings to
- do garbage collection.
-
-
-3.5 Caching
- A DNS lookup proxy MAY implement positive and/or negative caching
- technique to improve efficiency.
-
- In the case of positive caching, the proxy MUST honor the TTL
- provided in the DNS answer; the proxy MAY use a smaller TTL than it
- received, but MUST NOT cache the answer beyond the period specified
- by the TTL.
-
-
-
-3.5 rate limitation
-
- A DNS lookup proxy may also impose some rate limitation measure on
- packet they sent to the same address, either IPv4 or IPv6, to lower
- the impact of potential DOS attack inherent with any public proxy.
-
-
-
-4. Converting IPv4 referrals into IPv6 referrals
-
- When an IPv6 only resolver is following a chain of referrals and
- cannot complete because it is referred only to IPv4 addresses, it
- SHOULD automatically derived an IPv6 addresses by padding the IPv4
- addresses to the prefix P and send the DNS queries to those
- addresses.
-
-
-
-5. Scaling issues
-
-
- Using an anycast prefix P will allow to use as many proxy as
- necessary, thus this mechanism has very good scaling properties.
-
-
-6. Anycast issues
-
- IPv6 architecture requires the anycast addresses MUST NOT be used as
- source addresses. Thus, when returning the DNS answer, the proxy MUST
- replace the anycast address by one of its unicast address with the
- appropriate scope. Also, the IPv6 DNS resolver MUST not check the
- source address of packets returning from the proxy.
-
-
-
-
-7. Security consideration
-
-
- Any public proxy is inherently a source of DOS attack. Rate limiting
- packet emission as suggested in 3.5 is expected to lower the risks.
-
-
-
-8. Author address
-
-
- Alain Durand
- SUN Microsystems, Inc
- 901 San Antonio Road
- MPK17-202
- Palo Alto, CA 94303-4900
- USA
- Mail: Alain.Durand@sun.com
-
-
-9. References
-
- [DNSOPreq] draft-ietf-ngtrans-dns-ops-req-02.txt
-
-
- 10. Acknowledgment
-
- The author whishes to acknowledge the input of Johan Ihren and
- Akira Kato.
-
-
-
-
-
-
-
-
-
-
-
-
-
+++ /dev/null
-
-
- INTERNET-DRAFT Eric A. Hall
- Document: draft-hall-dns-data-00.txt May 2003
- Expires: December, 2003
- Category: Informational
-
- Considerations for DNS Resource Records
-
-
- Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
-
- 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 discusses some common issues which should be taken
- into consideration whenever any new service proposes to extend the
- Domain Name Service.
-
-
- \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
-
- Table of Contents
-
- 1. Introduction...............................................2
- 2. Prerequisites and Terminology..............................3
- 3. DNS Architectural Principles...............................3
- 3.1. Resource Records........................................3
- 3.2. Hierarchical Partitioning...............................4
- 3.3. Minimalist Messages.....................................4
- 3.4. Built-In Record Caching.................................5
- 4. Inherent Design Limitations................................5
- 4.1. Domain Name Length......................................5
- 4.2. Ambiguity...............................................5
- 4.3. Incomplete Answer Sets..................................6
- 4.4. Lookups Only............................................6
- 4.5. UDP and TCP Restriction.................................7
- 4.6. Compression.............................................7
- 4.7. Cache Overflow..........................................8
- 4.8. Cache Lag...............................................8
- 4.9. World-Readable Data.....................................9
- 5. Design Conclusion.........................................10
- 6. Going Standards-Track.....................................10
- 7. Security Considerations...................................11
- 8. IANA Considerations.......................................11
- 9. Author's Address..........................................11
- 10. Normative References......................................11
- 11. Acknowledgments...........................................11
- 12. Full Copyright Statement..................................11
-
- 1. Introduction
-
- In terms of deployment, the Domain Name System (DNS) [STD13] is an
- extremely successful network service, having perhaps the widest
- installed base and usage of any Internet service. Unfortunately,
- this omnipresence makes DNS a favorite target for well-intentioned
- but often-misguided efforts to extend the service into roles it is
- unsuited for, particularly due to its specialized nature. This
- document attempts to itemize the issues which prevent this
- expansion so that future developers and planners can be made aware
- of the limitations early in the development cycles.
-
- Note that this document does not define any formal rules or
- restrictions of any kind. Instead, the sole purpose of this
- document is to itemize the common reasons why various extension
- efforts have been rejected by the DNS community in the past, and
- why other efforts may be rejected in the future. It is entirely
-
- Hall I-D Expires: December 2003 [page 2] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
- possible for a usage model to be embraced by the DNS community
- even though all of the principles listed within this document are
- violated (although it is extremely unlikely), and as such, this
- document should not be considered as a governing device of any
- kind. Instead, this document should only be viewed as a planning
- aid for developers and planners to use when considering the
- creation of new uses for the DNS.
-
- 2. Prerequisites and Terminology
-
- Readers of this document are expected to be familiar with the
- following specifications:
-
- [RFC1034] Mockapetris, P. "Domain names - concepts and
- facilities", STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P. "Domain names - implementation
- and specification", STD 13, RFC 1035, November
- 1987.
-
- [RFC1123] Braden, R. "Requirements for Internet Hosts -
- Application and Support", STD 3, RFC 1123,
- October 1989.
-
- [RFC2181] Elz, R., and Bush, R. "Clarifications to the
- DNS Specification", RFC 2181, July 1997.
-
- 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. DNS Architectural Principles
-
- The current collection of DNS specifications define a lightweight
- lookup service which provides anonymous access to structured
- information about named entries from distributed database
- partitions ("zones"). The service is specifically optimized for
- "lookup by name" datagram transactions, distributed caches of
- previous lookup answer sets, and non-authenticated access.
-
- 3.1. Resource Records
-
- All data stored in DNS uses a common record format, consisting of
- six common fields (although one of these fields is a generic
- "data" field which varies in size and shape according to the type
- of data being provided). Four of these fields ("domain name",
-
- Hall I-D Expires: December 2003 [page 3] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
- "type", "class" and "data") provide attributes which collectively
- form a unique identifier for a piece of data. Any three of these
- four fields may be identical across multiple resource records; for
- example, multiple resource records may exist with the same domain
- name, type and class, but they must have different data values in
- order to represent unique records within the global DNS.
-
- For the purposes of this document, the most important of these
- fields is the domain name field, which provides a non-unique
- identifier for every record in the database. All queries must
- explicitly identify the domain name of the entry they are looking
- for, and may optionally specify the desired type and/or class
- values. If a query results in multiple matches, then all of the
- matching records must be returned.
-
- 3.2. Hierarchical Partitioning
-
- From a high-level perspective, the DNS database is distributed
- across multiple partitions called "zones", each of which have
- ownership for a specific subset of domain names. Zones are linked
- in a hierarchical tree, with the top-level zones having zones
- directly beneath them, and with some of those having additional
- subordinate zones, and so forth. Although the zones are structured
- in a hierarchical tree, each zone acts as an independent entity,
- and is only concerned with the records that it controls directly.
-
- The hierarchical partitioning structure is traversed whenever the
- DNS protocol needs to locate the zone which is authoritative for a
- named resource record. When a resolver asks for the resource
- records associated with a specific domain name, the zone hierarchy
- is followed until either an answer or an error is returned. In
- this regard, the domain name of a resource record provides a
- lookup key which is used by the protocol to navigate the zone
- structure itself.
-
- 3.3. Minimalist Messages
-
- The DNS protocol uses a binary message format which is designed
- specifically for lookup transactions. There are very few spurious
- bits or fields in the DNS message (there is no "version" field,
- for example). Among these optimizations are protocol-specific
- compression techniques which reduce message sizes, and the
- preferential use of UDP datagrams for the lookup transactions.
-
-
- Hall I-D Expires: December 2003 [page 4] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
-
- 3.4. Built-In Record Caching
-
- Further contributing to the lookup-centric design objective, DNS
- resolvers and servers are allowed to cache resource records that
- they have discovered, so that subsequent queries for duplicate
- data may be retrieved without having to reissue a complex query.
-
- 4. Inherent Design Limitations
-
- As a result of the highly-optimized lookup model, DNS has several
- critical built-in limitations. For example, DNS does not provide
- any functions to "search by value", nor does it provide any sort
- of mechanisms for cache-overrides, user authentication, access
- control services, nor most of the other mechanisms that are
- typically associated with richer (and slower) distributed
- directory or database services.
-
- Although DNS could be extended to accommodate some of these
- usages, such an effort would require a significant amount of
- design effort, and would likely require a complete redeployment of
- the associated software agents. Furthermore, there is a
- significant danger of overloading DNS with excessive features and
- data such that the service itself would be incapable of performing
- lightweight lookups for named entries quickly and efficiently.
-
- 4.1. Domain Name Length
-
- Domain names are restricted to a maximum length of 255 characters.
- Since a domain name is the primary identifier for a resource
- record -- and since the domain name of a record also identifies
- the zone where a record is stored -- the length of a domain name
- is can be a significant restriction.
-
- For example, a resource record in a zone that is nested several
- layers deep may have to be significantly shorter than a domain
- name for the same kind of resource record in a top-level hierarchy
- to comply with the length restriction. As a result, data models
- which require application-specific labels or sequences can be
- problematic for some users and should generally be avoided.
-
- 4.2. Ambiguity
-
- Although resource records provide six common fields, only three of
- these fields can be specified in a lookup query (domain name,
- record type, and network class). However, if multiple resource
-
- Hall I-D Expires: December 2003 [page 5] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
- records exist with identical values for these fields (but with
- different values in the data field), then all of those records
- will be returned. As such, it is not possible to explicitly
- request an exact resource record from among a set, unless only one
- instance of that record type exists at that domain name.
-
- However, it is not possible to guarantee that a particular
- resource record type will only exist in the singular form at any
- given time. Although it is possible to demand that administrators
- "MUST NOT" enter a particular resource record more than once for
- any domain name, such demands are at the whims of the systems in
- the query path, and are generally unenforceable.
-
- In short, it is not possible to guarantee that a newly-defined
- resource record will only exist in the singular form. Data models
- which depend on singular instances of a particular record should
- be designed with this issue in mind.
-
- 4.3. Incomplete Answer Sets
-
- Just as it is not possible to extract a single resource record
- from a set, it is not always possible to be sure that you will
- receive all of the resource records in a set. Specifically, the
- original DNS specifications allowed each resource record in a set
- to have different time-to-live values, and this allowed (in
- theory) each record in the set to be aged out of a cache at
- different times. Furthermore, there have been some bugs in some
- implementations which resulted in incomplete answer sets being
- sent and subsequently cached by other nodes.
-
- Although these problems have mostly been addressed over time, it
- is still not possible to guarantee with absolute certainty that
- all of the records in a set will always be returned. Data models
- which depend on spreading answer data over multiple resource
- records in a set should be designed with this in mind.
-
- 4.4. Lookups Only
-
- DNS currently only provides a lookup query, using the domain name
- of the query as an index value. DNS does not provide any queries
- which would allow a resolver to search all of the resource records
- in the entire distributed database for a data value, but instead
- only provides lookup queries which match against the three
- qualifier fields. Although the original DNS specifications did
- provide a mechanism to search a specific server for matching data-
-
- Hall I-D Expires: December 2003 [page 6] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
- values, this feature has never been widely deployed, and the
- capability has since been deprecated.
-
- In theory, it would be possible to create a super-index of all
- zones in the entire distributed database and search against that
- index, although nobody has built such an index so as-of-yet.
-
- Regardless, applications must be aware that all queries use the
- domain name as a lookup key, and it is not possible to search for
- resource records by their data-values.
-
- 4.5. UDP and TCP Restriction
-
- DNS messages which are sent over UDP have a maximum message size
- of 512 bytes. If a lookup results in an response message that
- exceeds this size, then the query process must be restarted using
- TCP. However, a DNS header restriction limits DNS message which
- are sent over TCP to a maximum message size of 65,535 bytes.
- Answer data that exceeds this threshold cannot be retrieved using
- DNS at all. In short, UDP overflows penalize performance, while
- TCP overflows cause the lookup process to fail entirely.
- Furthermore, not all servers support TCP, and in those cases, UDP
- messages which overflow the 512 byte limit will also be fatal.
-
- In those cases where falling back to TCP works as expected, there
- can be additional penalties apart from the longer setup time. For
- example, TCP session management typically consumes more resources
- than UDP datagrams, significantly limiting the number of queries
- which a server can process at any given time.
-
- For all of these reasons, planners and developers are strongly
- encouraged to limit resource record data to sizes that will not
- cause UDP overflow. In those cases where this is unavoidable, they
- should be prepared for a variety of problems, including
- performance issues and outright failure.
-
- 4.6. Compression
-
- The DNS specifications provide a compression mechanism which can
- be used to substitute label sequences with pointers to previous
- occurrences of those sequences. However, this mechanism only works
- with well-known resource records. New resource record types cannot
- make use of the pointer mechanism, since caches will not be aware
- of the resource record's data-structure, and therefore will not be
- able to tell that the data value is a domain name pointer which is
- supposed to reference some other sequence of labels.
-
- Hall I-D Expires: December 2003 [page 7] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
-
- This is an especially important consideration to keep in mind when
- considering large data structures; while it is tempting to believe
- that the domain name can be compressed, this simply is not true.
-
- 4.7. Cache Overflow
-
- Another issue related to data size is the amount of memory
- available to a particular cache. All caches have fixed amounts of
- available memory, and when that memory is consumed, some data will
- have to be expired from the cache. In these cases, the cache will
- have to query for the data again (causing performance penalties),
- and will then have to bump some other data from the memory pool in
- order to make room for the data again. In heavily loaded
- environments (such as a very busy ISP), this can result in a
- constant churning of the memory pool.
-
- This is obviously a good reason to limit the size of the resource
- records in use, but it is also a good reason for limiting the
- total number of resource records in use with a particular
- application. Since each entry will have to consume memory in a
- cache somewhere, excess records or excessively large records will
- both contribute to the potential for cache churning.
-
- 4.8. Cache Lag
-
- Since DNS is optimized for lookups, the use of intermediary and
- end-node caches allows lookups to be held in memory at a location
- that is "closer" to the user, which generally improves performance
- over having to follow a complex delegation chain for every query.
- However, caching can be somewhat hostile towards general-purpose
- database models, particularly in light of the fact that DNS
- provides no mechanisms for forcing a system to flush its cache of
- previously discovered records.
-
- In particular, caches prevent data from being validated against an
- authoritative source. While this is normally beneficial for lookup
- activities, it can be a devastating feature for data models that
- require data-integrity at all times. For example, a resource
- record which recorded the user who was currently logged on at a
- terminal might seem to be a useful feature, while cache lag would
- tend to make the data inaccurate more often than accurate, thereby
- making it useless for its intended purpose.
-
- Although DNS servers can dictate the length of time that a
- resource record is to be held in a cache, this feature depends on
-
- Hall I-D Expires: December 2003 [page 8] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
- several additional requirements. Furthermore, data models which
- require the use of low time-to-live settings are generally frowned
- upon by the DNS community, as these resource records place a
- disproportionate burden on the lookup infrastructure. For these
- reasons, DNS is inappropriate for data models which require full-
- time and instantaneous data integrity.
-
- 4.9. World-Readable Data
-
- DNS does not provide any mechanisms for authenticating users
- during the lookup process, nor does it provide any standardized
- mechanisms for linking access controls to a resource record.
- Without these features, DNS is unsuitable for queries which
- require authenticated access on a per-user basis.
-
- For example, if an application wanted to store contact information
- for employees in DNS, access to the data would likely be
- restricted to certain people (perhaps allowing the general public
- to see some level of anonymous data, while allowing internal
- personnel to see greater levels of detail, while allowing the
- supervisor to see all of the data). However, this model requires
- user-specific authentication for each lookup process, and it also
- requires that each resource record have an attribute list that
- determined who was allowed to see the data.
-
- However, DNS does not provide any mechanisms for providing
- authentication within the lookup process. Furthermore, such an
- effort would require a massive undertaking, which is not very
- likely given that there are many other protocols already in place
- which already provide similar mechanisms. Similarly, the DNS
- protocol does not provide any mechanisms for storing and
- exchanging access lists along with resource records. Adding this
- information to the standardized resource record structure is not a
- simple task, and would likely result in a substantial increase in
- message overflow.
-
- Although some DNS servers currently provide mechanisms for
- restricting access based on qualifiers such as the IP address of
- the client, it is important to point out that once the resource
- records get into a cache outside of the protected scope, the
- information is only as secure as that cache. In this regard, a
- caching server that resides outside of a firewall can be just as
- informative as the DNS servers inside the firewall. In the end,
- there is no such thing as "private" information with DNS. All data
- which is stored in DNS should be treated as if it were public
- data, visible to all users.
-
- Hall I-D Expires: December 2003 [page 9] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
-
- 5. Design Conclusion
-
- Due to the architectural tradeoffs inherent in the DNS lookup
- model, some usage models are better suited to DNS than others. In
- particular, DNS is highly efficient at lookups of compact, public
- and relatively stable data. Conversely, DNS is unsuitable for
- value-based queries or searches, restricted-access data, highly-
- dynamic data, or large records and arrays.
-
- For usage models which require access to those kinds of data,
- application protocols such as LDAP or HTTP would be more
- appropriate, and would provide greater rewards.
-
- 6. Going Standards-Track
-
- Generally speaking, planners and developers can usually define
- their own resource record types as part of another standards-track
- specification without interference from the DNS community as long
- as the functional scope is limited to defining data-structures for
- those resource record types. However, there are some cases where
- it may be useful or necessary for the DNS community to be involved
- with the standardization process.
-
- In particular, if a DNS resource record type requires a server to
- perform some kind of extra processing beyond echoing resource
- record data from a database into a message, then the DNS community
- should be consulted. For example, requiring that servers provide
- additional data outside the answer section of the response message
- should be vented with the community.
-
- Similarly, if a specification requires special structuring of the
- message for the benefit of a single service, then the DNS
- community should definitely be involved in the discussion, since
- any changes to the highly-optimized (binary) message format could
- be disastrous in non-obvious ways.
-
- Requests to reserve portions of the namespace for the use of a
- single network service should also be brought to the DNS community
- for discussion.
-
- Finally, if a resource record goes against more than two of the
- good-use guidelines put forth throughout this document, then it
- would probably be a good idea to consult with the DNS community
- over any alternatives which may be available.
-
-
- Hall I-D Expires: December 2003 [page 10] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
- In all cases, IANA must be involved in delegating resource record
- type codes and mnemonics.
-
- 7. Security Considerations
-
- This document does not create any security considerations.
-
- 8. IANA Considerations
-
- This document does not create any IANA considerations.
-
- 9. Author's Address
-
- Eric A. Hall
- ehall@ehsco.com
-
- 10. Normative References
-
- [RFC1123] Braden, R. "Requirements for Internet Hosts -
- Application and Support", STD 3, RFC 1123,
- October 1989.
-
- [RFC2181] Elz, R., and Bush, R. "Clarifications to the
- DNS Specification", RFC 2181, July 1997.
-
- [STD13] Mockapetris, P. "Domain names - concepts and
- facilities", STD 13, RFC 1034 and "Domain
- names - implementation and specification", STD
- 13, RFC 1035, November 1987.
-
- 11. Acknowledgments
-
- Funding for the RFC editor function is currently provided by the
- Internet Society.
-
- Edward Lewis provided valuable feedback during the development of
- this document.
-
- 12. 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
-
- Hall I-D Expires: December 2003 [page 11] \f
- Internet Draft draft-hall-dns-data-00.txt May 2003
-
-
- 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.
-
-
- Hall I-D Expires: December 2003 [page 12] \f
+++ /dev/null
-
-
- INTERNET-DRAFT Eric A. Hall
- Document: draft-hall-dns-datatypes-00.txt June 2002
- Expires: December 2002
-
-
- Domain Name Data-Types
-
-
- Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
-
- 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.
-
-
- 1. Abstract
-
- This document defines syntax and structural rules for a namespace
- of internationalized domain names, and also clarifies the syntax
- and structural rules for the existing DNS namespace. Furthermore,
- this document defines syntax and structural rules for specific
- types of labels and domain names, and also defines usage rules for
- specific resource records within the domain name system. This
- document specifically does not describe any mechanisms for
- interacting with these namespaces, domain names or resource
- records, but instead focuses exclusively on the syntax and
- structural rules.
-
-
-
-
-
-
- \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- Table of Contents
-
- 1. Abstract.................................................1
- 2. Introduction.............................................3
- 3. Background and Overview..................................3
- 4. The Namespaces...........................................7
- 4.1. The Class IN Hierarchy.................................7
- 4.2. The DNS Namespace......................................9
- 4.2.1. Length Restrictions in the DNS Namespace.............9
- 4.2.2. Characters Restrictions in the DNS Namespace........10
- 4.2.3. The DNS Namespace Escape Syntax.....................11
- 4.3. The Internationalized Namespace.......................13
- 4.3.1. Length Restrictions in the i18n Namespace...........14
- 4.3.2. Character Restrictions in the i18n Namespace........15
- 5. The DNS Data-Types......................................16
- 5.1. Syntax Validation.....................................16
- 5.2. Defining New Data-Types...............................17
- 5.3. The Root Label and Domain Name........................18
- 5.4. The Hostname Labels and Domain Names..................19
- 5.4.1. Legacy Hostnames....................................19
- 5.4.2. Internationalized Hostnames.........................20
- 5.5. The Octet Label and Domain Name.......................21
- 5.6. The Mailbox Labels and Domain Names...................22
- 5.6.1. Legacy Mailboxes....................................23
- 5.6.2. Internationalized Mailboxes.........................24
- 5.7. The Service Locator Labels and Domain Names...........24
- 5.7.1. Legacy Service Locators.............................24
- 5.7.2. Internationalized Service Locators..................25
- 6. Resource Records and Query Types........................25
- 6.1. Resource Records......................................25
- 6.2. Query Types...........................................34
- 7. Security Considerations.................................35
- 8. IANA Considerations.....................................35
- 9. References..............................................36
- 10. Acknowledgements........................................38
- 11. Author's Address........................................39
-
-
-
-
-
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 2] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- 2. Introduction
-
- The IDN working group has been developing mechanisms for
- supporting and interacting with internationalized domain names,
- although a prerequisite to the completion of any such work is the
- description of the internationalized namespace itself. During this
- work, it has also been determined that certain clarifications to
- the existing DNS namespace are also necessary.
-
- Encodings, protocols and other mechanisms for accessing domain
- names and resource records within the internationalized namespace
- are purposefully not described in this document.
-
- Discussion of this document and related work items is currently
- being held on the "idn@ops.ietf.org" mailing list. To join the
- list, send a message to <idn-request@ops.ietf.org> with the single
- word "subscribe" in the body of the message.
-
- Subsequent versions of this draft will be brought to DNSEXT for
- standards-track development, and will be discussed on the
- "namedroppers@ops.ietf.org" mailing list. To join that list, send
- a message to <namedroppers-request@ops.ietf.org> with the single
- word of "subscribe" in the body of the message.
-
-
- 3. Background and Overview
-
- The Internet (and the ARPANET before it) has had a formal
- namespace of network resources since RFC 608 [RFC608]. Over the
- years, however, the syntax rules associated with the global
- namespace have been changed, with various updates and
- clarifications being provided in RFC 810 [RFC810], RFC 882
- [RFC882], RFC 952 [RFC952], RFC 1034 [RFC1034], RFC 1123 [RFC1123]
- and RFC 2181 [RFC2181], with each revision expanding upon the
- namespace syntax to accommodate a more flexible usage model.
-
- The original namespace of network resources defined in [RFC608]
- used a flat HOSTS.TXT database as a simple list of systems and
- their network addresses, using a limited subset from the seven-bit
- US-ASCII charset [ASCII] for the system names. Essentially, the
- database format was the namespace, with all network services using
- this one-dimensional namespace for the purpose of specifying
- systems by name, regardless of whether these hostnames were used
- for intra-protocol services or for subsequent lookup operations.
-
-
-
- Hall I-D Expires: December 2002 [page 3] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- The format of the underlying database (and thus the namespace) was
- redefined by [RFC810] to reflect the coexistence of ARPANET and
- Internet networks and nodes, redefined again by [RFC952] to allow
- for multi-label hostnames, and updated in [RFC1123] to slightly
- expand the allowable character repertoire. Throughout these
- revisions, the syntax of the namespace was changed somewhat,
- although it continued to be one-dimensional in nature, reflecting
- the limitations of the underlying HOSTS.TXT database file.
-
- Once the Domain Name System (DNS) specifications were published
- (first in [RFC882] and RFC 883 [RFC883], then later in [RFC1034]
- and RFC 1035 [RFC1035]), the database of network resources and the
- hostname syntax separated into distinct entities. Although DNS
- uses an eight-bit syntax internally and allows any of the eight-
- bit codepoint values to be used for any purposes, most
- applications and protocols restrict their usage of the namespace
- to well-known data-types which only use subsets of the available
- namespace. This has resulted in a distinctly layered namespace,
- where applications and protocols use the data-type subsets, while
- the DNS itself uses the full range of characters.
-
- For example, [RFC1034] states that "the old rules for HOSTS.TXT
- should be followed" for domain names which reference host systems,
- and most of the application protocols have followed this advice.
- For all practical purposes, this means that the legacy hostname
- syntax is implicitly a strong data-type with formal syntax rules,
- even though it only represents a subset of the global DNS
- namespace. Meanwhile, a variety of protocol-specific data-types
- have also been defined for network resources which are not hosts,
- and these data-types have also been implemented by applications
- which work with those kinds of resources.
-
- In the end, the DNS namespace essentially exists as two separate
- layers, with the namespace at large being defined by the
- underlying DNS service, but with applications and protocols using
- the data-types and syntax rules which reflect their usage.
-
- Moving forward, the IDN working group has developed an
- internationalized namespace which uses characters from the
- Universal Character Set (UCS) [ISO-10646] (a.k.a. Unicode
- [UNICODE])]. Note that the UCS (and thus the namespace) only
- defines characters and their logical codepoint values, while
- external codecs are required to encode the canonical UCS
- characters into sequences which are suitable for specific
- environments. As such, the canonical UCS characters cannot be
-
-
-
- Hall I-D Expires: December 2002 [page 4] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- exchanged in their raw form, but instead can be only exchanged in
- their encoded form.
-
- Furthermore, there are no characters in the UCS character
- repertoire for "octet value 0xHH", so the internationalized
- namespace cannot directly support the eight-bit values used in the
- DNS namespace. For these reasons, the internationalized and DNS
- namespaces have to be defined and managed separately, with the
- internationalized namespace representing logical UCS characters,
- and with the DNS namespace representing raw and uninterpreted
- eight-bit values. However, these namespaces can coexist within the
- class IN database hierarchy as long as the underlying domain names
- are encoded in a compatible and consistent form. At that point,
- the only substantive difference between the two namespaces is in
- the canonical characters which are used by the presentation-layer
- namespaces at large.
-
- Cumulatively, this means that the internationalized namespace
- operates at three distinct layers. First of all, applications and
- protocols have to choose an internationalized data-type which is
- capable of supporting the characters they need for their domain
- names, while the protocols also have to choose the encoding
- formats they will use for the domain names that they exchange.
- Meanwhile, the end-system applications may need to use another
- encoding format whenever they map these domain names to the
- available lookup service(s).
-
- | HOSTS.TXT | DNS Names | IDNs |
- --------------+---------------+---------------+---------------+
- Application | database | protocol | data-type |
- Presentation | subset | subset | specific |
- | | | (UCS range) |
- --------------+---------------+---------------+---------------+
- Protocol | database | data-type | protocol |
- Transfer | subset | specific | encoding |
- | | (7- or 8-bit) | (7- or 8-bit) |
- --------------+---------------+---------------+---------------+
- Subsequent | HOSTS.TXT | 8-bit DNS | 8-bit DNS |
- Lookups | subset | or HOSTS.TXT | or HOSTS.TXT |
- | | subset | subset |
- --------------+---------------+---------------+---------------+
-
- Figure 1: Logical namespace layers and their representations.
-
- The different models which have been described in this section are
- illustrated in Figure 1 above. As can be seen, the hostname syntax
-
-
- Hall I-D Expires: December 2002 [page 5] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- defined for use with the HOSTS.TXT database essentially provided a
- monolithic and one-dimensional namespace for applications to use,
- while the DNS namespace provides multiple data-types for
- applications and protocols to use, with these data-types
- representing logical subsets of the underlying eight-bit
- namespace. Finally, the internationalized namespace also uses
- logical data-types for the applications and protocols, but also
- requires that protocols define encoding formats for the domain
- names they use internally, and for the domain names they pass to
- the underlying lookup services.
-
- Collectively, there are a variety of different data elements
- discussed above which require definitions or clarifications.
- Originally, this document was only meant to provide definitions
- for the internationalized namespace and its associated data-types,
- although several issues with the DNS namespace and data-types have
- also been encountered which require clarifications and definitions
- of their own. In particular, since the internationalized namespace
- is unable to use the eight-bit codepoint values from the DNS
- namespace, the legacy hostname data-type must be defined with an
- explicit syntax and its usage must be restricted to specific
- scenarios in order for those domain names to be accessible from
- the internationalized namespace. Subsequently, this requires that
- DNS resource records also be redefined to use the data-types which
- are appropriate to the data they represent, thereby ensuring that
- host resources in the common hierarchy are always accessible to
- both namespaces.
-
- On the surface, some of this work may appear to be a reversal of
- existing standards, since the DNS specifications and the
- clarifications made in [RFC2181] explicitly allow eight-bit
- codepoint values to be used with any domain name. In truth,
- however, this redefinition is a codification of existing practices
- and recommendations. Specifically, this document encourages
- applications to define their own data-types and syntax rules when
- needed but also requires that the common hostname syntax be
- supported in those places where hosts are specifically referenced,
- which is essentially a restatement of the [RFC1034] requirements.
-
- The only real difference here is that this document also requires
- that resource records be explicitly restricted to use the
- appropriate data-types, rather than being allowed to diverge at
- will. While this is a reversal of policy as defined in [RFC2181],
- this is necessary in order to ensure basic interoperability across
- the different namespaces, and is also necessary in order to
-
-
-
- Hall I-D Expires: December 2002 [page 6] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- prevent basic interoperability problems from developing due to
- fragmentation of the class IN hierarchy.
-
-
- 4. The Namespaces
-
- Conceptually, the DNS namespace and the internationalized
- namespace are separate, in that they allow for different ranges of
- characters, with the namespaces containing different identifiers.
- However, both of the namespaces reside in the class IN hierarchy
- and share a common root in that class, and are effectively the
- same namespace when the identifiers have been encoded into a
- compatible and consistent form.
-
- Applications and protocols which specifically utilize any of the
- data-types defined in this document MUST conform to the syntax
- rules associated with the parent namespace for that data-type. For
- example, if an application specifically claims to support the
- internationalized hostname data-type then that application MUST
- conform to the requirements associated with the internationalized
- namespace at large, while applications which claim to conform to
- the legacy mailbox data-type MUST conform to the requirements of
- the DNS namespace.
-
- If a protocol supports some other external namespace (such as LDAP
- directories), then the syntax rules for that protocol SHOULD
- define specific handling rules which clearly state how that
- protocol will use each of the namespaces defined here.
-
-
- 4.1. The Class IN Hierarchy
-
- The IN class use a hierarchical structure, where each domain name
- is represented by a series of labels, and where the entire
- sequence of labels represents a globally-unique domain name in the
- hierarchy. Essentially, the IN class hierarchy represents the
- database portion of the DNS, and therefore represents the storage,
- transfer and processing services which are used to construct the
- DNS namespace. Note that the namespace syntax (such as length and
- character restrictions) is discussed separately in section 4.2.
- Also note that alternative classes may have their own structural
- rules which are different from those used in the IN class.
-
- When a domain name from the IN class is used in the DNS, the
- constituent labels are typically treated as binary sequences (but
- not always), with each label being prefaced by a length indicator.
-
-
- Hall I-D Expires: December 2002 [page 7] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- The labels are ordered from right-to-left, with the least-specific
- label at the right edge of the domain name, and with the most-
- specific labels at the left edge. The right-most label will have a
- length indicator with the value of zero (it is truly a null
- label), and represents the root of the class IN hierarchy which is
- by definition the least-specific label in the hierarchy.
-
- When a domain name is used for lookups, the entire sequence of
- labels act as a lookup key against a globally-distributed
- hierarchy of database partitions and their leaf-nodes. Some or all
- of the labels will identify a specific database partition in the
- hierarchy, while any remaining labels will identify a particular
- leaf-node within a partition. As a lookup is processed, the input
- domain name is matched against the contents of the current
- partition, with the results of this comparison operation either
- being a referral to another partition, an answer, or an error. If
- a referral is returned, the matching process is restarted at the
- referenced partition, with this process repeating until either an
- answer or an error is returned.
-
- Domain names from the DNS namespace which are written out in
- longhand form are usually written as character sequences, with the
- labels typically being separated by a Full-Stop character (0x2E)
- from [ASCII]. When used with longhand domain names in the
- internationalized namespace, the separator mark is either a
- trailing Full-Stop (U+002E), an Ideographic Full-Stop (U+3002), an
- Ideographic Full-Width Full-Stop (U+FF0E), or an Ideographic Half-
- Width Full-Stop (U+FF61) from the UCS. When any of the ideographic
- forms are used, they MUST be converted to the traditional Full-
- Stop character when the domain name labels are normalized, and
- MUST NOT be exchanged with other applications or protocols in
- their provided form.
-
- Although the separator frequently appears to represent the length
- indicators in the domain name system, this is not always true. For
- example, domain names which are written out in longhand form do
- not typically use a Full-Stop character at the beginning of the
- domain name to represent the length indicator from the first
- label, nor do they typically provide a trailing Full-Stop
- character to represent the root of the hierarchy.
-
- Outside of the domain name system, domain names are typically
- treated as simple identifiers, with no database context being
- implied. Humans normally treat domain names as simple identifiers
- of named network resources, without concern for the leaf-node or
- partitions which may be referenced. Meanwhile, most applications
-
-
- Hall I-D Expires: December 2002 [page 8] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- and protocols also treat domain names as simple identifiers,
- although many of them apply syntactical analysis to the domain
- name before performing any additional processing (even in these
- situations, however, the domain name will not normally be analyzed
- for database context).
-
- Note that a one-to-one match between labels, partitions and leaf-
- nodes is neither required nor implied. Multiple labels may be used
- to refer to a partition or a leaf-node, as desired. In most cases,
- the specific database context of a domain name cannot be
- determined without querying DNS directly.
-
-
- 4.2. The DNS Namespace
-
- These rules represent the allowable syntax of all domain names
- within the IN class hierarchy as defined by [RFC1034] and
- [RFC1035]. Alternative classes may define their own namespaces and
- rules. Subsets of these rules are defined for specific labels and
- domain names in section 5. The rules provided in this section
- specifically apply to the DNS namespace at large, and do not
- define any formal data-types.
-
-
- 4.2.1. Length Restrictions in the DNS Namespace
-
- A label from the DNS namespace is restricted to a minimum of one
- octet and a maximum of 63 octets, inclusive.
-
- A domain name from the DNS namespace is restricted to a minimum of
- one octet and a maximum of 255 octets, inclusive. Any number of
- labels may be provided in a domain name, but the maximum length
- restriction MUST NOT be exceeded.
-
- Note that many delegation bodies have defined their own minimum
- length rules for their zones. For example, the historic generic
- top-level domains (such as com, net and org) require a minimum of
- two characters for all immediate delegations, while some of the
- newer generic TLDs have three- and four-character minimums. Since
- these rules only affect the delegations within those zones (and
- not the subordinate delegations from the child zones), this usage
- is not in conflict with any of the other rules defined in this
- document, and is expressly allowed.
-
- Whenever a domain name is written in longhand form, it SHOULD be
- restricted to a maximum length which allows a direct conversion to
-
-
- Hall I-D Expires: December 2002 [page 9] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- the DNS format. In particular, a longhand domain name SHOULD allow
- a length indicator to be added to the first label in the DNS
- domain name, and SHOULD allow a length indicator to be added to
- the end of the domain name (representing the root domain), if
- necessary. In the common case, a longhand domain name will only
- allow for 253 octets of data so that it can be directly converted
- to the DNS format.
-
- If a longhand domain name uses the escape syntax described in
- section 4.2.3, the allowable length of the longhand domain name
- MAY be extended to accommodate the escape sequence, since a multi-
- byte escape sequence will generally collapse to a single octet in
- the DNS message.
-
- Applications and protocols which need to specify the root domain
- explicitly MUST allow a single Full-Stop character to be specified
- in the longhand domain name for this purpose. Other application-
- or protocol-specific syntaxes MAY also be supported for this
- purpose, if necessary. Note that this usage is not required to be
- supported unless the application needs to explicitly reference the
- root domain for some purpose, but since the root domain is not
- addressable as a host system, this is not a common scenario.
-
-
- 4.2.2. Characters Restrictions in the DNS Namespace
-
- The lower seven-bit range of values (0x00 through 0x7F) from the
- DNS namespace MUST be interpreted as characters from [ASCII].
-
- The eight-bit range of values (0x80 through 0xFF) are defined in
- [RFC1034] as opaque octets, with no default character assignments.
- Therefore, eight-bit values from the DNS namespace MUST NOT be
- interpreted as any specific charset, characters or encoding, and
- SHOULD NOT be rendered as such unless the protocol in use has
- defined a specific data-type which explicitly states otherwise.
-
- When a domain name from the DNS namespace is stored, transferred
- or compared, the capitalization of the [ASCII] characters in that
- domain name MUST be preserved as they were provided to the current
- operation. Secondarily, whenever two domain names from the DNS
- namespace are compared, the [ASCII] characters in the domain names
- MUST be treated as case-neutral for the purposes of comparison.
-
- Note that these rules combine such that the capitalization of the
- input domain name will be preserved across a search operation. For
- example, the search input of "A.example.COM" MUST match the stored
-
-
- Hall I-D Expires: December 2002 [page 10] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- domain name of "a.EXAMPLE.com", and the capitalization of the
- input domain name MUST be used for the resulting output. However,
- if the queried domain name referenced "HOST.c.EXAMPLE.net", that
- domain name MUST be provided in its original capitalization.
-
- In those scenarios where the input and output domain names are
- different but they exist in the same branch of the class IN
- hierarchy, the secondary references to the common domains MUST
- inherit the capitalization of the input domain name. For example,
- if the search input of "A.example.COM" matches with
- "a.EXAMPLE.com" but that domain name only exists as an alias for
- the domain name of "HOST.b.EXAMPLE.com", then the output domain
- name MUST be provided as "HOST.b.example.COM", with the
- capitalization of the input domain name being used to construct
- the overlapping domain names in the output.
-
- These rules guarantee that the output from the compression
- algorithm defined in [RFC1035] is always valid. Unless a protocol
- specifically states otherwise, these rules MUST be followed for
- all applications and protocols which use domain names and labels
- from the DNS namespace as specific data.
-
-
- 4.2.3. The DNS Namespace Escape Syntax
-
- Although DNS uses raw eight-bit codepoint values, less than half
- of the codepoint values have defined character equivalents from
- [ASCII] which can be rendered, which means that most of the
- codepoint values cannot be written in a longhand domain name which
- supports those values.
-
- For example, the octet label data-type supports 256 possible
- codepoint values (0x00 through 0xFF), while the mailbox label
- data-type supports all 128 of the seven-bit character codes
- defined in [ASCII] (0x00 through 0x7F), but only the printable
- subset of characters from [ASCII] have defined character
- representations (0x21 through 0x7E). As such, longhand domain
- names which use these data-types are generally restricted to the
- printable subset.
-
- Furthermore, some of these domain names make use of characters
- which are "confusing" to applications and/or their resolvers. For
- example, many email addresses make use of the Full-Stop character
- within the local-part element, although this character can easily
- be misinterpreted as a label separator rather than an embedded
- Full-Stop character.
-
-
- Hall I-D Expires: December 2002 [page 11] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- [RFC1035] defined a syntax for escaping these characters within
- the zone database, but it does not require (nor imply) that this
- mechanism should be supported in other applications, with the
- result being that most of these applications do not adequately
- support the necessary syntax. This document corrects this
- shortcoming by requiring that any application which supports the
- octet label or mailbox label data-types MUST allow longhand domain
- names to use the escaping syntax defined herein.
-
- Note that these syntax rules only apply to the octet label and
- mailbox label data-types. The remaining data-types have tighter
- character ranges, and do not contain characters which require
- escaping. Furthermore, applications MUST NOT allow these other
- data-types to use the escaping syntax whatsoever, as this could
- result in unexpected characters being inserted into the label or
- domain name, thereby triggering unexpected failures in other
- applications or systems.
-
- The escape syntax uses the Reverse-Solidus (0x5C) character as an
- escape flag, with this flag preceding a printable [ASCII]
- character or a three-digit decimal value for a specific codepoint
- value. For example, if a label contains an embedded Full-Stop
- character, that character may be escaped as either "\." or "\046"
- (where "46" is the decimal value of the Full-Stop character's
- codepoint value from [ASCII]).
-
- This escape syntax MUST be used to encapsulate Full-Stop (0x2E),
- Reverse-Solidus (0x5C), Double-Quote (0x22), a non-printing
- character from [ASCII] (0x00 through 0x20, or 0x7F) or any of the
- eight-bit codepoint values (0x80 through 0xFF) whenever one of
- these domain names is written in longhand form. Protocols which
- exchange the octet or mailbox data-types as textual data MUST
- support the use of this escaping syntax within that data. Other
- application- or protocol-specific syntaxes MAY also be supported
- for this purpose, if necessary.
-
- However, DNS messages MUST NOT contain the escape sequences, and
- MUST always use the raw octet value of the escaped character. As
- such, the escape syntax MUST be interpreted by an application or a
- resolver (depending on the resolver's capabilities) before these
- characters are passed into DNS.
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 12] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- 4.3. The Internationalized Namespace
-
- These rules represent the allowable syntax of all domain names
- within the internationalized IN class namespace. Alternative
- classes may define their own namespaces and rules. Subsets of
- these rules are defined for specific labels and domain names in
- section 5. Conversely, the rules provided in this section apply to
- the internationalized namespace at large, and do not define any
- formal data-types.
-
- Note that the internationalized namespace is a logical namespace,
- and does not exist in the same way that the DNS namespace exists.
- Instead of being a direct mapping to the underlying database, the
- internationalized namespace is defined as a range of UCS character
- codes which may be accessed or represented with any of several
- different encoding mechanisms.
-
- Mechanisms which have been discussed for this purpose include
- codecs that convert the UCS character codes into seven-bit [ASCII]
- sequences compatible with the legacy hostname syntax, UCS transfer
- encodings such as UTF-8, and legacy charsets which can be mapped
- to the UCS repertoire. Any of these mechanisms (or any others) can
- be used to represent, store, transfer and compare domain names in
- the internationalized namespace, as is necessary for the
- application or protocol at hand.
-
- For example, an internationalized protocol may use UTF-8 domain
- names as protocol data or arguments, although it may be necessary
- to convert a domain name into a hostname-compatible encoding
- whenever a lookup operation is performed. In this scenario, the
- logical internationalized namespace will be accessed through two
- different mechanisms, although the canonical domain name will
- still be represented as the UCS characters. Similarly, conversion
- between two or more access mechanisms will likely require an
- intermediate conversion to UCS first, and in this regard, the
- canonical UCS characters will represent the logical namespace.
-
- Note that this document does not define or describe any codecs or
- namespace-access mechanisms. However, these different mechanisms
- have affected the structure and syntax rules of the
- internationalized namespace at large.
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 13] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- 4.3.1. Length Restrictions in the i18n Namespace
-
- For the purposes of defining boundary conditions, a label in the
- internationalized namespace is restricted to a minimum of one UCS
- character and a maximum of 63 UCS characters, while a domain name
- in the internationalized namespace is restricted to a maximum of
- 255 UCS characters, inclusive. Note that this rule specifically
- refers to the canonical UCS characters, rather than any encoded
- form. Encoding will often result in labels and domain names with a
- fewer or greater number of octets, depending on the encoding
- algorithm in use. For example, an application which uses UCS-4 to
- represent internationalized domain names will require 32 bits for
- each UCS character, while an application which uses UTF-8 can
- require up to 48 bits for each character.
-
- The canonical UCS characters will frequently require conversion
- into a transfer encoding which will be subject to its own length
- requirements. For example, the ASCII-compatible encoding mechanism
- defined in [PUNYCODE] and [IDNA] is subject to the length
- restrictions inherent in the DNS namespace. Although all encodings
- have their own requirements, [IDNA] is the only encoding which is
- known to have hard limits beyond its control. As such, labels in
- the internationalized namespace MUST be restricted to lengths
- which can be encoded in their [IDNA] encoded form, with the
- resulting sequence being limited to the DNS namespace restrictions
- defined in section 4.2.1. This rule MUST be enforced regardless of
- any other codecs or access mechanisms which may be available that
- offer larger sizes.
-
- These rules combine so that an application can restrict the input
- of a label or domain name (such as in a form) to a certain number
- of characters, but once the internationalized domain name has been
- provided and normalized into its canonical form, any subsequent
- verification of that domain name MUST ensure that the [IDNA]
- encoded form of that domain name will comply with the DNS
- namespace limits, which is a maximum of 63 octets for a label, and
- 255 octets for a domain name.
-
- As with the DNS namespace, domain names written in longhand form
- MUST leave room for any omitted length indicators when these
- boundary conditions are tested. In particular, this includes the
- length indicator at the beginning of the first label and the
- length indicator at the end of the domain name, both of which are
- frequently omitted from longhand domain names.
-
-
-
- Hall I-D Expires: December 2002 [page 14] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- 4.3.2. Character Restrictions in the i18n Namespace
-
- The logical internationalized namespace uses the entire UCS,
- including character codes which are currently unassigned.
- Currently the UCS occupies a 21-bit range of character code
- values, containing tens of thousands of assigned characters, and
- hundreds of thousands of unassigned characters, although this
- repertoire is expected to grow in size over time.
-
- Internationalized label and domain name data-types MUST declare
- their own specific ranges of supportable UCS characters, and MUST
- also define any normalization, case-conversion, and any other
- transformations which are needed for that data-type. The
- guidelines and rules for the development of these
- internationalized domain name data-types are provided in
- STRINGPREP [STRINGPREP].
-
- In the normal scenario, the data-type rules will result in labels
- and domain names containing case-specific, strongly-normalized UCS
- characters. As a result, the internationalized namespace is case-
- specific, meaning that all storage, transfer, comparison and
- conversion operations MUST always preserve the capitalization and
- normalization of the data as it is processed.
-
- Since the domain name provided to the original application can be
- significantly different from the domain name which is subsequently
- passed to the underlying protocol, the original domain name MUST
- NOT be provided to any other applications or protocols if at all
- possible. Note that certain situations are unavoidable, such as a
- user copying the hostname from a manually-entered URL into an
- email message, where the original sequence will not reflect any
- subsequent normalization. However, this type of bleed-over MUST
- NOT occur if it can be presented by an application with simple
- measures.
-
- If a label ONLY contains character codes from the seven-bit
- [ASCII] range of characters (U+0000 through U+007F), then that
- label MUST be treated as a legacy label from the DNS namespace for
- the purposes of comparison. In other words, labels which only
- contain seven-bit [ASCII] MUST be compared as case-neutral
- sequences, while all other labels MUST be compared as case-exact
- sequences. In all situations, the output capitalization MUST
- reflect the capitalization of the input domain name (since these
- labels will have been capitalized and normalized according to
-
-
-
- Hall I-D Expires: December 2002 [page 15] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- their domain name syntax rules, the answer data will also be
- provided in the appropriate form if this rule is always followed).
-
-
- 5. The DNS Data-Types
-
- As part of the efforts towards strongly defining strict data-
- types, this document defines syntax rules for different kinds of
- domain names and labels. Some of the domain name data-types will
- only contain labels of a single data-type, while some domain name
- data-types may contain multiple label data-types. For example, a
- legacy hostname domain name can only contain legacy hostname
- labels, while an internationalized service locator domain name can
- contain a mix of different label types.
-
- When one of the internationalized data-types is used with an
- internationalized protocol, one or more encoding syntaxes MUST be
- specified by the underlying protocol before the data can be
- exchanged in a meaningful form. Note that RFC 2277 [RFC2277]
- states that the preferred encoding for internationalized protocol
- data is UTF-8.
-
- When one of the internationalized data-types is used with a legacy
- protocol which only has explicit support for [ASCII], the
- internationalized data-type MUST be encoded into an ASCII-
- compatible form before the data can exchanged. The [IDNA]
- specification describes one such mechanism, and is the preferred
- encoding form whenever legacy protocols are required to be used.
-
-
- 5.1. Syntax Validation
-
- Each label in a domain name has specific syntax rules which
- reflect on the data provided in that label. Therefore,
- applications which validate domain names against a particular
- data-type SHOULD apply the appropriate syntax rules to each label,
- as well as validating the domain name in its entirety.
-
- While it may appear that this model is overtly ambiguous, the
- process of determining the appropriate syntax can be fairly simple
- if the data-types are consistently enforced. For example, most of
- the domain name data-types use relatively simple sequences of
- label data-types, and most applications only support a single
- domain name data-type for any particular protocol usage. Thus, it
- is a simple matter to determine if the domain name is valid by
- comparing it to the syntax rules for the expected usage.
-
-
- Hall I-D Expires: December 2002 [page 16] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- In those cases where the application or protocol allows multiple
- kinds of domain name to be used, it is still possible to apply
- some fairly simple lexical analysis to determine the domain name
- which is in use (a service location label is different from a
- hostname label, while mailbox labels and octet labels may contain
- specific escape sequences, and so forth). In those cases where
- multiple data-types are supported and the domain name data-type
- cannot be determined (this may happen with an application such as
- "dig" or "nslookup", for example), then the application MAY choose
- to simply validate the domain name against the relevant namespace
- and leave it at that. However, this level of detachment SHOULD NOT
- be the default behavior; applications SHOULD attempt to validate
- the labels and domain names to the best of their ability using the
- available syntax rules.
-
- Specifically, the syntax of a label SHOULD be validated whenever a
- resource record is added to the replication master for a zone, or
- whenever an application first creates a domain name for use within
- that application or its associated network service. These rules
- are specifically designed to avoid garbage-in, garbage-out
- syndrome. Subsequent applications and protocol end-points MAY
- perform syntax validation of any domain names, and specific
- application protocols MAY require verification by the application
- end-points, although this will not be required if the
- participating end-points have performed the necessary validation.
-
-
- 5.2. Defining New Data-Types
-
- Application protocols MAY define any new label or domain name
- data-types which are needed, although these data-types MUST
- conform to the rules which govern the controlling namespace, as
- described in section 4.
-
- Application protocols SHOULD reuse one of the hostname syntaxes if
- at all possible, since these syntaxes have the widest deployment,
- and this will facilitate faster adoption of the protocol.
-
- If a protocol needs to support a broader syntax for uses other
- than referring to hostnames in the DNS or internationalized
- namespaces, then the protocol SHOULD indicate which operations or
- external syntaxes require specific exceptions, and document those
- exception syntaxes separately if possible. For example, if a
- protocol is capable of using DNS and LDAP equally, this SHOULD be
- stated explicitly when the protocol-specific data-types are
-
-
- Hall I-D Expires: December 2002 [page 17] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- defined, and a subset data-type which applies specifically to DNS
- lookups SHOULD also be defined.
-
-
- 5.3. The Root Label and Domain Name
-
- Whenever the DNS message format is used to transport a domain
- name, [RFC1034] requires the root domain to be specified. However,
- most applications and protocols do not require or even allow the
- root domain to be specified as part of the domain names they use
- internally. In these cases, the applications and protocols will
- typically leave it up to the local resolver to fully-qualify the
- domain name as provided, although this process can fail and cause
- unexpected domain name to be used (see RFC 1535 [RFC1535] for an
- example and a discussion of this problem).
-
- There are two separate considerations here. First is that an
- application may need to fully-qualify the domain name in order to
- prevent misinterpretation. Secondarily, some applications and
- protocols require that the root domain be provided as the complete
- domain name, or as part of a domain name (such as a service
- locator domain name associated with the root zone). The root label
- is defined to suit both of those purposes, where this is needed.
- It can be used to explicitly terminate a fully-qualified domain
- name, and it can be used to explicitly represent the root domain
- as a standalone entity.
-
- In a multi-label domain name, the root label is represented by a
- trailing separator mark. The root label MAY be used at the end of
- any domain name, regardless of its data-type.
-
- In those cases where the root label is provided by itself, the
- separator mark will specifically represent the root domain of the
- class IN hierarchy. Note that the root domain is not currently
- defined as a host (it does not have an IP address), so it cannot
- currently be used as a connection identifier.
-
- Application protocols SHOULD support the use of a standalone root
- label as an explicit domain name, although this is specifically
- not required. Where a protocol defines this usage, it SHOULD NOT
- be a mandatory requirement for all implementations. Other
- application- or protocol-specific syntaxes MAY also be supported
- for this purpose, if necessary. Applications MUST follow the
- protocol-specific guidelines on this subject.
-
-
-
-
- Hall I-D Expires: December 2002 [page 18] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- 5.4. The Hostname Labels and Domain Names
-
- Hostnames identify specific systems and zone partitions by name,
- and are the most widely used of all the data-types. Hostnames are
- used as the owner name and data values of almost all the common
- resource records, are used as the connection identifier for almost
- all protocol-specific syntaxes and generalized applications, and
- are used for storing system names in local hosts databases, among
- other purposes.
-
- Since hostnames have such a broad number of uses and potential
- storage formats, they also have the strictest syntax rules. A
- hostname is not valid unless each label and the entire domain
- validate successfully.
-
-
- 5.4.1. Legacy Hostnames
-
- A legacy hostname domain name is a sequence of one or more legacy
- hostname labels, with an optional root label at the end.
- Applications which use legacy "hostnames" as specific data-types
- MUST validate the hostname domain name and label sequences
- separately and cumulatively.
-
- Note that the syntax for legacy hostnames has undergone many
- subtle and varied shifts over the years, with multiple updates and
- revisions allowing for slightly different syntaxes. This document
- unifies these definitions and clarifies some ambiguities, and is
- to be considered the definitive reference on the definition of a
- valid legacy hostname label and domain name.
-
- A legacy hostname label may only contain the Hyphen (0x2D), the
- numerals "0" through "9" (0x30 through 0x39), the uppercase
- letters "A" through "Z" (0x41 through 0x5A), and the lowercase
- letters "a" through "z" (0x61 through 0x7A) from [ASCII]. The
- first and last character in a hostname label MUST NOT be a Hyphen
- character, but any other character sequence is valid within the
- confines of a hostname label.
-
- A legacy hostname domain name is a sequence of one or more legacy
- hostname labels. However, at least one of the labels MUST contain
- at least one alphabetic character (a domain name which consists
- entirely of numeric values has the potential to be confused with
- an IP address, and this rule prevents this ambiguity). A legacy
- hostname domain name MAY contain an optional root label at the end
-
-
-
- Hall I-D Expires: December 2002 [page 19] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- of the domain name, although this usage MUST be explicitly allowed
- by the application protocol in use.
-
- With the exception of the optional root label at the end of a
- domain name, a legacy hostname domain name MUST NOT contain any
- other label data-types. If any of the labels do not validate as
- legacy hostname labels, or if the entire domain name does not
- validate as a legacy hostname domain name, then the entire domain
- name MUST be rejected for use as a legacy hostname domain name.
-
- The length rules associated with the DNS namespace are
- specifically adopted as the length rules for the legacy hostname
- label and domain name data-types. This definition updates the
- definitions provided in [RFC952] and [RFC1123], which had set
- these lengths at different values. As such, any system which
- implements a HOSTS.TXT database (or a local equivalent, such as
- the "/etc/hosts" file on traditional UNIX systems) MUST conform to
- the length restrictions defined in section 4.2.1.
-
- The syntax rules defined above are somewhat tighter than the
- syntax allowed in [RFC2181]. However, no standards-track network
- services have defined hostname syntax rules to use the allowable
- syntax from [RFC2181]. Instead, almost all application protocols
- and network services use stricter rules which are highly similar
- to those defined here.
-
- Applications and protocols which need to support internationalized
- hostnames MUST use the syntax defined in section 5.4.2.
-
- Applications and protocols which need to support eight-bit octets
- in their domain names MUST either use the octet label syntax
- described in section 5.5 or define a new syntax specifically for
- use with that network service. In either event, new resource
- records are also likely to be required.
-
-
- 5.4.2. Internationalized Hostnames
-
- An internationalized hostname domain name is a sequence of one or
- more internationalized hostname labels, with an optional root
- label at the end. Applications MUST validate the domain name and
- label sequences separately and cumulatively.
-
- The syntax for internationalized hostname labels is defined in
- NAMEPREP [NAMEPREP], while this document defines the syntax for
- internationalized hostname domain names.
-
-
- Hall I-D Expires: December 2002 [page 20] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- The international hostname label rules defined in NAMEPREP require
- that a label be lowercased and normalized with Unicode
- normalization form KC prior to use. Due to the massive number of
- characters which are available for use with internationalized
- hostname labels, this document cannot summarize the entire set.
-
- Note that an internationalized hostname label which only contains
- seven-bit codepoint values from the [ASCII] range MUST also
- validate as a legacy hostname label, using the rules described in
- section 5.4.1. This is necessary in order for a label to be
- reusable in both namespaces.
-
- An internationalized hostname domain name is a sequence of
- internationalized hostname labels, with the additional requirement
- that at least one of the labels MUST contain a non-numeric
- character. An internationalized hostname domain name MAY contain
- an optional root label at the end of the domain name, although
- this usage MUST be explicitly allowed by the application protocol
- in use.
-
- With the exception of the optional root label at the end of a
- domain name, an internationalized hostname domain name MUST NOT
- contain any other label data-types. If any of the labels do not
- validate as internationalized hostname labels, or if the entire
- domain name does not validate as an internationalized hostname
- domain name, then the entire domain name MUST be rejected for use
- as an internationalized hostname domain name.
-
-
- 5.5. The Octet Label and Domain Name
-
- The DNS namespace allows labels to contain eight-bit codepoint
- values, although no standardized representation or interpretation
- of these values is defined. While [RFC2181] allows these codepoint
- values to be used with any domain name or label, this document
- restricts the usage of these values to the octet label data-type.
-
- A octet label essentially provides a direct pass-thru mapping to
- the underlying DNS namespace. No additional restrictions or
- interpretations are defined. Multiple octet labels may be used in
- conjunction with multiple legacy hostname labels (with an optional
- root label at the end of the end of the domain name) to form an
- octet domain name.
-
-
-
-
- Hall I-D Expires: December 2002 [page 21] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- The UCS character repertoire does not provide any mechanisms for
- specifying raw octet values, but instead only identifies
- characters and their codepoint values. As such, eight-bit
- codepoint values are not accessible to applications which use the
- internationalized namespace. Instead, those applications will be
- required to use the DNS namespace directly whenever an octet
- domain name contains eight-bit codes. However, if the domain name
- only contains seven-bit characters, then that label can be
- accessed from the internationalized namespace.
-
- For this reason, applications and protocols SHOULD give preference
- to the range of characters defined for legacy hostname labels, as
- this allows the domain name to be accessed from the largest number
- of sources. However, applications MUST allow the full eight-bit
- range of values to be specified if the octet domain name data-type
- is required for the protocol at hand, with the caveat that these
- labels will be inaccessible from the internationalized namespace.
-
- If a octet label contains a Full-Stop (0x2E), Reverse-Solidus
- (0x5C), Double-Quote (0x22), a non-printing character from [ASCII]
- (0x00 through 0x20, or 0x7F) or any of the eight-bit codepoint
- values (0x80 through 0xFF), then those characters MUST be escaped
- (using the syntax rules provided in section 4.2.3) whenever the
- domain name is written in longhand form.
-
- Any number of octet labels may be assigned to a leaf-node in the
- DNS namespace. However, zone delegations use NS and SOA resource
- records which use hostname labels, so a fully-qualified domain
- name outside of the root zone MUST contain at least one legacy
- hostname label. Since this usage allows for a variable number of
- octet labels, and since applications outside of the domain name
- system cannot determine the database context of any given label,
- this can result in some ambiguity. However, no standards-track
- network services outside of the DNS currently require the use of
- octets, so this is fairly narrow area.
-
-
- 5.6. The Mailbox Labels and Domain Names
-
- A variety of resource records make use of mailbox label and domain
- name data-types in order to encapsulate email addresses into the
- domain name system (this model allows email addresses to use the
- DNS compression service). Although there are no known application
- protocols outside of DNS which use this data-type, the label type
- still has to be defined for use with DNS, and is therefore defined
- with its own syntax in this document.
-
-
- Hall I-D Expires: December 2002 [page 22] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
-
- 5.6.1. Legacy Mailboxes
-
- The legacy mailbox domain name consists of a single legacy mailbox
- label followed by one or more legacy hostname labels. In this
- model, the legacy mailbox label represents the local-part element
- from an RFC 2822 [RFC2822] email address, while the legacy
- hostname labels represent the mail domain element from an
- [RFC2822] email address. When a legacy mailbox domain name is
- expanded and mapped to an [RFC2822] email address, the legacy
- mailbox label goes on the left of the "@" separator, while the
- hostname labels go on the right of the "@" separator.
-
- The local-part element is defined in [RFC2822] as being either a
- dot-atom or a quoted-string. The dot-atom syntax allows for a
- relatively complete set of [ASCII] punctuation, numbers and
- alphabetic characters, while the quoted-string syntax allows for
- nearly all of the other characters from [ASCII] (certain control
- characters are globally prohibited in [RFC2822], and these apply
- to the quoted-string syntax as well).
-
- In order to accommodate as many email addresses as possible, these
- characters are defined as valid for a legacy mailbox label as
- well. However, if a legacy mailbox label contains a Full-Stop
- (0x2E), Reverse-Solidus (0x5C), Double-Quote (0x22), or any non-
- printing character from [ASCII] (0x00 through 0x20, or 0x7F), then
- those characters MUST be escaped using the syntax rules provided
- in section 4.2.3 whenever the domain name is written out in
- longhand form.
-
- Note that [RFC2821] defines the maximum length of a local-part
- element as 64 characters, although the maximum length of a legacy
- label is 63 characters. As a result, not all local-parts can be
- supported by the legacy mailbox label.
-
- Also note that [RFC2822] also defines the syntax of a "mail
- domain" as the dot-atom data-type, which allows for a larger
- subset of [ASCII] characters than the legacy hostname data-type
- allows. However, [RFC2821] also requires that mail domains be
- queried through DNS with MX and A resource records, both of which
- specify host systems. As such, the dot-atom syntax has never been
- usable with the legacy hostname data-type for the purpose of mail
- routing. The requirements for stronger data-types and syntax
- checks defined in this document do not affect this fundamental
- conflict other than to highlight its presence.
-
-
- Hall I-D Expires: December 2002 [page 23] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
-
- 5.6.2. Internationalized Mailboxes
-
- Legacy mailbox labels MAY be used with internationalized hostname
- labels to form an internationalized mailbox domain name. In this
- model, the legacy mailbox label represents a legacy local-part,
- while the internationalized hostname labels represent an
- international mail domain.
-
- However, note that an internationalized local-part syntax has not
- yet been defined, and until such a time, an internationalized
- mailbox label syntax cannot be defined.
-
-
- 5.7. The Service Locator Labels and Domain Names
-
- The service locator label and domain name syntax is used to
- provide service-specific redirection functions for a particular
- domain name. This usage is specific to DNS, so it does not have
- general applicability outside of the domain name system, although
- the label type still has to be supported, and is therefore defined
- with its own syntax in this document.
-
-
- 5.7.1. Legacy Service Locators
-
- The service locator label and domain name syntax is defined in RFC
- 2782 [RFC2782]. In summary, a legacy service locator domain name
- consists of two legacy service locator labels which uniquely
- identify a specific network service, with the remainder of the
- domain name containing hostname and/or root labels.
-
- The service locator labels are identical to the legacy hostname
- label syntax, with the additional requirement that a service
- locator label MUST begin with an Underscore (0x5F) character (this
- usage prevents the SRV resource record's owner domain name from
- colliding with other owner domain names). In this model, a
- registered network service is assigned a _service._proto label
- sequence, with this sequence being appended to the left of a
- legacy hostname domain name. Application clients can then issue
- queries for the fully-qualified service locator domain name, with
- the resulting answer data providing indicating which hosts offer
- that service on behalf of the queried domain name.
-
-
-
-
- Hall I-D Expires: December 2002 [page 24] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Note that zone delegation requires the use of legacy hostname
- labels, so a fully-qualified domain name for an SRV resource
- record associated with a domain name outside of the root zone MUST
- contain at least one legacy hostname label. However, an
- application can also query for an SRV resource record associated
- with the root domain itself, and in that scenario, the fully-
- qualified domain name would be "_service._proto.", with the
- trailing separator mark explicitly representing the root domain.
-
-
- 5.7.2. Internationalized Service Locators
-
- Service locator labels MAY be used with internationalized hostname
- labels. In this model, the legacy service locator labels represent
- a known service associated with an international domain.
-
- Note that [RFC2277] says that protocol identifiers do not need to
- be internationalized. As such, there is no requirement foreseen to
- allow non-ASCII characters in the service locator label syntax.
-
-
- 6. Resource Records and Query Types
-
- This section describes the domain name data-types in use with all
- of the registered resource records and query-types. These
- definitions include the valid owner domain names for a particular
- kind of resource record, and also include the valid domain names
- for the resource record data sections. Note that each of these
- rules only use domain name data-types, while those data-types are
- defined by constituent sets of label data-types.
-
-
- 6.1. Resource Records
-
- Resource records may be provided in any section of a DNS message.
- When they are provided in the question section as the query
- question, they only have owner names. When they are provided in
- any other section, they have owner names and resource record data.
- All resource records have owner name syntax rules, while those
- resource records which also provide domain names in resource
- record data also have syntax rules for those domain names.
-
- All new resource records MUST be defined with syntax rules
- appropriate to that resource record.
-
-
-
-
- Hall I-D Expires: December 2002 [page 25] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Resource Record Name: IPv4 Address
- Resource Record Mnemonic: A
- Resource Record Code: 1
- Defined In: [RFC1035]
- Owner Name: Hostname
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: Name Server
- Resource Record Mnemonic: NS
- Resource Record Code: 2
- Defined In: [RFC1035]
- Owner Name: Hostname (delegated zone partition)
- Resource Record Data: Hostname (authoritative server)
- Note: All domain delegations MUST use the hostname data-type.
-
- Resource Record Name: Mail Destination
- Resource Record Mnemonic: MD
- Resource Record Code: 3
- Defined In: [RFC1035]
- Owner Name: Hostname (mail domain)
- Resource Record Data: Hostname (delivery server)
- Note: Obsoleted and deprecated by RFC1035 in favor of MX
-
- Resource Record Name: Mail Forwarder
- Resource Record Mnemonic: MF
- Resource Record Code: 4
- Defined In: [RFC1035]
- Owner Name: Hostname (mail domain)
- Resource Record Data: Hostname (relay server)
- Note: Obsoleted and deprecated by RFC1035 in favor of MX
-
- Resource Record Name: Canonical Name
- Resource Record Mnemonic: CNAME
- Resource Record Code: 5
- Defined In: [RFC1035]
- Owner Name: inherited from target owner name
- Resource Record Data: inherited from target owner name
- Note: The owner domain name and resource record data are both
- inherited from the target of the CNAME resource record. For
- example, if a CNAME resource record references an A resource
- record, then the owner name and the resource record data
- both use the Hostname domain name data-type. However, if a
- CNAME resource record references an SRV resource record,
- then the owner name and the resource record data both use
- the Service Locator domain name data-type.
-
-
-
- Hall I-D Expires: December 2002 [page 26] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Resource Record Name: Start-of-Authority
- Resource Record Mnemonic: SOA
- Resource Record Code: 6
- Defined In: [RFC1035]
- Owner Name: Hostname
- Resource Record Data: multiple fields (see below)
- MNAME: Hostname (replication master server)
- RNAME: Mailbox (administrator's email address)
- SERIAL: (no domain name data-types)
- REFRESH: (no domain name data-types)
- RETRY: (no domain name data-types)
- EXPIRE: (no domain name data-types)
- MINIMUM: (no domain name data-types)
-
- Resource Record Name: Mailbox
- Resource Record Mnemonic: MB
- Resource Record Code: 7
- Defined In: [RFC1035]
- Owner Name: Mailbox (recipient email address)
- Resource Record Data: Hostname (delivery server)
-
- Resource Record Name: Mail Group
- Resource Record Mnemonic: MG
- Resource Record Code: 8
- Defined In: [RFC1035]
- Owner Name: Mailbox (original email address)
- Resource Record Data: Mailbox (expanded email address)
-
- Resource Record Name: Mail Rename
- Resource Record Mnemonic: MR
- Resource Record Code: 9
- Defined In: [RFC1035]
- Owner Name: Mailbox (original email address)
- Resource Record Data: Mailbox (new email address)
-
- Resource Record Name: Null
- Resource Record Mnemonic: NULL
- Resource Record Code: 10
- Defined In: [RFC1035]
- Owner Name: Legacy Octets
- Resource Record Data: (no domain name data-types)
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 27] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Resource Record Name: Well-Known Services
- Resource Record Mnemonic: WKS
- Resource Record Code: 11
- Defined In: [RFC1035]
- Owner Name: Hostname
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: Pointer
- Resource Record Mnemonic: PTR
- Resource Record Code: 12
- Defined In: [RFC1035]
- Owner Name: inherited from target owner name
- Resource Record Data: inherited from target owner name
- Note: Although PTR resource records are most often used to provide
- reverse-lookup mappings, the data can be used for any domain
- name which needs to point to another domain name. As such,
- the owner name and the resource record data must both
- inherit the domain name data-type in use with the
- destination.
-
- Resource Record Name: Host Information
- Resource Record Mnemonic: HINFO
- Resource Record Code: 13
- Defined In: [RFC1035]
- Owner Name: Hostname
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: Mail List Information
- Resource Record Mnemonic: MINFO
- Resource Record Code: 14
- Defined In: [RFC1035]
- Owner Name: Mailbox (mailing list primary address)
- Resource Record Data: multiple fields (see below)
- RMAILBOX: Mailbox / Root (responsible party address)
- EMAILBOX: Mailbox / Root (error-handler mailbox)
- Note: MINFO defines an application-specific interpretation for the
- root domain in the resource record as an alternative to the
- Mailbox data-type.
-
-
-
-
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 28] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Resource Record Name: Mail Exchange
- Resource Record Mnemonic: MX
- Resource Record Code: 15
- Defined In: [RFC1035]
- Owner Name: Hostname (mail domain)
- Resource Record Data: multiple fields (see below)
- PREFERENCE: (no domain name data-types)
- DESTINATION: Hostname (mail server)
-
- Resource Record Name: Text
- Resource Record Mnemonic: TXT
- Resource Record Code: 16
- Defined In: [RFC1035]
- Owner Name: Legacy Octets
- Resource Record Data: (no domain name data-types)
- Note: The TXT resource record is commonly used as a proving ground
- for new resource records, and this must continue to be
- supported.
-
- Resource Record Name: Responsible Person
- Resource Record Mnemonic: RP
- Resource Record Code: 17
- Defined In: RFC 1183 [RFC1183]
- Owner Name: Hostname
- Resource Record Data: multiple fields (see below)
- RMAILBOX: Mailbox (responsible person contact address)
- DETAILS: Legacy Octets (pointer to TXT record)
- Note: Binding this resource record to the hostname data-type may
- artificially limits its usefulness, although it results in
- greater predictability and consistency in the
- internationalized namespace.
-
- Resource Record Name: AFS Database Entry
- Resource Record Mnemonic: AFSDB
- Resource Record Code: 18
- Defined In: [RFC1183]
- Owner Name: Hostname
- Resource Record Data: multiple fields (see below)
- PREFERENCE: (no domain name data-types)
- DESTINATION: Hostname (AFS server)
-
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 29] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Resource Record Name: X.25 Number
- Resource Record Mnemonic: X.25
- Resource Record Code: 19
- Defined In: [RFC1183]
- Owner Name: Hostname (host)
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: ISDN Number
- Resource Record Mnemonic: ISDN
- Resource Record Code: 20
- Defined In: [RFC1183]
- Owner Name: Hostname (host)
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: Route-Through
- Resource Record Mnemonic: RT
- Resource Record Code: 21
- Defined In: [RFC1183]
- Owner Name: Hostname (host)
- Resource Record Data: multiple fields (see below)
- PREFERENCE: (no domain name data-types)
- DESTINATION: Hostname (next-hop host)
-
- Resource Record Name: OSI NSAP Address
- Resource Record Mnemonic: NSAP
- Resource Record Code: 22
- Defined In: RFC 1706 [RFC1706]
- Owner Name: Hostname
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: OSI NSAP Pointer
- Resource Record Mnemonic: NSAP-PTR
- Resource Record Code: 23
- Defined In: [RFC1706]
- Owner Name: Hostname (hexadecimal NSAP address)
- Resource Record Data: Hostname (host)
-
- Resource Record Name: Signature
- Resource Record Mnemonic: SIG
- Resource Record Code: 24
- Defined In: RFC 2535 [RFC2535] and RFC 2931 [RFC2931]
- Owner Name: Hostname (?)
- Resource Record Data: (no domain name data-types)
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 30] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Resource Record Name: Public Key
- Resource Record Mnemonic: KEY
- Resource Record Code: 25
- Defined In: [RFC2535]
- Owner Name: Legacy Octets
- Resource Record Data: (no domain name data-types)
- Note: The owner name must be treated as unstructured, since the
- KEY resource record may be bound to any domain name.
-
- Resource Record Name: Pointer to X.400 Mapping
- Resource Record Mnemonic: PX
- Resource Record Code: 26
- Defined In: RFC 2163 [RFC2163]
- Owner Name: Hostname (encoded X.400 mail domain)
- Resource Record Data: multiple fields (see below)
- RFC822-MAIL: Hostname (mail domain)
- X400-MAIL: Hostname (mail domain)
-
- Resource Record Name: Geographical Position
- Resource Record Mnemonic: GPOS
- Resource Record Code: 27
- Defined In: RFC 1712 [RFC1712]
- Owner Name: Hostname
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: IPv6 Simple Address
- Resource Record Mnemonic: AAAA
- Resource Record Code: 28
- Defined In: RFC 1886 [RFC1886]
- Owner Name: Hostname
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: Location
- Resource Record Mnemonic: LOC
- Resource Record Code: 29
- Defined In: RFC 1876 [RFC1876]
- Owner Name: Hostname
- Resource Record Data: (no domain name data-types)
-
-
-
-
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 31] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Resource Record Name: Next Record
- Resource Record Mnemonic: NXT
- Resource Record Code: 30
- Defined In: [RFC2535]
- Owner Name: Legacy Octets
- Resource Record Data: multiple fields (see below)
- NEXT-OWNER: Legacy Octets (the next domain name)
- TYPE: (no domain name data-types)
- Note: The owner name must be treated as unstructured, since the
- NXT resource record may be bound to any domain name.
-
- Resource Record Name: Service Locator
- Resource Record Mnemonic: SRV
- Resource Record Code: 33
- Defined In: [RFC2782]
- Owner Name: Service Locator
- Resource Record Data: multiple fields (see below)
- PRIORITY: (no domain name data-types)
- WEIGHT: (no domain name data-types)
- PORT: (no domain name data-types)
- TARGET: Hostname (target server)
-
- Resource Record Name: ATM Address
- Resource Record Mnemonic: ATMA
- Resource Record Code: 34
- Defined In: N/A (see ATM Forum standards)
- Owner Name: Hostname
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: Naming Authority Pointer
- Resource Record Mnemonic: NAPTR
- Resource Record Code: 35
- Defined In: RFC 2915 [RFC2915]
- Owner Name: Hostname
- Resource Record Data: multiple fields (see below)
- ORDER: (no domain name data-types)
- PREFERENCE: (no domain name data-types)
- FLAGS: (no domain name data-types)
- SERVICE: (no domain name data-types)
- REGEXPS: (no domain name data-types)
- REPLACEMENT: Hostname / Service Locator (see notes)
- Note: The domain name provided in the REPLACEMENT sub-field can
- reference a NAPTR, SRV or A resource record by its owner
- name, depending on the value of the FLAGS sub-field.
-
-
-
-
- Hall I-D Expires: December 2002 [page 32] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Resource Record Name: Key Exchange
- Resource Record Mnemonic: KX
- Resource Record Code: 36
- Defined In: RFC 2230 [RFC2230]
- Owner Name: Legacy Octets (any domain name)
- Resource Record Data: multiple fields (see below)
- PREFERENCE: (no domain name data-types)
- DESTINATION: Hostname (key server)
- Note: The owner name must be treated as unstructured, since the KX
- resource record may be bound to any domain name.
-
- Resource Record Name: Certificate
- Resource Record Mnemonic: CERT
- Resource Record Code: 37
- Defined In: RFC 2538 [RFC2538]
- Owner Name: Hostname
- Resource Record Data: (no domain name data-types)
- Note: The owner name must be treated as unstructured, since the
- CERT resource record may be bound to any domain name.
-
- Resource Record Name: IPv6 Complex Address
- Resource Record Mnemonic: A6
- Resource Record Code: 38
- Defined In: RFC 2874 [RFC2874]
- Owner Name: Hostname (host)
- Resource Record Data: (no domain name data-types)
-
- Resource Record Name: Domain Name Redirection
- Resource Record Mnemonic: DNAME
- Resource Record Code: 39
- Defined In: RFC 2672 [RFC2672]
- Owner Name: Hostname
- Resource Record Data: Hostname
-
- Resource Record Name: Extended Option
- Resource Record Mnemonic: OPT
- Resource Record Code: 41
- Defined In: RFC 2671 [RFC2671]
- Owner Name: Root
- Resource Record Data: (no domain name data-types)
-
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 33] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Resource Record Name: Transaction Key
- Resource Record Mnemonic: TKEY
- Resource Record Code: 249
- Defined In: RFC 2930 [RFC2930]
- Owner Name: Legacy Octets
- Resource Record Data: (no domain name data-types)
- Note: The owner name must be treated as unstructured, since the
- TKEY resource record may be bound to any domain name.
-
- Resource Record Name: Transaction Signature
- Resource Record Mnemonic: TSIG
- Resource Record Code: 250
- Defined In: RFC 2845 [RFC2845]
- Owner Name: Legacy Octets
- Resource Record Data: (no domain name data-types)
- Note: The owner name must be treated as unstructured, since the
- TSIG resource record may be bound to any domain name.
-
-
- 6.2. Query Types
-
- Apart from the resource records defined in section 6.1 above,
- there are also a handful of query types. Query types are only
- provided in the question section of a DNS message, and do not have
- resource record data. However, their owner names have domain name
- data-types which require standardization.
-
- All new query-types MUST be defined with syntax rules appropriate
- to that query-type.
-
- Query Name: Incremental Transfer
- Query Mnemonic: IXFR
- Query Code: 251
- Defined In: RFC 1995 [RFC1995]
- Owner Name: Hostname
-
- Query Name: Zone Transfer
- Query Mnemonic: AXFR
- Query Code: 252
- Defined In: [RFC1035]
- Owner Name: Hostname
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 34] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- Query Name: Mailbox Records
- Query Mnemonic: MAILB
- Query Code: 253
- Defined In: [RFC1035]
- Owner Name: Mailbox
- Note: This query-type requests all of the Mailbox, Mail Group,
- Mail Rename and Mail List resource records associated with
- an email address.
-
- Query Name: Mail Transfer Records
- Query Mnemonic: MAILA
- Query Code: 254
- Defined In: [RFC1035]
- Owner Name: Hostname
- Note: Obsoleted and deprecated by RFC1035 in favor of MX, but used
- to request all of the Mail Forwarder and Mail Destination
- resource records associated with a mail domain.
-
- Query Name: All Records
- Query Mnemonic: "*" or ALL
- Query Code: 255
- Defined In: [RFC1035]
- Owner Name: Hostname
-
-
- 7. Security Considerations
-
- This document does not change any on-the-wire formats, and
- therefore does not introduce any new security risks within the
- affected protocols. However, it is the author's hope that by
- defining strict syntaxes for domain names and labels that overall
- security can be improved as a result of higher predictability and
- better development practices.
-
-
- 8. IANA Considerations
-
- This document requires the use of an EDNS extended label type
- identification code. This document uses the b000011 ELT code.
-
-
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 35] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- 9. References
-
-
- [RFC608] RFC 608, "HOST NAMES ON-LINE", M. Kudlick, January
- 1974.
-
- [RFC810] RFC 810, "DoD INTERNET HOST TABLE SPECIFICATION", E.
- Feinler et al, March 1982.
-
- [RFC882] RFC 882, "DOMAIN NAMES - CONCEPTS and FACILITIES",
- P. Mockapetris, November 1983.
-
- [RFC952] RFC 952, "DOD INTERNET HOST TABLE SPECIFICATION", K.
- Harrenstien et al, October 1985.
-
- [RFC1034] RFC 1034, "DOMAIN NAMES - CONCEPTS and FACILITIES",
- P. Mockapetris, November 1987.
-
- [RFC1123] RFC 1123, "Requirements for Internet Hosts --
- Application and Support", R. Braden, October 1989.
-
- [RFC2181] RFC 2181, "Clarifications to the DNS
- Specification", R. Elz et al, July 1997.
-
- [ASCII] "ANSI X3.4-1968. USA Standard Code for Information
- Interchange", ANSI.
-
- [RFC883] RFC 883, "DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION", P. Mockapetris, November 1983.
-
- [RFC1035] RFC 1035, "DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION", P. Mockapetris, November 1987.
-
- [ISO-10646] "ISO/IEC 10646-1:2000. International Standard --
- Information technology -- Universal Multiple-Octet Coded
- Character Set (UCS) -- Part 1: Architecture and Basic
- Multilingual Plane" and "Part 2: Supplementary Planes",
- ISO.
-
- [UNICODE] "The Unicode Consortium, The Unicode Standard,
- Version 3.0", Addison-Wesley: Reading, MA, 2000. Update to
- version 3.1, 2001. Update to version 3.2, 2002.
-
- [PUNYCODE] Internet-Draft, "Punycode:An encoding of Unicode
- for use with IDNA", A. Costello, May 2002.
-
-
- Hall I-D Expires: December 2002 [page 36] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- [IDNA] Internet-Draft, "Internationalizing Domain Names In
- Applications (IDNA)", P. Faltstrom et al, May 2002.
-
- [STRINGPREP] Internet-Draft, "Preparation of
- Internationalized Strings", P. Hoffman et al, May 2002.
-
- [NAMEPREP] Internet-Draft, "Nameprep: A Stringprep Profile
- for Internationalized Domain Names", P. Hoffman et al, May
- 2002.
-
- [RFC1535] RFC 1535, "A Security Problem and Proposed
- Correction With Widely Deployed DNS Software", E. Gavron,
- October 1993.
-
- [RFC2821] RFC 2821, "Simple Mail Transfer Protocol", J.
- Klensin, April 2001.
-
- [RFC2822] RFC 2822, "Internet Message Format", P. Resnick,
- April 2001.
-
- [RFC2782] RFC 2782, "A DNS RR for specifying the location of
- services (DNS SRV)", A. Gulbrandsen et al, February 2000.
-
- [RFC2277] RFC 2277, "IETF Policy on Character Sets and
- Languages", H. Alvestrand, January 1998.
-
- [RFC1183] RFC 1183, "New DNS RR Definitions", C. Everhart et
- al, October 1990.
-
- [RFC1706] RFC 1706, "DNS NSAP Resource Records", B. Manning
- et al, October 1994.
-
- [RFC2535] RFC 2535, "Domain Name System Security Extensions",
- D. Eastlake, March 1999.
-
- [RFC2931] RFC 2931, "DNS Request and Transaction Signatures (
- SIG(0)s )", D. Eastlake, September 2000.
-
- [RFC2163] RFC 2163, "Using the Internet DNS to Distribute
- MIXER Conformant Global Address Mapping (MCGAM)", C.
- Allocchio, January 1998.
-
- [RFC1712] RFC 1712, "DNS Encoding of Geographical Location",
- C. Farrell et al, November 1994.
-
-
-
- Hall I-D Expires: December 2002 [page 37] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
- [RFC1886] RFC 1886, "DNS Extensions to support IP version 6",
- S. Thomson et al, December 1995.
-
- [RFC1876] RFC 1876, "A Means for Expressing Location
- Information in the Domain Name System", C. Davis et al,
- January 1996.
-
- [RFC2915] RFC 2915, "The Naming Authority Pointer (NAPTR) DNS
- Resource Record", M. Mealling et al, September 2000.
-
- [RFC2230] RFC 2230, "Key Exchange Delegation Record for the
- DNS", R. Atkinson, November 1997.
-
- [RFC2538] RFC 2538, "Storing Certificates in the Domain Name
- System (DNS)", D. Eastlake et al, March 1999.
-
- [RFC2874] RFC 2874, "DNS Extensions to Support IPv6 Address
- Aggregation and Renumbering", M. Crawford et al, July 2000.
-
- [RFC2672] RFC 2672, "Non-Terminal DNS Name Redirection", M.
- Crawford, August 1999.
-
- [RFC2671] RFC 2671, "Extension Mechanisms for DNS (EDNS0)",
- P. Vixie, August 1999.
-
- [RFC2930] RFC 2930, "Secret Key Establishment for DNS (TKEY
- RR)", D. Eastlake, September 2000.
-
- [RFC2845] RFC 2845, "Secret Key Transaction Authentication
- for DNS (TSIG)", P. Vixie et al, May 2000.
-
- [RFC1995] RFC 1995, "Incremental Zone Transfer in DNS", M.
- Ohta, August 1996.
-
-
- 10. Acknowledgements
-
- The author made multiple attempts at avoiding this work. David
- Hopwood and Mark Andrews are credited with arguing that it needed
- to be done, and John Klensin is credited with providing helpful
- feedback on how it should be done.
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 38] \f
- INTERNET-DRAFT draft-hall-dns-datatypes-00.txt June 2002
-
-
-
- 11. Author's Address
-
- Eric A. Hall
- ehall@ehsco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Hall I-D Expires: December 2002 [page 39] \f
+++ /dev/null
-\r
-This Internet-Draft has been deleted. Unrevised documents placed in the\r
-Internet-Drafts directories have a maximum life of six months. After\r
-that time, they are deleted. This Internet-Draft was not published as\r
-an RFC.\r
-\r
-Internet-Drafts are not an archival document series, and expired\r
-drafts, such as this one, are not available; please do not ask for\r
-copies... they are not available. The Secretariat does not have\r
-information as to future plans of the authors or working groups WRT the\r
-deleted Internet-Draft.\r
-\r
-For more information or a copy of the document, contact the author directly.\r
-\r
-Draft Author(s):\r
-\r
-R. Hibbs: rbhibbs@pacbell.com \r
-\r
-\r
+++ /dev/null
-
-
-
-
-
-
-Network Working Group R. Austein
-draft-ietf-dnsext-dnsmib-historical-00.txt InterNetShare.com, Inc.
- October 2000
-
-
- Applicability Statement for DNS MIB Extensions
-
-
-Status of this document
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
-
- 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>
-
- Distribution of this document is unlimited. Please send comments to
- the Namedroppers mailing list <namedroppers@ops.ietf.org>.
-
-Abstract
-
- More than six years after the DNS Server and Resolver MIB extensions
- became proposed standards, there still has not been any significant
- deployment of these MIB extensions. This note examines the reasons
- why these MIB extensions were never deployed, and recommends retiring
- these MIB extensions by moving them to Historical status.
-
-History
-
- The road to the DNS MIB extensions was paved with good intentions.
-
- In retrospect, it's obvious that the working group never had much
- agreement on what belonged in the MIB extensions, just that we should
- have some. This happened during the height of the craze for MIB
- extensions in virtually every protocol that the IETF was working on
-
-
-
-Austein Expires 2 May 2001 [Page 1]
-\f
-draft-ietf-dnsext-dnsmib-historical-00.txt October 2000
-
-
- at the time, so the question of why we were doing this in the first
- place never got a lot of scrutiny. Very late in the development
- cycle we discovered that much of the support for writing the MIB
- extensions in the first place had come from people who wanted to use
- SNMP SET operations to update DNS zones on the fly. Examination of
- the security model involved, however, led us to conclude that this
- was not a good way to do dynamic update and that a separate DNS
- Dynamic Update protocol would be necessary.
-
- The MIB extensions started out being fairly specific to one
- particular DNS implementation (BIND-4.8.3); as work progressed, the
- BIND-specific portions were rewritten to be as implementation-neutral
- as we knew how to make them, but somehow every revision of the MIB
- extensions managed to accrete new counters that just happened to
- closely match statistics kept by some version of BIND. As a result,
- the MIB extensions ended up being much too big, which raised a number
- of concerns with the network management directorate, but the WG
- resisted every attempt to remove any of these variables. In the end,
- large portions of the MIB extensions were moved into optional groups
- in an attempt to get the required subset down to a manageable size.
-
- The DNS Server and Resolver MIB extensions were one of the first
- attempts to write MIB extensions for a protocol usually considered to
- be at the application layer. Fairly early on it became clear that,
- while it was certainly possible to write MIB extensions for DNS, the
- SMI was not really designed with this sort of thing in mind. A case
- in point was the attempt to provide direct indexing into the caches
- in the resolver MIB extensions: while arguably the only sane way to
- do this for a large cache, this required much more complex indexing
- clauses than is usual, and ended up running into known length limits
- for object identifiers in some SNMP implementations.
-
- Furthermore, the lack of either real proxy MIB support in SNMP
- managers or a standard subagent protocol meant that there was no
- reasonable way to implement the MIB extensions in the dominant
- implementation (BIND). When the AgentX subagent protocol was
- developed a few years later, we initially hoped that this would
- finally clear the way for an implementation of the DNS MIB
- extensions, but by the time AgentX was a viable protocol it had
- become clear that nobody really wanted to implement these MIB
- extensions.
-
- Finally, the MIB extensions took much too long to produce. In
- retrospect, this should have been a clear warning sigh, particularly
- when the WG had clearly become so tired of the project that the
- authors found it impossible to elicit any comments whatsoever on the
- documents.
-
-
-
-
-Austein Expires 2 May 2001 [Page 2]
-\f
-draft-ietf-dnsext-dnsmib-historical-00.txt October 2000
-
-
-Lessons
-
- Observations based on the preceding list of mistakes, for the benefit
- of anyone else who ever attempts to write DNS MIB extensions again:
-
- - Define a clear set of goals before writing any MIB extensions.
- Know who the constituency is and make sure that what you write
- solves their problem.
-
- - Keep the MIB extensions short, and don't add variables just because
- somebody in the WG thinks they'd be a cool thing to measure.
-
- - If some portion of the task seems to be very hard to do within the
- SMI, that's a strong hint that SNMP is not the right tool for
- whatever it is that you're trying to do.
-
- - If the entire project is taking too long, perhaps that's a hint
- too.
-
-
-Recommendation
-
- In view of the community's apparent total lack of interest in
- deploying these MIB extensions, we recommend that RFCs 1611 and 1612
- be reclassified as Historical documents.
-
-Security Considerations
-
- Getting rid of the DNS MIB extensions undoubtedly closes a few
- security holes, or would if anybody had ever implemented them.
-
-IANA Considerations
-
- Getting rid of the DNS MIB extensions should not impose any new work
- on IANA.
-
-Acknowledgments
-
- The author would like to thank all the people who were involved in
- this silly project over the years for their optimism and patience,
- misguided though it may have been.
-
-References
-
- [DNS-SERVER-MIB] Austein, R., and Saperia, J., "DNS Server MIB
- Extensions", RFC 1611, May 1994.
-
-
-
-
-
-Austein Expires 2 May 2001 [Page 3]
-\f
-draft-ietf-dnsext-dnsmib-historical-00.txt October 2000
-
-
- [DNS-RESOLVER-MIB] Austein, R., and Saperia, J., "DNS Resolver MIB
- Extensions", RFC 1612, May 1994.
-
- [DNS-DYNAMIC-UPDATE] Vixie, P., Ed., Thomson, S., Rekhter, Y., and
- Bound, J., "Dynamic Updates in the Domain Name System (DNS
- UPDATE)", RFC 2136, April 1997.
-
- [AGENTX] Daniele, M., Wijnen, B., Ellison, M., and Francisco, D.,
- "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741,
- January 2000.
-
-Author's addresses:
-
- Rob Austein
- InterNetShare.com, Inc.
- 505 West Olive Ave., Suite 321
- Sunnyvale, CA 94086
- USA
- sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires 2 May 2001 [Page 4]
+++ /dev/null
-
-
-DNSEXT R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 28, 2003 M. Kosters
- D. Blacka
- Verisign, Inc.
- February 27, 2003
-
-
- DNSSEC Opt-In
- draft-ietf-dnsext-dnssec-opt-in-05
-
-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 28, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- In RFC 2535, delegations to unsigned subzones are cryptographically
- secured. Maintaining this cryptography is not practical or
- necessary. This document describes an "Opt-In" model that allows
- administrators to omit this cryptography and manage the cost of
- adopting DNSSEC with large zones.
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 1]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . 5
- 3.1 Server Considerations . . . . . . . . . . . . . . . . . . . 6
- 3.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1.2 Insecure Delegation Responses . . . . . . . . . . . . . . . 6
- 3.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . . . . 6
- 3.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . 7
- 3.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 7
- 3.2.2 Validation Process Changes . . . . . . . . . . . . . . . . . 7
- 3.2.3 NXT Record Caching . . . . . . . . . . . . . . . . . . . . . 8
- 3.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . . . . 8
- 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 6. Transition Issues . . . . . . . . . . . . . . . . . . . . . 13
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 14
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
- Normative References . . . . . . . . . . . . . . . . . . . . 18
- Informative References . . . . . . . . . . . . . . . . . . . 19
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
- A. Implementing Opt-In using "Views" . . . . . . . . . . . . . 21
- B. Changes from Prior Versions . . . . . . . . . . . . . . . . 23
- Intellectual Property and Copyright Statements . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 2]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system, RFC 1035
- [1], DNS security extensions, RFC 2535 [2], and DNSSEC terminology
- RFC 3090 [8] 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 [6]. In this
- document, the RRset is also defined to include the covering SIG
- records, if any exist.
-
- signed name: refers to a DNS name that has, at minimum, a (signed)
- NXT record.
-
- unsigned name: refers to a DNS name that does not (at least) have a
- NXT record.
-
- covering NXT record/RRset: is the NXT record used to prove
- (non)existence of a particular name or RRset. This means that for
- a RRset or name 'N', the covering NXT 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.
-
- 2535/DS 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 NXT 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 [5].
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 3]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-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 NXT record chain may be extremely high relative to
- the gain of cryptographically authenticating existence of unsecured
- zones.
-
- This document describes a method of eliminating the superfluous
- cryptography present in secure delegations to insecure zones. Using
- "Opt-In", a zone administrator can choose to remove insecure
- delegations from the NXT chain. This is accomplished by extending
- the semantics of the NXT record by using a redundant bit in the type
- map.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 4]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-3. Protocol Additions
-
- In RFC 2535, delegation NS RRsets are not signed, but are instead
- accompanied by a NXT RRset of the same name, and possibly a
- ("no-key") KEY RR [2] or DS record [3]. The security status of the
- subzone is determined by the presence of the KEY or DS records,
- cryptographically proven by the NXT record. Opt-In expands this
- definition by allowing insecure delegations to exist within an
- otherwise signed zone without the corresponding NXT record at the
- delegation's owner name. These insecure delegations are proven
- insecure by using a covering NXT record.
-
- Since this represents a change of the interpretation of NXT records,
- resolvers must be able to distinguish between RFC 2535 NXT records
- and Opt-In NXT records. This is accomplished by "tagging" the NXT
- records that cover (or potentially cover) insecure delegation nodes.
- This tag is indicated by the absence of the NXT bit in the type map.
- Since the NXT bit in the type map merely indicates the existence of
- the record itself, this bit is redundant and safe for use as a tag.
-
- An Opt-In tagged NXT 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 the NXT chain. However, Opt-In
- tagged NXT records do assert the (non)existence of other RRsets.
-
- An Opt-In NXT 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, or the presence of a "no-key" KEY
- RRset, and the NXT record does assert the existence of the
- delegation.
-
- Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records
- and RFC 2535 NXT records. If a NXT 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 NXT 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 NXT RDATA.
-
- In summary,
-
- o An Opt-In NXT type is identified by a zero-valued (or
- not-specified) NXT bit in the type bit map of the NXT record.
-
- o A RFC2535 NXT type is identified by a one-valued NXT bit in the
- type bit map of the NXT record.
-
- and,
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 5]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- o An Opt-In NXT 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 NXT record does assert the (non)existence of RRsets with
- the same owner name.
-
-
-3.1 Server Considerations
-
- Opt-In imposes some new requirements on authoritative DNS servers.
-
-3.1.1 Delegations Only
-
- This specification dictates that only insecure delegations may exist
- between the owner and "next" names of an Opt-In tagged NXT 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.
-
-3.1.2 Insecure Delegation Responses
-
- When returning an Opt-In insecure delegation, the server MUST return
- the covering NXT RRset in the Authority section.
-
- This presents a change from RFC 2535, where the "no-key" KEY RRset
- would be returned instead. However, in the delegation signer
- proposal, NXT records already must be returned along with the
- insecure delegation. The primary difference that this proposal
- introduces is that the Opt-In tagged NXT record will have a different
- owner name from the delegation RRset. This may require
- implementations to do a NXT search on cached responses.
-
-3.1.3 Wildcards and Opt-In
-
- RFC 2535, in section 5.3, describes the practice of returning NXT
- records to prove the non-existence of an applicable wildcard in
- non-existent name responses. This NXT record can be described as a
- "negative wildcard proof". The use of Opt-In NXT records changes the
- necessity for this practice. For non-existent name responses when the
- query name (qname) is covered by an Opt-In tagged NXT record, servers
- MAY choose to omit the wildcard proof record, and clients MUST NOT
- treat the absence of this NXT record as a validation error.
-
- The intent of the RFC 2535 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:
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 6]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- 1. The exact qname does not exist. This is done by the "normal" NXT
- record.
-
- 2. No applicable wildcard exists. This is done by returning a NXT
- record proving that the wildcard does not exist (negative
- wildcard proof).
-
- However, if the NXT record covering the exact qname is an Opt-In NXT
- 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 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 NXT record does not change the
- practice of returning a NXT along with a wildcard expansion. Even
- though the Opt-In NXT 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.
-
-3.1.4 Dynamic Update
-
- Opt-In changes the semantics of Secure DNS Dynamic Update [7]. In
- particular, it introduces the need for rules that describe when to
- add or remove a delegation name from the NXT 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 NXT records.
-
-3.2 Client Considerations
-
- Opt-In imposes some new requirements on DNS resolvers (caching or
- otherwise).
-
-3.2.1 Delegations Only
-
- As stated in the "Server Considerations" section above, this
- specification restricts the namespace covered by Opt-In tagged NXT
- records to insecure delegations only. Thus, resolvers MUST reject as
- invalid any records that fall within an Opt-In NXT record's span that
- are not NS records or corresponding glue records.
-
-3.2.2 Validation Process Changes
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 7]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- 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 NXT 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 RFC 2535, the security status is proven by existence of a
- verified "no-key" KEY RRset. The absence of the "no-key" KEY
- RRset indicates that the referred-to zone is secure.
-
- o Using Delegation Signer, 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 secure. The absence of the DS RRset is proven
- using a verified NXT record of the same name that does not have
- the DS bit set in the type map. This NXT 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 secure) or the presence of a verified Opt-In tagged
- NXT record that covers the delegation name. That is, the NXT
- record does not have the NXT bit set in the type map, and the
- delegation name falls between the NXT's owner and "next" name.
-
- 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 subzone is secure or insecure.
-
- 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 NXT record, the resolver MUST NOT require proof (in the form
- of a NXT record) that a wildcard did not exist.
-
-3.2.3 NXT Record Caching
-
- Caching resolvers MUST be able to retrieve the appropriate covering
- Opt-In NXT record when returning referrals that need them. This
- requirement differs from Delegation Signer in that the covering NXT
- will not have the same owner name as the delegation. Some
- implementations may have to use new methods for finding these NXT
- records.
-
-3.2.4 Use of the AD bit
-
- The AD bit, as defined by [4], MUST NOT be set when:
-
- o sending a non-existent name (NXDOMAIN) response where the covering
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 8]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- NXT is tagged as Opt-In.
-
- o sending an Opt-In insecure delegation response, unless the
- covering (Opt-In) NXT record's owner name equals the delegation
- name.
-
- This rule is based on what the Opt-In NXT record actually proves.
- For names that exist between the Opt-In NXT record's owner and "next"
- names, the Opt-In NXT 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 9]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-4. 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 both "no-key"
- KEY (in [2]) and NXT 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 NXT record chain. Zones that are
- frequently updating insecure delegations (e.g., TLDs) can avoid the
- substantial overhead of modifying and resigning the affected NXT
- records.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 10]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-5. Example
-
- Consider the zone EXAMPLE, shown below. This is a zone where all of
- the NXT records are tagged as Opt-In.
-
- Example A: Fully DS/Opt-In Zone.
-
- EXAMPLE. SOA ...
- EXAMPLE. SIG SOA ...
- EXAMPLE. NS FIRST-SECURE.EXAMPLE.
- EXAMPLE. SIG NS ...
- EXAMPLE. KEY ...
- EXAMPLE. SIG KEY ...
- EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY
- EXAMPLE. SIG NXT ...
-
- FIRST-SECURE.EXAMPLE. A ...
- FIRST-SECURE.EXAMPLE. SIG A ...
- FIRST-SECURE.EXAMPLE. NXT NOT-SECURE-2.EXAMPLE. A SIG
- FIRST-SECURE.EXAMPLE. SIG NXT ...
-
- 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 NXT SECOND-SECURE.EXAMPLE NS SIG
- NOT-SECURE-2.EXAMPLE SIG NXT ...
-
- SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE.
- SECOND-SECURE.EXAMPLE. DS ...
- SECOND-SECURE.EXAMPLE. SIG DS ...
- SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY
- SECOND-SECURE.EXAMPLE. SIG NXT ...
-
- 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 RFC 2535
- response.
-
- A query for a nonexistent RRset will result in a response that
- differs from RFC 2535 by: the NXT record will be tagged as Opt-In,
- there may be no NXT record proving the non-existence of a matching
- wildcard record, and the AD bit will not be set.
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 11]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- A query for an insecure delegation RRset (or a referral) will return
- both the answer (in the Authority section) and the corresponding
- Opt-In NXT 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. NXT EXAMPLE. NS SIG DS
- SECOND-SECURE.EXAMPLE. SIG NXT ...
-
- Additional Section:
- NS.UNSIGNED.EXAMPLE. A ...
-
- In the Example A.1 zone, the EXAMPLE. node MAY use either style of
- NXT 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 NXT record for EXAMPLE.
- was changed to the following RR:
-
- EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY NXT
-
- However, the other NXT 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 NXT chain and also covered by an Opt-In tagged NXT
- record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
- removed from the zone without modifying and resigning the prior NXT
- record. Delegations with names that fall between
- NOT-SECURE-2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or
- removed without resigning any NXT records.
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 12]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-6. Transition Issues
-
- Opt-In is not backwards compatible with RFC 2535. RFC 2535 compliant
- DNSSEC implementations will not recognize Opt-In tagged NXT records
- as different from RFC 2535 NXT records. Because of this, RFC 2535
- implementations will reject all Opt-In insecure delegations within a
- zone as invalid.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 13]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-7. 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
- vulnerabilites are described in more detail in [10] (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 NXT 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 August 28, 2003 [Page 14]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- 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. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY
- EXAMPLE. SIG NXT ...
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 15]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-8. IANA Considerations
-
- None.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 16]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-9. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 17]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Normative References
-
- [1] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [2] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [3] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-12 (work in progress),
- December 2002.
-
- [4] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit",
- draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 18]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Informative References
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [7] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
- 2137, April 1997.
-
- [8] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [9] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
- December 2001.
-
- [10] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
- System", draft-ietf-dnsext-dns-threats-02 (work in progress),
- November 2002.
-
-
-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
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 19]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 20]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-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 NXT 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 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 2535 [2].
-
- 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 [9] 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:
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 21]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- 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 August 28, 2003 [Page 22]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Appendix B. Changes from Prior Versions
-
- Changes from version 04:
-
- Added definitions for "signed name" and "unsigned name".
-
- Added text to make it clear that insecure delegations may have
- Opt-In NXT records of the same name. Updated the example to have
- one of these.
-
- Changed Server-side requirements from MUST NOT to SHOULD NOT and
- added some basic description of what action to take in the face of
- violating the delegation-only restriction.
-
- Relaxed requirement that servers drop negative wildcard proof from
- MUST to MAY, reiterated the client requirement.
-
- Added section on Dynamic Update declaring it to be undefined wrt
- Opt-In.
-
- Essentially rewrote the "Security Considerations" section. It does
- not actually say anything different, but hopefully it says it in a
- clearer fashion.
-
- Split references into Normative and Informative.
-
- Fixed the example zone and responses to match Delegation Signer.
-
- Changes from version 03:
-
- Editorial changes for clarification only.
-
- Changes from version 02:
-
- Added text on changes to validation process, use of the AD bit,
- and interactions with wildcards. Added wildcard caveats to the
- "Security Considerations" section. Added "Transition Issues"
- section.
-
- Changes from version 01:
-
- Changed to "delegation only". Strengthened "Security
- Considerations" section. Added "Server Considerations" and "Client
- Considerations" sections. Added AD bit requirement.
-
- Changes from version 00:
-
- Complete rewrite, altering approach from "views" to tagged NXT
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 23]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- records
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 24]
-\f
-Internet-Draft DNSSEC Opt-In February 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
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 25]
-\f
-Internet-Draft DNSSEC Opt-In February 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 26]
-\f
+++ /dev/null
-
-
-DNS Extensions S. Rose
-Internet-Draft NIST
-Expires: August 5, 2003 February 4, 2003
-
-
- DNS Security Document Roadmap
- draft-ietf-dnsext-dnssec-roadmap-07
-
-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 5, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- DNS Security (DNSSEC) technology is composed of extensions to the
- Domain Name System (DNS) protocol that provide data integrity and
- authentication to security aware resolvers and applications through
- the use of cryptographic digital signatures. Several documents exist
- to describe these extensions and the implementation-specific details
- regarding specific digital signing schemes. The interrelationship
- between these different documents is discussed here. A brief
- overview of what to find in which document and author guidelines for
- what to include in new DNS Security documents, or revisions to
- existing documents, is described.
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 1]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Interrelationship of DNS Security Documents . . . . . . . . . 4
- 3. Relationship of DNS Security Documents to other DNS
- Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4. Recommended Content for new DNS Security Documents . . . . . . 9
- 4.1 Security Related Resource Records . . . . . . . . . . . . . . 9
- 4.2 Digital Signature Algorithm Implementations . . . . . . . . . 9
- 4.3 Refinement of Security Procedures . . . . . . . . . . . . . . 10
- 4.4 The Use of DNS Security Extensions with Other Protocols . . . 10
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
- Normative References . . . . . . . . . . . . . . . . . . . . . 13
- Informative References . . . . . . . . . . . . . . . . . . . . 15
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 2]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-1. Introduction
-
- This document is intended to provide guidelines for the development
- of supplemental documents describing security extensions to the
- Domain Name System (DNS).
-
- The main goal of the DNS Security (DNSSEC) extensions is to add data
- authentication and integrity services to the DNS protocol. These
- protocol extensions should be differentiated from DNS operational
- security issues, which are beyond the scope of this effort. DNS
- Security documents fall into one or possibly more of the following
- sub-categories: new DNS security resource records, implementation
- details of specific digital signing algorithms for use in DNS
- Security and DNS transaction authentication. Since the goal of DNS
- Security extensions is to become part of the DNS protocol standard,
- additional documents that seek to refine a portion of the security
- extensions will be introduced as the specifications progress along
- the IETF standards track.
-
- There is a set of basic guidelines for each sub-category of documents
- that explains what should be included, what should be considered a
- protocol extension, and what should be considered an operational
- issue. Currently, there are at least two documents that fall under
- operational security considerations that deal specifically with the
- DNS security extensions: the first is RFC 2541 [6] which deals with
- the operational side of implementing the security extensions; the
- other is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These
- documents should be considered part of the operational side of DNS,
- but will be addressed as a supplemental part of the DNS Security
- roadmap. That is not to say that these two documents are not
- important to securing a DNS zone, but they do not directly address
- the proposed DNS security extensions. Authors of documents that seek
- to address the operational concerns of DNS security should be aware
- of the structure of DNS Security documentation.
-
- It is assumed the reader has some knowledge of the Domain Name System
- [2] and the Domain Name System Security Extensions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 3]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-2. Interrelationship of DNS Security Documents
-
- The DNSSEC set of documents can be partitioned into five main groups
- as depicted in Figure 1. All of these documents in turn are under
- the larger umbrella group of DNS base protocol documents. It is
- possible that some documents fall into more than one of these
- categories, such as RFC 2535, and should follow the guidelines for
- the all of the document groups it falls into. However, it is wise to
- limit the number of "uberdocuments" that try to be everything to
- everyone. The documents listed in each category are current as to
- the time of writing.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 4]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- ---------------------------------------------------------------------
-
-
-
- +--------------------------------+
- | |
- | Base DNS Protocol Docs. |
- | [RFC1035, RFC2181, etc.] |
- | |
- +--------------------------------+
- |
- |
- |
- +------------+ +-----------+ +-------------+
- | New | | DNSSEC | | New |
- | Security |----------| protocol |----------| Security |
- | RRs | | | | Uses |
- +------------+ | | +-------------+
- +-----------+
- |
- |
- +----------------------+***********************
- | * *
- | * *
- +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
- | DS | | | | Implementation |
- | Algorithm | | Transactions | * Notes *
- | Impl. | | | | |
- +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
-
-
-
-
- DNSSEC Document Roadmap
-
- ---------------------------------------------------------------------
-
- The "DNSSEC protocol" document set refers to the document that makes
- up the groundwork for adding security to the DNS protocol [1]and
- updates to this document. RFC 2535 laid out the goals and
- expectations of DNS Security and the new security-related Resource
- Records KEY, SIG, DS, and NXT [23]. Expanding from this document,
- related document groups include the implementation documents of
- various digital signature algorithms with DNSSEC, and documents
- further refining the transaction of messages. It is expected that
- RFC 2535 will be obsoleted by one or more documents that refine the
- set of security extensions [22], [23], [24]. Documents that seek to
- modify or clarify the base protocol documents should state so clearly
-
-
-
-Rose Expires August 5, 2003 [Page 5]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- in the introduction of the document (as well as proscribe to the IETF
- guidelines of RFC/Internet Draft author guidelines). Also, the
- portions of the specification to be modified should be synopsized in
- the new document for the benefit of the reader. The "DNSSEC
- protocol" set includes the documents [1], [11], [12], [9], [14],
- [15], [21], [16], [OPTIN], [17] and their derivative documents.
-
- The "New Security RRs" set refers to the group of documents that seek
- to add additional Resource Records to the set of base DNS Record
- types. These new records can be related to securing the DNS protocol
- [1], [8], or using DNS security for other purposes such as storing
- certificates [5]. Another related document is [26]. While not
- detailing a new RR type, it defines a flag bit in the existing KEY
- RR. This flag bit does not affect the protocol interpretation of the
- RR, only a possible operational difference. Therefore, this draft is
- place here and not with the protocol document set.
-
- The "DS Algorithm Impl" document set refers to the group of documents
- that describe how a specific digital signature algorithm is
- implemented to fit the DNSSEC Resource Record format. Each one of
- these documents deals with one specific digital signature algorithm.
- Examples of this set include [4], [5], [25], [19][18] and [13].
-
- The "Transactions" document set refers to the group of documents that
- deal with the message transaction sequence of security-related DNS
- operations. The contents and sequence for operations such as dynamic
- update [3], [11] and transaction signatures [10] are described in
- this document category. Additional message transaction schemes to
- support DNSSEC operation would also fall under this group, including
- secret key establishment [7], [RENEW], and verification.
-
- The final document set, "New Security Uses", refers to documents that
- seek to use proposed DNS Security extensions for other security
- related purposes. Documents that fall in this category include the
- use of DNS in the storage and distribution of certificates and
- individual user public keys (PGP, e-mail, etc.) Some documents in
- this group may fall beyond the DNSEXT WG scope, but they are included
- because of their use of the security extensions. The documents in
- this group should not propose any changes to the DNS protocol to
- support other protocols; only how existing DNS security records and
- transactions can be used to support other protocols. Such documents
- include [SSH-DNS] and [IPSEC-DNS] which deals with storing SSH and
- IPSec keying information the DNS using new records and utilizing
- DNSSEC to provide authentication and integrity checking.
-
- Lastly, there is a set of documents that should be classified as
- "Implementation Notes". Because the DNS security extensions are
- still in the developmental stage, there is an audience for documents
-
-
-
-Rose Expires August 5, 2003 [Page 6]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- that detail the transition and implementation of the security
- extensions. These have more to do with the practical side of DNS
- operations, but can also point to places in the protocol
- specifications that need improvement. An example of this type is the
- report on the CAIRN DNSSEC testbed [CAIRN] This document was
- submitted through the DNSOP Working Group at the time of this
- writing, however the main concern of this document is the
- implementation and limitations of the DNS security extensions, hence
- their interest to the DNS security community. The CAIRN draft deals
- with the implementation of a secure DNS. Authors of documents that
- deal with the implementation and operational side of the DNSSEC
- specifications would be advised/encouraged to submit their documents
- to any other relevant DNS related WG meeting in the problem space.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 7]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-3. Relationship of DNS Security Documents to other DNS Documents
-
- The DNS security-related extensions should be considered a subset of
- the DNS protocol. Therefore, all DNS security-related documents
- should be seen as a subset of the main DNS architecture documents.
- It is a good idea for authors of future DNS security documents to be
- familiar with the contents of these base protocol documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 8]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-4. Recommended Content for new DNS Security Documents
-
- Documents that seek to make additions or revisions to the DNS
- protocol to add security should follow common guidelines as to
- minimum required content and structure. It is the purpose of this
- document roadmap to establish criteria for content that any new DNS
- security protocol specifications document should contain. These
- criteria should be interpreted as a minimum set of information
- required/needed in a document, any additional information regarding
- the specific extension should also be included in the document.
- These criteria are not officially part of the IETF guidelines
- regarding RFC/Internet Drafts, but should be considered as guidance
- to promote uniformity to Working Group documents.
-
- Since the addition of security to the DNS protocol is now considered
- a general extension to the DNS protocol, any guideline for the
- contents of a DNS Security document could be taken as a framework
- suggestion for the contents of any DNS extension document. The
- development process of the DNS security extensions could be used as a
- model framework for any, more general DNS extensions.
-
-4.1 Security Related Resource Records
-
- Documents describing a new type of DNS Security Resource Record (RR)
- should contain information describing the structure and use of the
- new RR type. It is a good idea to only discuss one new type in a
- document, unless the set of new resource records are closely related
- or a protocol extension requires the use of more than one new record
- type. Specifically, each document detailing a new security-related
- RR type should include the following information:
-
- o The format of the new RR type, both "on the wire" (bit format) and
- ASCII representation (for text zone files), if appropriate;
-
- o when and in what section of a DNS query/response this new RR type
- is to be included;
-
- o at which level of the DNS hierarchy this new RR type is to be
- considered authoritative (i.e. in a zone, in a zone's superzone)
- and who is authoritative to sign the new RR;
-
-
-4.2 Digital Signature Algorithm Implementations
-
- Documents describing the implementation details of a specific digital
- signature algorithm such as [4] ,[13] (and others as new digital
- signatures schemes are introduced) for use with DNS Security should
- include the following information:
-
-
-
-Rose Expires August 5, 2003 [Page 9]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- o The format/encoding of the algorithm's public key for use in a KEY
- Resource Record;
-
- o the acceptable key size for use with the algorithm;
-
- o the current known status of the algorithm (as one of REQUIRED,
- RECOMMENDED, or OPTIONAL).
-
- In addition, authors are encouraged to include any necessary
- description of the algorithm itself, as well as any know/suspected
- weaknesses as an appendix to the document. This is for reference
- only, as the goals of the DNSEXT working group is to propose
- extensions to the DNS protocol, not cryptographic research.
-
-4.3 Refinement of Security Procedures
-
- This set of documents includes DNS protocol operations that
- specifically relate to DNS Security, such as DNS secret key
- establishment [7] and security extensions to pre-existing or
- proposed DNS operations such as dynamic update [3]. Documents that
- describe a new set of DNS message transactions, or seek to refine a
- current series of transactions that make up a DNS operation should
- include the following information:
-
- o The order in which the DNS messages are sent by the operation
- initiator and target;
-
- o the format of these DNS messages;
-
- o any required authentication mechanisms for each stage of the
- operation and the required authority for that mechanism (i.e.
- zone, host, or some other trusted authority such as a DNS
- administrator or certificate authority);
-
-
-4.4 The Use of DNS Security Extensions with Other Protocols
-
- Because of the flexibility and ubiquity of the DNS, there may exist
- other Internet protocols and applications that could make use of, or
- extend, the DNS security protocols. Examples of this type of
- document include the use of DNS to support IPSEC [IPSEC-DNS], SSH
- [SSH-DNS] the Public Key Infrastructure (PKI). It is beyond the
- scope of this roadmap to describe the contents of this class of
- documents. However, if uses or extensions require the addition or
- modification of a DNS Resource Record type or DNS query/response
- transactions, then the guidelines laid out in the previous sections
- of this document should be adhered to.
-
-
-
-
-Rose Expires August 5, 2003 [Page 10]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-5. Security Considerations
-
- This document provides a roadmap and guidelines for writing DNS
- Security related documents. This document does not discuss the
- aspects of the DNS security extensions. The reader should refer to
- the documents outlined here for the details of the services and
- shortcomings of DNS security.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 11]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-6. Acknowledgements
-
- In addition to the RFCs mentioned in this document, there are also
- numerous Internet drafts that fall in one or more of the categories
- of DNS Security documents mentioned above. Depending on where (and
- if) these documents are on the IETF standards track, the reader may
- not be able to access these documents through the RFC repositories.
- All of these documents are "Work in Progress" and are subject to
- change; therefore a version number is not supplied for the current
- revision. Some Internet Drafts are in the RFC editor's queue or
- nearing WG Last Call at the time of writing. These Drafts have been
- placed in the References section. The drafts below are still subject
- to agreement in the IETF.
-
- o CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC
- Implementation in the CAIRN Testbed". draft-ietf-dnsop-
- dnsseccairn-NN.txt
-
- o OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" draft-
- kosters-dnsext-dnssec-opt-in-NN.txt
-
- o SSH-DNS: W. Griffin, J. Schlyter. "Using DNS to securely
- publish SSH key fingerprints" draft-ietf-secsh-dns-NN.txt
-
- o IPSEC-DNS: M. Richardson. "A method for storing IPsec keying
- material in DNS". draft-richardson-ipsec-rr-NN.txt
-
- o RENEW: Y. Kamite, M. Nakayama. "TKEY Secret Key Renewal Mode".
- draft-ietf-dnsext-tkey-renewal-mode-NN.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 12]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-Normative References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
- 2137, April 1997.
-
- [4] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
- (DNS)", RFC 2536, March 1999.
-
- [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
- Domain Name System (DNS)", RFC 2538, March 1999.
-
- [6] Eastlake, D., "DNS Security Operational Considerations", RFC
- 2541, March 1999.
-
- [7] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
- 2930, September 2000.
-
- [8] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [9] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [12] Wellington, B., "Domain Name System Security (DNSSEC) Signing
- Authority", RFC 3008, April 2000.
-
- [13] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
- System (DNS)", RFC 3110, May 2001.
-
- [14] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
- December 2001.
-
- [15] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
-
-
-
-Rose Expires August 5, 2003 [Page 13]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record (RR)", RFC 3445, December 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 14]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-Informative References
-
- [17] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name
- System (Work in Progress)", RFC XXXX.
-
- [18] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain
- Name System (DNS) (Work in Progress)", RFC XXXX.
-
- [19] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS
- (Work in Progress)", RFC XXXX.
-
- [20] Gundmundsson, O., "Delegation Signer Record in Parent (Work in
- Progress)", RFC XXXX.
-
- [21] Wellington, B., "Redefinition of the DNS AD bit (Work in
- Progress)", RFC XXXX.
-
- [22] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security
- Introduction and Requirements (Work in Progress)", RFC XXXX.
-
- [23] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
- Records for DNS Security Extensions (Work in Progress)", RFC
- XXXX.
-
- [24] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
- Modifications for the DNS Security Extensions (Work in
- Progress)", RFC XXXX.
-
- [25] Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm
- for TSIG (Work in Progress)", RFC XXXX.
-
- [26] Kolkman, O. and J. Schlyter, "KEY RR Key-Signing-Key (KSK) Flag
- (Work in Progress)", RFC XXXX.
-
-
-Author's Address
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-3460
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 15]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 16]
-\f
+++ /dev/null
-
-INTERNET-DRAFT ECC Keys in the DNS
-Expires: February 2004 August 2003
-
-
-
-
- Elliptic Curve KEYs in the DNS
- -------- ----- ---- -- --- ---
- <draft-ietf-dnsext-ecc-key-04.txt>
-
- Richard C. Schroeppel
- Donald Eastlake 3rd
-
-
-Status of This Document
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNS mailing list <namedroppers@internic.com> or to the
- authors.
-
- This document is an Internet Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. 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
-
- A standard method for storing elliptic curve cryptographic keys in
- the Domain Name System is described.
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 1]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-Acknowledgement
-
- The assistance of Hilarie K. Orman in the production of this document
- is greatfully acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Acknowledgement............................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. Elliptic Curve Data in Resource Records.................3
- 3. The Elliptic Curve Equation.............................9
- 4. How do I Compute Q, G, and Y?..........................10
- 5. Performance Considerations.............................11
- 6. Security Considerations................................11
- 7. IANA Considerations....................................11
-
- Informational References..................................12
- Normative Refrences.......................................12
-
- Authors' Addresses........................................13
- Expiration and File Name..................................13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 2]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. The DNS has been extended to include digital
- signatures and cryptographic keys as described in [RFC 2535].
-
- This document describes how to store elliptic curve cryptographic
- (ECC) keys in the DNS so they can be used for a variety of security
- purposes. A DNS elliptic curve SIG resource record is not defined.
- Familiarity with ECC cryptography is assumed [Menezes].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-
-2. Elliptic Curve Data in Resource Records
-
- Elliptic curve public keys are stored in the DNS within the RDATA
- portions of RRs with the structure shown below.
-
- The period of key validity may not be in the RR with the key but
- could be indicated by RR(s) with signatures that authenticates the
- RR(s) containing the key.
-
- The research world continues to work on the issue of which is the
- best elliptic curve system, which finite field to use, and how to
- best represent elements in the field. So, we have defined
- representations for every type of finite field, and every type of
- elliptic curve. The reader should be aware that there is a unique
- finite field with a particular number of elements, but many possible
- representations of that field and its elements. If two different
- representations of a field are given, they are interconvertible with
- a tedious but practical precomputation, followed by a fast
- computation for each field element to be converted. It is perfectly
- reasonable for an algorithm to work internally with one field
- representation, and convert to and from a different external
- representation.
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 3]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S M -FMT- A B Z|
- +-+-+-+-+-+-+-+-+
- | LP |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | P (length determined from LP) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LF |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | F (length determined from LF) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEG |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGI |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGJ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | TRDV |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | H (length determined from LH) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LK |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | K (length determined from LK) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LQ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Q (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | A (length determined from LA) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | ALTA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LB |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | B (length determined from LB) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LC |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | C (length determined from LC) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LG |
-
-
-R. Schroeppel, et al [Page 4]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | G (length determined from LG) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LY |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Y (length determined from LY) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- SMFMTABZ is a flags octet as follows:
-
- S = 1 indicates that the remaining 7 bits of the octet selects
- one of 128 predefined choices of finite field, element
- representation, elliptic curve, and signature parameters.
- MFMTABZ are omitted, as are all parameters from LP through G.
- LY and Y are retained.
-
- If S = 0, the remaining parameters are as in the picture and
- described below.
-
- M determines the type of field underlying the elliptic curve.
-
- M = 0 if the field is a GF[2^N] field;
-
- M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
-
- FMT is a three bit field describing the format of the field
- representation.
-
- FMT = 0 for a (mod P) field.
- > 0 for an extension field, either GF[2^D] or GF[P^D].
- The degree D of the extension, and the field polynomial
- must be specified. The field polynomial is always monic
- (leading coefficient 1.)
-
- FMT = 1 The field polynomial is given explicitly; D is implied.
-
- If FMT >=2, the degree D is given explicitly.
-
- = 2 The field polynomial is implicit.
- = 3 The field polynomial is a binomial. P>2.
- = 4 The field polynomial is a trinomial.
- = 5 The field polynomial is the quotient of a trinomial by a
- short polynomial. P=2.
- = 6 The field polynomial is a pentanomial. P=2.
-
- Flags A and B apply to the elliptic curve parameters.
-
-
-
-
-
-
-R. Schroeppel, et al [Page 5]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- A = 1 When P>=5, the curve parameter A is negated. If P=2, then
- A=1 indicates that the A parameter is special. See the
- ALTA parameter below, following A. The combination A=1,
- P=3 is forbidden.
-
- B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
- then B=1 indicates an alternate elliptic curve equation is
- used. When P=2 and B=1, an additional curve parameter C
- is present.
-
- The Z bit SHOULD be set to zero on creation of an RR and MUST be
- ignored when processing an RR (when S=0).
-
- Most of the remaining parameters are present in some formats and
- absent in others. The presence or absence of a parameter is
- determined entirely by the flags. When a parameter occurs, it is in
- the order defined by the picture.
-
- Of the remaining parameters, PFHKQABCGY are variable length. When
- present, each is preceded by a one-octet length field as shown in the
- diagram above. The length field does not include itself. The length
- field may have values from 0 through 110. The parameter length in
- octets is determined by a conditional formula: If LL<=64, the
- parameter length is LL. If LL>64, the parameter length is 16 times
- (LL-60). In some cases, a parameter value of 0 is sensible, and MAY
- be represented by an LL value of 0, with the data field omitted. A
- length value of 0 represents a parameter value of 0, not an absent
- parameter. (The data portion occupies 0 space.) There is no
- requirement that a parameter be represented in the minimum number of
- octets; high-order 0 octets are allowed at the front end. Parameters
- are always right adjusted, in a field of length defined by LL. The
- octet-order is always most-significant first, least-significant last.
- The parameters H and K may have an optional sign bit stored in the
- unused high-order bit of their length fields.
-
- LP defines the length of the prime P. P must be an odd prime. The
- parameters LP,P are present if and only if the flag M=1. If M=0, the
- prime is 2.
-
- LF,F define an explicit field polynomial. This parameter pair is
- present only when FMT = 1. The length of a polynomial coefficient is
- ceiling(log2 P) bits. Coefficients are in the numerical range
- [0,P-1]. The coefficients are packed into fixed-width fields, from
- higher order to lower order. All coefficients must be present,
- including any 0s and also the leading coefficient (which is required
- to be 1). The coefficients are right justified into the octet string
- of length specified by LF, with the low-order "constant" coefficient
- at the right end. As a concession to storage efficiency, the higher
- order bits of the leading coefficient may be elided, discarding high-
- order 0 octets and reducing LF. The degree is calculated by
-
-
-R. Schroeppel, et al [Page 6]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- determining the bit position of the left most 1-bit in the F data
- (counting the right most bit as position 0), and dividing by
- ceiling(log2 P). The division must be exact, with no remainder. In
- this format, all of the other degree and field parameters are
- omitted. The next parameters will be LQ,Q.
-
- If FMT>=2, the degree of the field extension is specified explicitly,
- usually along with other parameters to define the field polynomial.
-
- DEG is a two octet field that defines the degree of the field
- extension. The finite field will have P^DEG elements. DEG is
- present when FMT>=2.
-
- When FMT=2, the field polynomial is specified implicitly. No other
- parameters are required to define the field; the next parameters
- present will be the LQ,Q pair. The implicit field poynomial is the
- lexicographically smallest irreducible (mod P) polynomial of the
- correct degree. The ordering of polynomials is by highest-degree
- coefficients first -- the leading coefficient 1 is most important,
- and the constant term is least important. Coefficients are ordered
- by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial
- of degree D is X^D (which is not irreducible). The next is X^D+1,
- which is sometimes irreducible, followed by X^D-1, which isn't.
- Assuming odd P, this series continues to X^D - (P-1)/2, and then goes
- to X^D + X, X^D + X + 1, X^D + X - 1, etc.
-
- When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
- odd. The polynomial is determined by the degree and the low order
- term K. Of all the field parameters, only the LK,K parameters are
- present. The high-order bit of the LK octet stores on optional sign
- for K; if the sign bit is present, the field polynomial is X^DEG - K.
-
- When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
- K. When P=2, the H and K parameters are implicitly 1, and are
- omitted from the representation. Only DEG and DEGH are present; the
- next parameters are LQ,Q. When P>2, then LH,H and LK,K are
- specified. Either or both of LH, LK may contain a sign bit for its
- parameter.
-
- When FMT=5, then P=2 (only). The field polynomial is the exact
- quotient of a trinomial divided by a small polynomial, the trinomial
- divisor. The small polynomial is right-adjusted in the two octet
- field TRDV. DEG specifies the degree of the field. The degree of
- TRDV is calculated from the position of the high-order 1 bit. The
- trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
- DEGH is 0, the middle term is omitted from the trinomial. The
- quotient must be exact, with no remainder.
-
- When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
- with the degrees of the middle terms given by the three 2-octet
-
-
-R. Schroeppel, et al [Page 7]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
- X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
- > DEGJ > 0.
-
- DEGH, DEGI, DEGJ are two-octet fields that define the degree of
- a term in a field polynomial. DEGH is present when FMT = 4,
- 5, or 6. DEGI and DEGJ are present only when FMT = 6.
-
- TRDV is a two-octet right-adjusted binary polynomial of degree <
- 16. It is present only for FMT=5.
-
- LH and H define the H parameter, present only when FMT=4 and P
- is odd. The high bit of LH is an optional sign bit for H.
-
- LK and K define the K parameter, present when FMT = 3 or 4, and
- P is odd. The high bit of LK is an optional sign bit for K.
-
- The remaining parameters are concerned with the elliptic curve and
- the signature algorithm.
-
- LQ defines the length of the prime Q. Q is a prime > 2^159.
-
- In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
- member of the pair is an element from the finite field defined
- earlier. The length field defines a long octet string. Field
- elements are represented as (mod P) polynomials of degree < DEG, with
- DEG or fewer coefficients. The coefficients are stored from left to
- right, higher degree to lower, with the constant term last. The
- coefficients are represented as integers in the range [0,P-1]. Each
- coefficient is allocated an area of ceiling(log2 P) bits. The field
- representation is right-justified; the "constant term" of the field
- element ends at the right most bit. The coefficients are fitted
- adjacently without regard for octet boundaries. (Example: if P=5,
- three bits are used for each coefficient. If the field is GF[5^75],
- then 225 bits are required for the coefficients, and as many as 29
- octets may be needed in the data area. Fewer octets may be used if
- some high-order coefficients are 0.) If a flag requires a field
- element to be negated, each non-zero coefficient K is replaced with
- P-K. To save space, 0 bits may be removed from the left end of the
- element representation, and the length field reduced appropriately.
- This would normally only happen with A,B,C, because the designer
- chose curve parameters with some high-order 0 coefficients or bits.
-
- If the finite field is simply (mod P), then the field elements are
- simply numbers (mod P), in the usual right-justified notation. If
- the finite field is GF[2^D], the field elements are the usual right-
- justified polynomial basis representation.
-
-
-
-
-
-R. Schroeppel, et al [Page 8]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- LA,A is the first parameter of the elliptic curve equation.
- When P>=5, the flag A = 1 indicates A should be negated (mod
- P). When P=2 (indicated by the flag M=0), the flag A = 1
- indicates that the parameter pair LA,A is replaced by the two
- octet parameter ALTA. In this case, the parameter A in the
- curve equation is x^ALTA, where x is the field generator.
- Parameter A often has the value 0, which may be indicated by
- LA=0 (with no A data field), and sometimes A is 1, which may
- be represented with LA=1 and a data field of 1, or by setting
- the A flag and using an ALTA value of 0.
-
- LB,B is the second parameter of the elliptic curve equation.
- When P>=5, the flag B = 1 indicates B should be negated (mod
- P). When P=2 or 3, the flag B selects an alternate curve
- equation.
-
- LC,C is the third parameter of the elliptic curve equation,
- present only when P=2 (indicated by flag M=0) and flag B=1.
-
- LG,G defines a point on the curve, of order Q. The W-coordinate
- of the curve point is given explicitly; the Z-coordinate is
- implicit.
-
- LY,Y is the user's public signing key, another curve point of
- order Q. The W-coordinate is given explicitly; the Z-
- coordinate is implicit. The LY,Y parameter pair is always
- present.
-
-
-
-3. The Elliptic Curve Equation
-
- (The coordinates of an elliptic curve point are named W,Z instead of
- the more usual X,Y to avoid confusion with the Y parameter of the
- signing key.)
-
- The elliptic curve equation is determined by the flag octet, together
- with information about the prime P. The primes 2 and 3 are special;
- all other primes are treated identically.
-
- If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
- + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
- If A and/or B is negative (i.e., in the range from P/2 to P), and
- P>=5, space may be saved by putting the sign bit(s) in the A and B
- bits of the flags octet, and the magnitude(s) in the parameter
- fields.
-
- If M=1 and P=3, the B flag has a different meaning: it specifies an
- alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
- the right-hand-side is different. When P=3, this equation is more
-
-
-R. Schroeppel, et al [Page 9]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- commonly used.
-
- If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
- A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
- parameter can often be 0 or 1, or be chosen as a single-1-bit value.
- The flag B is used to select an alternate curve equation, Z^2 + C*Z =
- W^3 + A*W + B. This is the only time that the C parameter is used.
-
-
-
-4. How do I Compute Q, G, and Y?
-
- The number of points on the curve is the number of solutions to the
- curve equation, + 1 (for the "point at infinity"). The prime Q must
- divide the number of points. Usually the curve is chosen first, then
- the number of points is determined with Schoof's algorithm. This
- number is factored, and if it has a large prime divisor, that number
- is taken as Q.
-
- G must be a point of order Q on the curve, satisfying the equation
-
- Q * G = the point at infinity (on the elliptic curve)
-
- G may be chosen by selecting a random [RFC 1750] curve point, and
- multiplying it by (number-of-points-on-curve/Q). G must not itself
- be the "point at infinity"; in this astronomically unlikely event, a
- new random curve point is recalculated.
-
- G is specified by giving its W-coordinate. The Z-coordinate is
- calculated from the curve equation. In general, there will be two
- possible Z values. The rule is to choose the "positive" value.
-
- In the (mod P) case, the two possible Z values sum to P. The smaller
- value is less than P/2; it is used in subsequent calculations. In
- GF[P^D] fields, the highest-degree non-zero coefficient of the field
- element Z is used; it is chosen to be less than P/2.
-
- In the GF[2^N] case, the two possible Z values xor to W (or to the
- parameter C with the alternate curve equation). The numerically
- smaller Z value (the one which does not contain the highest-order 1
- bit of W (or C)) is used in subsequent calculations.
-
- Y is specified by giving the W-coordinate of the user's public
- signature key. The Z-coordinate value is determined from the curve
- equation. As with G, there are two possible Z values; the same rule
- is followed for choosing which Z to use.
-
-
-
-
-
-
-R. Schroeppel, et al [Page 10]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- During the key generation process, a random [RFC 1750] number X must
- be generated such that 1 <= X <= Q-1. X is the private key and is
- used in the final step of public key generation where Y is computed
- as
-
- Y = X * G (as points on the elliptic curve)
-
- If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
- in the (mod P) case, or the high-order non-zero coefficient of Z >
- P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
- GF[2^N] case), then X must be replaced with Q-X. This will
- correspond to the correct Z-coordinate.
-
-
-
-5. Performance Considerations
-
- Elliptic curve signatures use smaller moduli or field sizes than RSA
- and DSA. Creation of a curve is slow, but not done very often. Key
- generation is faster than RSA or DSA.
-
- DNS implementations have been optimized for small transfers,
- typically less than 512 octets including DNS overhead. Larger
- transfers will perform correctly and and extensions have been
- standardized to make larger transfers more efficient [RFC 2671].
- However, it is still advisable at this time to make reasonable
- efforts to minimize the size of RR sets stored within the DNS
- consistent with adequate security.
-
-
-
-6. Security Considerations
-
- Many of the general security consideration in [RFC 2535] apply. Some
- specific key generation considerations are given above. Of course,
- the elliptic curve key stored in the DNS for an entity should not be
- trusted unless it has been obtain via a trusted DNS resolver that
- vouches for its security or unless the application using the key has
- done a similar authentication.
-
-
-
-7. IANA Considerations
-
- Assignment of meaning to the remaining ECC data flag bits or to
- values of ECC fields outside the ranges for which meaning in defined
- in this document requires an IETF consensus as defined in [RFC 2434].
-
-
-
-
-
-R. Schroeppel, et al [Page 11]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-Informational References
-
- [RFC 1034] - P. Mockapetris, "Domain names - concepts and
- facilities", 11/01/1987.
-
- [RFC 1035] - P. Mockapetris, "Domain names - implementation and
- specification", 11/01/1987.
-
- [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness
- Recommendations for Security", 12/29/1994.
-
- [RFC 2535] - D. Eastlake,"Domain Name System Security Extensions",
- March 1999.
-
- [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August
- 1999.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C", 1996, John Wiley and Sons
-
- [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
- Cryptosystems", 1993 Kluwer.
-
- [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves",
- 1986, Springer Graduate Texts in mathematics #106.
-
-
-
-Normative Refrences
-
- [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", March 1997.
-
- [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", October 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 12]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-Authors' Addresses
-
- Rich Schroeppel
- 500 S. Maple Drive
- Woodland Hills, UT 84653 USA
-
- Telephone: 1-801-423-7998(h)
- 1-505-844-9079(w)
- Email: rcs@cs.arizona.edu
- rschroe@sandia.gov
-
-
- Donald E. Eastlake 3rd
- Motorola
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-634-2066 (h)
- +1 508-851-8280 (w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in February 2004.
-
- Its file name is draft-ietf-dnsext-ecc-key-04.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 13]
-\f
+++ /dev/null
-
-
-
-
-
-
- DNSIND Working Group Paul Vixie
- INTERNET-DRAFT ISC
- <draft-ietf-dnsext-edns1-03.txt> August, 2002
-
-
- Extensions to DNS (EDNS1)
-
-
- 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 specifies a number of extensions within the Extended
- DNS framework defined by [EDNS0], including several new extended
- label types and the ability to ask multiple questions in a single
- request.
-
- 1 - Rationale and Scope
-
- 1.1. EDNS (see [RFC2671]) specifies an extension mechanism to DNS (see
- [RFC1035]) which provides for larger message sizes, additional label
- types, and new message flags.
-
- 1.2. This document makes use of the EDNS extension mechanisms to add the
- ability to ask multiple questions in a single request.
-
-
-
-
- Expires March 2003 [Page 1]
-\f
- INTERNET-DRAFT EDNS1 August, 2002
-
-
- 2 - Affected Protocol Elements
-
- 2.1. Multiple queries in a question section have not been supported in
- DNS due the applicability of some DNS Message Header flags (such as AA)
- and of the RCODE field only to a single QNAME, QTYPE, and QCLASS.
- Multiple questions per request are desirable, and some way of asking
- them must be made available.
-
- 3 - OPT pseudo-RR Flags and Options
-
- 3.1. The extended RCODE and flags are structured as follows:
-
- +0 (MSB) +1 (LSB)
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 0: | extended-rcode | VERSION |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- 2: |md |FM |RRD|lm | z |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
- VERSION Indicates the implementation level of whoever sets it. Full
- conformance with the draft standard version of this
- specification is version ``1.'' Note that both requestors and
- responders should set this to the highest level they implement,
- that responders should send back RCODE=BADVERS and that
- requestors should be prepared to probe using lower version
- numbers if they receive an RCODE=BADVERS.
-
- FM ``First match'' flag. Notable only when multiple questions are
- present. If set in a request, questions will be processed in
- wire order and the first question whose answer would have
- NOERROR AND ANCOUNT>0 is treated as if it were the only
- question in the query message. Otherwise, questions can be
- processed in any order and all possible answer records will be
- included in the response. Response FM should be ignored by
- requestors.
-
- RRD ``Recursion really desired'' flag. Notable only when a request
- is processed by an intermediate name server (``forwarder'') who
- is not authoritative for the zone containing QNAME, and where
- QTYPE=ANY or QDCOUNT>1. If set in a request, the intermediate
- name server can only answer using unexpired cached answers
- (either positive or negative) which were atomically acquired
- using (a) the same QTYPE or set of QTYPEs present in the
- current question and whose TTLs were each minimized to the
-
-
-
- Expires March 2003 [Page 2]
-\f
- INTERNET-DRAFT EDNS1 August, 2002
-
-
- smallest among them when first cached, and (b) the same FM and
- LM settings present in the current question.
-
- Z Set to zero by senders and ignored by receivers, unless
- modified in a subsequent specification.
-
- 4 - Multiple Questions for QUERY
-
- 4.1. If QDCOUNT>1, multiple questions are present. All questions must
- be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It
- is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY.
-
- 4.2. RCODE and AA apply to all RRs in the answer section having the
- QNAME that is shared by all questions in the question section. AA
- applies to all matching answers, and will not be set unless the exact
- original request was processed by an authoritative server and the
- response forwarded in its entirety.
-
- 4.3. If a multiple question request is processed by an intermediate
- server and the authority server does not support multiple questions, the
- intermediate server must generate an answer iteratively by making
- multiple requests of the authority server. In this case, AA must never
- be set in the final answer due to lack of atomicity of the contributing
- authoritative responses.
-
- 4.4. If iteratively processing a multiple question request using an
- authority server which can only process single question requests, if any
- contributing request generates a SERVFAIL response, then the final
- response's RCODE should be SERVFAIL.
-
- 4.5. An authority server processing a query for which QDCOUNT>1 will
- respond with a delegation or referral if any of the multiple QTYPEs
- present would yield such a response when QDCOUNT==1.
-
- 4.6. An initiator can infer the absence of any RRs for one of the QTYPEs
- where QDCOUNT>1 if the response contains no RRs of that type but some
- RRs for one of the other QTYPEs present.
-
-
-
-
-
-
-
-
-
-
-
- Expires March 2003 [Page 3]
-\f
- INTERNET-DRAFT EDNS1 August, 2002
-
-
- 5 - References
-
- [RFC1035] P. Mockapetris, ``Domain Names - Implementation and
- Specification,'' RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [RFC2671] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671,
- IETF DNSIND, September 1998
-
- 6 - Author's Address
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063
- +1.650.779.7001
- <vixie@isc.org>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Expires March 2003 [Page 4]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Stuart Kwan
-<draft-ietf-dnsext-gss-tsig-06.txt> Praerit Garg
-February 28, 2003 James Gilroy
-Expires August 28, 2003 Levon Esibov
- Jeff Westhead
- Microsoft Corp.
- Randy Hall
- Lucent Technologies
-
-
-
- GSS Algorithm for TSIG (GSS-TSIG)
-
-
-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
-
-The TSIG protocol provides transaction level authentication for DNS.
-TSIG is extensible through the definition of new algorithms. This
-document specifies an algorithm based on the Generic Security Service
-Application Program Interface (GSS-API) (RFC2743). This document updates
-RFC 2845.
-
-
-
-
-
-
-
-
-
-
-
-Expires August 28, 2003 [Page 1]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-Table of Contents
-
-1: Introduction......................................................2
-2: Algorithm Overview................................................3
- 2.1: GSS Details...................................................4
- 2.2: Modifications to the TSIG protocol (RFC 2845).................4
-3: Client Protocol Details...........................................4
- 3.1: Negotiating Context...........................................5
- 3.1.1: Call GSS_Init_sec_context.................................5
- 3.1.2: Send TKEY Query to Server.................................7
- 3.1.3: Receive TKEY Query-Response from Server...................7
- 3.2: Context Established..........................................10
- 3.2.1: Terminating a Context....................................10
-4: Server Protocol Details..........................................10
- 4.1: Negotiating Context..........................................10
- 4.1.1: Receive TKEY Query from Client...........................11
- 4.1.2: Call GSS_Accept_sec_context..............................11
- 4.1.3: Send TKEY Query-Response to Client.......................12
- 4.2: Context Established..........................................13
- 4.2.1: Terminating a Context....................................13
-5: Sending and Verifying Signed Messages............................14
- 5.1: Sending a Signed Message - Call GSS_GetMIC...................14
- 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............15
-6: Example usage of GSS-TSIG algorithm..............................16
-7: Security Considerations..........................................20
-8: IANA Considerations..............................................20
-9: Conformance......................................................20
-10:Acknowledgements.................................................20
-11:References.......................................................20
-
-1. Introduction
-
-The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
-protocol was developed to provide a lightweight authentication and
-integrity of messages between two DNS entities, such as client and
-server or server and server. TSIG can be used to protect dynamic
-update messages, authenticate regular message or to off-load
-complicated DNSSEC [RFC2535] processing from a client to a server and
-still allow the client to be assured of the integrity of the answers.
-
-The TSIG protocol [RFC2845] is extensible through the definition of new
-algorithms. This document specifies an algorithm based on the Generic
-Security Service Application Program Interface (GSS-API) [RFC2743].
-GSS-API is a framework that provides an abstraction of security to the
-application protocol developer. The security services offered can
-include authentication, integrity, and confidentiality.
-
-The GSS-API framework has several benefits:
-* Mechanism and protocol independence. The underlying mechanisms that
-realize the security services can be negotiated on the fly and varied
-over time. For example, a client and server MAY use Kerberos [RFC1964]
-for one transaction, whereas that same server MAY use SPKM [RFC2025]
-with a different client.
-
-Expires August 28, 2003 [Page 2]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-* The protocol developer is removed from the responsibility of
-creating and managing a security infrastructure. For example, the
-developer does not need to create new key distribution or key
-management systems. Instead the developer relies on the security
-service mechanism to manage this on its behalf.
-
-The scope of this document is limited to the description of an
-authentication mechanism only. It does not discuss and/or propose an
-authorization mechanism. Readers that are unfamiliar with GSS-API
-concepts are encouraged to read the characteristics and concepts section
-of [RFC2743] before examining this protocol in detail. It is also
-assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034]
-and [RFC1035].
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-"RECOMMENDED", and "MAY" in this document are to be interpreted as
-described in RFC 2119 [RFC2119].
-
-
-2. Algorithm Overview
-
-In GSS, client and server interact to create a "security context".
-The security context can be used to create and verify transaction
-signatures on messages between the two parties. A unique security
-context is required for each unique connection between client and
-server.
-
-Creating a security context involves a negotiation between client and
-server. Once a context has been established, it has a finite lifetime
-for which it can be used to secure messages. Thus there are three
-states of a context associated with a connection:
-
- +----------+
- | |
- V |
- +---------------+ |
- | Uninitialized | |
- | | |
- +---------------+ |
- | |
- V |
- +---------------+ |
- | Negotiating | |
- | Context | |
- +---------------+ |
- | |
- V |
- +---------------+ |
- | Context | |
- | Established | |
- +---------------+ |
- | |
- +----------+
-
-Expires August 28, 2003 [Page 3]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-Every connection begins in the uninitialized state.
-
-
-2.1 GSS Details
-
-Client and server MUST be locally authenticated and have acquired
-default credentials before using this protocol as specified in
-Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
-
-The GSS-TSIG algorithm consists of two stages:
-
-I. Establish security context. The Client and Server use the
-GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate the
-tokens that they pass to each other using [RFC2930] as a transport
-mechanism.
-
-II. Once the security context is established it is used to generate and
-verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. These
-signatures are exchanged by the Client and Server as a part of the TSIG
-records exchanged in DNS messages sent between the Client and Server,
-as described in [RFC2845].
-
-
-2.2 Modifications to the TSIG protocol (RFC 2845)
-
-Modification to RFC 2845 allows use of TSIG through signing server's
-response in an explicitly specified place in multi message exchange
-between two DNS entities even if client's request wasn't signed.
-
-Specifically Section 4.2 of RFC 2845 MUST be modified as follows.
-
-Replace:
-"The server MUST not generate a signed response to an unsigned
-request."
-
-With:
-"The server MUST not generate a signed response to an unsigned request,
-except in case of response to client's unsigned TKEY query if secret
-key is established on server side after server processed client's
-query. Signing responses to unsigned TKEY queries MUST be explicitly
-specified in the description of an individual secret key establishment
-algorithm."
-
-
-
-3. Client Protocol Details
-
-A unique context is required for each server to which the client sends
-secure messages. A context is identified by a context handle. A
-client maintains a mapping of servers to handles,
-
- (target_name, key_name, context_handle)
-
-Expires August 28, 2003 [Page 4]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-The value key_name also identifies a context handle. The key_name is
-the owner name of the TKEY and TSIG records sent between a client and a
-server to indicate to each other which context MUST be used to process
-the current request.
-
-DNS client and server MAY use various underlying security mechanisms to
-establish security context as described in sections 3 and 4. At the
-same time, in order to guarantee interoperability between DNS clients
-and servers that support GSS-TSIG it is REQUIRED that security
-mechanism used by client enables use of Kerberos v5 (see Section 9
-for more information).
-
-
-3.1 Negotiating Context
-
-In GSS, establishing a security context involves the passing of opaque
-tokens between the client and the server. The client generates the
-initial token and sends it to the server. The server processes the
-token and if necessary, returns a subsequent token to the client. The
-client processes this token, and so on, until the negotiation is
-complete. The number of times the client and server exchange tokens
-depends on the underlying security mechanism. A completed negotiation
-results in a context handle.
-
-The TKEY resource record [RFC2930] is used as the vehicle to transfer
-tokens between client and server. The TKEY record is a general
-mechanism for establishing secret keys for use with TSIG. For more
-information, see [RFC2930].
-
-
-3.1.1 Call GSS_Init_sec_context
-
-To obtain the first token to be sent to a server, a client MUST call
-GSS_Init_sec_context API.
-The following input parameters MUST be used. The outcome of the call is
-indicated with the output values below. Consult Sections 2.2.1
-"GSS_Init_sec_context call" of [RFC2743] for syntax definitions.
-
- INPUTS
- CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
- default"). Client MAY instead specify some other valid handle
- to its credentials.
- CONTEXT HANDLE input_context_handle = 0
- INTERNAL NAME targ_name = "DNS@<target_server_name>"
- OBJECT IDENTIFIER mech_type = Underlying security
- mechanism chosen by implementers. To guarantee
- interoperability of the implementations of the GSS-TSIG
- mechanism client MUST specify a valid underlying security
- mechanism that enables use of Kerberos v5 (see Section 9 for
- more information).
- OCTET STRING input_token = NULL
- BOOLEAN replay_det_req_flag = TRUE
-
-Expires August 28, 2003 [Page 5]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
- BOOLEAN mutual_req_flag = TRUE
- BOOLEAN deleg_req_flag = TRUE
- BOOLEAN sequence_req_flag = TRUE
- BOOLEAN anon_req_flag = FALSE
- BOOLEAN integ_req_flag = TRUE
- INTEGER lifetime_req = 0 (0 requests a default
- value). Client MAY instead specify another upper bound for the
- lifetime of the context to be established in seconds.
- OCTET STRING chan_bindings = Any valid channel bindings
- as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
- OUTPUTS
- INTEGER major_status
- CONTEXT HANDLE output_context_handle
- OCTET STRING output_token
- BOOLEAN replay_det_state
- BOOLEAN mutual_state
- INTEGER minor_status
- OBJECT IDENTIFIER mech_type
- BOOLEAN deleg_state
- BOOLEAN sequence_state
- BOOLEAN anon_state
- BOOLEAN trans_state
- BOOLEAN prot_ready_state
- BOOLEAN conf_avail
- BOOLEAN integ_avail
- INTEGER lifetime_rec
-
-If returned major_status is set to one of the following errors
-
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_DEFECTIVE_CREDENTIAL
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_NO_CRED
- GSS_S_CREDENTIALS_EXPIRED
- GSS_S_BAD_BINDINGS
- GSS_S_OLD_TOKEN
- GSS_S_DUPLICATE_TOKEN
- GSS_S_NO_CONTEXT
- GSS_S_BAD_NAMETYPE
- GSS_S_BAD_NAME
- GSS_S_BAD_MECH
- GSS_S_FAILURE
-
-then the the client MUST abandon the algorithm and MUST NOT use the
-GSS-TSIG algorithm to establish this security contex. This document
-does not prescribe which other mechanism could be used to establish
-a security context. Next time when this client needs to establish
-security context, the client MAY use GSS-TSIG algorithm.
-
-Success values of major_status are GSS_S_CONTINUE_NEEDED and
-GSS_S_COMPLETE. The exact success code is important during later
-processing.
-
-Expires August 28, 2003 [Page 6]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-The values of replay_det_state and mutual_state indicate if the
-security package provides replay detection and mutual authentication,
-respectively. If returned major_status is GSS_S_COMPLETE AND one or both
-of these values are FALSE, the client MUST abandon this algorithm.
-
-Client's behavior MAY depend on other OUTPUT parameters according
-to the policy local to the client.
-
-The handle output_context_handle is unique to this negotiation and
-is stored in the client's mapping table as the context_handle that
-maps to target_name.
-
-
-
-3.1.2 Send TKEY Query to Server
-
-An opaque output_token returned by GSS_Init_sec_context is transmitted
-to the server in a query request with QTYPE=TKEY. The token itself
-will be placed in a Key Data field of the RDATA field in the TKEY
-resource record in the additional records section of the query. The
-owner name of the TKEY resource record set queried for and the owner
-name of the supplied TKEY resource record in the additional records
-section MUST be the same. This name uniquely identifies the security
-context to both the client and server, and thus the client SHOULD use
-a value which is globally unique as described in [RFC2930]. To achieve
-global uniqueness, the name MAY contain a UUID/GUID [ISO11578].
-
- TKEY Record
- NAME = client-generated globally unique domain name string
- (as described in [RFC2930])
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
- Key Data = output_token
-
-The remaining fields in the TKEY RDATA, i.e. Inception, Expiration,
-Error, Other Size and Data Fields, MUST be set according to [RFC2930].
-
-The query is transmitted to the server.
-
-Note: if the original client call to GSS_Init_sec_context returned any
-major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then
-the client MUST NOT send TKEY query. Client's behavior in this case is
-described above in Section 3.1.1.
-
-
-3.1.3 Receive TKEY Query-Response from Server
-
-Upon the reception of the TKEY query DNS server MUST respond according
-to the description in Section 4. This Section specifies the behavior
-of the client after it receives the matching response to its query.
-
-Expires August 28, 2003 [Page 7]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-The next processing step depends on the value of major_status from the
-most recent call that client performed to GSS_Init_sec_context: either
-GSS_S_COMPLETE or GSS_S_CONTINUE.
-
-
-3.1.3.1 Value of major_status == GSS_S_COMPLETE
-
-If the last call to GSS_Init_sec_context yielded a major_status value
-of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
-then the client side component of the negotiation is complete and the
-client is awaiting confirmation from the server.
-
-Confirmation is in the form of a query response with RCODE=NOERROR
-and with the last client supplied TKEY record in the answer section
-of the query. The response MUST be signed with a TSIG record. Note
-that server is allowed to sign a response to unsigned client's query
-due to modification to the RFC 2845 specified in Section 2.2 above.
-The signature in the TSIG record MUST be verified using the procedure
-detailed in section 5, Sending and Verifying Signed Messages. If the
-response is not signed, OR if the response is signed but signature is
-invalid, then an attacker has tampered with the message in transit or
-has attempted to send the client a false response. In this case the
-client MAY continue waiting for a response to its last TKEY query until
-the time period since the client sent last TKEY query expires. Such a
-time period is specified by the policy local to the client. This is a
-new option that allows DNS client to accept multiple answers for one
-query ID and select one (not necessarily the first one) based on some
-criteria.
-
-If the signature is verified the context state is advanced to Context
-Established. Proceed to section 3.2 for usage of the security context.
-
-
-3.1.3.2 Value of major_status == GSS_S_CONTINUE
-
-If the last call to GSS_Init_sec_context yielded a major_status value
-of GSS_S_CONTINUE, then the negotiation is not yet complete. The server
-will return to the client a query-response with a TKEY record in the
-Answer section. If the DNS message error is not NO_ERROR or error field
-in the TKEY record is not 0 (i.e. no error), then the client MUST
-abandon this negotiation sequence. The client MUST delete an active
-context by calling GSS_Delete_sec_context providing the associated
-context_handle. The client MAY repeat the negotiation sequence starting
-with the uninitialized state as described in section 3.1. To prevent
-infinite looping the number of attempts to establish a security context
-MUST be limited to ten or less.
-
-If the DNS message error is NO_ERROR and error filed in the TKEY record
-is 0 (i.e. no error), then the client MUST pass a token specified in the
-Key Data field in the TKEY resource record to GSS_Init_sec_context
-using the same parameters values as in previous call except values for
-CONTEXT HANDLE input_context_handle and OCTET STRING input_token as
-described below:
-
-Expires August 28, 2003 [Page 8]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
- INPUTS
- CONTEXT HANDLE input_context_handle = context_handle (this is the
- context_handle corresponding to the key_name which is the
- owner name of the TKEY record in the answer section in the
- TKEY query response)
- OCTET STRING input_token = token from Key field of
- TKEY record
-
-Depending on the following OUTPUT values of GSS_Init_sec_context
- INTEGER major_status
- OCTET STRING output_token
-the client MUST take one of the following actions:
-
-If OUTPUT major_status is set to one of the following values
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_DEFECTIVE_CREDENTIAL
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_NO_CRED
- GSS_S_CREDENTIALS_EXPIRED
- GSS_S_BAD_BINDINGS
- GSS_S_OLD_TOKEN
- GSS_S_DUPLICATE_TOKEN
- GSS_S_NO_CONTEXT
- GSS_S_BAD_NAMETYPE
- GSS_S_BAD_NAME
- GSS_S_BAD_MECH
- GSS_S_FAILURE
-
-the client MUST abandon this negotiation sequence. This means that the
-client MUST delete an active context by calling GSS_Delete_sec_context
-providing the associated context_handle. The client MAY repeat the
-negotiation sequence starting with the uninitialized state as described
-in section 3.1. To prevent infinite looping the number of attempts to
-establish a security context MUST be limited to ten or less.
-
-If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then
-client MUST act as described below.
-
-If the response from the server was signed, and the OUTPUT major_status
-is GSS_S_COMPLETE,then the signature in the TSIG record MUST be verified
-using the procedure detailed in section 5, Sending and Verifying Signed
-Messages. If the signature is invalid, then the client MUST abandon this
-negotiation sequence. This means that the client MUST delete an active
-context by calling GSS_Delete_sec_context providing the associated
-context_handle. The client MAY repeat the negotiation sequence starting
-with the uninitialized state as described in section 3.1. To prevent
-infinite looping the number of attempts to establish a security context
-MUST be limited to ten or less.
-
-If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
-finished. The token output_token MUST be passed to the server in a TKEY
-record by repeating the negotiation sequence beginning with section
-
-Expires August 28, 2003 [Page 9]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-3.1.2. The client MUST place a limit on the number of continuations in
-a context negotiation to prevent endless looping. Such limit SHOULD NOT
-exceed value of 10.
-
-If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
-client-side component of the negotiation is complete but the token
-output_token MUST be passed to the server by repeating the negotiation
-sequence beginning with section 3.1.2.
-
-If major_status is GSS_S_COMPLETE and output_token is NULL, context
-negotiation is complete. The context state is advanced to Context
-Established. Proceed to section 3.2 for usage of the security context.
-
-
-3.2 Context Established
-
-When context negotiation is complete, the handle context_handle MUST be
-used for the generation and verification of transaction signatures.
-
-The procedures for sending and receiving signed messages are described
-in section 5, Sending and Verifying Signed Messages.
-
-
-3.2.1 Terminating a Context
-
-When the client is not intended to continue using the established
-security context, the client SHOULD delete an active context by
-calling GSS_Delete_sec_context providing the associated context_handle,
-AND client SHOULD delete the established context on the DNS server
-by using TKEY RR with the Mode field set to 5, i.e. "key deletion"
-[RFC2930].
-
-
-
-4. Server Protocol Details
-
-As on the client-side, the result of a successful context negotiation
-is a context handle used in future generation and verification of the
-transaction signatures.
-
-A server MAY be managing several contexts with several clients.
-Clients identify their contexts by providing a key name in their
-request. The server maintains a mapping of key names to handles:
-
- (key_name, context_handle)
-
-
-
-4.1 Negotiating Context
-
-A server MUST recognize TKEY queries as security context negotiation
-messages.
-
-Expires August 28, 2003 [Page 10]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-4.1.1 Receive TKEY Query from Client
-
-Upon receiving a query with QTYPE = TKEY, the server MUST examine
-whether the Mode and Algorithm Name fields of the TKEY record in the
-additional records section of the message contain values of 3 and
-gss-tsig, respectively. If they do, then the (key_name, context_handle)
-mapping table is searched for the key_name matching the owner name of
-the TKEY record in the additional records section of the query. If the
-name is found in the table and the security context for this name is
-established and not expired, then the server MUST respond to the query
-with BADNAME error in the TKEY error field. If the name is found in the
-table and the security context is not established, the corresponding
-context_handle is used in subsequent GSS operations. If the name is
-found but the security context is expired, then the server deletes this
-security context, as described in Section 4.2.1, and interprets this
-query as a start of new security context negotiation and performs
-operations described in Section 4.1.2 and 4.1.3. If the name is not
-found, then the server interprets this query as a start of new security
-context negotiation and performs operations described in Section 4.1.2
-and 4.1.3.
-
-
-
-4.1.2 Call GSS_Accept_sec_context
-
-The server performs its side of a context negotiation by calling
-GSS_Accept_sec_context. The following input parameters MUST be used. The
-outcome of the call is indicated with the output values below. Consult
-Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743[RFC2743]
-for syntax definitions.
-
- INPUTS
- CONTEXT HANDLE input_context_handle = 0 if new negotiation,
- context_handle matching
- key_name if ongoing negotiation
- OCTET STRING input_token = token specified in the Key
- field from TKEY RR (from Additional records Section of
- the client's query)
- CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
- default"). Server MAY instead specify some other valid handle
- to its credentials.
- OCTET STRING chan_bindings = Any valid channel bindings
- as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
- OUTPUTS
- INTEGER major_status
- CONTEXT_HANDLE output_context_handle
- OCTET STRING output_token
- INTEGER minor_status
- INTERNAL NAME src_name
- OBJECT IDENTIFIER mech_type
- BOOLEAN deleg_state
-
-Expires August 28, 2003 [Page 11]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
- BOOLEAN mutual_state
- BOOLEAN replay_det_state
- BOOLEAN sequence_state
- BOOLEAN anon_state
- BOOLEAN trans_state
- BOOLEAN prot_ready_state
- BOOLEAN conf_avail
- BOOLEAN integ_avail
- INTEGER lifetime_rec
- CONTEXT_HANDLE delegated_cred_handle
-
-If this is the first call to GSS_Accept_sec_context in a new
-negotiation, then output_context_handle is stored in the server's
-key-mapping table as the context_handle that maps to the name of the
-TKEY record.
-
-
-4.1.3 Send TKEY Query-Response to Client
-
-The server MUST respond to the client with a TKEY query response with
-RCODE = NOERROR, that contains a TKEY record in the answer section.
-
-If OUTPUT major_status is one of the following errors the error field
-in the TKEY record set to BADKEY.
-
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_DEFECTIVE_CREDENTIAL
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_DUPLICATE_TOKEN
- GSS_S_OLD_TOKEN
- GSS_S_NO_CRED
- GSS_S_CREDENTIALS_EXPIRED
- GSS_S_BAD_BINDINGS
- GSS_S_NO_CONTEXT
- GSS_S_BAD_MECH
- GSS_S_FAILURE
-
-If OUTPUT major_status is set to GSS_S_COMPLETE or
-GSS_S_CONTINUE_NEEDED then server MUST act as described below.
-
-If major_status is GSS_S_COMPLETE the server component of the
-negotiation is finished. If output_token is non-NULL, then it MUST be
-returned to the client in a Key Data field of the RDATA in TKEY. The
-error field in the TKEY record is set to NOERROR. The message MUST be
-signed with a TSIG record as described in section 5, Sending and
-Verifying Signed Messages. Note that server is allowed to sign a
-response to unsigned client's query due to modification to the RFC
-2845 specified in Section 2.2 above. The context state is advanced to
-Context Established. Section 4.2 discusses the usage of the security
-context.
-
-
-
-Expires August 28, 2003 [Page 12]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-If major_status is GSS_S_COMPLETE and output_token is NULL, then the
-TKEY record received from the client MUST be returned in the Answer
-section of the response. The message MUST be signed with a TSIG record
-as described in section 5, Sending and Verifying Signed Messages. Note
-that server is allowed to sign a response to unsigned client's query
-due to modification to the RFC 2845 specified in section 2.2 above. The
-context state is advanced to Context Established. Section 4.2 discusses
-the usage of the security context.
-
-If major_status is GSS_S_CONTINUE, the server component of the
-negotiation is not yet finished. The server responds to the TKEY
-query with a standard query response, placing in the answer section a
-TKEY record containing output_token in the Key Data RDATA field. The
-error field in the TKEY record is set to NOERROR. The server MUST limit
-the number of times that a given context is allowed to repeat, to
-prevent endless looping. Such limit SHOULD NOT exceed value of 10.
-
-In all cases except if major_status is GSS_S_COMPLETE and output_token
-is NULL other TKEY record fields MUST contain the following values:
- NAME = key_name
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
-
-The remaining fields in the TKEY RDATA, i.e. Inception, Expiration,
-Error, Other Size and Data Fields, MUST be set according to [RFC2930].
-
-
-
-4.2 Context Established
-
-When context negotiation is complete, the handle context_handle
-is used for the generation and verification of transaction signatures.
-The handle is valid for a finite amount of time determined by the
-underlying security mechanism. A server MAY unilaterally terminate
-a context at any time (see section 4.2.1).
-
-Server SHOULD limit the amount of memory used to cache established
-contexts.
-
-The procedures for sending and receiving signed messages are given in
-section 5, Sending and Verifying Signed Messages.
-
-
-4.2.1 Terminating a Context
-
-A server can terminate any established context at any time. The
-server MAY hint to the client that the context is being deleted by
-including a TKEY RR in a response with the Mode field set to 5, i.e.
-"key deletion" [RFC2930].
-An active context is deleted by calling GSS_Delete_sec_context
-providing the associated context_handle.
-
-Expires August 28, 2003 [Page 13]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-5. Sending and Verifying Signed Messages
-
-5.1 Sending a Signed Message - Call GSS_GetMIC
-
-The procedure for sending a signature-protected message is specified
-in [RFC2845]. The data to be passed to the signature routine includes
-the whole DNS message with specific TSIG variables appended. For the
-exact format, see [RFC2845]. For this protocol, use the following
-TSIG variable values:
-
- TSIG Record
- NAME = key_name that identifies this context
- RDATA
- Algorithm Name = gss-tsig
-
-Assign the remaining fields in the TSIG RDATA appropriate values
-as described in [RFC2845].
-
-The signature is generated by calling GSS_GetMIC. The following input
-parameters MUST be used. The outcome of the call is indicated with the
-output values specified below. Consult Sections 2.3.1 "GSS_GetMIC
-call" of the RFC 2743[RFC2743] for syntax definitions.
-
- INPUTS
- CONTEXT HANDLE context_handle = context_handle for key_name
- OCTET STRING message = outgoing message plus TSIG
- variables (per [RFC2845])
- INTEGER qop_req = 0 (0 requests a default
- value). Caller MAY instead specify other valid value (for
- details see Section 1.2.4 in [RFC2743])
-
- OUTPUTS
- INTEGER major_status
- INTEGER minor_status
- OCTET STRING per_msg_token
-
-If major_status is GSS_S_COMPLETE, then signature generation
-succeeded. The signature in per_msg_token is inserted into the
-Signature field of the TSIG RR and the message is transmitted.
-
-If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED or
-GSS_S_FAILURE the caller MUST delete the security context, return to the
-uninitialized state and SHOULD negotiate a new security context, as
-described above in Section 3.1
-
-If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry
-for key_name from the (target_ name, key_name, context_handle) mapping
-table, return to the uninitialized state and SHOULD negotiate a new
-security context, as described above in Section 3.1
-
-If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the
-GSS_GetMIC call with allowed QOP value. The number of such repetitions
-MUST be limited to prevent infinite loops.
-
-Expires August 28, 2003 [Page 14]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-5.2 Verifying a Signed Message - Call GSS_VerifyMIC
-
-The procedure for verifying a signature-protected message is specified
-in [RFC2845].
-The NAME of the TSIG record determines which context_handle maps to
-the context that MUST be used to verify the signature. If the NAME
-does not map to an established context, the server MUST send a
-standard TSIG error response to the client indicating BADKEY in the
-TSIG error field (as described in [RFC2845]).
-
-For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
- INPUTS
- CONTEXT HANDLE context_handle = context_handle for key_name
- OCTET STRING message = incoming message plus TSIG
- variables (per [RFC2845])
- OCTET STRING per_msg_token = Signature field from TSIG RR
-
- OUTPUTS
- INTEGER major_status
- INTEGER minor_status
- INTEGER qop_state
-
-If major_status is GSS_S_COMPLETE, the signature is authentic and the
-message was delivered intact. Per [RFC2845], the timer values of the
-TSIG record MUST also be valid before considering the message to be
-authentic. The caller MUST not act on the request or response in the
-message until these checks are verified.
-
-When a server is processing a client request,
-the server MUST send a standard TSIG error response to the client
-indicating BADKEY in the TSIG error field as described in [RFC2845],
-if major_status is set to one of the following values
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_DUPLICATE_TOKEN
- GSS_S_OLD_TOKEN
- GSS_S_UNSEQ_TOKEN
- GSS_S_GAP_TOKEN
- GSS_S_CONTEXT_EXPIRED
- GSS_S_NO_CONTEXT
- GSS_S_FAILURE
-
-
-If the timer values of the TSIG record are invalid, the message MUST
-NOT be considered authentic. If this error checking fails when a server
-is processing a client request, the appropriate error response MUST be
-sent to the client according to [RFC2845].
-
-
-
-
-
-
-Expires August 28, 2003 [Page 15]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-6. Example usage of GSS-TSIG algorithm
-
-This Section describes an example where a Client, client.example.com,
-and a Server, server.example.com, establish a security context according
-to the algorithm described above.
-
-
- I. Client initializes security context negotiation
- To establish a security context with a server, server.example.com, the
- Client calls GSS_Init_sec_context with the following parameters
- (Note that some INPUT and OUTPUT parameters not critical for this
- algorithm are not described in this example)
- CONTEXT HANDLE input_context_handle = 0
- INTERNAL NAME targ_name = "DNS@server.example.com"
- OCTET STRING input_token = NULL
- BOOLEAN replay_det_req_flag = TRUE
- BOOLEAN mutual_req_flag = TRUE
-
- The OUTPUTS parameters returned by GSS_Init_sec_context include
- INTEGER major_status = GSS_S_CONTINUE_NEEDED
- CONTEXT HANDLE output_context_handle context_handle
- OCTET STRING output_token output_token
- BOOLEAN replay_det_state = TRUE
- BOOLEAN mutual_state = TRUE
-
- Client verifies that replay_det_state and mutual_state values are
- TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
- success OUTPUT major_status value, client stores context_handle that
- maps to "DNS@server.example.com" and proceeds to the next step.
-
-
- II. Client sends a query with QTYPE = TKEY to server
- Client sends a query with QTYPE = TKEY for a client-generated globally
- unique domain name string, 789.client.example.com.server.example.com.
- Query contains a TKEY record in its Additional records section with
- the following fields (Note that some fields not specific to this
- algorithm are not specified)
-
- NAME = 789.client.example.com.server.example.com.
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
- Key Data = output_token
-
- After the key_name 789.client.example.com.server.example.com.
- is generated it is stored in the client's (target_name, key_name,
- context_handle) mapping table.
-
-
-
-
-
-Expires August 28, 2003 [Page 16]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
- III. Server receives a query with QTYPE = TKEY
- When server receives a query with QTYPE = TKEY, the server verifies
- that Mode and Algorithm fields in the TKEY record in the Additional
- records section of the query are set to 3 and "gss-tsig" respectively.
- It finds that the key_name 789.client.example.com.server.example.com.
- is not listed in its (key_name, context_handle) mapping table.
-
-
- IV. Server calls GSS_Accept_sec_context
- To continue security context negotiation server calls
- GSS_Accept_sec_context with the following parameters (Note that some
- INPUT and OUTPUT parameters not critical for this algorithm are not
- described in this example)
- INPUTS
- CONTEXT HANDLE input_context_handle = 0
- OCTET STRING input_token = token specified in the Key
- field from TKEY RR (from Additional
- records section of the client's query)
- The OUTPUTS parameters returned by GSS_Accept_sec_context include
- INTEGER major_status = GSS_S_CONTINUE_NEEDED
- CONTEXT_HANDLE output_context_handle context_handle
- OCTET STRING output_token output_token
-
- Server stores the mapping of the
- 789.client.example.com.server.example.com. to OUTPUT context_handle
- in its (key_name, context_handle) mapping table.
-
-
- V. Server responds to the TKEY query
- Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
- call to GSS_Accept_sec_context, the server responds to the TKEY query
- placing in the answer section a TKEY record containing output_token in
- the Key Data RDATA field. The error field in the TKEY record is set to
- 0. The RCODE in the query response is set to NOERROR.
-
-
- VI. Client processes token returned by server
- When the client receives the TKEY query response from the server, the
- client calls GSS_Init_sec_context with the following parameters (Note
- that some INPUT and OUTPUT parameters not critical for this algorithm
- are not described in this example)
- CONTEXT HANDLE input_context_handle = the context_handle stored
- in the client's mapping table entry (DNS@server.example.com.,
- 789.client.example.com.server.example.com., context_handle)
- INTERNAL NAME targ_name = "DNS@server.example.com"
- OCTET STRING input_token = token from Key field of TKEY
- record from the Answer section of the server's response
- BOOLEAN replay_det_req_flag = TRUE
- BOOLEAN mutual_req_flag = TRUE
-
-
- The OUTPUTS parameters returned by GSS_Init_sec_context include
- INTEGER major_status = GSS_S_COMPLETE
-
-Expires August 28, 2003 [Page 17]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
- CONTEXT HANDLE output_context_handle = context_handle
- OCTET STRING output_token = output_token
- BOOLEAN replay_det_state = TRUE
- BOOLEAN mutual_state = TRUE
-
- Since the major_status is set to GSS_S_COMPLETE the client side
- security context is established, but since the output_token is not
- NULL client MUST send a TKEY query to the server as described below.
-
-
- VII. Client sends a query with QTYPE = TKEY to server
- Client sends to the server a TKEY query for the
- 789.client.example.com.server.example.com. name. Query contains a TKEY
- record in its Additional records section with the following fields
- (Note that some INPUT and OUTPUT parameters not critical to this
- algorithm are not described in this example)
- NAME = 789.client.example.com.server.example.com.
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
- Key Data = output_token
-
-
- VIII. Server receives a TKEY query
- When the server receives a TKEY query, the server verifies that Mode
- and Algorithm fields in the TKEY record in the Additional records
- section of the query are set to 3 and gss-tsig, repectively. It
- finds that the key_name 789.client.example.com.server.example.com. is
- listed in its (key_name, context_handle) mapping table.
-
-
- IX. Server calls GSS_Accept_sec_context
- To continue security context negotiation server calls
- GSS_Accept_sec_context with the following parameters (Note that some
- INPUT and OUTPUT parameters not critical for this algorithm are not
- described in this example)
- INPUTS
- CONTEXT HANDLE input_context_handle = context_handle from the
- (789.client.example.com.server.example.com., context_handle)
- entry in the server's mapping table
- OCTET STRING input_token = token specified in the Key
- field of TKEY RR (from Additional records Section of
- the client's query)
-
- The OUTPUTS parameters returned by GSS_Accept_sec_context include
- INTEGER major_status = GSS_S_COMPLETE
- CONTEXT_HANDLE output_context_handle = context_handle
- OCTET STRING output_token = NULL
-
-
-
-
-Expires August 28, 2003 [Page 18]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
- Since major_status = GSS_S_COMPLETE, the security context on the
- server side is established, but the server still needs to respond to
- the client's TKEY query, as described below. The security context
- state is advanced to Context Established.
-
-
- X. Server responds to the TKEY query
- Since the major_status = GSS_S_COMPLETE in the last server's call to
- GSS_Accept_sec_context and the output_token is NULL, the server
- responds to the TKEY query placing in the answer section a TKEY record
- that was sent by the client in the Additional records section of the
- client's latest TKEY query. In addition to this server places a
- TSIG record in additional records section of its response. Server
- calls GSS_GetMIC to generate a signature to include it in the TSIG
- record. The server specifies the following GSS_GetMIC INPUT
- parameters:
- CONTEXT HANDLE context_handle = context_handle from the
- (789.client.example.com.server.example.com., context_handle)
- entry in the server's mapping table
- OCTET STRING message = outgoing message plus TSIG
- variables (as described in [RFC2845])
-
- The OUTPUTS parameters returned by GSS_GetMIC include
- INTEGER major_status = GSS_S_COMPLETE
- OCTET STRING per_msg_token
-
- Signature field in the TSIG record is set to per_msg_token.
-
-
- XI. Client processes token returned by server
- Client receives the TKEY query response from the server. Since the
- major_status was GSS_S_COMPLETE in the last client's call to
- GSS_Init_sec_context, the client verifies that the server's response
- is signed. To validate the signature client calls GSS_VerifyMIC with
- the following parameters:
-
- INPUTS
- CONTEXT HANDLE context_handle = context_handle for
- 789.client.example.com.server.example.com. key_name
- OCTET STRING message = incoming message plus TSIG
- variables (as described in [RFC2845])
- OCTET STRING per_msg_token = Signature field from TSIG RR
- included in the server's query response
-
- Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
- signature is validated, security negotiation is complete and the
- security context state is advanced to Context Established. These
- client and server will use the established security context to sign
- and validate the signatures when they exchange packets with each
- other until the context expires.
-
-
-
-Expires August 28, 2003 [Page 19]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-7. Security Considerations
-
-This document describes a protocol for DNS security using GSS-API.
-The security provided by this protocol is only as effective as the
-security provided by the underlying GSS mechanisms.
-
-All the security considerations from RFC2845, RFC2930 and RFC 2743
-apply to the protocol described in this document.
-
-
-8. IANA Considerations
-
-The authors request that the IANA reserve the TSIG Algorithm name
-gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource
-records. This Algorithm name refers to the algorithm described in this
-document. The requirement to have this name registered with IANA is
-specified in RFC 2845.
-
-
-9. Conformance
-
-The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
-choose the underlying security mechanisms that enables security context
-negotiation. GSS API using SPNEGO [RFC2478] enables client and server to
-negotiate and choose such underlying security mechanisms on the fly. To
-support such flexibility, DNS clients and servers SHOULD specify SPNEGO
-mech_type in their GSS API calls. At the same time, in order to
-guarantee interoperability between DNS clients and servers that support
-GSS-TSIG it is required that
-- DNS servers specify SPNEGO mech_type
-- GSS APIs called by DNS client support Kerberos v5
-- GSS APIs called by DNS server support SPNEGO [RFC2478] and
- Kerberos v5.
-
-In addition to these, GSS APIs used by DNS client and server MAY also
-support other underlying security mechanisms.
-
-
-10. Acknowledgements
-
-The authors of this document would like to thank the following people
-for their contribution to this specification: Chuck Chan, Mike Swift,
-Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake 3rd and Erik
-Nordmark.
-
-
-11. References
-
-[RFC2743] J. Linn, "Generic Security Service Application Program
- Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories,
- January 2000.
-
-
-
-Expires August 28, 2003 [Page 20]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, ISC, NAI Labs, Motorola, Nominum, May, 2000,
-
-[RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)",
- RFC 2930, Motorola, September 2000.
-
-[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
- RFC 2535, IBM, March 1999.
-
-[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
- RFC 2137, CyberCash, April 1997.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[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 1034, November 1987.
-
-[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
- RFC 1964, OpenVision Technologies, June 1996.
-
-[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
- RFC 2025, Bell-Northern Research, October 1996.
-
-[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
- Negotiation Mechanism", RFC 2478, Bull, December 1998.
-
-[ISO11578]"Information technology", "Open Systems
- Interconnection", "Remote Procedure Call",
- ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html.
-
-
-12. Author's Addresses
-
-Stuart Kwan Praerit Garg
-Microsoft Corporation Microsoft Corporation
-One Microsoft Way One Microsoft Way
-Redmond, WA 98052 Redmond, WA 98052
-USA USA
-skwan@microsoft.com praeritg@microsoft.com
-
-James Gilroy Levon Esibov
-Microsoft Corporation Microsoft Corporation
-One Microsoft Way One Microsoft Way
-Redmond, WA 98052 Redmond, WA 98052
-USA USA
-jamesg@microsoft.com levone@microsoft.com
-
-
-
-Expires August 28, 2003 [Page 21]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-Randy Hall Jeff Westhead
-Lucent Technologies Microsoft Corporation
-400 Lapp Road One Microsoft Way
-Malvern PA 19355 Redmond, WA 98052
-USA USA
-randyhall@lucent.com jwesth@microsoft.com
-
-
-
-Expires August 28, 2003 [Page 22]
+++ /dev/null
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-Clarifies STD0013 Motorola Laboratories
-Expires September 2003 April 2003
-
-
-
- Domain Name System (DNS) Case Insensitivity Clarification
- ------ ---- ------ ----- ---- ------------- -------------
- <draft-ietf-dnsext-insensitive-03.txt>
-
- Donald E. Eastlake 3rd
-
-
-
-Status of This Document
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group at namedroppers@ops.ietf.org.
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. 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
-
- Domain Name System (DNS) names are "case insensitive". This document
- explains exactly what that means and provides a clear specification
- of the rules. This clarification should not have any interoperability
- consequences.
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Acknowledgements
-
- The contributions to this document of Rob Austein, Olafur
- Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
- Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully
- acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. Case Insensitivity of DNS Labels........................3
- 2.1 Escaping Unusual DNS Label Octets......................3
- 2.2 Example Labels with Escapes............................4
- 2.3 Name Lookup Case Insensitivity.........................4
- 2.4 Original DNS Label Types...............................5
- 3. Additional DNS Case Insensitivity Considerations........5
- 3.1 CLASS Case Insensitivity Considerations................5
- 3.2 Extended Label Type Case Insensitivity Considerations..5
- 4. Case on Input and Output................................6
- 4.1 DNS Output Case Preservation...........................6
- 4.2 DNS Input Case Preservation............................6
- 4.3 Wildcard Matching......................................7
- 5. Internationalized Domain Names..........................7
- 6. Security Considerations.................................7
-
- Normative References.......................................9
- Informative References.....................................9
- -02 to -03 Changes........................................10
- Author's Address..........................................10
- Expiration and File Name..................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. Each node in the DNS tree has a name consisting of
- zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
- case insensitive fashion. This document clarifies the meaning of
- "case insensitive" for the DNS.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-
-2. Case Insensitivity of DNS Labels
-
- DNS was specified in the era of [ASCII]. DNS names were expected to
- look like most host names or Internet email address right halves (the
- part after the at-sign, "@") or be numeric as in the in-addr.arpa
- part of the DNS name space. For example,
-
- foo.example.net.
- aol.com.
- www.gnu.ai.mit.edu.
- or 69.2.0.192.in-addr.arpa.
-
- Case varied alternatives to the above would be DNS names like
-
- Foo.ExamplE.net.
- AOL.COM.
- WWW.gnu.AI.mit.EDU.
- or 69.2.0.192.in-ADDR.ARPA.
-
- The individual octets of which DNS names consist are not limited to
- valid ASCII character codes. They are as 8-bit bytes and all values
- are allowed. Many applications, however, interprete them as ASCII
- characters.
-
-
-
-2.1 Escaping Unusual DNS Label Octets
-
- In Master Files [STD 13] and other human readable and writable ASCII
- contexts, an escape is needed for the byte value for period (0x2E,
- ".") and all octet values outside of the inclusive range of 0x21 ("!")
- to 0x7E ("~"). That is to say, 0x2E and all octet values in the two
- inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
-
- One typographic convention for octets that do not correspond to an
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- ASCII printing graphic is to use a back-slash followed by the value of
- the octet as an unsigned integer represented by exactly three decimal
- digits.
-
- The same convention can be used for printing ASCII characters so that
- they will be treated as a normal label character. This includes the
- back-slash character used in this convention itself and the special
- label separator period (".") which can be expressed as \092 and \046
- respectively. It is advisable to avoid using a backslash to quote an
- immediately following non-printing ASCII character code to avoid
- implementation difficulties.
-
- A back-slash followed by only one or two decimal digits is
- undefined. A back-slash followed by four decimal digits produces two
- octets, the first octet having the value of the first three digits
- considered as a decimal number and the second octet being the
- character code for the fourth decimal digit.
-
-
-
-2.2 Example Labels with Escapes
-
- The first example below shows embedded spaces and a period (".")
- within a label. The second one show a 5 octet label where the second
- octet has all bits zero, the third is a backslahs,
- and the fourth octet has all bits one.
-
- Donald\032E\.\032Eastlake\0323rd.example.
- and a\000\\\255z.example.
-
-
-
-2.3 Name Lookup Case Insensitivity
-
- The design decision was made that comparisons on name lookup for DNS
- queries should be case insensitive [STD 13]. That is to say, a lookup
- string octet with a value in the inclusive range of 0x41 to 0x5A, the
- upper case ASCII letters, MUST match the identical value and also
- match the corresponding value in the inclusive range 0x61 to 0x7A,
- the lower case ASCII letters. And a lookup string octet with a lower
- case ASCII letter value MUST similarly match the identical value and
- also match the corresponding value in the upper case ASCII letter
- range.
-
- (Historical Note: the terms "upper case" and "lower case" were
- invented after movable type. The terms originally referred to the
- two font trays for storing, in partitioned areas, the different
- physical type elements. Before movable type, the nearest equivalent
- terms were "majuscule" and "minuscule".)
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- One way to implement this rule would be, when comparing octets, to
- subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
- before the comparison. Such an operation is commonly known as "case
- folding" but implementation via case folding is not required. Note
- that the DNS case insensitivity does NOT correspond to the case
- folding specified in iso-8859-1 or iso-8859-2. For example, the
- octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
- contexts, where they are interpreted as the upper and lower case
- version of "Y" with an acute accent, they might.
-
-
-
-2.4 Original DNS Label Types
-
- DNS labels in wire encoded names have a type associated with them.
- The original DNS standard [RFC 1035] had only two types. ASCII
- labels, with a length of from zero to 63 octets and indirect labels
- which consist of an offset pointer to a name location elsewhere in
- the wire encoding on a DNS message. (The ASCII label of length zero
- is reserved for use as the name of the root node of the name tree.)
- ASCII labels follow the ASCII case conventions described above.
- Indirect labels are, in effect, replaced by the name to which they
- point which is then treated with the case insensitivity rules in this
- document.
-
-
-
-3. Additional DNS Case Insensitivity Considerations
-
- This section clarifies the effect of DNS CLASS and extended Label
- Type on case insensitivity.
-
-
-
-3.1 CLASS Case Insensitivity Considerations
-
- As described in [STD 13] and [RFC 2929], DNS has an additional axis
- for data location called CLASS. The only CLASS in global use at this
- time is the "IN" or Internet CLASS.
-
- The handling of DNS label case is not CLASS dependent.
-
-
-
-3.2 Extended Label Type Case Insensitivity Considerations
-
- DNS was extended by [RFC 2671] to have additional label type numbers
- available. (The only such type defined so far is the BINARY type [RFC
- 2673].)
-
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- The ASCII case insensitivity conventions, or case folding, only apply
- to ASCII labels, that is to say, label type 0x0, whether appearing
- directly or invoked by indirect labels.
-
-
-
-4. Case on Input and Output
-
- While ASCII label comparisons are case insensitive, case MUST be
- preserved on output, except when output is optimized by the use of
- indirect labels, and preserved when convenient on input.
-
-
-
-4.1 DNS Output Case Preservation
-
- [STD 13] views the DNS namespace as a node tree. ASCII output is as
- if a name was marshalled by taking the label on the node whose name
- is to be output, converting it to a typographically encoded ASCII
- string, walking up the tree outputting each label encountered, and
- preceding all labels but the first with a period ("."). Wire output
- follows the same sequence but each label is wire encoded and no
- periods inserted. No "case conversion" or "case folding" is done
- during such output operations. However, to optimize output, indirect
- labels may be used to point to names elsewhere in the DNS answer. In
- determining whether the name to be pointed to is the "same" as the
- remainder of the name being optimized, the case insensitive
- comparison specified above is done. Thus such optimization MAY
- destroy the output preservation of case. This type of optimization is
- commonly called "name compression".
-
-
-
-4.2 DNS Input Case Preservation
-
- Originally, DNS input came from an ASCII Master File as defined in
- [STD 13]. DNS Dynamic update has been added as a source of DNS data
- [RFC 2136, 3007]. When a node in the DNS name tree is created by such
- input, no case conversion is done and the case of ASCII labels is
- preserved if they are for nodes being created. However, when a name
- label is input for a node that already exist in DNS data being
- augmented or updated, the situation is more complex. Implemenations
- may retain the case first input for such a label or allow new input
- to override the old case or maintain separate copies preserving the
- input case.
-
- For example, if data with owner name "foo.bar.example" is input and
- then later data with owner name "xyz.BAR.example" is input, the name
- of the label on the "bar.example" node, i.e. "bar", might or might
- not be changed to "BAR" or the actual input case could be preserved.
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- Thus later retrieval of data stored under "xyz.bar.example" in this
- case can easily result is obtaining data with "xyz.BAR.example". The
- same considerations apply when inputting multiple data records with
- owner names differing only in case. From the example above, if an "A"
- record is stored under owner name "xyz.BAR.example" and then a second
- "A" record under "XYZ.BAR.example", the second MAY be stored with the
- first (lower case initial label) name.
-
- Note that the order of insertion into a server database of the DNS
- name tree nodes that appear in a Master File is not defined so that
- the results of inconsistent capitalization in a Master File are
- unpredicatable output capitalization.
-
-
-
-4.3 Wildcard Matching
-
- There is one additional instance of note, which reflects the general
- rules that output case reflects input case unless there is
- conflicting capitalization in the DNS database or the output case is
- hidden by name compression. This is when a query matches a wildcard
- in the DNS database at a server. In that case, the answer SHOULD
- reflect the input case of the label or labels that matched the
- wildcard unless they are replaced by an indirect label which MAY
- point to a name with different capitalization.
-
-
-
-5. Internationalized Domain Names
-
- A scheme has been adopted for "internationalized domain names" and
- "internationalized labels" as described in [RFC 3490, 3454, 3491, and
- 3492]. It makes most of [UNICODE] available through a separate
- application level transformation from internationalized domain name
- to DNS domain name and from DNS domain name to internationalized
- domain name. Any case insensitivity that internationalized domain
- names and labels have varies depending on the script and is handled
- entirely as part of the transformation described in [RFC 3454] and
- [RFC 3491] which should be seen for further details. This is not a
- part of the DNS as standardized in STD 13.
-
-
-
-6. Security Considerations
-
- The equivalence of certain DNS label types with case differences, as
- clarified in this document, can lead to security problems. For
- example, a user could be confused by believing two domain names
- differing only in case were actually different names.
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- Furthermore, a domain name may be used in contexts other than the
- DNS. It could be used as a case sensitive index into some data base
- system. Or it could be interpreted as binary data by some integrity
- or authentication code system. These problems can usually be handled
- by using a standardized or "canonical" form of the DNS ASCII type
- labels, that is, always map the ASCII letter value octets in ASCII
- labels to some specific pre-chosen case, either upper case or lower
- case. An example of a canonical form for domain names (and also a
- canonical ordering for them) appears in Section 8 of [RFC 2535]. See
- also [UNKRR].
-
- Finally, a non-DNS name may be stored into DNS with the false
- expectation that case will always be preserved. For example, although
- this would be quite rare, on a system with case sensitive email
- address local parts, an attempt to store two "RP" records that
- differed only in case would probably produce unexpected results that
- might have security implications. That is because the entire email
- address, including the possibly case sensitive local or left hand
- part, is encoded into a DNS name in a readable fashion where the case
- of some letters might be changed on output as described above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Normative References
-
- [ASCII] - ANSI, "USA Standard Code for Information Interchange",
- X3.4, American National Standards Institute: New York, 1968.
-
- [RFC 1034, 1035] - See [STD 13].
-
- [RFC 2119] - "Key words for use in RFCs to Indicate Requirement
- Levels", S. Bradner, March 1997.
-
- [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
-
- [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
- March 1999.
-
- [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
- Update", November 2000.
-
- [STD 13]
- - P. Mockapetris, "Domain names - concepts and facilities", RFC
- 1034, November 1987.
- - P. Mockapetris, "Domain names - implementation and
- specification", RFC 1035, November 1987.
-
- [UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
- draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
-
-
-
-Informative References
-
- [RFC 1591] - J. Postel, "Domain Name System Structure and
- Delegation", March 1994.
-
- [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
- June 1999.
-
- [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
- Name System (DNS) IANA Considerations", September 2000.
-
- [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
- 1999.
-
- [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
- August 1999.
-
- [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
- Internationalized String ("stringprep")", December 2002.
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)", March 2003.
-
- [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
- for Internationalized Domain Names (IDN)", March 2003.
-
- [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
- for Internationalized Domain Names in Applications (IDNA)", March
- 2003.
-
- [UNICODE] - The Unicode Consortium, "The Unicode Standard",
- <http://www.unicode.org/unicode/standard/standard.html>.
-
-
-
--02 to -03 Changes
-
- The following changes were made between draft version -02 and -03:
-
- 1. Add internationalized domain name section and references.
-
- 2. Change to indicate that later input of a label for an existing DNS
- name tree node may or may not be normalized to the earlier input or
- override it or both may be preserved.
-
- 3. Numerous minor wording changes.
-
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-851-8280 (w)
- +1 508-634-2066 (h)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires September 2003.
-
- Its file name is draft-ietf-dnsext-insensitive-03.txt.
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT H. Kitamura
-<draft-ietf-dnsext-ipv6-name-auto-reg-01.txt> NEC Corporation
-Expires in six months 23 July 2003
-
- Domain Name Auto-Registration for Plugged-in IPv6 Nodes
- <draft-ietf-dnsext-ipv6-name-auto-reg-01.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.
-
-Abstract
-
- This document describes a scheme of "Domain Name Auto-Registration
- for Plugged-in IPv6 Nodes" mechanism that makes it possible to
- register both regular and inverse domain name information of plugged-
- in IPv6 nodes to DNS servers automatically.
-
- Since IPv6 addresses are too long to remember and EUI64-based
- addresses are too complicated to remember, there are strong
- requirements to use logical names that are easy to remember instead
- of IPv6 addresses to specify IPv6 nodes and to register domain name
- information of plugged-in IPv6 nodes automatically.
-
- In order to meet the requirements, a mechanism is proposed as one of
- the IPv6 auto-configuration (plug and play) functions. After the
- Address Autoconfiguration [ADDR-AUTO] has been executed, it works as
- a succeeding plug and play mechanism.
-
- This document clarifies problems that we meet when we apply the
- Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
- information registration mechanisms. This document describes the
- Domain Name Auto-Registration mechanism as a solution to these
- problems.
-
-
-
-H. Kitamura [Page 1]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- The Domain Name Auto-Registration mechanism, in addition to its main
- functionality, provides two types of additional benefits.
-
- One is that IP address information that should be registered to the
- DNS is collected automatically. The mechanism can also be used under
- (non plug and play) manual configuration situations in a different
- manner from its main functionality. Under such situations, network
- administrators meet a problem that it is not easy to collect IP
- address information to register to the DNS. The mechanism solves it.
-
- The other is that a plugged-in IPv6 node can obtain its domain name
- information (FQDN and DNS zone suffix) without having new functions
- installed into it. By simply executing inverse DNS name resolving
- procedures with its IPv6 address argument, the plugged-in IPv6 node
- can obtain its FQDN and DNS zone suffix with ease.
-
-
-1. Introduction
-
- This document describes a scheme of "Domain Name Auto-Registration
- for Plugged-in IPv6 Nodes" mechanism that makes it possible to
- register both regular and inverse domain name information of plugged-
- in IPv6 nodes to DNS servers automatically.
-
- In order to specify destination nodes to communicate, SOME
- identifiers are necessary for users. Since IPv6 addresses are too
- long to remember and EUI64-based addresses are too complicated to
- remember, they are not suitable for such identifiers. Logical names
- are suitable identifiers because they are easy to remember.
- Therefore, there are strong requirements to use logical names instead
- of IPv6 addresses to specify IPv6 destination nodes and to register
- domain name information of plugged-in IPv6 nodes automatically.
-
- In order to meet the requirements, a mechanism is proposed as one of
- the IPv6 auto-configuration (plug and play) functions. After the
- Address Autoconfiguration [ADDR-AUTO] has been executed, it works as
- a succeeding plug and play mechanism.
-
- It is known that the Dynamic Updates in the DNS [DYN-DNS] have
- already been defined and that they can help automatic domain name
- information registration mechanisms. However, some problems need to
- be solved to apply this idea to actual situations.
-
- This document clarifies problems that we meet when we apply the
- Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
- information registration mechanisms. This document describes the
- Domain Name Auto-Registration mechanism as a solution to these
- problems.
-
-
-
-H. Kitamura [Page 2]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- Basic target situations for the mechanism are plug and play
- situations. Accordingly, it has been designed for plugged-in IPv6
- nodes under plug and play situations.
-
- We have to consider the following issues to design the "Domain Name
- Auto-Registration for Plugged-in IPv6 Nodes" mechanism.
-
- 1. Plugged-in IPv6 nodes do not have sufficient capability to show
- their preferences. In most cases, it is difficult for plugged-in
- IPv6 nodes to show their preferences for their domain names.
-
- 2. Since it is not easy to install new function to all IPv6 nodes, it
- is desirable to achieve the mechanism without installing new
- functions into plugged-in IPv6 nodes.
-
- 3. It is essential to have (register) SOME domain name for a
- plugged-in node. It is NOT main concern for a plugged-in node
- which actual name is assigned to it.
-
- Thus, the idea of "default domain name" is introduced. When a new
- plugged-in IPv6 node appears, its appearance is automatically
- detected and a default domain name is selected for it, and both
- regular and inverse information of the default domain name are
- registered to appropriate DNS servers.
-
- This document does not deal with cases where IPv6 nodes want to
- register domain names that they absolutely prefer. Such cases do not
- fall within the target range of plug and play situations; they will
- be supported under manual configuration situations.
-
- There are various types of plugged-in IPv6 nodes that can/cannot show
- their preferences for their domain names. In order to meet various
- plug and play situations, this document considers several cases.
-
- The Domain Name Auto-Registration mechanism is basically designed for
- domain name registrations for global unicast addresses. By setting
- the query scope of the target DNS server appropriately, the mechanism
- will be able to be applied to domain name registrations for site-
- local and link-local scope unicast addresses.
-
- The Domain Name Auto-Registration mechanism, in addition to its main
- functionality, provides two types of additional benefits.
-
- One is that IP address information that should be registered to the
- DNS is collected automatically. The mechanism can also be used under
- (non plug and play) manual configuration situations in a different
- manner from its main functionality. Under such situations where
- network is maintained by administrators manually, administrators meet
-
-
-
-H. Kitamura [Page 3]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- a problem that it is not easy to collect IP address information to
- register to the DNS. The mechanism solves the problem, and IP address
- information to register to the DNS is collected automatically.
-
- Under manual configuration situations, the automatic DNS registration
- procedure that is the last procedure of the mechanism can be replaced
- by the administrators' manual registration (not by the Dynamic
- Updates).
-
-
- The other is that a plugged-in IPv6 node can obtain its domain name
- information (FQDN and DNS zone suffix) with ease. The plugged-in IPv6
- nodes know its IPv6 address that are automatically configured by the
- Address Autoconfiguration [ADDR-AUTO]. By simply executing inverse
- DNS name resolving procedures with the IPv6 address argument, the
- plugged-in IPv6 node can obtain information on its domain names (FQDN
- and DNS zone suffix) easily. Since all IPv6 nodes have DNS name
- resolving functions for both regular and inverse queries, this
- procedure can be achieved without installing new functions into IPv6
- nodes.
-
-
-2. Problems in applying the Dynamic Updates mechanism
-
- This section clarifies problems that we meet when we apply the
- Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
- information registration mechanisms.
-
- 1: Ordinary DNS servers accept Dynamic Updates messages only from
- trusted nodes.
-
- Since it is difficult for plugged-in IPv6 nodes to become trusted
- nodes of the DNS servers, Dynamic Updates messages from plugged-in
- IPv6 nodes are usually not accepted by the DNS servers.
-
- 2: It is difficult for plugged-in IPv6 nodes to know the location of
- the appropriate DNS server to register their domain name
- information to.
- ([DNS-DISC] discusses on issues of this type.)
-
- 3: It is difficult for plugged-in IPv6 nodes to prepare sufficient
- domain name information to register. They need to know their DNS
- zone suffix information to prepare FQDN for registration, but it
- is difficult for them to acquire it.
- ([DNS-DISC] also discusses on issues of this type.)
-
- 4: There is no explicit method to avoid duplicated, conflicting name
- registrations.
-
-
-
-H. Kitamura [Page 4]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- When a DNS server receives Dynamic Updates messages that are
- correctly formatted and authenticated, the server accepts them and
- updates DNS database with them without checking for duplication.
- (It is essentially difficult for a DNS server to distinguish
- overwrite (update) registrations from duplicate registrations.)
-
- 5: Basically, there is no mechanism to control (restrict) the number
- of issued Dynamic Updates messages for plugged-in nodes.
-
- In order to minimize the effects of malicious or misconfigured
- registration requests, it is necessary to control them.
-
- 6: It is not clear when domain name registration requests must be
- issued. It is necessary to define trigger timings to start
- registrations.
-
-
-3. Basic Design of the Domain Name Auto-Registration
-
- This section describes the basic design of the Domain Name Auto-
- Registration mechanism. The mechanism solves all of the above-
- mentioned problems.
-
-
-3.1 Design Policies
-
- The Domain Name Auto-Registration mechanism is composed of two new
- functions. One is the "Detector" function, which detects appearances
- of new plugged-in IPv6 nodes. The other is the "Registrar" function,
- which registers detected domain name information to DNS servers.
- These functions are introduced into the IPv6 network system to
- achieve the mechanism.
-
- There are several reasons why the mechanism is implemented as two
- functions.
-
- 1. To make the mechanism easy to control
-
- By concentrating administrative operations only on the Registrar
- side, administrative costs are reduced and the mechanism is
- basically maintained by administering only Registrars.
-
- The number of DNS servers' trusted nodes that require much
- administrative operation is reduced.
-
- Since registration information is aggregated at Registrars, it
- becomes easy to control registrations and minimize the effects of
- malicious or misconfigured registration requests.
-
-
-
-H. Kitamura [Page 5]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- 2. To make Detector easy to implement
-
- There are certain constraints in placing Detectors on the IPv6
- network. Thus, it is necessary for Detectors to be simple enough
- to be installed on IPv6 nodes of any type.
-
- This need is filled by putting all the intelligent operations into
- Registrars.
-
- Furthermore, the system becomes well balanced since intelligent
- operations are not placed on each end link.
-
- 3. To make the mechanism flexible and enable it to be applied
- to various environments (office networks, home networks, etc.)
-
- If the mechanism is applied to home networks, Registrars can be
- placed at the Provider side, and Detectors can be placed at the
- User side.
-
-
- Figure 1 and 2 show typical examples that indicate locations where
- Detector and Registrar functions are placed on the IPv6 network.
-
- Figure 1 shows a case for a single link, and Figure 2 shows a case
- for multiple links.
-
-
-
-
- | +------------+
- | | DNS Server |
- +-+-+ %%%%%%%%%%%% ############# +------+-----+
- | R | % Detector % # Registrar # /
- +-+-+ %%%%%%%%%%%% ############# +---+
- | | | /
- ----+---------+-------+------+---------------+-----
- |
- +===========+
- | Plugged-in|
- | IPv6 Node |
- +===========+
-
- Fig. 1 Single-Link Case Example
-
-
-
-
-
-
-
-
-H. Kitamura [Page 6]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- +------------+
- | DNS Server |
- ############# +------+-----+
- # Registrar # /
- ############# +---+
- | /
- ----+-----------+------------+-------+------
- | |
- +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%%
- | R1| % Detector1 % | R2| % Detector2 %
- +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%%
- | | | |
- ----+-----+-----+----- ----+-----+-----+-----
- | |
- +===========+ +===========+
- | Plugged-in| | Plugged-in|
- | IPv6 Node | | IPv6 Node |
- +===========+ +===========+
-
- Fig. 2 Multiple-Link Case Example
-
-
- One Registrar can take charge of multiple Detectors, and one
- Registrar can cover multiple DNS zones.
-
- Multiple Detectors can provide detected information for one DNS zone.
- If the corresponding Registrars of these Detectors are different,
- multiple Registrars can cover one DNS zone.
-
- Therefore, Registrars must be designed to support both cases.
-
-
-
-3.2 Detector Function
-
- The role of a "Detector" is to detect appearances of new plugged-in
- IPv6 nodes and to send the detected information to a "Registrar"
- without applying any selection rules to it.
-
- Detectors are NOT required to perform any "intelligent" operations.
-
- A Detector knows the location of its corresponding Registrar. (This
- location is configured manually.) Detected information must be sent
- securely from the Detector to the Registrar by using some kind of
- secure communication method (e.g., [TSIG]-like authentication, IPsec
- (AH, ESP), [TLS]).
-
-
-
-
-
-H. Kitamura [Page 7]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- Since a Detector must be placed where appearances of new plugged-in
- IPv6 nodes can be detected, the Detector location is restricted.
-
- In typical cases, appearances are detected by watching for DAD
- packets that are issued from plugged-in IPv6 nodes (see section 3.4).
- So, the Detector must be placed where it can listen to link-local
- scope multicast packets. In other words, a Detector must be placed on
- each link to achieve the mechanism.
-
- The Detector function can be implemented on routers, because its
- operations are simple and lightweight and routers are located at
- suitable places for listening to link-local scope multicast packets
- that are issued from plugged-in IPv6 nodes.
-
- In order to identify Detectors, each Detector must have its own
- Detector ID. Since a Detector is placed on each link, the Detector's
- IP address that is connected to its watching link can be used for the
- Detector ID. (Default Address Selection for IPv6 [DEF-ADDR] algorithm
- is also applied here.) When a Detector sends detected information to
- a Registrar, the Detector ID is attached to it.
-
- In order to meet "temporary address" [RFC3041] issues (see section
- 5), a link-layer address of a detected IP address is also attached to
- detected information.
-
- Some simple protocol is necessary to send detected information from
- the Detector to the Registrar. In Appendix A, [HTTP]-based or [TLS-
- HTTP]-based simple protocol is shown.
-
-3.3 Registrar Function
-
- The role of a "Registrar" is to prepare appropriate domain name
- information for registration and to register it by sending Dynamic
- Update messages to the corresponding "DNS servers".
-
- Appropriate domain name information for registration is created from
- detected information that is sent from the Detector. Some sort of
- intelligent algorithm is necessary in such procedures. One of the
- roles of the algorithm is to minimize the effects of malicious or
- misconfigured registration requests.
-
- Registrars are required to perform "intelligent" operations.
-
- By using some sort of algorithm, the Registrar verifies (checks)
- whether detected information must be registered (see section 3.5).
- After the verification procedures are completed, the Registrar
- selects a "default domain name" for the detected information.
-
-
-
-
-H. Kitamura [Page 8]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- In order to prepare appropriate domain name information, the
- Registrar must know the appropriate DNS zone suffix for detected
- information. (The suffix is configured manually.) The DNS zone suffix
- depends on the Detector ID information.
-
- A Registrar must know the locations of "DNS servers" that correspond
- to detected information for registration (both regular DNS zone
- prefix and its inverse zone). Registrars must be trusted nodes of the
- DNS servers and Dynamic Update messages must be sent securely from
- the Registrar to the DNS servers by using some sort of secure
- communication methods. The [TSIG] technique would be suitable for
- authenticating the messages.
-
- A Registrar has a database table to manage such knowledge. The
- following elements are managed in the database table:
- Detector IDs, DNS zone suffixes, locations of DNS servers, applied
- algorithms (naming rules, how to deal with link-local or site-local
- scope addresses, etc.) and keys for secure communications.
-
- A Registrar can be placed anywhere in the IPv6 network, because the
- Registrar communicates only with Detectors and DNS servers, all
- communications are unicast.
-
- In order to optimize the communication path for packets between them,
- the Registrar is usually placed in the network upstream from the
- Detectors (see Fig.2).
-
- Detected information that is sent from Detectors is aggregated at the
- Registrar.
-
- The Registrar may frequently execute inverse DNS name resolving
- procedures to verify (check) whether detected information must be
- registered. It is recommended to put a DNS cache server function on
- the same node where the Registrar is placed to reduce inverse DNS
- name resolving traffic (see section 3.5).
-
-3.4 Methods of Detecting Appearances of New Plugged-in IPv6 Nodes
-
- In order to detect appearances of new plugged-in IPv6 nodes, the
- Detector must watch or receive packets from new plugged-in nodes.
- Accordingly, detection methods on the Detector are categorized into
- two types.
-
- One is detection of the appearance of "standard" plugged-in nodes
- that do not issue special packets to show their appearance. The other
- is detection of the appearance of "active" plugged-in nodes that
- issue special packets to show their appearance.
-
-
-
-
-H. Kitamura [Page 9]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- We can assume there will be complex cases in which standard and
- active plugged-in nodes are mixed together. For purposes of
- simplification, such cases are not discussed here.
-
-3.4.1 Detecting Appearance of "Standard" Plugged-in IPv6 Nodes
-
- In this case, plugged-in nodes do NOT issue special dedicated packets
- to show their appearance. (Current standard networks are composed of
- such nodes.) So, the Detector must watch for packets that are issued
- somewhere from new plugged-in nodes.
-
- The initial procedure for a standard plugged-in IPv6 node is to auto-
- configure its address and do DAD (Duplicate Address Detection) [ADDR-
- AUTO].
-
- DAD packets have sufficient characteristics for an appearance-
- detection method, because they are issued only when IPv6 nodes are
- plugged in, and address information for the plugged-in IPv6 nodes is
- included in DAD packets.
-
- By watching for only DAD packets, the Detector can detect appearances
- of new plugged-in IPv6 nodes, and DAD packets become triggers to
- start Domain Name Auto-Registration.
-
- This method enables the mechanism to function without introducing new
- protocols and without installing new functions into plugged-in IPv6
- nodes.
-
-
- DAD packets are issued not only for global addresses but also for
- link-local or site-local scope addresses. All detected information is
- sent to the Registrar, and the manner of dealing with information for
- non-global addresses is determined by Registrar algorithms that are
- indicated by Detector IDs of the detected information.
-
-
- This method works effectively on ordinary IPv6 links where DAD
- packets are issued. However, on extraordinary IPv6 links where DAD
- packets are not issued, it does not work. On such links, there must
- be another initial procedure that substitutes the DAD function. Such
- a procedure can be used as a trigger for a detection method on
- extraordinary IPv6 links.
-
- (IP addresses can be assigned by other methods (e.g., DHCP). Domain
- name registration mechanisms for such cases will be discussed further
- in other documents.)
-
-
-
-
-
-H. Kitamura [Page 10]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
-3.4.2 Detecting Appearance of "Active" Plugged-in Nodes
-
- In this case, plugged-in nodes issue special dedicated packets to
- show their appearance. The Detector must listen for and receive
- packets from the new plugged-in nodes.
-
- Since plugged-in nodes do not know the location of the Detector,
- anycast or multicast packets are used for the special dedicated
- packets.
-
- In this method, plugged-in nodes can actively show their preference
- for their domain names. However, it will be difficult to show their
- preference under plug and play situations.
-
- In order to achieve the method, new protocols must be defined and new
- functions must be installed into plugged-in IPv6 nodes.
- (This will be discussed further in other documents.)
-
-3.5 Methods of Controlling Registration
-
- If received Dynamic Update messages are correctly formatted and
- authenticated, the DNS server accepts them without checking for any
- duplication, because the DNS server can not distinguish overwrite
- (update) registrations from duplicate registrations. It is difficult
- to achieve a mechanism for avoiding duplicated registrations on the
- DNS server side.
-
- Therefore, registrations by the Dynamic Update messages must be
- controlled on the Registrar side. This control mechanism also helps
- to minimize the effects of malicious or misconfigured registration
- requests.
-
- Plugged-in nodes may switch on and off frequently and issue DAD
- packets frequently. Since the Detector sends detected information
- without applying any selection rules to it, all detected information
- is sent to the Registrar. Thus, the Registrar must have some
- information verification mechanism to avoid duplicated registrations.
-
- All candidate information (detected addresses) for registration is
- checked by using inverse DNS resolving queries of them. If there is
- FQDN information that matches the detected address, such registration
- candidates are not registered.
-
- Only when FQDN information for it is NOT found and it is verified
- that the detected information is based on first appearance of the
- plugged-in node, appropriate domain name information for registration
- is prepared and both regular and inverse domain name information for
- it are registered to the DNS servers by the Dynamic Update messages.
-
-
-
-H. Kitamura [Page 11]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- By using this verification mechanism, the Registrar does not have to
- have a local database to maintain the status of the detected
- information and no DNS registration inconsistency problems are
- caused.
-
- By restricting the number of Dynamic Update messages that are sent
- from the Registrar per unit of time, the effects of malicious or
- misconfigured registration requests are minimized.
-
-
-3.6 Naming Rules for Default Domain Names
-
- This section describes a method of setting "default domain names" for
- plugged-in nodes.
-
- A fully qualified "default domain name" is composed of a node's
- original prefix part and a DNS zone suffix part that is the same for
- each site or link.
-
- Since a DNS zone suffix is given to the Registrar manually, only the
- naming rules for a node's original prefix are discussed here. A
- naming rule algorithm for a node's prefix is given to the Registrar
- manually.
-
- It is not necessary to define naming rules for a node's prefix
- explicitly in this document. Each site can define its own naming
- rules (algorithms) per link according to site policy.
-
- This document shows some example naming rules for a node's prefix
- name.
-
- 1. Prefix Letter(s) + Number
-
- This is the easiest rule. First, prefix letter(s) that depends on
- each link (Detector ID) is/are selected, and the following number
- is selected after that.
-
- The following numbers comprise sequential numbers. In order to
- achieve this, the Registrar must remember the last selected
- number.
-
- There are some situations where using sequential numbers is not
- favorable because the next number could be easily predicted. In
- those cases, random numbers can be used, which makes it necessary
- to implement the Registrar with a duplicate number check
- mechanism.
-
-
-
-
-
-H. Kitamura [Page 12]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- 2. Predefined Names
-
- The Registrar prepares predefined names (e.g., names of flowers)
- that are used for prefix names for plugged-in nodes. Random or
- sequential numbers can be used to prepare predefined names.
-
- This method can be used for an environment where the number of
- plugged-in nodes can be estimated and the number is not
- excessively large.
-
- 3. Use Preferences of Plugged-in Nodes.
-
- The Registrar inquires the preference or property of a plugged-in
- node, and uses the obtained information as a hint to define a
- prefix name for the plugged-in node.
-
- There are two types of methods for plugged-in nodes to indicate
- their preference or property.
-
-
- One is "passive" indication. Plugged-in nodes do NOT become an
- initiator to indicate their preferences. The Registrar becomes an
- initiator and issues query packets to plugged-in nodes. Existing
- protocol (e.g., Node Information Query [NIQ], SNMP) is used for
- it.
-
- For a detected global address, the Registrar can use Node
- Information Query [NIQ] to obtain hint information to define a
- name for the plugged-in node.
-
- By using [SNMP], the Registrar can also obtain hint information to
- define a name for the plugged-in node. Plugged-in nodes use parts
- of MIB to indicate their preferences or properties. It is possible
- to define a special MIB for this purpose. Also, some parts of
- currently existing MIB can be used for it. Most plugged-in nodes
- have already set some property information (OS type, version,
- etc.) to their MIB when they are plugged in. Such information can
- be used for a hint to define a prefix name. (The Registrar must
- have an appropriate read access right to such MIB information.)
-
- The other is "active" indication. Plugged-in nodes become an
- initiator to indicate their preferences and issue special
- dedicated packets for it. Since plugged-in nodes do not know the
- location of the Detector or Registrar, anycast or multicast
- packets are used for them. It is possible to attach name
- preference information to packets that are used for showing the
- appearance of plugged-in nodes. The Registrar can receive such
- information via the Detector.
-
-
-
-H. Kitamura [Page 13]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- In order to achieve the "active" indication method, new protocols
- must be defined and new functions must be installed into plugged-
- in IPv6 nodes.
- (This will be discussed further in other documents.)
-
-
-4. Procedures of the Domain Name Auto-Registration
-
- Figure 3 shows an example of typical Domain Name Auto-Registration
- procedures at IPv6 links where DAD packets are issued. DAD packets
- are used for the appearance detection method (for standard plugged-in
- IPv6 nodes).
-
- Plugged-in Router Detector Registrar DNS servers
- IPv6 Node
- | link local | | | |
- (a)|---DAD NS--->----------->| | |
- (b)| no NA | | | |
- (c)| | |----------->| |
- | | | | |
- | global | | | |
- (d)|(----RS--->)| | | |
- (e)|<----RA-----| | | |
- (f)|---DAD NS--->----------->| | |
- (g)| no NA | | | |
- (h)| | |----------->| |
- | | | | |
- (i)| | | |----------->|
- (j)| | | |<-----------|
- | | | | |
- (k)|(<-----------------------------------)| |
- (l)|(----------------------------------->)| |
- | | | | |
- (m)| | | |----------->|
- (n)| | | |<-----------|
- | | | | |
- (o)| | | |----------->|
- (p)| | | |<-----------|
- (q)| | | |----------->|
- (r)| | | |<-----------|
- | | | | |
-
- Fig. 3 Example of Typical Auto-Registration Procedures
-
- (a) and (b) are DAD procedures for the link-local address of the
- Plugged-in Node. (b) is a procedure to verify that there is no NA
- (reply to NS) and the link-local address is not duplicated on the
- link.
-
-
-
-H. Kitamura [Page 14]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- The Detector watches (a) and (b), and detects the appearance of new
- plugged-in IPv6 nodes. (c) is a procedure for sending the detected
- information, to which the Detector ID is attached. The scope of the
- detected address is not checked at the Detector.
-
- After the Registrar receives the detected information by the
- procedure (c), the scope of the detected address and the decision
- algorithm (which depends on the Detector ID) are checked on the
- Registrar.
-
- In typical cases, the decision algorithm shows that link-local
- addresses are not candidates for registration. In such cases, the
- detected information for the link-local address is discarded at this
- point.
-
- (d)(e)(f) and (g) are DAD procedures for the global address of the
- Plugged-in Node. (d) is an optional procedure. (g) is a procedure to
- verify that there is no NA (reply to NS) and that the global address
- is not duplicated.
-
- The Detector watches (f) and (g), and detects the appearance of new
- plugged-in IPv6 nodes. (h) is a procedure for sending the detected
- information, to which the Detector ID is attached.
-
- After the Registrar receives the detected information by the
- procedure (h), the scope of the detected address and decision
- algorithm (which depends on Detector ID) are checked on the
- Registrar.
-
- In typical cases, the decision algorithm shows that global addresses
- are candidates for registration. In such cases, check procedures to
- avoid duplicated registrations are started at this point.
-
- (i) and (j) are check procedures to verify that the detected address
- is must be registered to the DNS. The Registrar checks for the
- existence of FQDN information for the detected address by executing
- "inverse DNS name resolving" procedures with the detected address
- argument.
-
- If the existence of FQDN information for the detected address is
- verified, such detected address information for registration is
- canceled and discarded at this point.
-
- If the existence is not verified, the Registrar starts preparing
- "default domain name" information for the candidate IPv6 address. DNS
- zone suffix information that depends on the Detector ID is taken from
- the Registrar's manually configured database table, and the naming
- rule algorithm that depends on the Detector ID is also taken from it.
-
-
-
-H. Kitamura [Page 15]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- By following the defined naming rule algorithm, the plugged-in node's
- prefix name is selected.
-
- (k) and (l) are optional procedures for preparing "default domain
- name." If the naming rule that is applied for the detected address
- stipulates inquiring the preference or property of the node, (k) and
- (l) are executed and such information is obtained by the Registrar.
- The obtained information is used as a hint to select the prefix name
- of the plugged-in node.
-
- A candidate "default domain name" for the detected address is
- prepared here.
-
- (m) and (n) are check procedures to verify that the candidate
- "default domain name" is not used by anyone. The Registrar checks for
- the existence of the candidate "default domain name" by executing
- "regular DNS name resolving" procedures with the candidate "default
- domain name."
-
- If the existence is not verified, it becomes fully qualified "default
- domain name." If the existence is verified, the Registrar restarts
- and repeats preparing a candidate "default domain name" for the
- detected address.
-
-
- After fully qualified "default domain name" information to register
- is prepared, (o)(p)(q) and (r) are executed to register both regular
- and inverse domain name information to the DNS servers by the Dynamic
- Update messages.
-
- (Under manual configuration situations, (o)(p)(q) and (r) procedures
- are replaced by the administrators' manual registration (not by the
- Dynamic Updates).)
-
-
-5. Treatment of "Temporary Addresses" in the Mechanism
-
- "Temporary address" is defined in [RFC3041]. Temporary addresses are
- detected in this mechanism, because DAD packets are issued when
- temporary address are generated.
-
- There are two views whether domain names for temporary addresses
- should be registered to the DNS or not.
-
- One view is that domain names for temporary addresses should NOT be
- registered to the DNS, because temporary addresses are temporary and
- they are introduced to lessen privacy concerns.
-
-
-
-
-H. Kitamura [Page 16]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- The other view is domain names for temporary addresses should be
- registered to the DNS. [RFC3041] discusses on this issue at section 4
- of [RFC3041]. In order to meet conventional inverse-DNS-based
- "authentication," nodes could register temporary addresses in the DNS
- using random names. The Domain Name Auto-Registration mechanism can
- provide a solution for this issue.
-
- Since there are two views for domain names registration of temporary
- addresses, which view should be chosen is depends on site policies.
-
-
-
-5.1 How to Distinguish "Temporary Addresses" from Public Addresses
-
- In order to apply above discussed policies, it is necessary to
- distinguish "temporary addresses" from public addresses.
-
- Only with IP address information, it is difficult to tell that a
- detected address is a temporary address or a public addresses. So,
- link-layer address information is utilized to achieve this operation
- (see section 3.2).
-
- By utilizing link-layer address information, we can easily tell that
- a detected address is a EUI64-based address or not. (This operation
- is called a "EUI64 check" operation.)
-
- If a detected address is a EUI64-based, it is not a temporary
- address. It is a normal target address for the Domain Name Auto-
- Registration mechanism.
-
- If not, it must be a either temporary address or manually configured
- address. We can assume that a domain name for a manually configured
- address must have been registered in the DNS manually.
-
- In the mechanism, an IP address whose domain name has been already
- registered does not become a candidate. It is verified by "inverse
- DNS name resolving" check procedures (see (i) and (j) procedures in
- Figure 3).
-
- By applying a "EUI64 check" operation after "inverse DNS name
- resolving" check procedures, we can assume that non EUI64-based
- address must be a temporary address. Since temporary addresses are
- distinguished from public addresses, we can apply above discussed
- policies to temporary addresses.
-
-
-
-
-
-
-
-H. Kitamura [Page 17]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
-6. Security Considerations
-
- After the Address Autoconfiguration [ADDR-AUTO] has been executed,
- the Domain Name Auto-Registration works as a succeeding of the plug
- and play mechanism. The plugged-in IPv6 nodes' appearances detection
- method is depend on the Address Autoconfiguration.
-
- Thus, the items that are described in the Security Considerations
- section of the Address Autoconfiguration [ADDR-AUTO] are also
- applicable to this document.
-
- In addition, the following security issues are considered.
-
- Since the Detector must send detected information to the Registrar
- securely, some sort of secure communication method (e.g., [TSIG]-like
- authentication, IPsec (AH, ESP), [TLS]) must be used.
-
- The Registrars must be trusted nodes of the DNS servers and Dynamic
- Update messages must be sent securely from the Registrar to the DNS
- servers by using some sort of secure communication method. The [TSIG]
- technique would be suitable for authenticating the messages.
-
- In order to minimize the effects of malicious or misconfigured
- registration requests, the Registrar restricts the number of Dynamic
- Update messages that are sent from the Registrar per unit of time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-H. Kitamura [Page 18]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
-Appendix A. HTTP-based simple protocol between Detector and Registrar
-
- a. Design of HTTP parameters
-
- - Request Parameters
- method = <registration protocol>
- detectorID = <detector identifier(address)>
- IP-address = <detected IP address>
- link-layer-address = <detected link-layer address>
- source = <source type>
- time-detected = <detected time>
-
- - Response Parameters
- result = <result>
- address = <registered address>
- hostname = <registered hostname>
- namehint = <name hint>
- error = <error>
- time-accepted = <accepted time>
-
- b. Message Examples
-
- - Request message
- POST /cgi-bin/registrar.cgi HTTP/1.1
- Host: registrar-host
- Content-Length: mmm
- User-Agent: DAD-detector
- Content-type: application/x-pnp-dnar
-
- method=register/2.0
- detectorID=3ffe:xxxx::2a0:c9ff:fea6:7ff1
- IP-address=3ffe:yyyy::202:b3ff:fe2d:68c0
- link-layer-address=00:00:4c:zz:zz:zz
- source=DAD-detector
- time-detected=1013078377
-
- - Response message
- HTTP/1.1 200 OK
- Content-Type : text/plain
- Content-Length : nnn
- Connection : close
-
- result=REGISTER
- address=3ffe:yyyy::202:b3ff:fe2d:68c0
- hostname=host.example.com
- namehint=none
- time-accepted=1013078378
-
-
-
-
-H. Kitamura [Page 19]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
-References
-
- [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification," RFC2460, December 1998.
-
- [ND] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
- for IP Version 6 (IPv6)," RFC 2461, December 1998.
-
- [ADDR-AUTO] S. Thomson, T. Narten, "IPv6 Stateless Address
- Autoconfiguration," RFC2462, December 1998.
-
- [DYN-DNS] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic
- Updates in the Domain Name System," RFC 2136, April 1997.
-
- [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, D. and B.
- Wellington, "Secret Key Transaction Signatures for DNS
- (TSIG)," RFC 2845, May 2000.
-
- [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
- RFC2246, January 1999
-
- [DNS-SIG0] D. Eastlake, "DNS Request and Transaction Signatures
- ( SIG(0)s)," RFC2931, September 2000.
-
- [DYN-DNSSEC] B. Wellington, "Secure Domain Name System (DNS) Dynamic
- Update," RFC3007, November 2000.
-
- [DNSSEC] B. Wellington, "Domain Name System Security (DNSSEC) Signing
- Authority," RFC 3008, November 2000.
-
- [SNMP] J. Case, K. McCloghrie, M. Rose, S.Waldbusser, "Protocol
- Operations for Version 2 of the Simple Network Management
- Protocol (SNMPv2)," RFC1905, January 1996.
-
- [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless
- Address Autoconfiguration in IPv6," RFC3041, January 2001
-
- [HTTP] R. Fielding, et al, "Hypertext Transfer Protocol -- HTTP/1.1"
- RFC2616, June 1999
-
- [TLS-HTTP] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1"
- RFC2817, May 2000
-
- [DEF-ADDR] R. Draves, "Default Address Selection for Internet
- Protocol version 6 (IPv6)," RFC3484, February 2003
-
-
-
-
-
-
-H. Kitamura [Page 20]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2003
-
-
- [NIQ] M. Crawford, "IPv6 Node Information Queries,"
- <draft-ietf-ipngwg-icmp-name-lookups-10.txt>, June 2003
- "work in progress"
-
- [DNS-DISC] A. Durand, J. Hagino, D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers,"
- <draft-ietf-ipv6-dns-discovery-07.txt>, October 2002
- "work in progress"
-
-
-
-
-
-Author's Address:
-
- Hiroshi Kitamura
- Network Development Laboratories, NEC Corporation
- (Igarashi Building 4F) 11-5, Shibaura 2-Chome,
- Minato-Ku, Tokyo 108-8557, JAPAN
-
- Phone: +81 (3) 5476-1071
- Fax: +81 (3) 5476-1005
- Email: kitamura@da.jp.nec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-H. Kitamura [Page 21]
+
+
DNS Extensions Working Group J. Schlyter, Ed.
-Internet-Draft March 3, 2004
+Internet-Draft March 11, 2004
Updates: RFC 2535, RFC TCR
-Expires: September 1, 2004
+Expires: September 9, 2004
DNSSEC NSEC RDATA Format
- draft-ietf-dnsext-nsec-rdata-04.txt
+ draft-ietf-dnsext-nsec-rdata-05.txt
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on September 1, 2004.
+ This Internet-Draft will expire on September 9, 2004.
Copyright Notice
-Schlyter Expires September 1, 2004 [Page 1]
+Schlyter Expires September 9, 2004 [Page 1]
Internet-Draft DNSSEC NSEC RDATA Format March 2004
-Schlyter Expires September 1, 2004 [Page 2]
+Schlyter Expires September 9, 2004 [Page 2]
Internet-Draft DNSSEC NSEC RDATA Format March 2004
1. Introduction
- The NSEC [5] Resource Record (RR) is used for authenticated proof of
+ The NSEC [6] Resource Record (RR) is used for authenticated proof of
the non-existence of DNS owner names and types. The NSEC RR is based
- on the NXT RR as described in RFC 2535 [2], and is similar except for
+ on the NXT RR as described in RFC 2535 [3], and is similar except for
the name and typecode. The RDATA format for the NXT RR had a
limitation in that, without using a yet undefined extension
mechanism, the the RDATA could only carry information about the
For convenience and completeness this document presents the syntax
and semantics for the NSEC RR based on the specification in RFC 2535
- [2] and as updated by RFC TCR [5], thereby not introducing changes
+ [3] and as updated by RFC TCR [6], thereby not introducing changes
except for the syntax of the type bit map.
- This document updates RFC 2535 [2] and RFC TCR [5].
+ This document updates RFC 2535 [3] and RFC TCR [6].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
NSEC RRs in a zone both indicate which RRsets exist in a zone and
also form a chain of owner names in the zone. This information is
used to provide authenticated denial of existence for DNS data, as
- described in RFC 2535 [2].
+ described in RFC 2535 [3].
The type value for the NSEC RR is 47.
-Schlyter Expires September 1, 2004 [Page 3]
+Schlyter Expires September 9, 2004 [Page 3]
Internet-Draft DNSSEC NSEC RDATA Format March 2004
The NSEC RR RDATA format is class independent and defined for all
classes.
- The NSEC RR has no special TTL requirements.
+ The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+ field. This is in the spirit of negative caching [2].
2.1 NSEC RDATA Wire Format
-
-Schlyter Expires September 1, 2004 [Page 4]
+Schlyter Expires September 9, 2004 [Page 4]
Internet-Draft DNSSEC NSEC RDATA Format March 2004
it MUST be set to 0. After verification, the validator MUST ignore
the value of bit 0 in window block 0.
- Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [3]
+ Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [4]
(section 3.1) or within the range reserved for assignment only to
QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
zone data. If encountered, they must be ignored upon reading.
is treated as a literal symbol and is treated the same as any other
owner name for purposes of generating NSEC RRs. Wildcard owner names
appear in the Next Domain Name field without any wildcard expansion.
- RFC 2535 [2] describes the impact of wildcards on authenticated
+ RFC 2535 [3] describes the impact of wildcards on authenticated
denial of existence.
2.2 The NSEC RR Presentation Format
The List of Type Bit Map(s) Field is represented as a sequence of RR
type mnemonics. When the mnemonic is not known, the TYPE
- representation as described in RFC 3597 [4] (section 5) MUST be used.
+ representation as described in RFC 3597 [5] (section 5) MUST be used.
-Schlyter Expires September 1, 2004 [Page 5]
+Schlyter Expires September 9, 2004 [Page 5]
Internet-Draft DNSSEC NSEC RDATA Format March 2004
could be used to prove that beta.example.com does not exist, or could
be used to prove there is no AAAA record associated with
alfa.example.com. Authenticated denial of existence is discussed in
- RFC 2535 [2].
+ RFC 2535 [3].
3. IANA Considerations
This document introduces no new IANA considerations, because all of
the protocol parameters used in this document have already been
- assigned by RFC TCR [5].
+ assigned by RFC TCR [6].
4. Security Considerations
[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
+ [2] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-Schlyter Expires September 1, 2004 [Page 6]
+Schlyter Expires September 9, 2004 [Page 6]
Internet-Draft DNSSEC NSEC RDATA Format March 2004
+ 2308, March 1998.
+
+ [3] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
- [3] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name
+ [4] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name
System (DNS) IANA Considerations", BCP 42, RFC 2929, September
2000.
- [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+ [5] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
- [5] Weiler, S., "Legacy Resolver Compatibility for Delegation
+ [6] Weiler, S., "Legacy Resolver Compatibility for Delegation
Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
in progress), October 2003.
Informational References
- [6] Mockapetris, P., "Domain names - concepts and facilities", STD
+ [7] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
- [7] Mockapetris, P., "Domain names - implementation and
+ [8] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
-
-
-
-Schlyter Expires September 1, 2004 [Page 7]
+Schlyter Expires September 9, 2004 [Page 7]
Internet-Draft DNSSEC NSEC RDATA Format March 2004
-Schlyter Expires September 1, 2004 [Page 8]
+Schlyter Expires September 9, 2004 [Page 8]
Internet-Draft DNSSEC NSEC RDATA Format March 2004
-Schlyter Expires September 1, 2004 [Page 9]
+Schlyter Expires September 9, 2004 [Page 9]
+++ /dev/null
-DNSEXT Working Group David C Lawrence
-INTERNET-DRAFT Nominum
-<draft-ietf-dnsext-obsolete-iquery-04.txt> July 2002
-Updates: RFC 1035
-
-
-
-
- Obsoleting IQUERY
-
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
-
- 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
-
- Comments should be sent to the authors or the DNSEXT WG mailing list
- namedroppers@ops.ietf.org.
-
- This draft expires on 14 January 2003.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2002). All rights reserved.
-
-Abstract
-
- The IQUERY method of performing inverse DNS lookups, specified in
- RFC 1035, has not been generally implemented and has usually been
- operationally disabled where it has been implemented. Both reflect
- a general view in the community that the concept was unwise and
- that the widely-used alternate approach of using PTR queries and
- reverse-mapping records is preferable. Consequently, this document
- deprecates the IQUERY operation and updates RFC 1035 to declare it
- entirely obsolete.
-
-
-Expires Jan 2003 [Page 1]
-\f
-INTERNET-DRAFT Obsoleting IQUERY July 2002
-
-1 - Introduction
-
- As specified in RFC 1035 (section 6.4), the IQUERY operation for
- DNS queries is used to look up the name(s) which are associated
- with the given value. The value being sought is provided in the
- query's answer section and the response fills in the question
- section with one or more 3-tuples of type, name and class.
-
- As noted in [RFC1035], section 6.4.3, inverse query processing can
- put quite an onerous burden on a server. A server would need to
- perform either an exhaustive search of its database or maintain a
- separate database that is keyed by the values of the primary
- database. Both of these approaches could strain system resource
- use, particularly for servers that are authoritative for millions
- of names.
-
- Response packet from these megaservers could be exceptionally
- large, and easily run into megabyte sizes. For example, using
- IQUERY to find every domain that is delegated to one of the
- nameservers of a large ISP could return tens of thousands of
- 3-tuples in the question section. This could easily be used to
- launch denial of service attacks.
-
- Operators of servers that do support IQUERY in some form (such as
- very old BIND 4 servers) generally opt to disable it. This is
- largely due to bugs in insufficiently-exercised code, or concerns
- about exposure of large blocks of names in their zones by probes
- such as inverse MX queries.
-
- IQUERY is also somewhat inherently crippled by being unable to tell
- a requestor where it needs to go to get the information that was
- requested. The answer is very specific to the single server that
- was queried. This is sometimes a handy diagnostic tool, but
- apparently not enough so that server operators like to enable it,
- or request implementation where it's lacking.
-
- No known clients use IQUERY to provide any meaningful service. The
- only common reverse mapping support on the Internet, mapping
- address records to names, is provided through the use of PTR
- records in the in-addr.arpa tree and has served the community well
- for many years.
-
- Based on all of these factors, this draft proposes that the IQUERY
- operation for DNS servers be officially obsoleted.
-
-2 - Requirements
-
- The key word "SHOULD" in this document is to be interpreted as
- described in RFC 2119, namely that there may exit valid reasons
- to ignore a particular item, but the full implications must be
- understood and carefully weighed before choosing a different course.
-
-Expires Jan 2003 [Page 2]
-\f
-INTERNET-DRAFT Obsoleting IQUERY July 2002
-
-3 - Effect on RFC 1035
-
- The effect of this document is to change the definition of opcode 1
- from that originally defined in section 4.1.1 of RFC 1035, and to
- entirely supersede section 6.4 (including subsections) of RFC 1035.
-
- The definition of opcode 1 is hereby changed to:
-
- "1 an inverse query (IQUERY) (obsolete)"
-
-
- The text in section 6.4 of RFC 1035 is now considered obsolete.
- The following is an applicability statement regarding the IQUERY
- opcode:
-
- Inverse queries using the IQUERY opcode were originally described
- as the ability to look up the names that are associated with a
- particular RR. Their implementation was optional and never
- achieved widespread use. Therefore IQUERY is now obsolete, and
- name servers SHOULD return a "Not Implemented" error when an IQUERY
- request is received.
-
-4 - Security Considerations
-
- Since this document obsoletes an operation that was once available,
- it is conceivable that someone was using it as the basis of a
- security policy. However, since the most logical course for such a
- policy to take in the face of a lack of positive response from a
- server is to deny authentication/authorization, it is highly
- unlikely that removing support for IQUERY will open any new
- security holes.
-
- Note that if IQUERY is not obsoleted, securing the responses with
- DNSSEC is extremely difficult without out-on-the-fly digital signing.
-
-5 - IANA Considerations
-
- The IQUERY opcode of 1 should be permanently retired, not to be
- assigned to any future opcode.
-
-6 - Acknowledgments
-
- Olafur Gudmundsson was the instigator for this action.
- Matt Crawford, John Klensin, Erik Nordmark and Keith Moore
- contributed some improved wording as the matter of how to handle
- obsoleting functionality described by an Internet Standard.
-
-
-
-
-
-
-Expires Jan 2003 [Page 3]
-\f
-INTERNET-DRAFT Obsoleting IQUERY July 2002
-
-7 - References
-
-[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
- Specification'', STD 13, RFC 1035, November 1987.
-
-[RFC2026] S. Bradner, ``The Internet Standards Process -- Revision 3'',
- BCP 9, RFC 2026, October 1996.
-
-[RFC2119] S. Bradner, ``Key Words for Use in RFCs to Indicate
- Requirement Levels'', BCP 14, RFC 2119, March 1997.
-
-8 - Author's Address
-
- David C Lawrence
- Nominum, Inc.
- 2385 Bay Rd
- Redwood City CA 94063
- USA
-
- Phone: +1.650.779.6042
- EMail: tale@nominum.com
-
-9 - 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.
-
- 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."
-
-
-
-Expires Jan 2003 [Page 4]
+++ /dev/null
-INTERNET-DRAFT R. Gieben
-DNSEXT Working Group NLnet Labs
-Expires September 2001 T. Lindgreen
- NLnet Labs
-
- Parent's SIG over child's KEY
-
- draft-ietf-dnsext-parent-sig-00.txt
-
-
-Status of This Document
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. 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.
-
- Comments should be sent to the authors or the DNSEXT WG mailing
- list namedroppers@ops.ietf.org.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All rights reserved.
-
-
-Abstract
-
- When dealing with large amounts of keys the procedures to update a
- zone and to sign a zone need to be clearly defined and practically
- possible. The current idea is to have the KEY RR and the parent's
- SIG to reside in the child's zone and perhaps also in the parent's
- zone. We feel that this would lead to very complicated procedures for
- large TLDs. We propose an alternative scheme in which the parent zone
- stores the parent's signature over the child's key and also a copy of
- the child's key itself.
-
- The advantage of this proposal is that all signatures signed by a
- key are in the same zone file as the producing key. This allows for a
- simple key rollover and resigning mechanism. For large TLDs this is
- extremely important.
-
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 2]
-
-
- We further discuss the impact on a secure aware resolver/forwarder
- and the impact on the authority of KEYs and the NXT record.
-
-Table of Contents
-
- Status of This Document....................................2
- Abstract...................................................2
-
- Table of Contents..........................................3
- 1 Introduction.............................................3
- 2 Proposal.................................................4
- 3 Impact on a secure aware resolver/forwarder..............4
- 3.1 Impact of key rollovers on resolver/forwarder..........4
- 4 Key rollovers............................................5
- 4.1 Scheduled key rollover.................................5
- 4.2 Unscheduled key rollover...............................5
- 5 Zone resigning...........................................6
- 6. Consequences for KEY and NXT records....................6
- 6.1. KEY bit in NXT records................................6
- 6.2. Authority of KEY records..............................6
- 7. Security Considerations.................................6
-
- Authors' Addresses.........................................7
- References.................................................7
- Full Copyright Statement...................................7
-
-
-1. Introduction
- Within a CENTR working group NLnet Labs is researching the impact
- of DNSSEC on the ccTLDs and gTLDs.
-
- In this document we are considering a secure zone, somewhere under
- a secure entry point and on-tree [1] validation between the secure
- entry point and the zone in question. The resolver we are
- considering is security aware and is preconfigured with the KEY of
- the secure entry point.
-
- RFC 2535 [3] states that a zone key must be present in the apex of
- a zone. This can be in the at the delegation point in the parent's
- zonefile (normally the case for null keys), or in the child's
- zonefile, or in both. This key is only valid if it is signed by the
- parent, so there is also the question where this signature is
- located.
-
- The original idea was to have the KEY RR and the parent's SIG to
- reside in the child's zone and perhaps also in the parent's zone.
- There is a draft proposal [4], that describes how a keyrollover can
- be handled.
-
- At NLnet Labs we found that storing the parent's signature over
- the child's key in the child's zone:
- - makes resigning a KEY by the parent difficult
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 3]
-
-
- - makes a scheduled keyrollover very complicated
- - makes an unscheduled keyrollover virtually impossible
-
- We propose an alternative scheme in which the parent's signature
- over the child's key is only stored in the parent's zone, i.e. where
- the signing key resides. This would solve the above problems.
-
- 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 [2].
-
-
-2. Proposal
- The core of the new proposal is that the parent zone stores the
- parent's signature over the child's key and also a copy of the
- child's key itself. The child zone also contains its zonekey, where
- it is selfsigned.
-
- The advantage of this proposal is that all signatures signed by a
- key are in the same zone file as the producing key. This allows for a
- simple key rollover and resigning mechanism. For large TLD's this is
- extremely important. A disadvantage would be that not all the
- information concerning one zone is stored at that zone, namely the
- (parent) SIG RR. Note that the same argument can be applied to a
- zone's NULL key, which is also stored at the parent.
-
-
-3. Impact on a secure aware resolver/forwarder
- The resolver must be aware of the fact that the parent is more
- authoritative than a child when it comes to deciding whether a zone
- is secured or not.
-
- Without caching and with on-tree validation, a resolver will
- always start its search at a secure entry point. In this way it can
- determine whether it must expect SIG records or not.
-
- Considering caching in a secure aware resolver or forwarder. If
- information of a secure zone is cached, its validated KEY should also
- be cached.
-
- If the KEY record expires, because the KEY TTL expires or because
- the SIG is no longer valid, the KEY should be discarded. The resolver
- or forwarder should then also discard other data concerning the zone
- because it is no longer validated and possible bad data should not be
- cached.
-
-3.1. Impact of key rollovers on resolver/forwarder
-
- When a zone is in the process of a key rollover, there could be a
- discrepancy between the KEY and the SIG in the apex of the zone and
- the KEY and SIG that are stored in the cache of a resolver.
-
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 4]
-
-
-
- Suppose a resolver has cached the NS, KEY and SIG records of a
- zone. Next a request comes for an A record in that zone. Also the
- zone is in the process of a keyrollover and already has new keys in
- its zone. The resolver receives an answer consisting of the A record
- and a SIG over the A record. It uses the tag field in the SIG to
- determine if it has a KEY which is suitable to validate the SIG. If
- it does not has such a KEY the resolver must ask the parent of the
- zone for a new KEY and then try it again. Now the resolver has 2
- keys for the zone, according to the tag field in the SIG it can use
- either one.
-
- If the new key also does not validate the SIG the zone is marked
- bad. If the KEY found at the parent is the NULL key the resolver
- knows that the child is considered insecure. This could for instance
- be in the case the private key of the zone is stolen.
-
-
-4. Key rollovers
- Private keys can be stolen or a key can become over used. In both
- cases a new key must be signed and distributed. This event is called
- keyrollover. We further distinguish between a scheduled and an
- unscheduled key rollover. A scheduled rollover is announced before
- hand. An unscheduled key rollover is needed when a private key is
- compromised.
-
-4.1. Scheduled key rollover
- When the signatures, produced by the key to be rolled over, are
- all in one zone file, there are two parties involved. Let us look at
- an example where a TLD rolls over its zone key. The new key needs to
- be signed with the root's key before it can be used to sign the TLD
- zone and the zone keys of the TLD's children. The steps that need to
- be taken by TLD and root are:
- - the TLD adds the new key to its keyset in its zonefile. This
- zone and keyset are signed with the old zonekey
- - then the TLD signals the parent
- - the root copies the new keyset, consisting of the both new
- and the old key, in its zonefile, resigns it and signals the
- TLD
- - the TLD removes the old key from its keyset, resigns its zone
- with the new key, and signals the the root
- - the root copies the new keyset, now consisting of the new key
- only, and resigns it
-
-4.2. Unscheduled key rollover
- Although nobody hopes that this will ever happen, we must be able
- to cope with possible key compromises. When such an event occurs, an
- immediate keyrollover is needed and must be completed in the shortest
- possible time. With two parties involved, it will still be awkward,
- but not impossible to update two zonefiles overnight. "Out-of-band"
- communication between the two parties will be necessary, since the
- compromised old key can not be trusted. We think that between two
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 5]
-
-
- parties this is doable, but this complicated procedure is beyond the
- scope of this document. [5]
-
-
-5. Zone resigning
- Resigning a TLD is necessary before the current signatures expire.
- When all SIG records, produced by the TLD's zone key are kept in the
- TLD's zonefile, and only there, such a resign session is trivial, as
- only one party (the TLD) and one zonefile is involved.
-
-
-6. Consequences for KEY and NXT records
- A key record is only present in a child zone to facilitate a key
- rollover. A resolver should therefore be aware that the zonekey of a
- child zone is actually stored in the parent's zone. This also affects
- the NXT record and the authority of KEY resource records.
-
-6.1. KEY bit in NXT records
- RFC 2535 [3], section 5.2 states:
-
- " The NXT RR type bit map format currently defined is one bit per
- RR type present for the owner name. A one bit indicates that at
- least one RR of that type is present for the owner name. A zero
- indicates that no such RR is present. [....] "
-
- With a KEY still present in a child zone we do not see a compelling
- reason to change this default behavior.
-
-6.2. Authority of KEY records
- The parent of a zone generates the signature for the key belonging
- to that zone. By making that signature available the parent publicly
- states that the child zone is trustworthy: when it comes to security
- in DNSSEC the parent is more authoritative than the child.
-
- From this we conclude that a parent zone MUST set the authority
- bit to 1 and child zones MUST set this bit to 0 when dealing with
- KEYs from that child zone.
-
- A secure entry point has a selfsigned key and thus has no parent who
- is more authoritative on that key. This is not a problem. If a
- resolver knows that a secure entry point is a secure entry point it
- must have its key preconfigured. There is no need for a parent in
- this scenario, because the resolver itself can check the security of
- that zone. A interesting consequence of this is that nobody, but the
- resolver is authoritative for a key belonging to a secure entry
- point. This authority must established via some out of band
- mechanism, like publishing keys in a newspaper.
-
-
-7. Security Considerations
- This whole document is about security.
-
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 6]
-
-
-
-
-Authors' Addresses
-
- R. Gieben
- Stichting NLnet Labs
- Kruislaan 419
- 1098 VA Amsterdam
- miek@nlnetlabs.nl
-
- T. Lindgreen
- Stichting NLnet Labs
- Kruislaan 419
- 1098 VA Amsterdam
- ted@nlnetlabs.nl
-
-
-References
-
- [1] Lewis, E. "DNS Security Extension Clarification on Zone Status",
- www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.txt
- [2] Bradner, S. "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119
- www.ietf.org/rfc/rfc2119.txt
- [3] Eastlake, D. "DNS Security Extensions", RFC 2535
- www.ietf.org/rfc/rfc2535.txt
- [4] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security Key Rollover"
- www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt
- [5] Gieben, R. "Chain of trust"
- secnl.nlnetlabs.nl/thesis/thesis.html
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (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
- 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.
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 7]
-
-
-
- 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.
+++ /dev/null
-INTERNET-DRAFT R. Gieben
-DNSEXT Working Group NLnet Labs
-Expires September 2001 T. Lindgreen
- NLnet Labs
-
- Parent stores the child's zone KEYs
-
- draft-ietf-dnsext-parent-stores-zone-keys-01.txt
-
-
-Status of This Document
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. 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.
-
- Comments should be sent to the authors or the DNSEXT WG mailing
- list namedroppers@ops.ietf.org.
-
- This document updates RFC 2535.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All rights reserved.
-
-
-Abstract
-
- When dealing with large amounts of keys the procedures to update a
- zone and to sign a zone need to be clearly defined and practically
- possible. The current idea is to have the zone KEY RR and the
- parent's SIG to reside in the child's zone and perhaps also in the
- parent's zone. Operational experiences have prompted us to develop an
- alternative scheme in which the parent zone stores the parent's
- signature over the child's key and also the child's key itself.
-
- The advantage of this scheme is that all signatures signed by a key
- are in the same zone file as the producing key. This allows for a
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 2]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- simple key rollover and resigning mechanism. For large TLDs this is
- extremely important.
-
- Besides the operational advantages, this also obsoletes the NULL key,
- as the absence of child's zone KEY, which is securely verified by the
- absence of the KEY-bit in the corresponding NXT RR, now unambiguously
- indicates that the child is not secured by this parent.
-
- We further discuss the impact on a secure aware resolver/forwarder
- and the impact on the authority of KEYs and the NXT record.
-
-
-Table of Contents
-
- Status of This Document....................................
- Abstract...................................................
-
- Table of Contents..........................................
- 1 Introduction.............................................
- 2 Proposal.................................................
- 2.1. TTL of the KEY and SIG at the parent..................
- 2.2. No NULL KEY...........................................
- 3 Impact on a secure aware resolver/forwarder..............
- 3.1 Impact of key rollovers on resolver/forwarder..........
- 4 Scheduled key rollover...................................
- 5 Unscheduled key rollover.................................
- 6 Zone resigning...........................................
- 7. Consequences for KEY and NXT records....................
- 7.1. KEY bit in NXT records................................
- 7.2. Authority of KEY records..............................
- 7.3. Selecting KEY sets....................................
- 8. The zone-KEY and local KEY records......................
- 9. Security Considerations.................................
-
- Authors' Addresses.........................................
- References.................................................
- Full Copyright Statement...................................
-
-
-1. Introduction
- Within a CENTR working group NLnet Labs is researching the impact of
- DNSSEC on the ccTLDs and gTLDs.
-
- In this document we are considering a secure zone, somewhere under a
- secure entry point and on-tree [RFC 3090] validation between the
- secure entry point and the zone in question. The resolver we are
- considering is security aware and is preconfigured with the KEY of
- the secure entry point. We also make a distinction between a
- scheduled and a unscheduled key rollover. A scheduled rollover is
- announced before hand. An unscheduled key rollover is needed when a
- private key is compromised.
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 3]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
-
- RFC 2535 states that a zone KEY must be present in the apex of a
- zone. This can be in the at the delegation point in the parent's
- zonefile, or in the child's zonefile, or in both. This key is only
- valid if it is signed by the parent, so there is also the question
- where this signature and this zone KEY are located.
-
- The original idea was to have the zone KEY RR and the parent's SIG to
- reside in the child's zone and perhaps also in the parent's zone.
- There is a draft proposal [RFC 2535], that describes how a
- keyrollover can be handled.
-
- At NLnet Labs we found that storing the parent's signature over the
- child's zone KEY in the child's zone:
- - makes resigning a KEY by the parent difficult
- - makes a scheduled keyrollover very complicated
- - makes an unscheduled keyrollover virtually impossible
-
- We propose an alternative scheme in which the parent's signature over
- the child's zone KEY and the child's zone KEY itself are only stored
- in the parent's zone, i.e. where the signing key resides. This would
- solve the above problems and also obsoletes the NULL KEY.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119.
-
-
-2. Proposal
- The core of the new proposal is that the parent zone stores the
- parent's signature over the child's zone KEY and also the child's
- zone KEY itself, and is authoritative for both KEY and SIG. The
- child zone may also contain its zone KEY, in which case is must be
- selfsigned. The child zone must not hold the parent's SIG, and must
- also not set the AA-bit on requests for its zone KEY.
-
- The main advantage of this proposal is that all signatures signed by
- a key are in the same zone file as the producing key. This allows for
- a simple key rollover and resigning mechanism. For large TLDs this is
- extremely important. A disadvantage would be that not all the
- information concerning one zone is stored at that zone, this is
- covered in section 7.2.
-
- A parent running DNSSEC SHOULD NOT refuse a request from a child to
- include and sign its key, but can ask for certain conditions to be
- met. These condition could include a fee, sufficient authentication,
- signing a non liability clause, the conditions specified in section 8
- of this document, etc.
-
-2.1. TTL of the KEY and SIG at the parent
- Each zone in DNS expresses in its SOA record the maximum and minimum
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 4]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- TTL values that they allow in the zone. Thus it is possible that the
- parent will sign with a value that is unacceptable to the child. The
- parent MUST follow the TTL request of the child as long as that is
- within the allowed range for the parent.
-
-2.2. No NULL KEY
- This proposal obsoletes the NULL KEY. If there is no child KEY at the
- parent, which can be securely verified by inspecting the the unset
- KEY-bit in the corresponding NXT RR, the child is not secured by this
- parent (of course, the child can then still be secured off-tree).
- This updates section 3.1.2 "The zone KEY RR Flag Field" of RFC 2535,
- it says:
-
- " 11: If both bits are one, the "no key" value, there is no key
- information and the RR stops after the algorithm octet.
- By the use of this "no key" value, a signed zone KEY RR can
- authenticatably assert that, for example, a zone is not
- secured. See section 3.4 below. "
-
- As we don't have a NULL KEY anymore this is obsoleted.
- Section 3.4 "Determination of Zone Secure/Unsecured Status":
-
- " A zone KEY RR with the "no-key" type field value (both key type
- flag bits 0 and 1 on) indicates that the zone named is unsecured
- while a zone KEY RR with a key present indicates that the zone named
- is secure. The secured versus unsecured status of a zone may vary
- with different cryptographic algorithms. Even for the same
- algorithm, conflicting zone KEY RRs may be present. "
-
- This is rewritten as:
-
- " A zone is considered secured by on-tree validation [RFC 3090] when
- the there is a zone KEY from that zone present at its parent. If
- there is no zone KEY present, and the resolver is also unaware of
- alternative algorithms used and/or possible off-tree validation, the
- zone is considered unsecured. "
-
- To further clarify this. A zone is secure, when the resolver expects
- it to be, there are two possibilities:
- 1. When its parent is secure and holds a signed KEY for this child.
- 2. When zone is a secure entry point, i.e. the resolver is
- preconfigured with the KEY of this zone.
-
- RFC 3090 calls this globally secured.
-
- When a zone contains SIGs and a selfsigned KEY and this KEY is
- preconfigured in the resolvers of interest, the a zone can be
- considered locally secured (the RFC 3090 defintion). hijacked.
-
- If a zone is not globally or locally it must be considered unsecure.
-
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 5]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
-
-3. Impact on a secure aware resolver/forwarder
- The resolver must be aware of the fact that the parent is more
- authoritative than a child when it comes to deciding whether a zone
- is secured or not.
-
- Without caching and with on-tree validation, a resolver will always
- start its search at a secure entry point. In this way it can
- determine whether it must expect SIG records or not.
-
- Considering caching in a secure aware resolver or forwarder. If
- information of a secure zone is cached, its validated KEY should also
- be cached.
-
-3.1. Impact of key rollovers on resolver/forwarder
- When a zone is in the process of a key rollover, there could be a
- discrepancy between the KEY and the SIG in the apex of the zone and
- the KEY and SIG that are stored in the cache of a resolver.
-
- Suppose a resolver has cached the NS, KEY and SIG records of a zone.
- Next a request comes for an A record in that zone. Also the zone is
- in the process of a key rollover and already has new keys in its
- zone. The resolver receives an answer consisting of the A record and
- a SIG over the A record. It uses the tag field in the SIG to
- determine if it has a KEY which is suitable to validate the SIG. If
- it does not has such a KEY the resolver must ask the parent of the
- zone for a new KEY and then try it again. Now the resolver has 2
- keys for the zone, according to the tag field in the SIG it can use
- either one.
-
- If the new key also does not validate the SIG the zone is marked bad.
- If the parent indicates by having a not set KEY-bit in the NXT RR
- that there is no KEY for this zone, the child must be considered
- unsecured by this parent, despite the appearance of an (old) KEY in
- the cache. This could for instance happen after an emergency request
- from the child, who has suffered a key compromise, and has decided to
- prefer being unsecured over either dropping of the Internet or being
- exposed to have verifiable secure info added by the key-compromiser
- to their zone information.
-
-
-4. Scheduled key rollover
- When the signatures, produced by the key to be rolled over, are all
- in one zone file, there are two parties involved. Let us look at an
- possible example where a TLD rolls over its zone KEY. The new key
- needs to be signed with the root's key before it can be used to sign
- the TLD zone and the zone KEYs of the TLD's children. The steps that
- need to be taken by TLD and root are:
- - the TLD adds the new key to its KEY set in its zonefile. This
- zone and KEY set are signed with the old zone KEY
- - then the TLD signals the parent
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 6]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- - the root copies the new KEY set, consisting of the both new and
- the old key, in its zonefile, resigns it and signals the TLD
- - the TLD removes the old key from its KEY set, resigns its zone
- with the new KEY, and signals the the root
- - the root copies the new KEY set, now consisting of the new key
- only, and resigns it
-
- Note that this procedure is immune to fake signals and spoofing
- attacks (as long as there is no key compromise):
- - on a fake signal either way the action becomes a null-action as
- the new KEY set is identical to the existing one.
- - a spoofed new KEY set will not validate with the existing KEY
- that the parent holds.
-
-
-5. Unscheduled key rollover
- Although nobody hopes that this will ever happen, we must be able to
- cope with possible key compromises. When such an event occurs, an
- immediate keyrollover is needed and must be completed in the shortest
- possible time. With two parties involved, it will still be awkward,
- but not impossible to update two zonefiles overnight. "Out-of-band"
- communication between the two parties will be necessary, since the
- compromised old key can not be trusted. We think that between two
- parties this is doable, but this complicated procedure is beyond the
- scope of this document.
-
- An alternative to an emergency key-rollover is becoming unsecured as
- an emergency measure. This has already been mentioned above in
- section 3.1. This only involves an emergency change in the parents
- zonefile (deleting the child's zone KEY), and allows the child and
- its underlying zones time to clean up before becoming secured again,
- without dropping from the Internet or being exposed to having secured
- but false zone information.
-
-
-6. Zone resigning
- Resigning a TLD is necessary before the current signatures expire.
- When all SIGs (produced by the TLD's zone KEY) and the child KEY
- records, are kept in the TLD's zonefile, such a resign session is
- trivial, as only one party (the TLD) and one zonefile are involved.
-
-
-7. Consequences for KEY and NXT records
- There are two reasons to have of the child's zone KEY not only at the
- parent but also in the child's own zonefile:
- 1. to facilitate a key-rollover
- 2. to prevent local lookups for local information to suffer
- from possible loss of access to its outside parent
-
- To cope with 1, secure aware resolvers MUST be aware that during a
- key-rollover there may be a conflict, and that in that case the
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 7]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- parent always holds the active KEY set. To cope with 2, the local
- resolver/caching forwarder should be preconfigured with the zone-KEY
- and thus looks at its own zone as were it a secure entry-point. For
- both things to work, the zone-KEY set must be selfsigned in the child
- zonefile.
-
-7.1. KEY bit in NXT records
- RFC 2535, section 5.2 states:
-
- " The NXT RR type bit map format currently defined is one bit per RR
- type present for the owner name. A one bit indicates that at least
- one RR of that type is present for the owner name. A zero indicates
- that no such RR is present. [....] "
-
- As the zone KEY is present in a child zone, and signed by the zone
- KEY (thus selfsigned), the definition of NXT RR type bit states in
- RFC 2535, section 5.2 that the KEY bit must be set. We do not see a
- compelling reason to change this default behavior.
-
-7.2. Authority of KEY records
- The parent of a zone generates the signature for the key belonging to
- that zone. By making that signature available the parent publicly
- states that the child zone is trustworthy: when it comes to security
- in DNSSEC the parent is more authoritative than the child.
-
- From this we conclude that a parent zone MUST set the authority bit
- to 1 and child zones MUST set this bit to 0 when dealing with KEYs
- from that child zone.This also causes resolvers to pick up and cache
- the right KEY set, in case it finds conflicting KEY sets during a
- key-rollover.
-
- Some zones have no parent to make it authoritatively secure, for
- instance, the root. To be secure anyway it must be defined a secure
- entry point. If a resolver knows that a secure entry point is a
- secure entry point it must have its key preconfigured. There is no
- need for a parent in this scenario, because the resolver itself can
- check the security of that zone. A interesting consequence of this is
- that nobody is authoritative for a key belonging to a secure entry
- point. This authority must established via some out of band
- mechanism, like publishing it in a newspaper.
-
-7.3. Selecting KEY sets
- As the zone KEY set is present in two places, there is a possibility
- of two conflicting KEY sets, this will happen during a key-rollover
- and may happen at other times.
-
- With one exception, a resolver MUST always select the KEY set from
- the parent in case of a conflict, as this is the active KEY set. For
- this reason, the parent sets the AA-bit on requests, while the child
- does not.
-
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 8]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- The one exception is when a resolver regards the child's zone as a
- secure-entry point, in which case it has the zone KEY preconfigured.
- In other words: a preconfigured KEY has even more authority then what
- a parent says. Specifying a zone as a secure entry-point makes sense
- for a local resolver in its own local zone.
-
-
-8. The zone KEY and local KEY records.
- It must be recognized that the zone KEY RR, which is signed by a
- non-local organization, is something special. The external signature
- over the public part of the key provides the local zone-administrator
- with the authority to use the corresponding private part to sign
- everything local, and thus to make his/her own zone secure. Please
- also note that the external signer, and NOT the local zone is
- authoritative for the zone KEY RRset.
-
- Part of the RRs that the zone-administrator may wish to sign are KEY
- RRs for local use, for instance for IPSEC.
-
- To make sure, that the local zone is authoritative for its own local
- KEY RRs, and that they get not exported and signed externally, these
- local KEY records SHOULD not be part of the zone KEY RRset.
- Therefore, they could be placed under a label in the zonefile, f.i.
- keys.child.parent, or for these kind of keys a new RR type could be
- defined (e.g. PUBKEY).
-
- Besides being kept clear of local KEY records, the zone KEY RRset
- SHOULD also be kept clear of any other obsolete or otherwise not
- strictly needed KEY records, because this increases the number of
- possible key compromise attacks and also increases the size of the
- parents zone file unnecessarily.
-
- In other words: the KEY RRset with the toplevel label of a zone
- SHOULD only contain its active zone KEY, unless a key-rollover is in
- progress. During a keyrollover a new KEY RR must be added to this
- RRset. Once the new KEY becomes the active zone KEY, the old KEY
- becomes obsolete and SHOULD be removed as soon as practically
- possible. Information stored in caches SHOULD NOT be an issue on when
- to remove the old zone KEY.
-
-
-9. Security Considerations
- This document addresses the operational difficulties that arise when
- DNSSEC is deployed. By putting the child's zone KEY at the parent we
- solve at lot of problems by minimizing the amount of communication
- between the two. There is one security issue: the parent must not
- ever create a valid parental SIG over a KEY RR, from which the
- private part is (also) known to someone else than the legitimate
- administrator of the child zone. This can happen in two ways:
- 1. The private KEY at the child has been compromised.
- 2. The parent has been fooled and thus insufficiently checked
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 9]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- whether the KEY RR is really from the child.
-
- For the security it doesn't matter if the SIG and the KEY are located
- at the child or at the parent, but if they are located at the parent
- it is much easier to replace the SIG. And by keeping the parental SIG
- lifetime short, the parent helps to protect the child against
- possible key compromises. The selfsigned zone KEY stored in the
- child's zone can have a long SIG expiration lifetime, this has no
- impact on the child's security.
-
- All security considerations from RFC 2535 apply.
-
-
-Authors' Addresses
-
- R. Gieben T. Lindgreen
- Stichting NLnet Labs Stichting NLnet Labs
- Kruislaan 419 Kruislaan 419
- 1098 VA Amsterdam 1098 VA Amsterdam
- miek@nlnetlabs.nl ted@nlnetlabs.nl
-
-
-References
-
- [RFC 3090] Lewis, E. "DNS Security Extension Clarification on Zone
- Status", RFC 3090
- www.ietf.org/rfc/rfc3090.txt
- [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119
- www.ietf.org/rfc/rfc2119.txt
- [RFC 2535] Eastlake, D. "DNS Security Extensions", RFC 2535
- www.ietf.org/rfc/rfc2535.txt
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (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
- 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.
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 10]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
-
- 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.
+++ /dev/null
-Internet Engineering Task Force S. Thomson, Cisco
-INTERNET-DRAFT C. Huitema, Microsoft
-May 12, 2003 V. Ksinant, 6WIND
-Expires November 12, 2003 M. Souissi, AFNIC
-
-
-
-
-
- DNS Extensions to support IP version 6
- <draft-ietf-dnsext-rfc1886bis-03.txt>
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of [RFC2026].
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
- This Internet Draft expires November 12, 2003.
-
-
-
-Abstract
-
- This document defines the changes that need to be made to the Domain
- Name System to support hosts running IP version 6 (IPv6). The
- changes include a resource record type to store an IPv6 address,
- a domain to support lookups based on an IPv6 address, and updated
- definitions of existing query types that return Internet addresses as
- part of additional section processing. The extensions are designed
- to be compatible with existing applications and, in particular, DNS
- implementations themselves.
-
- This Document combines RFC1886 and changes to RFC 1886 made by
- RFC 3152, obsoleting both. Changes mainly consist in replacing
- the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
-
-
-
-
-
-
-draft-ietf-dnsext-rfc1886bis-03.txt [Page 1]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 May 2003
-
-
-Table of Contents
-
- 1. Introduction............................................. 2
- 2. New resource record definition and domain................ 2
- 2.1. AAAA record type.................................... 3
- 2.2. AAAA data format.................................... 3
- 2.3. AAAA query.......................................... 3
- 2.4. Textual format of AAAA records...................... 3
- 2.5. IP6.ARPA domain..................................... 3
- 3. Modifications to existing query types.................... 4
- 4. Security Considerations.................................. 4
- 5. IANA Considerations...................................... 4
- APPENDIX A: Changes from RFC-1886............................ 4
- Acknowledgments.............................................. 5
- References................................................... 5
- Authors' Addresses........................................... 6
- Full Copyright Statement..................................... 7
-
-
-1. INTRODUCTION
-
- Current support for the storage of Internet addresses in the Domain
- Name System (DNS)[1,2] cannot easily be extended to support IPv6
- addresses[3] since applications assume that address queries return
- 32-bit IPv4 addresses only.
-
- To support the storage of IPv6 addresses in DNS, this document
- defines the following extensions:
-
- o A resource record type is defined to map a domain name to an
- IPv6 address.
-
- o A domain is defined to support lookups based on address.
-
- o Existing queries that perform additional section processing to
- locate IPv4 addresses are redefined to perform additional
- section processing on both IPv4 and IPv6 addresses.
-
- The changes are designed to be compatible with existing software. The
- existing support for IPv4 addresses is retained. Transition issues
- related to the co-existence of both IPv4 and IPv6 addresses in DNS
- are discussed in [4].
-
-
-2. RESOURCE RECORD DEFINITION AND DOMAIN
-
- A record type is defined to store a host's IPv6 address. A host
- that has more than one IPv6 address must have more than one such
- record.
-
-draft-ietf-dnsext-rfc1886bis-03.txt [Page 2]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 May 2003
-
-2.1 AAAA record type
-
- The AAAA resource record type is a record specific to the Internet
- class that stores a single IPv6 address.
-
- The IANA assigned value of the type is 28 (decimal).
-
-
-2.2 AAAA data format
-
- A 128 bit IPv6 address is encoded in the data portion of an AAAA
- resource record in network byte order (high-order byte first).
-
-
-2.3 AAAA query
-
- An AAAA query for a specified domain name in the Internet class
- returns all associated AAAA resource records in the answer section of
- a response.
-
- A type AAAA query does not perform additional section processing.
-
-
-2.4 Textual format of AAAA records
-
- The textual representation of the data portion of the AAAA resource
- record used in a master database file is the textual representation
- of a IPv6 address as defined in [3].
-
-
-2.5 IP6.ARPA Domain
-
- A special domain is defined to look up a record given an address. The
- intent of this domain is to provide a way of mapping an IPv6 address
- to a host name, although it may be used for other purposes as well.
- The domain is rooted at IP6.ARPA.
-
- An IPv6 address is represented as a name in the IP6.ARPA domain by a
- sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
- The sequence of nibbles is encoded in reverse order, i.e. the
- low-order nibble is encoded first, followed by the next low-order
- nibble and so on. Each nibble is represented by a hexadecimal digit.
- For example, the inverse lookup domain name corresponding to the
- address
-
- 4321:0:1:2:3:4:567:89ab
-
- would be
-
-b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
- ARPA.
-
-draft-ietf-dnsext-rfc1886bis-03.txt [Page 3]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 May 2003
-
-3. MODIFICATIONS TO EXISTING QUERY TYPES
-
- All existing query types that perform type A additional section
- processing, i.e. name server (NS), location of services (SRV) and
- mail exchange (MX) query types, must be redefined to perform both
- type A and type AAAA additional section processing. These definitions
- mean that a name server must add any relevant IPv4 addresses and any
- relevant IPv6 addresses available locally to the additional section
- of a response when processing any one of the above queries.
-
-
-4. SECURITY CONSIDERATIONS
-
- Any information obtained from the DNS must be regarded as unsafe
- unless techniques specified in [7] or [8] are used. The definitions
- of the AAAA record type and of the IP6.ARPA domain do not change the
- model for use of these techniques.
-
- So, this specification is not believed to cause any new security
- problems, nor to solve any existing ones.
-
-5. IANA CONSIDERATIONS
-
- There are no IANA assignments to be performed.
-
-APPENDIX A: Changes from RFC 1886
-
- The following changes were made from RFC 1886 "DNS Extensions to
- support IP version 6":
-
- - Replaced the "IP6.INT" domain by "IP6.ARPA".
- - Mentioned SRV query types in section 3 "MODIFICATIONS TO
- EXISTING QUERY TYPES"
- - Added security considerations.
- - Updated references :
- * From RFC 1884 to RFC 3513 (IP Version 6 Addressing
- Architecture).
- * From "work in progress" to RFC 2893 (Transition Mechanisms for
- IPv6 Hosts and Routers).
- * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
- - Updated document abstract
- - Added table of contents
- - Added full copyright statement
- - Added IANA considerations section
-
-
-
-
-
-
-draft-ietf-dnsext-rfc1886bis-03.txt [Page 4]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 May 2003
-
-Acknowledgements
-
- Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
- Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael
- Guerin (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND),
- Frederic Roudaut (IRISA) and G6 group for their help during the RFC
- 1886 Interop tests sessions.
-
- Many thanks to Alain Durand and Olafur Gudmundsson for their support.
-
-
-
-Normative References
-
- [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
- 13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [2] Mockapetris, P., "Domain Names - Implementation and Specifica-
- tion", STD 13, RFC 1035, USC/Information Sciences Institute,
- November 1987.
-
-
-
-Informative References
-
- [3] Hinden, R., and S. Deering, "Internet Protocol Version 6 (IPv6)
- Addressing Architecture", RFC 3513, Nokia, Cisco, April 2003.
-
- [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
- Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems
- Inc., August 2000.
- This RFC is being updated. The current draft is
- "draft-ietf-v6ops-mech-v2-00.txt", Gilligan, R., and
- E. Nordmark, February 24, 2003
-
- [5] Thomson, S., and C. Huitema, "DNS Extensions to support IP
- version 6", RFC 1886, Bellcore, INRIA, December 1995.
-
- [6] Bush, R., "Delegation of IP6.ARPA", RFC 3152, RGnet, August
- 2001.
-
- [7] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, IBM, March 1999
-
- [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, ISC, NAI Labs, Motorola, Nominum, May 2000.
-
-
-
-
-
-draft-ietf-dnsext-rfc1886bis-03.txt [Page 5]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 May 2003
-
-
-Authors' Addresses
-
-
- Susan Thomson
- Cisco Systems
- 499 Thornall Street, 8th floor
- Edison, NJ 08837
- Telephone: 732-635-3086
- Email: sethomso@cisco.com
-
-
- Christian Huitema
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052-6399
- Email: huitema@microsoft.com
-
-
- Vladimir Ksinant
- 6WIND S.A.
- Immeuble Central Gare - Bat.C
- 1, place Charles de Gaulle
- 78180, Montigny-Le-Bretonneux - France
- Phone: +33 1 39 30 92 36
- Email: vladimir.ksinant@6wind.com
-
-
- Mohsen Souissi
- AFNIC
- Immeuble International
- 2, rue Stephenson,
- 78181, Saint-Quentin en Yvelines Cedex - France
- Phone: +33 1 39 30 83 40
- Email: Mohsen.Souissi@nic.fr
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-dnsext-rfc1886bis-03.txt [Page 6]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 May 2003
-
-Full Copyright Statement
-
-
- Copyright (C) The Internet Society (date). All Rights
- Reserved.
-
- This document and translations of it may be copied and
- furnished to others, and derivative works that comment on or
- otherwise explain it or assist in its implmentation may be
- prepared, copied, published and distributed, in whole or in
- part, without restriction of any kind, provided that the above
- copyright notice and this paragraph are included on all such
- copies and derivative works. However, this document itself may
- not be modified in any way, such as by removing the copyright
- notice or references to the Internet Society or other Internet
- organizations, except as needed for the purpose of developing
- Internet standards in which case the procedures for copyrights
- defined in the Internet Standards process must be followed, or
- as required to translate it into languages other than English.
-
- The limited permissions granted above are perpetual and will
- not be revoked by the Internet Society or its successors or
- assigns.
-
- This document and the information contained herein is provided
- on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
- IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
- OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
- IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
- PARTICULAR PURPOSE."
-
- 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.
-
-
-draft-ietf-dnsext-rfc1886bis-03.txt [Page 7]
+++ /dev/null
-
-
-INTERNET-DRAFT DSA Information in the DNS
-OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: January 2004 July 2003
-
-
-
-
-
- DSA Keying and Signature Information in the DNS
- --- ------ --- --------- ----------- -- --- ---
- <draft-ietf-dnsext-rfc2536bis-dsa-03.txt>
-
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org> or to the author.
-
- This document is an Internet Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. 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
-
- A standard method of encoding US Government Digital Signature
- Algorithm keying and signature information is described for use in
- the Domain Name System.
-
-
-
-
-
-
-
-
-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
-
- Normative References.......................................6
- Informative References.....................................6
- Author's Address...........................................6
- Expiration and File Name...................................7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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 2535] 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 th RR being used is as shown
- below.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR 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 so 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
- occur.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- 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 infromation on the SHA-1 hash function see [FIPS 180-1] 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 [RFC 1750] 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 requires an IETF standards actions. It is intended
- that values unallocated herein be used to cover future extensions of
- the DSS standard.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Normative References
-
- [FIPS 180-1] - U.S. Federal Information Processing Standard: Secure
- Hash Standard, April 1995.
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, 27 January 2000.
-
-
-
-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 1750] - "Randomness Recommendations for Security", D. Eastlake,
- S. Crocker, J. Schiller, December 1994.
-
- [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake
- 3rd, March 1999.
-
- [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.
-
- [Schneier] - "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C", Bruce Schneier, 1996, John Wiley
- and Sons, ISBN 0-471-11709-9.
-
-
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Labortories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-851-8280(w)
- +1-508-634-2066(h)
- EMail: Donald.Eastlake@motorola.com
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DSA Information in the DNS
-
-
-Expiration and File Name
-
- This draft expires in January 2004.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-03.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
- Motorola Laboratories
-Expires: January 2004 July 2003
-
-
-
-
- Storage of Diffie-Hellman Keying Information in the DNS
- ------- -- -------------- ------ ----------- -- --- ---
- <draft-ietf-dnsext-rfc2539bis-dhk-03.txt>
-
-
-
-Status of This Document
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org> or to the author.
-
- This document is an Internet Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. 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
-
- A standard method for encoding Diffie-Hellman keys in the Domain Name
- System is described.
-
-
-
-
-
-
-
-
-
-
-
-
-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
-
- Normative References.......................................6
- Informative Refences.......................................6
- Author's Address...........................................6
- Expiration and File Name...................................7
-
- Appendix A: Well known prime/generator pairs...............8
- A.1. Well-Known Group 1: A 768 bit prime..................8
- A.2. Well-Known Group 2: A 1024 bit prime.................8
- A.3. Well-Known Group 3: A 1536 bit prime.................9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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 2535] and additonal work is underway which would require the
- storage of keying and signature information in the DNS.
-
-
-
-1.1 About This Document
-
- This document describes how to store Diffie-Hellman keys in the DNS.
- Familiarity with the Diffie-Hellman key exchange algorithm is assumed
- [Schneier, RFC 2631].
-
-
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Thus Diffie-
- Hellman is inherently a key agreement algorithm. As a result, no
- format is defined for Diffie-Hellman "signature information". For
- example, assume that two parties have local secrets "i" and "j".
- Assume they each respectively calculate X and Y as follows:
-
- X = g**i ( mod p )
-
- Y = g**j ( mod p )
-
- They exchange these quantities and then each calculates a Z as
- follows:
-
- Zi = Y**i ( mod p )
-
- Zj = X**j ( mod p )
-
- Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
- secret between the two parties that an adversary who does not know i
- or j will not be able to learn from the exchanged messages (unless
- the adversary can derive i or j by performing a discrete logarithm
- mod p which is hard for strong p and g).
-
- The private key for each party is their secret i (or j). The public
- key is the pair p and g, which must be the same for the parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
- in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
- When Diffie-Hellman keys appear within the RDATA portion of a RR,
- they are encoded as shown below.
-
- The period of key validity is not included in this data but is
- indicated separately, for example by an RR 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 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, 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 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.
-
-
-
-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. [RFC 2631, Schneier]
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Normative References
-
- [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
- 1999.
-
- [RFC 2434] - Guidelines for Writing an IANA Considerations Section in
- RFCs, T. Narten, H. Alvestrand, October 1998.
-
-
-
-Informative Refences
-
- [RFC 1034] - P. Mockapetris, "Domain names - concepts and
- facilities", November 1987.
-
- [RFC 1035] - P. Mockapetris, "Domain names - implementation and
- specification", November 1987.
-
- [RFC 2535] - Domain Name System Security Extensions, D. Eastlake 3rd,
- March 1999.
-
- [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.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
- and Sons.
-
-
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-851-8280 (w)
- +1-508-634-2066 (h)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Information in the DNS
-
-
-Expiration and File Name
-
- This draft expires in January 2004.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-03.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 7]
-\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 8]
-\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 9]
-\f
+++ /dev/null
-
-
-
-
-
-Network Working Group A. Gulbrandsen
-Category: INTERNET-DRAFT Trolltech AS
-Obsoletes: 2782 P. Vixie
-draft-ietf-dnsext-rfc2782bis-01.txt Internet Software Consortium
-June 6, 2001 L. Esibov
-Expires: December 6, 2001 Microsoft Corp.
-
-
-
- A DNS RR for specifying the location of services (DNS SRV)
-
-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 (2001). All Rights Reserved.
-
-Abstract
-
- This document describes a DNS RR which specifies the location of the
- server(s) for a specific protocol and domain.
-
-Overview and rationale
-
- Currently, one must either know the exact address of a server to
- contact it, or broadcast a question.
-
- 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.
-
- Clients ask for a specific service/protocol for a specific domain
- (the word domain is used here in the strict RFC 1034 sense), and get
- back the names of any available servers.
-
- Note that where this document refers to "address records", it means A
- RR's, AAAA RR's, or their most modern equivalent.
-
-
-
-
-
-Expires December 2001 [Page 1]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-Definitions
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
- used in this document are to be interpreted as specified in [BCP 14].
- Other terms used in this document are defined in the DNS
- specification, RFC 1034.
-
-Applicability Statement
-
- In general, it is expected that SRV records will be used by clients
- for applications where the relevant protocol specification indicates
- that clients should use the SRV record. Such specification MUST
- define the symbolic name to be used in the Service field of the SRV
- record as described below. It also MUST include security
- considerations. Service SRV records SHOULD NOT be used in the absence
- of such specification.
-
-Introductory example
-
- If a SRV-cognizant LDAP client wants to discover a LDAP server that
- supports TCP protocol and provides LDAP service for the domain
- example.com., it does a lookup of
-
- _ldap._tcp.example.com
-
- as described in [ARM]. The example zone file near the end of this
- memo contains answering RRs for an SRV query.
-
- Note: LDAP is chosen as an example for illustrative purposes only,
- and the LDAP examples used in this document should not be considered
- a definitive statement on the recommended way for LDAP to use SRV
- records. As described in the earlier applicability section, consult
- the appropriate LDAP documents for the recommended procedures.
-
-The format of the SRV RR
-
- Here is the format of the SRV RR, whose DNS type code is 33:
-
- _Service._Proto.Domain TTL Class SRV Priority Weight Port Target
-
- (There is an example near the end of this document.)
-
- Service
- The symbolic name of the desired service, as defined in Assigned
- Numbers [STD 2] or locally. An underscore (_) is prepended to
- the service identifier to avoid collisions with DNS labels that
- occur in nature.
-
-
-
-
-
-Expires December 2001 [Page 2]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- Some widely used services, notably POP, don't have a single
- universal name. If Assigned Numbers names the service
- indicated, that name is the only name which is legal for SRV
- lookups. The Service is case insensitive.
-
- Proto
- The symbolic name of the desired protocol, with an underscore
- (_) prepended to prevent collisions with DNS labels that occur
- in nature. _TCP and _UDP are at present the most useful values
- for this field, though any name defined by Assigned Numbers or
- locally may be used (as for Service). The Proto is case
- insensitive.
-
- Domain
- The domain this RR refers to. The SRV RR is unique in that the
- name one searches for is not this Domain name; the example near
- the end shows this clearly.
-
- TTL
- Standard DNS meaning [RFC 1035].
-
- Class
- Standard DNS meaning [RFC 1035]. SRV records occur in the IN
- Class.
-
- Priority
- The priority of this target host. A client MUST attempt to
- contact the target host with the lowest-numbered priority it can
- reach; target hosts with the same priority SHOULD be tried in an
- order defined by the weight field. The range is 0-65535. This
- is a 16 bit unsigned integer in network byte order.
-
- Weight
- A server selection mechanism. The weight field specifies a
- relative weight for entries with the same priority. Larger
- weights SHOULD be given a proportionately higher probability of
- being selected. The range of this number is 0-65535. This is a
- 16 bit unsigned integer in network byte order. Domain
- administrators SHOULD use Weight 0 when there isn't any server
- selection to do, to make the RR easier to read for humans (less
- noisy). In the presence of records containing weights greater
- than 0, records with weight 0 should have a very small chance of
- being selected.
-
- In the absence of a protocol whose specification calls for the
- use of other weighting information, a client arranges the SRV
- RRs of the same Priority in the order in which target hosts,
-
-
-
-
-Expires December 2001 [Page 3]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- specified by the SRV RRs, will be contacted. The following
- algorithm SHOULD be used to order the SRV RRs of the same
- priority:
-
- To select a target to be contacted next, arrange all SRV RRs
- (that have not been ordered yet) in any order, except that all
- those with weight 0 are placed at the beginning of the list.
-
- Compute the sum of the weights of those RRs, and with each RR
- associate the running sum in the selected order. Then choose a
- uniform random real number between 0 and the sum computed
- (inclusive), and select the RR whose running sum value is the
- first in the selected order which is greater than or equal to
- the random number selected. The target host specified in the
- selected SRV RR is the next one to be contacted by the client.
- Remove this SRV RR from the set of the unordered SRV RRs and
- apply the described algorithm to the unordered SRV RRs to select
- the next target host. Continue the ordering process until there
- are no unordered SRV RRs. This process is repeated for each
- Priority.
-
- Port
- The port on this target host of this service. The range is 0-
- 65535. This is a 16 bit unsigned integer in network byte order.
- This is often as specified in Assigned Numbers but need not be.
-
- Target
- The domain name of the target host. There MUST be one or more
- address records for this name, the name MUST NOT be an alias (in
- the sense of RFC 1034 or RFC 2181). Implementors are urged, but
- not required, to return the address record(s) in the Additional
- Data section. Unless and until permitted by future standards
- action, name compression is not to be used for this field.
-
- A Target of "." means that the service is decidedly not
- available at this domain.
-
-Domain administrator advice
-
- Expecting everyone to update their client applications when the first
- server publishes a SRV RR is futile (even if desirable). Therefore
- SRV would have to coexist with address record lookups for existing
- protocols, and DNS administrators should try to provide address
- records to support old clients:
-
- - Where the services for a single domain are spread over several
- hosts, it seems advisable to have a list of address records at
- the same DNS node as the SRV RR, listing reasonable (if perhaps
-
-
-
-Expires December 2001 [Page 4]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- suboptimal) fallback hosts for Telnet, NNTP and other protocols
- likely to be used with this name. Note that some programs only
- try the first address they get back from e.g. gethostbyname(),
- and we don't know how widespread this behavior is.
-
- - Where one service is provided by several hosts, one can either
- provide address records for all the hosts (in which case the
- round-robin mechanism, where available, will share the load
- equally) or just for one (presumably the fastest).
-
- - If a host is intended to provide a service only when the main
- server(s) is/are down, it probably shouldn't be listed in
- address records.
-
- - Hosts that are referenced by backup address records must use the
- port number specified in Assigned Numbers for the service.
-
- - Designers of future protocols for which "secondary servers" is
- not useful (or meaningful) may choose to not use SRV's support
- for secondary servers. Clients for such protocols may use or
- ignore SRV RRs with Priority higher than the RR with the lowest
- Priority for a domain.
-
- Currently there's a practical limit of 512 bytes for DNS replies.
- Until all resolvers can handle larger responses, domain
- administrators are strongly advised to keep their SRV replies below
- 512 bytes.
-
- All round numbers, wrote Dr. Johnson, are false, and these numbers
- are very round: A reply packet has a 30-byte overhead plus the name
- of the service ("_ldap._tcp.example.com" for instance); each SRV RR
- adds 20 bytes plus the name of the target host; each NS RR in the NS
- section is 15 bytes plus the name of the name server host; and
- finally each A RR in the additional data section is 20 bytes or so,
- and there are A's for each SRV and NS RR mentioned in the answer.
- This size estimate is extremely crude, but shouldn't underestimate
- the actual answer size by much. If an answer may be close to the
- limit, using a DNS query tool (e.g. "dig") to look at the actual
- answer is a good idea.
-
-The "Weight" field
-
- Weight, the server selection field, is not quite satisfactory, but
- the actual load on typical servers changes much too quickly to be
- kept around in DNS caches. It seems to the authors that offering
- administrators a way to say "this machine is three times as fast as
- that one" is the best that can practically be done.
-
-
-
-
-Expires December 2001 [Page 5]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- The only way the authors can see of getting a "better" load figure is
- asking a separate server when the client selects a server and
- contacts it. For short-lived services an extra step in the
- connection establishment seems too expensive, and for long-lived
- services, the load figure may well be thrown off a minute after the
- connection is established when someone else starts or finishes a
- heavy job.
-
- Note: There are currently various experiments at providing relative
- network proximity estimation, available bandwidth estimation, and
- similar services. Use of the SRV record with such facilities, and in
- particular the interpretation of the Weight field when these
- facilities are used, is for further study. Weight is only intended
- for static, not dynamic, server selection. Using SRV weight for
- dynamic server selection would require assigning unreasonably short
- TTLs to the SRV RRs, which would limit the usefulness of the DNS
- caching mechanism, thus increasing overall network load and
- decreasing overall reliability. Server selection via SRV is only
- intended to express static information such as "this server has a
- faster CPU than that one" or "this server has a much better network
- connection than that one".
-
-The Port number
-
- Currently, the translation from service name to port number happens
- at the client, often using a file such as /etc/services.
-
- Moving this information to the DNS makes it less necessary to update
- these files on every single computer of the net every time a new
- service is added, and makes it possible to move standard services out
- of the "root-only" port range on unix.
-
-Usage rules
-
- A SRV-cognizant client SHOULD use this procedure to locate a list of
- servers and connect to the preferred one:
-
- Do a lookup for QNAME=_service._protocol.domain, QCLASS=IN,
- QTYPE=SRV.
-
- If the reply is NOERROR, ANCOUNT>0 and there is at least one
- SRV RR which specifies the requested Service and Protocol in
- the reply:
-
- If there is precisely one SRV RR, and its Target is "."
- (the root domain), abort and do not attempt lookup for
- QNAME=domain, QCLASS=IN, QTYPE=A.
-
-
-
-
-
-
-Expires December 2001 [Page 6]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- Else, for all such RR's, build a list of (Priority, Weight,
- Target) tuples
-
- Sort the list by priority (lowest number first)
-
- Create a new empty list
-
- For each distinct priority level
- While there are still elements left at this priority
- level
-
- Select an element as specified above, in the
- description of Weight in "The format of the SRV
- RR" Section, and move it to the tail of the new
- list
-
- For each element in the new list
-
- query the DNS for address records for the Target or
- use any such records found in the Additional Data
- section of the earlier SRV response.
-
- for each address record found, try to connect to the
- (protocol, address, service).
-
- else
-
- Do a lookup for QNAME=domain, QCLASS=IN, QTYPE=A
-
- for each address record found, try to connect to the
- (protocol, address, service)
-
-Notes:
-
- - Port numbers SHOULD NOT be used in place of the symbolic service
- or protocol names (for the same reason why variant names cannot
- be allowed: Applications would have to do two or more lookups).
-
- - If a truncated response comes back from an SRV query, the rules
- described in [RFC 2181] shall apply.
-
- - A client MUST parse all of the RR's in the reply.
-
- - If the Additional Data section doesn't contain address records
- for all the SRV RR's and the client may want to connect to the
- target host(s) involved, the client MUST look up the address
- record(s). (This happens quite often when the address record
- has shorter TTL than the SRV or NS RR's.)
-
-
-
-Expires December 2001 [Page 7]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- - Future protocols could be designed to use SRV RR lookups as the
- means by which clients locate their servers.
-
-Fictional example
-
- This example uses fictional service "foobar" as an aid in
- understanding SRV records. If ever service "foobar" is implemented,
- it is not intended that it will necessarily use SRV records. This is
- (part of) the zone file for example.com, a still-unused domain:
-
- $ORIGIN example.com.
- @ SOA server.example.com. root.example.com. (
- 1995032001 3600 3600 604800 86400 )
- NS server.example.com.
- NS ns1.ip-provider.net.
- NS ns2.ip-provider.net.
- ; foobar - use old-slow-box or new-fast-box if either is
- ; available, make three quarters of the logins go to
- ; new-fast-box.
- _foobar._tcp SRV 0 1 9 old-slow-box.example.com.
- SRV 0 3 9 new-fast-box.example.com.
- ; if neither old-slow-box or new-fast-box is up, switch to
- ; using the sysdmin's box and the server
- SRV 1 0 9 sysadmins-box.example.com.
- SRV 1 0 9 server.example.com.
- server A 172.30.79.10
- old-slow-box A 172.30.79.11
- sysadmins-box A 172.30.79.12
- new-fast-box A 172.30.79.13
- ; NO other services are supported
- *._tcp SRV 0 0 0 .
- *._udp SRV 0 0 0 .
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires December 2001 [Page 8]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- In this example, a client of the "foobar" service in the
- "example.com." domain needs an SRV lookup of
- "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
- box.example.com." and/or the other hosts named. The size of the SRV
- reply is approximately 365 bytes:
-
- 30 bytes general overhead
- 20 bytes for the query string, "_foobar._tcp.example.com."
- 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
- fast-box", "old-slow-box", "server" and "sysadmins-box" -
- "example.com" in the query section is quoted here and doesn't
- need to be counted again.
- 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
- "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
- quoted and only needs to be counted once.
- 120 bytes for the 6 address records (assuming IPv4 only) mentioned
- by the SRV and NS RR's.
-
-IANA Considerations
-
- The IANA has assigned RR type value 33 to the SRV RR. No other IANA
- services are required by this document.
-
-Changes from RFC 2782
-
- This document obsoletes RFC 2782
- Only editorial clarifications were made to this document. Namely
-
- - it was clarified that "Weight" subsection refers to real "random
- number" rather than integer number;
-
- - it was clarified that the "Name" used in the owner name of the SRV
- record used in "The format of the SRV RR" section is a "Domain"
- name;
-
- - the "QNAME=_service._protocol.target" was replaced by
- "QNAME=_service._protocol.domain" in "Usage rules" section to
- eliminate a possibility of confusion with the Target field of the
- SRV record.
-
- - client's behavior when response to a query contains a single SRV
- RR and its Target is "." is clarified in "Usage rules" section.
-
-
-Security Considerations
-
- The authors believe this RR to not cause any new security problems.
- Some problems become more visible, though.
-
-
-
-
-
-Expires December 2001 [Page 9]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
- - The ability to specify ports on a fine-grained basis obviously
- changes how a router can filter packets. It becomes impossible
- to block internal clients from accessing specific external
- services, slightly harder to block internal users from running
- unauthorized services, and more important for the router
- operations and DNS operations personnel to cooperate.
-
- - There is no way a site can keep its hosts from being referenced
- as servers. This could lead to denial of service.
-
-
- - With SRV, DNS spoofers can supply false port numbers, as well as
- host names and addresses. Because this vulnerability exists
- already, with names and addresses, this is not a new
- vulnerability, merely a slightly extended one, with little
- practical effect.
-
-
-
-References
-
- STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
- 1700, October 1994.
-
- RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- RFC 1035: Mockapetris, P., "Domain names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- RFC 974: Partridge, C., "Mail routing and the domain system", STD
- 14, RFC 974, January 1986.
-
- BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
- Services", BCP 17, RFC 2219, October 1997.
-
- BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
- Services with DNS", Work in Progress.
-
- KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
- Realm Information with DNS", Work in Progress.
-
-
-
-
-Expires December 2001 [Page 10]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
-Acknowledgements
-
- The algorithm used to select from the weighted SRV RRs of equal
- priority is adapted from one supplied by Dan Bernstein.
-
-Authors' Addresses
-
- Arnt Gulbrandsen
- Trolltech AS
- Waldemar Thranes gate 98
- N-0175 Oslo, Norway
-
- Fax: +47 21604800
- Phone: +47 21604801
- EMail: arnt@trolltech.com
-
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063
-
- Phone: +1 650 779 7001
-
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires December 2001 [Page 11]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (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
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires December 6, 2001 [Page 12]
\ No newline at end of file
+++ /dev/null
-
-INTERNET-DRAFT Andreas Gustafsson
-draft-ietf-dnsext-unknown-rrs-06.txt Nominum Inc.
- June 2003
-
-Updates: RFC 1034, RFC 2163, RFC 2535
-
-
-
- Handling of Unknown DNS Resource Record Types
-
-
-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
-
- Extending the Domain Name System with new Resource Record (RR) types
- currently requires changes to name server software. This document
- specifies the changes necessary to allow future DNS implementations
- to handle new RR types transparently.
-
-1. Introduction
-
- The DNS is designed to be extensible to support new services through
- the introduction of new resource record (RR) types. In practice,
- deploying a new RR type currently requires changes to the name server
- software not only at the authoritative DNS server that is providing
- the new information and the client making use of it, but also at all
- slave servers for the zone containing it, and in some cases also at
- caching name servers and forwarders used by the client.
-
-
-
-Expires December 2003 [Page 1]
-\f
-draft-ietf-dnsext-unknown-rrs-06.txt June 2003
-
-
- Because the deployment of new server software is slow and expensive,
- the potential of the DNS in supporting new services has never been
- fully realized. This memo proposes changes to name servers and to
- procedures for defining new RR types aimed at simplifying the future
- deployment of new RR types.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-2. Definition
-
- An "RR of unknown type" is an RR whose RDATA format is not known to
- the DNS implementation at hand, such that it cannot be converted to a
- type-specific text format, compressed, or otherwise handled in a
- type-specific way, and whose type is not an assigned QTYPE or Meta-
- TYPE in RFC2929 section 3.1 nor within the range reserved in that
- section for assignment only to QTYPEs and Meta-TYPEs.
-
- In the case of a type whose RDATA format is class specific, an RR is
- considered to be of unknown type when the RDATA format for that
- combination of type and class is not known.
-
-3. Transparency
-
- To enable new RR types to be deployed without server changes, name
- servers and resolvers MUST handle RRs of unknown type transparently.
- That is, they must treat the RDATA section of such RRs as
- unstructured binary data, storing and transmitting it without change
- [RFC1123].
-
- To ensure the correct operation of equality comparison (section 6)
- and of the DNSSEC canonical form (section 7) when an RR type is known
- to some but not all of the servers involved, servers MUST also
- exactly preserve the RDATA of RRs of known type, except for changes
- due to compression or decompression where allowed by section 4 of
- this memo. In particular, the character case of domain names that
- are not subject to compression MUST be preserved.
-
-4. Domain Name Compression
-
- RRs containing compression pointers in the RDATA part cannot be
- treated transparently, as the compression pointers are only
- meaningful within the context of a DNS message. Transparently
- copying the RDATA into a new DNS message would cause the compression
- pointers to point at the corresponding location in the new message,
- which now contains unrelated data. This would cause the compressed
- name to be corrupted.
-
-
-
-Expires December 2003 [Page 2]
-\f
-draft-ietf-dnsext-unknown-rrs-06.txt June 2003
-
-
- To avoid such corruption, servers MUST NOT compress domain names
- embedded in the RDATA of types that are class-specific or not well-
- known. This requirement was stated in RFC1123 without defining the
- term "well-known"; it is hereby specified that only the RR types
- defined in RFC1035 are to be considered "well-known".
-
- The specifications of a few existing RR types have explicitly allowed
- compression contrary to this specification: RFC2163 specified that
- compression applies to the PX RR, and RFC2535 allowed compression in
- SIG RRs and NXT RRs records. Since this specification disallows
- compression in these cases, it is an update to RFC2163 (section 4)
- and RFC2535 (sections 4.1.7 and 5.2).
-
- Receiving servers MUST decompress domain names in RRs of well-known
- type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
- NXT, NAPTR, and SRV (although the current specification of the SRV RR
- in RFC2782 prohibits compression, RFC2052 mandated it, and some
- servers following that earlier specification are still in use).
-
- Future specifications for new RR types that contain domain names
- within their RDATA MUST NOT allow the use of name compression for
- those names, and SHOULD explicitly state that the embedded domain
- names MUST NOT be compressed.
-
- As noted in RFC1123, the owner name of an RR is always eligible for
- compression.
-
-5. Text Representation
-
- In the "type" field of a master file line, an unknown RR type is
- represented by the word "TYPE" immediately followed by the decimal RR
- type number, with no intervening whitespace. In the "class" field,
- an unknown class is similarly represented as the word "CLASS"
- immediately followed by the decimal class number.
-
- This convention allows types and classes to be distinguished from
- each other and from TTL values, allowing the "[<TTL>] [<class>]
- <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
- RFC1035 to both be unambiguously parsed.
-
- The RDATA section of an RR of unknown type is represented as a
- sequence of white space separated words as follows:
-
- The special token \# (a backslash immediately
- followed by a hash sign), which identifies the
- RDATA as having the generic encoding defined
- herein rather than a traditional type-specific
- encoding.
-
-
-
-Expires December 2003 [Page 3]
-\f
-draft-ietf-dnsext-unknown-rrs-06.txt June 2003
-
-
- An unsigned decimal integer specifying the
- RDATA length in octets.
-
- Zero or more words of hexadecimal data encoding
- the actual RDATA field, each containing an even
- number of hexadecimal digits.
-
- If the RDATA is of zero length, the text representation contains only
- the \# token and the single zero representing the length.
-
- An implementation MAY also choose to represent some RRs of known type
- using the above generic representations for the type, class and/or
- RDATA, which carries the benefit of making the resulting master file
- portable to servers where these types are unknown. Using the generic
- representation for the RDATA of an RR of known type can also be
- useful in the case of an RR type where the text format varies
- depending on a version, protocol, or similar field (or several)
- embedded in the RDATA when such a field has a value for which no text
- format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
- 0.
-
- Even though an RR of known type represented in the \# format is
- effectively treated as an unknown type for the purpose of parsing the
- RDATA text representation, all further processing by the server MUST
- treat it as a known type and take into account any applicable type-
- specific rules regarding compression, canonicalization, etc.
-
- The following are examples of RRs represented in this manner,
- illustrating various combinations of generic and type-specific
- encodings for the different fields of the master file format:
-
- a.example. CLASS32 TYPE731 \# 6 abcd (
- ef 01 23 45 )
- b.example. HS TYPE62347 \# 0
- e.example. IN A \# 4 0A000001
- e.example. CLASS1 TYPE1 10.0.0.2
-
-6. Equality Comparison
-
- Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
- to be compared for equality. Two RRs of the same unknown type are
- considered equal when their RDATA is bitwise equal. To ensure that
- the outcome of the comparison is identical whether the RR is known to
- the server or not, specifications for new RR types MUST NOT specify
- type-specific comparison rules.
-
- This implies that embedded domain names, being included in the
- overall bitwise comparison, are compared in a case-sensitive manner.
-
-
-
-Expires December 2003 [Page 4]
-\f
-draft-ietf-dnsext-unknown-rrs-06.txt June 2003
-
-
- As a result, when a new RR type contains one or more embedded domain
- names, it is possible to have multiple RRs owned by the same name
- that differ only in the character case of the embedded domain
- name(s). This is similar to the existing possibility of multiple TXT
- records differing only in character case, and not expected to cause
- any problems in practice.
-
-7. DNSSEC Canonical Form and Ordering
-
- DNSSEC defines a canonical form and ordering for RRs [RFC2535,
- section 8.1]. In that canonical form, domain names embedded in the
- RDATA are converted to lower case.
-
- The downcasing is necessary to ensure the correctness of DNSSEC
- signatures when case distinctions in domain names are lost due to
- compression, but since it requires knowledge of the presence and
- position of embedded domain names, it cannot be applied to unknown
- types.
-
- To ensure continued consistency of the canonical form of RR types
- where compression is allowed, and for continued interoperability with
- existing implementations that already implement the RFC2535 canonical
- form and apply it to their known RR types, the canonical form remains
- unchanged for all RR types whose whose initial publication as an RFC
- was prior to the initial publication of this specification as an RFC
- (RFC TBD).
-
- As a courtesy to implementors, it is hereby noted that the complete
- set of such previously published RR types that contain embedded
- domain names, and whose DNSSEC canonical form therefore involves
- downcasing according to the DNS rules for character comparisons,
- consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
- HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
- DNAME, and A6.
-
- This document specifies that for all other RR types (whether treated
- as unknown types or treated as known types according to an RR type
- definition RFC more recent than than RFC TBD), the canonical form is
- such that no downcasing of embedded domain names takes place, and
- otherwise identical to the canonical form specified in RFC2535
- section 8.1.
-
- Note that the owner name is always set to lower case according to the
- DNS rules for character comparisons, regardless of the RR type.
-
- The DNSSEC canonical RR ordering is as specified in RFC2535 section
- 8.3, where the octet sequence is the canonical form as revised by
- this specification.
-
-
-
-Expires December 2003 [Page 5]
-\f
-draft-ietf-dnsext-unknown-rrs-06.txt June 2003
-
-
-8. Additional Section Processing
-
- Unknown RR types cause no additional section processing. Future RR
- type specifications MAY specify type-specific additional section
- processing rules, but any such processing MUST be optional as it can
- only be performed by servers for which the RR type in case is known.
-
-9. IANA Considerations
-
- This document does not require any IANA actions.
-
-10. Security Considerations
-
- This specification is not believed to cause any new security
- problems, nor to solve any existing ones.
-
-Normative References
-
- [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
- November 1987.
-
- [RFC1035] - Domain Names - Implementation and Specifications, P.
- Mockapetris, November 1987.
-
- [RFC1123] - Requirements for Internet Hosts -- Application and
- Support, R. Braden, Editor, October 1989.
-
- [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
- S. Bradner, BCP 14, March 1997.
-
- [RFC2535] - Domain Name System Security Extensions. D. Eastlake,
- March 1999.
-
- [RFC2613] - Using the Internet DNS to Distribute MIXER Conformant
- Global Address Mapping (MCGAM), C. Allocchio, January 1998.
-
- [RFC2929] - Domain Name System (DNS) IANA Considerations, D.
- Eastlake, E. Brunner-Williams, B. Manning, September 2000.
-
-Non-normative References
-
- [RFC1876] - A Means for Expressing Location Information in the Domain
- Name System, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, January
- 1996.
-
- [RFC2052] - A DNS RR for specifying the location of services (DNS
- SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782.
-
-
-
-
-Expires December 2003 [Page 6]
-\f
-draft-ietf-dnsext-unknown-rrs-06.txt June 2003
-
-
- [RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE),
- P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997.
-
- [RFC2782] - A DNS RR for specifying the location of services (DNS
- SRV), A. Gulbrandsen, P. Vixie, L. Esibov, February 2000.
-
-Author's Address
-
- Andreas Gustafsson
- Nominum Inc.
- 2385 Bay Rd
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6004
-
- Email: gson@nominum.com
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001 - 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 implmentation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-Intellectual Property Statement
-
-
-
-Expires December 2003 [Page 7]
-\f
-draft-ietf-dnsext-unknown-rrs-06.txt June 2003
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires December 2003 [Page 8]
+++ /dev/null
-DNSEXT WG Edward Lewis
-INTERNET DRAFT NAI Labs
-Category:I-D September 19, 2000
-
- DNS Security Extension Clarification on Zone Status
- <draft-ietf-dnsext-zone-status-03.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.
-
-Comments should be sent to the authors or the DNSEXT WG mailing list
-namedroppers@ops.ietf.org.
-
-This draft expires on March, 19, 2001.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (1999, 2000). All rights reserved.
-
-Abstract
-
-The definition of a secured zone is presented, clarifying and updating
-sections of RFC 2535. RFC 2535 defines a zone to be secured based on a
-per algorithm basis, e.g., a zone can be secured with RSA keys, and
-not secured with DSA keys. This document changes this to define a
-zone to be secured or not secured regardless of the key algorithm used
-(or not used). To further simplify the determination of a zone's
-status, "experimentally secure" status is deprecated.
-
-1 Introduction
-
-Whether a DNS zone is "secured" or not is a question asked in at least
-four contexts. A zone administrator asks the question when
-configuring a zone to use DNSSEC. A dynamic update server asks the
-question when an update request arrives, which may require DNSSEC
-processing. A delegating zone asks the question of a child zone when
-the parent enters data indicating the status the child. A resolver
-asks the question upon receipt of data belonging to the zone.
-
-
-Expires March 19, 2001 [Page 1]
-\fInternet Draft September 19, 2000
-
-1.1 When a Zone's Status is Important
-
-A zone administrator needs to be able to determine what steps are
-needed to make the zone as secure as it can be. Realizing that due to
-the distributed nature of DNS and its administration, any single zone
-is at the mercy of other zones when it comes to the appearance of
-security. This document will define what makes a zone qualify as
-secure.
-
-A name server performing dynamic updates needs to know whether a zone
-being updated is to have signatures added to the updated data, NXT
-records applied, and other required processing. In this case, it is
-conceivable that the name server is configured with the knowledge, but
-being able to determine the status of a zone by examining the data is
-a desirable alternative to configuration parameters.
-
-A delegating zone is required to indicate whether a child zone is
-secured. The reason for this requirement lies in the way in which a
-resolver makes its own determination about a zone (next paragraph). To
-shorten a long story, a parent needs to know whether a child should be
-considered secured. This is a two part question. Under what
-circumstances does a parent consider a child zone to be secure, and
-how does a parent know if the child conforms?
-
-A resolver needs to know if a zone is secured when the resolver is
-processing data from the zone. Ultimately, a resolver needs to know
-whether or not to expect a usable signature covering the data. How
-this determination is done is out of the scope of this document,
-except that, in some cases, the resolver will need to contact the
-parent of the zone to see if the parent states that the child is
-secured.
-
-1.2 Islands of Security
-
-The goal of DNSSEC is to have each zone secured, from the root zone
-and the top-level domains down the hierarchy to the leaf zones.
-Transitioning from an unsecured DNS, as we have now, to a fully
-secured - or "as much as will be secured" - tree will take some time.
-During this time, DNSSEC will be applied in various locations in the
-tree, not necessarily "top down."
-
-For example, at a particular instant, the root zone and the "test."
-TLD might be secured, but region1.test. might not be. (For reference,
-let's assume that region2.test. is secured.) However,
-subarea1.region1.test. may have gone through the process of becoming
-secured, along with its delegations. The dilemma here is that
-subarea1 cannot get its zone keys properly signed as its parent zone,
-region1, is not secured.
-
-The colloquial phrase describing the collection of contiguous secured
-zones at or below subarea1.region1.test. is an "island of security."
-The only way in which a DNSSEC resolver will come to trust any data
-from this island is if the resolver is pre-configured with the zone
-key(s) for subarea1.region1.test., i.e., the root of the island of
-
-Expires March 19, 2001 [Page 2]
-\fInternet Draft September 19, 2000
-
-security. Other resolvers (not so configured) will recognize this
-island as unsecured.
-
-An island of security begins with one zone whose public key is
-pre-configured in resolvers. Within this island are subzones which
-are also secured. The "bottom" of the island is defined by
-delegations to unsecured zones. One island may also be on top of
-another - meaning that there is at least one unsecured zone between
-the bottom of the upper island and the root of the lower secured
-island.
-
-Although both subarea1.region1.test. and region2.test. have both been
-properly brought to a secured state by the administering staff, only
-the latter of the two is actually "globally" secured - in the sense
-that all DNSSEC resolvers can and will verify its data. The former,
-subarea1, will be seen as secured by a subset of those resolvers, just
-those appropriately configured. This document refers to such zones as
-being "locally" secured.
-
-In RFC 2535, there is a provision for "certification authorities,"
-entities that will sign public keys for zones such as subarea1. There
-is another draft, [SIGAUTH], that restricts this activity. Regardless
-of the other draft, resolvers would still need proper configuration to
-be able to use the certification authority to verify the data for the
-subarea1 island.
-
-1.2.1 Determing the closest security root
-
-Given a domain, in order to determine whether it is secure or not, the
-first step is to determine the closest security root. The closest
-security root is the top of an island of security whose name has the
-most matching (in order from the root) right-most labels to the given
-domain.
-
-For example, given a name "sub.domain.testing.signed.exp.test.", and
-given the secure roots "exp.test.", "testing.signed.exp.test." and
-"not-the-same.xy.", the middle one is the closest. The first secure
-root shares 2 labels, the middle 4, and the last 0.
-
-The reason why the closest is desired is to eliminate false senses of
-insecurity becuase of a NULL key. Continuing with the example, the
-reason both "testing..." and "exp.test." are listed as secure root is
-presumably because "signed.exp.test." is unsecured (has a NULL key).
-If we started to descend from "exp.test." to our given domain
-(sub...), we would encounter a NULL key and conclude that sub... was
-unsigned. However, if we descend from "testing..." and find keys
-"domain...." then we can conclude that "sub..." is secured.
-
-Note that this example assumes one-label deep zones, and assumes that
-we do not configure overlapping islands of security. To be clear, the
-definition given should exclude "short.xy.test." from being a closest
-security root for "short.xy." even though 2 labels match.
-
-Overlapping islands of security introduce no conceptually interesting
-
-Expires March 19, 2001 [Page 3]
-\fInternet Draft September 19, 2000
-
-ideas and do not impact the protocol in anyway. However, protocol
-implementers are advised to make sure their code is not thrown for a
-loop by overlaps. Overlaps are sure to be configuration problems as
-islands of security grow to encompass larger regions of the name
-space.
-
-1.3 Parent Statement of Child Security
-
-In 1.1 of this document, there is the comment "the parent states that
-the child is secured." This has caused quite a bit of confusion.
-
-The need to have the parent "state" the status of a child is derived
-from the following observation. If you are looking to see if an
-answer is secured, that it comes from an "island of security" and is
-properly signed, you must begin at the (appropriate) root of the
-island of security.
-
-To find the answer you are inspecting, you may have to descend through
-zones within the island of security. Beginning with the trusted root
-of the island, you descend into the next zone down. As you trust the
-upper zone, you need to get data from it about the next zone down,
-otherwise there is a vulnerable point in which a zone can be hijacked.
-When or if you reach a point of traversing from a secured zone to an
-unsecured zone, you have left the island of security and should
-conclude that the answer is unsecured.
-
-However, in RFC 2535, section 2.3.4, these words seem to conflict with
-the need to have the parent "state" something about a child:
-
- There MUST be a zone KEY RR, signed by its superzone, for every
- subzone if the superzone is secure. This will normally appear in
- the subzone and may also be included in the superzone. But, in
- the case of an unsecured subzone which can not or will not be
- modified to add any security RRs, a KEY declaring the subzone
- to be unsecured MUST appear with the superzone signature in the
- superzone, if the superzone is secure.
-
-The confusion here is that in RFC 2535, a secured parent states that a
-child is secured by SAYING NOTHING ("may also be" as opposed to "MUST
-also be"). This is counter intuitive, the fact that an absence of
-data means something is "secured." This notion, while acceptable in a
-theoretic setting has met with some discomfort in an operation
-setting. However, the use of "silence" to state something does indeed
-work in this case, so there hasn't been sufficient need demonstrated
-to change the definition.
-
-1.4 Impact on RFC 2535
-
-This document updates sections of RFC 2535. The definition of a
-secured zone is an update to section 3.4 of the RFC. Section 3.4 is
-updated to eliminate the definition of experimental keys and
-illustrate a way to still achieve the functionality they were designed
-to provide. Section 3.1.3 is updated by the specifying the value of
-the protocol octet in a zone key.
-
-Expires March 19, 2001 [Page 4]
-\fInternet Draft September 19, 2000
-
-1.5 "MUST" and other key words
-
-The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-in this document are to be interpreted as described in [RFC 2119].
-Currently, only "MUST" is used in this document.
-
-2 Status of a Zone
-
-In this section, rules governing a zone's DNSSEC status are presented.
-There are three levels of security defined: global, local, and
-unsecured. A zone is globally secure when it complies with the
-strictest set of DNSSEC processing rules. A zone is locally secured
-when it is configured in such a way that only resolvers that are
-appropriately configured see the zone as secured. All other zones are
-unsecured.
-
-Note: there currently is no document completely defining DNSSEC
-verification rules. For the purposes of this document, the strictest
-rules are assumed to state that the verification chain of zone keys
-parallels the delegation tree up to the root zone. (See 2.b below.)
-This is not intended to disallow alternate verification paths, just to
-establish a baseline definition.
-
-To avoid repetition in the rules below, the following terms are
-defined.
-
-2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01
-for name type (indicating a zone key) and either value 00 or value 01
-for key type (indicating a key permitted to authenticate data). (See
-RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value
-of DNSSEC (3) or ALL (255).
-
-The definition updates RFC 2535's definition of a zone key. The
-requirement that the protocol field be either DNSSEC or ALL is a new
-requirement, a change to section 3.1.3.)
-
-2.b On-tree Validation - The authorization model in which only the
-parent zone is recognized to supply a DNSSEC-meaningful signature that
-is used by a resolver to build a chain of trust from the child's keys
-to a recognized root of security. The term "on-tree" refers to
-following the DNS domain hierarchy (upwards) to reach a trusted key,
-presumably the root key if no other key is available. The term
-"validation" refers to the digital signature by the parent to prove
-the integrity, authentication and authorization of the child' key to
-sign the child's zone data.
-
-2.c Off-tree Validation - Any authorization model that permits domain
-names other than the parent's to provide a signature over a child's
-zone keys that will enable a resolver to trust the keys.
-
-2.1 Globally Secured
-
-A globally secured zone, in a nutshell, is a zone that uses only
-mandatory to implement algorithms (RFC 2535, section 3.2) and relies
-
-Expires March 19, 2001 [Page 5]
-\fInternet Draft September 19, 2000
-
-on a key certification chain that parallels the delegation tree
-(on-tree validation). Globally secured zones are defined by the
-following rules.
-
-2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least
-one zone signing KEY RR (2.a) of a mandatory to implement algorithm in
-the set.
-
-2.1.b. The zone's apex KEY RR set MUST be signed by a private key
-belonging to the parent zone. The private key's public companion MUST
-be a zone signing KEY RR (2.a) of a mandatory to implement algorithm
-and owned by the parent's apex.
-
-If a zone cannot get a conforming signature from the parent zone, the
-child zone cannot be considered globally secured. The only exception
-to this is the root zone, for which there is no parent zone.
-
-2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies
-RFC 2535, section 2.3.2.) Note: there is some operational discomfort
-with the current NXT record. This requirement is open to modification
-when two things happen. First, an alternate mechanism to the NXT is
-defined and second, a means by which a zone can indicate that it is
-using an alternate method.
-
-2.1.d. Each RR set that qualifies for zone membership MUST be signed
-by a key that is in the apex's KEY RR set and is a zone signing KEY RR
-(2.a) of a mandatory to implement algorithm. (Updates 2535, section
-2.3.1.)
-
-Mentioned earlier, the root zone is a special case. The root zone
-will be considered to be globally secured provided that if conforms to
-the rules for locally secured, with the exception that rule 2.1.a. be
-also met (mandatory to implement requirement).
-
-2.2 Locally Secured
-
-The term "locally" stems from the likely hood that the only resolvers
-to be configured for a particular zone will be resolvers "local" to an
-organization.
-
-A locally secured zone is a zone that complies with rules like those
-for a globally secured zone with the following exceptions. The
-signing keys may be of an algorithm that is not mandatory to implement
-and/or the verification of the zone keys in use may rely on a
-verification chain that is not parallel to the delegation tree
-(off-tree validation).
-
-2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least
-one zone signing KEY RR (2.a) in the set.
-
-2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
-one of the following two subclauses MUST hold true.
-
-
-
-Expires March 19, 2001 [Page 6]
-\fInternet Draft September 19, 2000
-
-2.2.b.1 The private key's public companion MUST be pre-configured in
-all the resolvers of interest.
-
-2.2.b.2 The private key's public component MUST be a zone signing KEY
-RR (2.a) authorized to provide validation of the zone's apex KEY RR
-set, as recognized by resolvers of interest.
-
-The previous sentence is trying to convey the notion of using a
-trusted third party to provide validation of keys. If the domain name
-owning the validating key is not the parent zone, the domain name must
-represent someone the resolver trusts to provide validation.
-
-2.2.c. NXT records MUST be deployed throughout the zone. Note: see
-the discussion following 2.1.c.
-
-2.2.d. Each RR set that qualifies for zone membership MUST be signed
-by a key that is in the apex's KEY RR set and is a zone signing KEY RR
-(2.a). (Updates 2535, section 2.3.1.)
-
-2.3 Unsecured
-
-All other zones qualify as unsecured. This includes zones that are
-designed to be experimentally secure, as defined in a later section on
-that topic.
-
-2.4 Wrap up
-
-The designation of globally secured, locally secured, and unsecured
-are merely labels to apply to zones, based on their contents.
-Resolvers, when determining whether a signature is expected or not,
-will only see a zone as secured or unsecured.
-
-Resolvers that follow the most restrictive DNSSEC verification rules
-will only see globally secured zones as secured, and all others as
-unsecured, including zones which are locally secured. Resolvers that
-are not as restrictive, such as those that implement algorithms in
-addition to the mandatory to implement algorithms, will see some
-locally secured zones as secured.
-
-The intent of the labels "global" and "local" is to identify the
-specific attributes of a zone. The words are chosen to assist in the
-writing of a document recommending the actions a zone administrator
-take in making use of the DNS security extensions. The words are
-explicitly not intended to convey a state of compliance with DNS
-security standards.
-
-3 Experimental Status
-
-The purpose of an experimentally secured zone is to facilitate the
-migration from an unsecured zone to a secured zone. This distinction
-is dropped.
-
-The objective of facilitating the migration can be achieved without a
-special designation of an experimentally secure status. Experimentally
-
-Expires March 19, 2001 [Page 7]
-\fInternet Draft September 19, 2000
-
-secured is a special case of globally secured. A zone administrator
-can achieve this by publishing a zone with signatures and configuring
-a set of test resolvers with the corresponding public keys. Even if
-the public key is published in a KEY RR, as long as there is no parent
-signature, the resolvers will need some pre-configuration to know to
-process the signatures. This allows a zone to be secured with in the
-sphere of the experiment, yet still be registered as unsecured in the
-general Internet.
-
-4 IANA/ICANN Considerations
-
-This document does not request any action from an assigned number
-authority nor recommends any actions.
-
-5 Security Considerations
-
-Without a means to enforce compliance with specified protocols or
-recommended actions, declaring a DNS zone to be "completely" secured
-is impossible. Even if, assuming an omnipotent view of DNS, one can
-declare a zone to be properly configured for security, and all of the
-zones up to the root too, a misbehaving resolver could be duped into
-believing bad data. If a zone and resolver comply, a non-compliant or
-subverted parent could interrupt operations. The best that can be
-hoped for is that all parties are prepared to be judged secure and
-that security incidents can be traced to the cause in short order.
-
-6 Acknowledgements
-
-The need to refine the definition of a secured zone has become
-apparent through the efforts of the participants at two DNSSEC
-workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a
-DARPA-funded research network), and other workshops. Further
-discussions leading to the document include Olafur Gudmundsson, Russ
-Mundy, Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen
-and others have contributed significant input via the namedroppers
-mailing list.
-
-7 References
-
-[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities,"
-RFC 1034, November 1987.
-
-[RFC1035] P. Mockapetris, "Domain Names - Implementation and
-Specification," RFC 1034, November 1987.
-
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels," RFC 2119, March 1997
-
-[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
-Updates in the Domain Name System," RFC 2136, April 1997.
-
-[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
-2535, March 1999.
-
-
-Expires March 19, 2001 [Page 8]
-\fInternet Draft September 19, 2000
-
-[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
-Secure Domain Name System (DNS) Dynamic Update," version 00, February
-2000.
-
-[SIGAUTH] B. Wellington, draft-ietf-dnsext-signing-auth-01.txt
-
-10 Author Information
-
-Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443
-259 2352 <lewis@tislabs.com>
-
-11 Full Copyright Statement
-
-Copyright (C) The Internet Society (1999, 2000). 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."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires March 19, 2001 [Page 9]
-
-
+++ /dev/null
-Internet Draft Philip Hazel
-draft-ietf-dnsop-dontpublish-unreachable-03.txt University of Cambridge
-Valid for six months February 2002
-Category: Best Current Practice
-
-
-
-
- IP Addresses that should never appear in the public DNS
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-
-
-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 specifies an Internet Best Current Practice for the
- Internet Community. It has two themes. Firstly, it reinforces the
- prohibition in [RFC 1918] about the appearance of private IP
- addresses in publicly visible DNS records, and extends the
- discussion to include IPv6 addresses.
-
- Secondly, the document discusses the problems that can be caused
- by the appearance of public addresses, or indirect references to
- them, when the service implied by the address or reference is
- inaccessible from the public Internet.
-
- Specifying a blanket prohibition in the second case is difficult
- because inaccessibility may arise from many causes, some possibly
- legitimate. Instead, the document points out some of the problems
- that can arise, and suggests that other means of achieving the
- desired effects should be used wherever possible.
-
-
-1. Introduction
-
- The increasing use of firewalls, NAT boxes, and similar technology
- has resulted in the fragmentation of the Internet into regions whose
- boundaries do not allow general connectivity. There are two primary
- reasons for this:
-
- (1) The perceived shortage of IPv4 addresses has caused increasing
- use of private IPv4 network addresses such as 10.0.0.0/8 on LANs. A
- number of such private address ranges are designated in [RFC 1918],
- and others may be also assigned by IANA.
-
-[Note: For example, there's 169.254/16, which is mentioned in
-draft-ietf-zeroconf-ipv4-linklocal-04.txt, but since that's still a
-draft, I can't cite it.]
-
- IPv6 addresses are not in short supply, but the IPv6 architecture
- uses a scoped address model, in which non-global addresses have
- limited reachability and domains of uniqueness. For instance, site-
- local addresses are reachable only within a particular site.
-
- Hosts using private addresses that wish to communicate with the
- public Internet must do so via an address translation mechanism such
- as a NAT box. This allows a host with a private address to send
- packets to public Internet hosts, and to receive replies. However,
- unsolicited incoming packets cannot reach these hosts from outside
- their own private network.
-
- (2) Increasing security concerns have caused many sites to install
- firewalls or to implement restrictions in their boundary routers in
- order to lock out certain kinds of connection to their hosts, even
- when the hosts are using public Internet addresses, though in many
- cases firewalls also provide NAT functionality.
-
- Thus, there are two classes of host which some or all types of
- unexpected incoming packet from the public Internet cannot reach:
- those using truly private IPv4 or IPv6 addresses, and those using
- public addresses where access is blocked.
-
- A number of instances have been observed where IP addresses that are
- never accessible from the public Internet have nevertheless been
- inserted into resource records in the public DNS. This document seeks
- to prohibit such behaviour in the case of truly private addresses,
- and to discourage it in the case of public, but unreachable,
- addresses.
-
- Although this document is specifically concerned with the contents of
- the public DNS, the principle of not publishing private IP addresses
- is applicable to any other form of general publication.
-
- The 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].
-
- The phrase "address record" means an A record or an AAAA record, or
- any other kind of name-to-address record that may come into use.
-
-
-2. Private network addresses
-
- Examples of [RFC 1918] private host addresses are 10.0.0.1 and
- 172.16.42.53. In the case of IPv6, all link-local and site-local
- addresses are private.
-
- Packets cannot be routed to such addresses from the public Internet.
- [RFC 1918] explains this in section 3, from where this paragraph is
- taken:
-
- Because private addresses have no global meaning, routing
- information about private networks shall not be propagated on
- inter-enterprise links, and packets with private source or
- destination addresses should not be forwarded across such links.
- Routers in networks not using private address space, especially
- those of Internet service providers, are expected to be
- configured to reject (filter out) routing information about
- private networks.
-
- Because the same private addresses are in use in many different
- organizations, they are ambiguous. The appearance of private
- addresses in the DNS could therefore lead to unpredictable and
- unwanted behaviour. Consider this set of entries:
-
- @ IN MX 10 smtp
- smtp IN A 10.1.2.3
- smtp IN A 131.111.10.206
-
- The MX record resolves to two IP addresses, one of which is private
- and one of which is public. Zones set up in this way have been seen,
- and some administrators apparently believe this is useful, because
- it allows mail on their local network to be delivered straight to
- the internal server (the one with address 10.1.2.3). However, this
- approach breaks down when a host on a foreign network that is also
- using the address 10.1.2.3 attempts to send mail to the domain.
-
- In section 5 of [RFC 1918] there is a prohibition of the appearance
- of private addresses in publicly visible DNS records. It says:
-
- If an enterprise uses the private address space, or a mix of
- private and public address spaces, then DNS clients outside of
- the enterprise should not see addresses in the private address
- space used by the enterprise, since these addresses would be
- ambiguous.
-
- The wording "should not" is not a very strong prohibition,
- considering the interworking problems that ignoring it can cause.
- Therefore, this document makes a stronger statement:
-
- Public DNS zones MUST NOT contain [RFC 1918] addresses, IPv6 link-
- local or site-local addresses, or any other addresses designated
- by IANA as private, in any resource records where the context makes
- them appear to be globally-meaningful addresses.
-
-
-3. Public network addresses that are inacessible
-
- The situation with public network addresses is more complicated
- because the Internet cannot in general be cleanly divided into
- "public" and "private" parts in this case. Examples of situations
- where the division is fuzzy are:
-
- (1) A host with a public address that is behind a firewall may be
- accessible for SSH sessions, but not for SMTP sessions. That is,
- the blocking may apply only to certain ports.
-
- (2) A host with a public address may make certain services available
- only to specific client hosts, for example, those in partner
- enterprises, or those in a specific geographic area.
-
- (3) A host might respond to incoming packets only if the client host
- is using IPsec.
-
- When a host is providing any service at all over the public Internet,
- a publicly visible address record is of course required to give
- access to that host.
-
- However, for some protocols and services, additional DNS records
- are defined that reference hosts' address records. These are the NS
- record for name servers, the MX record for SMTP, and the SRV record
- for other services. The existence of such indirect records advertises
- the availability of the relevant service.
-
- If these services are always inaccessible over the public Internet,
- it is bad practice to include the NS, MX or SRV records in public DNS
- zones, for the following reason:
-
- A host that tries to connect to an unreachable address (or port)
- may not receive an immediate rejection; in many cases the connection
- will fail only after a timeout expires. The wasted effort ties up
- resources on the calling host and the network, possibly for some
- considerable time (SMTP timeouts, for example, are of the order of
- minutes). It may also cause a gratuitous slowing down of the
- application.
-
- Furthermore, in the case of dial-up connections, ISDN, or other kinds
- of usage-based charged network connection, the wasted network
- resources may cost real money.
-
- Public DNS zones SHOULD NOT contain NS, MX or SRV records that point
- to hosts for which the relevant services are never accessible over the
- public Internet. In other words, if there is no host that is able to
- make use of the service using the public Internet, the service SHOULD
- NOT be publicly advertised.
-
-
-4. Other kinds of IPv6 address
-
-4.1 Anycast addresses
-
- Anycast addresses should be treated as global addresses with limited
- reachability.
-
-4.2 Multicast addresses
-
- Scoped multicast addresses (multicast addresses with a 4 bit scope
- value less than 0x0e) MUST NOT be put into public DNS zones. Globally-
- scoped multicast addresses MAY be put into public DNS zones.
-
-4.3 IPv4-mapped addresses
-
- IPv4-mapped addresses MUST NOT be put into public DNS zones, because
- their use is limited to an internal representation of IPv4 peers within
- the AF_INET6 socket API [RFC 2553].
-
-4.4 IPv4-compatible addresses
-
- IPv4-compatible addresses MUST NOT be put into public DNS zones.
- Although there might be a case for doing so in order to indicate
- that the node is willing to accept auto-tunnelled packets [RFC 2893],
- it is not clear that this transition mechanism will be widely used.
- It is therefore preferable to keep the DNS operationally "clean" by
- not allowing them.
-
-
-5. Loopback addresses
-
- The loopback addresses (127.0.0.1 for IPv4 and ::1 for IPv6) are
- another form of private address. There has been a practice of including
- them in DNS zones for two entirely different reasons.
-
-5.1 The name "localhost"
-
- Some hostmasters include records of this type in their zones:
-
- localhost.some.domain.example. A 127.0.0.1
-
- The reason for doing this is so that other hosts in the domain
- that use the DNS for all their name resolution can make use of the
- unqualified name "localhost". This works because DNS resolvers
- normally add the local enclosing domain to unqualified names.
-
- DNS zones MAY make use of this technique for the name "localhost"
- only, if it is required in their environment, but SHOULD avoid it
- if possible. See section 6.1 below for an alternative technique.
-
-5.2 DNS "black lists"
-
- There is an increasingly popular practice of creating "black
- lists" of misbehaving hosts (for example, open mail relays) in
- the DNS. The first of these was the "Realtime Blackhole List"
- (RBL). Such lists make use of address values in the 127.0.0.0/8
- network in DNS address records to give information about listed
- hosts (which are looked up via their inverted IP addresses).
-
- Such records are in specific "black list" domains, and are well
- understood not to be invitations to attempt connections to the
- addresses they publish. In other words, the values that appear
- in these records do not appear in a context where they are
- interpreted as IP addresses.
-
- DNS zones MAY continue to make use of this technique.
-
-5.3 Other uses of loopback networks
-
- Apart from the exceptions mentioned in 5.1 and 5.2 above, the
- loopback addresses MUST NOT appear in address records in the public
- DNS, unless it is clear from the context that the value is not to be
- interpreted as an IP address.
-
-5.4 References to loopback addresses
-
- When address records that contain loopback addresses do exist,
- DNS zones MUST NOT contain indirect records (NS, MX or SRV) that
- reference them.
-
-
-6. Alternative techniques
-
-6.1 Handling "localhost"
-
- Instead of including "localhost" within every domain for which a name
- server is authoritative, [RFC 1912] recommends setting up "localhost."
- as a top-level domain in each name server. [RFC 2606] reserves the
- name "localhost." for this purpose.
-
-6.2 Splitting DNS zones
-
- A site that is using private addresses may well want to use DNS
- lookups for address resolution on its hosts. The lazy way approach is
- simply to put the data into the public DNS zone, as in the example
- shown in section 2 above. Because this can cause problems for
- external hosts, this MUST NOT be done.
-
- One approach that is commonly taken is to run a so-called "split
- DNS". Two different authoritative servers are created: one containing
- all the zone data is accessible only from within the private network.
- External DNS queries are directed to the second server, which
- contains a filtered version of the zone, without the private
- addresses.
-
-6.3 SMTP servers behind firewalls
-
- The complication of a split DNS is not normally needed if it is only
- SMTP traffic that is being blocked to a public address on a host
- behind a firewall. Setting up MX records like this:
-
- plc.example. MX 5 mail.plc.example.
- MX 10 public.plc.example.
-
- where both hosts have public IP addresses, but the first is blocked
- at the firewall, SHOULD NOT be done. Only the publicly accessible
- host should be used:
-
- plc.example. MX 10 public.plc.example.
-
- If a split DNS is in use, the host public.plc.example can use the
- internal version to route the mail onwards. However, most MTAs have
- configuration facilities to allow for explicit routing of mail, without
- the need to use a DNS lookup.
-
-6.4 Specification of no SMTP service
-
- MX records that point to host names whose address records specify the
- loopback address have been seen in the DNS. This seems to be a
- misguided attempt to specify "no SMTP service for this domain" more
- positively than just refusing connections to the SMTP port. (A refused
- connection is treated as a temporary error, because it might be the
- result of a system rebooting, for example.)
-
- If such a facility is required, it SHOULD instead be done by
- arranging for the hosts in question to return
-
- 554 No SMTP service here
-
- to all SMTP connections.
-
-
-7. Security Considerations
-
- This document is not known to create new security issues in the DNS,
- mail agents, etc. In some sense, it may reduce security exposure by
- insisting that a site's inappropriate internal data not be exposed.
-
-
-8. IANA Considerations
-
- No IANA actions are required by this document.
-
-
-9. Acknowledgements
-
- Randy Bush read an early draft of this document and suggested several
- improvements.
-
- Draft 01 has benefitted from comments made by Daniel Senie, John
- Schnizlein, Robert Elz, Bert Hubert, and Stuart Cheshire.
-
- Draft 02 has benefitted from comments made by David Keegel and Simon
- Josefsson.
-
- Draft 03 has benefitted from comments made by Jun-ichiro itojun
- Hagino, David Terrell, Erik Nordmark, Matt Larson, and Zefram.
-
-
-10. Author's Address
-
- Philip Hazel
- University of Cambridge Computing Service
- New Museums Site, Pembroke Street
- Cambridge CB2 3QH, England
-
- Phone: + 44 1223 334714
- Email: ph10@cam.ac.uk
-
-
-11. References
-
- [RFC 1912] Barr, D. "Common DNS Operational and Configuration
- Errors", RFC 1912, February 1996.
-
- [RFC 1918] Rekhter, Y. et al "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 2553] Gilligan, S. et al "Basic Socket Interface Extensions
- for IPv6", RFC 2553, March 1999.
-
- [RFC 2606] Eastlake, D. and Panitz, A. "Reserved Top Level DNS
- Names", BCP 32, RFC 2606, June 1999.
-
- [RFC 2893] Gilligan, R. and Nordmark, E. "Transition Mechanisms
- for IPv6 Hosts and Routers", RFC 2893, August 2000.
-
-
-12. Changes made during development of this document
-
- This section is provided for the convenients of those tracking the
- document. It will be removed from the final draft.
-
-12.1 Changes made to the -00 version to create -01
-
- . While leaving the MUSTs in for truly private addresses, I've tried
- to be more "educational" about the case of public addresses that are
- inaccessible, and backed down to SHOULD in those cases.
-
- . I've pointed out the lack of a clear-cut public/private boundary,
- and tried to make the case for not advertising unavailable services
- without being so probititive in the wording. This includes using
- "never accessible" instead of "not accessible".
-
- . Changed "hostmaster" to "zone" in a couple of cases.
-
- . Included an example of bad MX practice with an [RFC 1918] address.
-
- . Noted that [RFC 1918] is not the only list of private addresses.
-
- . General tidying of the wording and rearrangement of the material.
-
- . The Post Office changed our postcode!
-
-12.2 Changes made to the -01 version to create -02
-
- . Add NS to MX and SRV as another DNS record that advertises a service
- indirectly.
-
- . Changed the address 1.2.3.4 in an example to a genuine real address
- to make it quite clear what I mean.
-
- . Added "geographic area" as another example of a service restriction.
-
- . Suggested why people might want something other than "connection
- refused" from hosts that don't provide SMTP service.
-
- . Some other very minor rewording.
-
-12.3 Changes made to the -02 version to create -03
-
- . Added more words about IPv6, with detail supplied by Jun-ichiro
- itojun Hagino about specific kinds of IPv6 address.
-
- . Added a references to RFCs 1912 and 2606 for the handling of
- "localhost" by setting it up as a TLD.
-
- . Generalized ideas such as "black hole lists" to talk about the
- context of interpretation of addresses.
-
- . Added a short statement about other (non-DNS) forms of publication.
-
-
-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.
-
- 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
-
-
-
-IETF DNSOPS working group T. Hardie
-Internet draft Nominum, Inc
-Category: Work-in-progress January, 2002
-
-draft-ietf-dnsop-hardie-shared-root-server-07.txt
-
-
- Distributing Authoritative Name Servers via Shared Unicast Addresses
-
-
-
-Status of this memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
-
- 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
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 1999. All Rights Reserved.
-
-Abstract
-
- This memo describes a set of practices intended to enable an
- authoritative name server operator to provide access to a single
- named server in multiple locations. The primary motivation for the
- development and deployment of these practices is to increase the
- distribution of DNS servers to previously under-served areas of the
- network topology and to reduce the latency for DNS query responses
- in those areas. This document presumes a one-to-one mapping between
- named authoritative servers and administrative entities (operators).
- This document contains no guidelines or recommendations for caching
- name servers. The shared unicast system described here is specific
- to IPv4; applicability to IPv6 is an area for further study. It
- should also be noted that the system described here is related to
- that described in [ANYCAST], but it does not require dedicated
- address space, routing changes, or the other elements of a full
- anycast infrastructure which that document describes.
-
-
-1. Architecture
-
-1.1 Server Requirements
-
- Operators of authoritative name servers may wish to refer to
- [SECONDARY] and [ROOT] for general guidance on appropriate practice
- for authoritative name servers. In addition to proper configuration
- as a standard authoritative name server, each of the hosts
- participating in a shared-unicast system should be configured with
- two network interfaces. These interfaces may be either two physical
- interfaces or one physical interface mapped to two logical
- interfaces. One of the network interfaces should use the IPv4
- shared unicast address associated with the authoritative name
- server. The other interface, referred to as the administrative
- interface below, should use a distinct IPv4 address specific to that
- host. The host should respond to DNS queries only on the
- shared-unicast interface. In order to provide the most consistent
- set of responses from the mesh of anycast hosts, it is good practice
- to limit responses on that interface to zones for which the host is
- authoritative.
-
-
-1.2 Zone file delivery
-
- In order to minimize the risk of man-in-the-middle attacks, zone
- files should be delivered to the administrative interface of the
- servers participating in the mesh. Secure file transfer methods and
- strong authentication should be used for all transfers. If the hosts
- in the mesh make their zones available for zone transfer, the administrative
- interfaces should be used for those transfers as well, in order to avoid
- the problems with potential routing changes for TCP traffic
- noted in section 1.5 below.
-
-1.3 Synchronization
-
- Authoritative name servers may be loosely or tightly synchronized,
- depending on the practices set by the operating organization. As
- noted below in section 3.1.2, lack of synchronization among servers
- using the same shared unicast address could create problems for some
- users of this service. In order to minimize that risk, switch-overs
- from one data set to another data set should be coordinated as much
- as possible. The use of synchronized clocks on the participating
- hosts and set times for switch-overs provides a basic level of
- coordination. A more complete coordination process would involve:
-
- a) receipt of zones at a distribution host
- b) confirmation of the integrity of zones received
- c) distribution of the zones to all of the servers in the
- mesh
- d) confirmation of the integrity of the zones at each server
- e) coordination of the switchover times for the servers in the
- mesh
- f) institution of a failure process to ensure that servers that
- did not receive correct data or could not switchover to the
- new data ceased to respond to incoming queries until the
- problem could be resolved.
-
- Depending on the size of the mesh, the distribution host may also be
- a participant; for authoritative servers, it may also be the host on
- which zones are generated.
-
- This document presumes that the usual DNS failover methods are the
- only ones used to ensure reachability of the data for clients. It
- does not advise that the routes be withdrawn in the case of failure;
- it advises instead the the DNS process shutdown so that servers on
- other addresses are queried. This recommendation reflects a choice
- between performance and operational complexity. While it would be
- possible to have some process withdraw the route for a specific
- server instance when it is not available, there is considerable
- operational complexity involved in ensuring that this occurs
- reliably. Given the existing DNS failover methods, the marginal
- improvement in performance will not be sufficient to justify
- the additional complexity for most uses.
-
-
-1.4 Server Placement
-
- Though the geographic diversity of server placement helps reduce the
- effects of service disruptions due to local problems, it is
- diversity of placement in the network topology which is the driving
- force behind these distribution practices. Server placement should
- emphasize that diversity. Ideally, servers should be placed
- topologically near the points at which the operator exchanges routes
- and traffic with other networks.
-
-1.5 Routing
-
- The organization administering the mesh of servers sharing a unicast
- address must have an autonomous system number and speak BGP to its
- peers. To those peers, the organization announces a route to the
- network containing the shared-unicast address of the name server.
- The organization's border routers must then deliver the traffic
- destined for the name server to the nearest instantiation. Routing
- to the administrative interfaces for the servers can use the normal
- routing methods for the administering organization.
-
- One potential problem with using shared unicast addresses is that
- routers forwarding traffic to them may have more than one available
- route, and those routes may, in fact, reach different instances of
- the shared unicast address. Applications like the DNS, whose
- communication typically consists of independent request-response
- messages each fitting in a single UDP packet presents no problem.
- Other applications, in which multiple packets must reach the same
- endpoint (e.g., TCP) may fail or present unworkable performance
- characteristics in some circumstances. Split-destination failures
- may occur when a router does per-packet (or round-robin) load
- sharing, a topology change occurs that changes the relative metrics
- of two paths to the same anycast destination, etc.
-
- Four things mitigate the severity of this problem. The first is
- that UDP is a fairly high proportion of the query traffic to name
- servers. The second is that the aim of this proposal is to
- diversify topological placement; for most users, this means that the
- coordination of placement will ensure that new instances of a name
- server will be at a significantly different cost metric from
- existing instances. Some set of users may end up in the middle, but
- that should be relatively rare. The third is that per packet load
- sharing is only one of the possible load sharing mechanisms, and
- other mechanisms are increasing in popularity.
-
- Lastly, in the case where the traffic is TCP, per packet load
- sharing is used, and equal cost routes to different instances of a
- name server are available, any DNS implementation which measures the
- performance of servers to select a preferred server will quickly
- prefer a server for which this problem does not occur. For the DNS
- failover mechanisms to reliably avoid this problem, however, those
- using shared unicast distribution mechanisms must take care that all
- of the servers for a specific zone are not participants in the same
- shared-unicast mesh. To guard even against the case where multiple
- meshes have a set of users affected by per packet load sharing along
- equal cost routes, organizations implementing these practices should
- always provide at least one authoritative server which is not a
- participant in any shared unicast mesh. Those deploying
- shared-unicast meshes should note that any specific host may become
- unreachable to a client should a server fail, a path fail, or the
- route to that host be withdrawn. These error conditions are,
- however, not specific to shared-unicast distributions, but would
- occur for standard unicast hosts.
-
- Since ICMP response packets might go to a different member of the
- mesh than that sending a packet, packets sent with a shared unicast
- source address should also avoid using path MTU discovery.
-
- Appendix A. contains an ASCII diagram of a example of a simple
- implementation of this system. In it, the odd numbered routers
- deliver traffic to the shared-unicast interface network and filter
- traffic from the administrative network; the even numbered routers
- deliver traffic to the administrative network and filter traffic
- from the shared-unicast network. These are depicted as separate
- routers for the ease this gives in explanation, but they could
- easily be separate interfaces on the same router. Similarly, a
- local NTP source is depicted for synchronization, but the level of
- synchronization needed would not require that source to be either
- local or a stratum one NTP server.
-
-
-2. Administration
-
-2.1 Points of Contact
-
- A single point of contact for reporting problems is crucial to the
- correct administration of this system. If an external user of the
- system needs to report a problem related to the service, there must
- be no ambiguity about whom to contact. If internal monitoring does
- not indicate a problem, the contact may, of course, need to work
- with the external user to identify which server generated the
- error.
-
-
-3. Security Considerations
-
- As a core piece of Internet infrastructure, authoritative name
- servers are common targets of attack. The practices outlined here
- increase the risk of certain kinds of attack and reduce the risk of
- others.
-
-3.1 Increased Risks
-
-3.1.1 Increase in physical servers
-
- The architecture outlined in this document increases the number of
- physical servers, which could increase the possibility that a
- server mis-configuration will occur which allows for a security
- breach. In general, the entity administering a mesh should ensure
- that patches and security mechanisms applied to a single member of
- the mesh are appropriate for and applied to all of the members of a
- mesh. "Genetic diversity" (code from different code bases) can be
- a useful security measure in avoiding attacks based on
- vulnerabilities in a specific code base; in order to ensure
- consistency of responses from a single named server, however, that
- diversity should be applied to different shared-unicast meshes or
- between a mesh and a related unicast authoritative server.
-
-3.1.2 Data synchronization problems
-
- The level of systemic synchronization described above should be
- augmented by synchronization of the data present at each of the
- servers. While the DNS itself is a loosely coupled system,
- debugging problems with data in specific zones would be far more
- difficult if two different servers sharing a single unicast address
- might return different responses to the same query. For example,
- if the data associated with www.example.com has changed and the
- administrators of the domain are testing for the changes at the
- example.com authoritative name servers, they should not need to
- check each instance of a named root server. The use of ntp to
- provide a synchronized time for switch-over eliminates some aspects
- of this problem, but mechanisms to handle failure during the
- switchover are required. In particular, a server which cannot make
- the switchover must not roll-back to a previous version; it must
- cease to respond to queries so that other servers are queried.
-
-3.1.3 Distribution risks
-
- If the mechanism used to distribute zone files among the servers is
- not well secured, a man-in-the-middle attack could result in the
- injection of false information. Digital signatures will alleviate
- this risk, but encrypted transport and tight access lists are a
- necessary adjunct to them. Since zone files will be distributed to
- the administrative interfaces of meshed servers, the access control
- list for distribution of the zone files should include the
- administrative interface of the server or servers, rather than
- their shared unicast addresses.
-
-3.2 Decreased Risks
-
- The increase in number of physical servers reduces the likelihood
- that a denial-of-service attack will take out a significant portion
- of the DNS infrastructure. The increase in servers also reduces
- the effect of machine crashes, fiber cuts, and localized disasters
- by reducing the number of users dependent on a specific machine.
-
-
-4. Full copyright statement
-
- Copyright (C) The Internet Society 1999. 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.
-
-5. Acknowledgments
-
- Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
- Mark Andrews, Robert Elz, Geoff Houston, Bill Norton, Akira Kato,
- Suzanne Woolf, Scott Tucker, Bernard Aboba, Casey Ajalat and Gunnar
- Lindberg all provided input and commentary on this work.
-
-
-6. References
-
-[SECONDARY] "Selection and Operation of Secondary Name Servers".
-R. Elz, R. Bush, S Bradner, M. Patton, BCP0016.
-
-[ROOT] "Root Name Server Operational Requirements". R. Bush,
-D. Karrenberg, M. Kosters, R. Plzak, BCP0040.
-
-[ANYCAST] "Host Anycasting Service". C. Patridge, T. Mendez, W. Milliken,
-RFC1546.
-
-
-7. Editor's address
-
- Ted Hardie
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- Ted.Hardie@nominum.com
- Tel: 1.650.381.6226
-
-
-
-
-Appendix A.
-
-
-
- __________________
-Peer 1-| |
-Peer 2-| |
-Peer 3-| Switch |
-Transit| | _________ _________
-etc | |--|Router1|---|----|--------------|Router2|---WAN-|
- | | --------- | | --------- |
- | | | | |
- | | | | |
- ------------------ [NTP] [DNS] |
- |
- |
- |
- |
- __________________ |
-Peer 1-| | |
-Peer 2-| | |
-Peer 3-| Switch | |
-Transit| | _________ _________ |
-etc | |--|Router3|---|----|--------------|Router4|---WAN-|
- | | --------- | | --------- |
- | | | | |
- | | | | |
- ------------------ [NTP] [DNS] |
- |
- |
- |
- |
- __________________ |
-Peer 1-| | |
-Peer 2-| | |
-Peer 3-| Switch | |
-Transit| | _________ _________ |
-etc | |--|Router5|---|----|--------------|Router6|---WAN-|
- | | --------- | | --------- |
- | | | | |
- | | | | |
- ------------------ [NTP] [DNS] |
- |
- |
- |
- |
- __________________ |
-Peer 1-| | |
-Peer 2-| | |
-Peer 3-| Switch | |
-Transit| | _________ _________ |
-etc | |--|Router7|---|----|--------------|Router8|---WAN-|
- | | --------- | | ---------
- | | | |
- | | | |
- ------------------ [NTP] [DNS]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT D. Senie
-Category: BCP Amaranth Networks Inc.
-Expires in six months March 2002
-
- Requiring DNS IN-ADDR Mapping
- draft-ietf-dnsop-inaddr-required-03.txt
-
-Status of this Memo
-
-
- This draft, is intended to be become a Best Current Practice RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the Domain Name Server Operations working group mailing list
- <dnsop@cafax.se> or to the author.
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of [RFC2026].
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000-2002). All Rights Reserved.
-
-Abstract
-
- Mapping of addresses to names has been a feature of DNS. Many sites,
- implement it, many others don't. Some applications attempt to use it
- as a part of a security strategy. The goal of this document is to
- encourage proper deployment of address to name mappings, and provide
- guidance for their use.
-
-1. Introduction
-
- The Domain Name Service has provision for providing mapping of IP
- addresses to host names. It is common practice to ensure both name to
- address, and address to name mappings are provided for networks. This
- practice, while documented, has never been documented as a
- requirement placed upon those who control address blocks. This
-
-
-
-Senie [Page 1]
-
-
-
-
-
-Internet-Draft Requiring DNS IN-ADDR Mapping March 2002
-
-
- document fills this gap.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
-2. Discussion
-
- From the early days of the Domain Name Service [RFC 883] a special
- domain has been set aside for resolving mappings of IP addresses to
- domain names. This was refined in [RFC1035], describing the .IN-
- ADDR.ARPA in use today.
-
- The assignment of blocks of IP Address space was delegated to three
- regional registries. Guidelines for the registries are specified in
- [RFC2050], which requires regional registries to maintain IN-ADDR
- records on the large blocks of space issued to ISPs and others.
-
- ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
- allocations. For smaller allocations, ARIN can provide IN-ADDR for
- /24 and shorter prefixes. [ARIN]. APNIC indicates in their policy
- document [APNIC] that those to whom they allocate blocks, and those
- further downstream SHOULD maintain IN-ADDR records. RIPE appears to
- have the strongest policy in this area [ripe-185] indicating Local
- Internet Registries are required to perform IN-ADDR services, and
- delegate those as appropriate when address blocks are delegated.
-
- As we can see, the regional registries have their own policies for
- requirements for IN-ADDR maintenance. It should be noted, however,
- that many address blocks were allocated before the creation of the
- regional registries, and thus it is unclear whether any of the
- policies of the registries are binding on those who hold blocks from
- that era.
-
- Registries allocate address blocks on CIDR [RFC1519] boundaries.
- Unfortunately the IN-ADDR zones are based on classful allocations.
- Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
- exist, but are not always implemented. Providers SHOULD follow these
- guidelines and ensure their clients set up zone files to answer the
- delegations.
-
-3. Effects of missing IN-ADDR
-
- Many applications use DNS lookups for security checks. To ensure
- validity of claimed names, some applications will look up IN-ADDR
- records to get names, and then look up the resultant name to see if
- it maps back to the address originally known. Failure to resolve
- matching names is seen as a potential security concern.
-
-
-
-Senie [Page 2]
-
-
-
-
-
-Internet-Draft Requiring DNS IN-ADDR Mapping March 2002
-
-
- Some popular FTP sites will flat-out reject users, even for anonymous
- FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR
- lookup when itself resolved, does not match. Some Telnet servers also
- implement this check.
-
- Web sites are in some cases using IN-ADDR checks to verify whether
- the client is located within a certain geopolitical entity. This is
- being employed for downloads of crypto software, for example, where
- export of that software is prohibited to some locales. Credit card
- anti-fraud systems also use these methods for geographic placement
- purposes.
-
- The popular TCP Wrappers program found on most Unix and Linux systems
- has options to enforce IN-ADDR checks and to reject any client which
- does not resolve.
-
- Wider-scale implementation of IN-ADDR on dialup, CDPD and other such
- client-oriented portions of the Internet would result in lower
- latency for queries (due to lack of negative caching), and lower name
- server load and DNS traffic.
-
- Some anti-spam (anti junk email) systems use IN-ADDR to verify return
- addresses before accepting email.
-
- Many web servers look up the IN-ADDR of visitors to be used in log
- analysis. This adds to the server load, but in the case of IN-ADDR
- unavailability, it can lead to delayed responses for users.
-
- Traceroutes with descriptive IN-ADDR naming proves useful when
- debugging problems spanning large areas. When this information is
- missing, the traceroutes take longer, and it takes additional steps
- to determine which network is the cause of problems.
-
-4. Requirements
-
- Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
- of IN-ADDR, sometimes in conjunction with a lookup of the name
- resulting from the PTR record adds no real security, can lead to
- erroneous results and generally just increases load on DNS servers.
- Further, in cases where address block holders fail to properly
- configure IN-ADDR, users of those blocks are penalized.
-
- All IP address space which is assigned and in use SHOULD be resolved
- by IN-ADDR records. All PTR records MUST use canonical names.
-
- Internet providers and other users to whom a block of addresses are
- delegated SHOULD provide for lookup of host names from IP addresses.
- This may be provided directly or by delegation to the user of the
-
-
-
-Senie [Page 3]
-
-
-
-
-
-Internet-Draft Requiring DNS IN-ADDR Mapping March 2002
-
-
- address block. The ISP is responsible for one or the other. In the
- event of delegation, the user is responsible for resolution.
-
- Only IP addresses not presently in use within a block, or which are
- not valid for use (zeros or ones broadcast addresses) are permitted
- to have no mapping. It should be noted that due to CIDR, many
- addresses which appear to be otherwise valid host addresses may
- actually be zeroes or ones broadcast addresses. As such, attempting
- to audit a site's degree of compliance can only be done with a
- knowledge of the internal routing structure of the site. However, any
- host which originates an IP packet necessarily will have a valid host
- address, and must therefore have an IN-ADDR mapping.
-
- Regional Registries and any Local Registries to whom they delegate
- SHOULD establish and convey a policy to those to whom they delegate
- blocks that IN-ADDR mappings are required. Internet providers and end
- users with address blocks must verify their own internal networks are
- properly represented in IN-ADDR records, either by providing that
- service themselves, or delegating it to others.
-
- Those to whom blocks have been delegated SHOULD convey a policy to
- delegatees requiring that they too provide IN-ADDR records and
- require and delegations below to do the same. ISPs may wish to
- provide IN-ADDR records for their clients if the customers are unable
- to provide this for themselves.
-
-5. Security Considerations
-
- This document has no negative impact on security. While it could be
- argued that lack of PTR record capabilities provides a degree of
- anonymity, this is really not valid. Trace routes, whois lookups and
- other sources will still provide methods for discovering identity.
-
- By recommending applications avoid using IN-ADDR as a security
- mechanism this document points out that this practice, despite its
- use by many applications, is an ineffective form of security.
- Applications should use better mechanisms of authentication.
-
-6. References
-
- [RFC883] P.V. Mockapetris, "Domain names: Implementation
- specification," RFC883, November 1983.
-
- [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
- Specification," RFC 1035, November 1987.
-
- [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
- an Address Assignment and Aggregation Strategy," RFC 1519, September
-
-
-
-Senie [Page 4]
-
-
-
-
-
-Internet-Draft Requiring DNS IN-ADDR Mapping March 2002
-
-
- 1993.
-
- [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
- RFC 2026, BCP 9, October 1996.
-
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, BCP 14, March 1997.
-
- [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
- Guidelines", RFC2050, BCP 12, Novebmer 1996.
-
- [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
- RFC 2317, March 1998.
-
- [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
- unknown, http://www.arin.net/regserv/initial-isp.html
-
- [APNIC] "Policies For IPv4 Address Space Management in the Asia
- Pacific Region," APNIC-086, Approval pending, 17 December 2001,
- http://www.apnic.net/drafts/add-manage-policy.html
-
- [RIPE185] "European Internet Registry Policies and Procedures,"
- ripe-185, October 26, 1998. http://www.ripe.net/docs/ripe-185.html
-
-
-7. Acknowledgements
-
- Thanks to Peter Koch and Gary Miller for their input, and to many
- people who encouraged me to write this document.
-
-8. Author's Address
-
- Daniel Senie
- Amaranth Networks Inc.
- 324 Still River Road
- Bolton, MA 01740
-
- Phone: (978) 779-6813
-
- EMail: dts@senie.com
-
-
-
-
-
-
-
-
-
-
-
-Senie [Page 5]
-
-
------------------------------------------------------------------
-Daniel Senie dts@senie.com
-Amaranth Networks Inc. http://www.amaranth.com
-
+++ /dev/null
-
-
-Internet Draft Johan Ihr\89n
-draft-ietf-dnsop-interim-signed-root-01.txt Autonomica
-February 2003
-Expires in six months
-
-
- An Interim Scheme for Signing the Public DNS Root
-
-
-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 proposed mechanism for a first stage of a
- transition from an unsigned DNS root to a signed root, such that
- the data in the root zone is accompanied by DNSSEC signatures to
- allow validation.
-
- The underlying reason for signing the root zone is to be able to
- provide a more secure DNS hierarchy, where it is possible to
- distinguish false answers from correct answers.
-
- For the special case of the DNS root zone, an interim scheme is
- proposed. This scheme is mostly aimed at securing the root zone
- itself for technical and operational reasons, and to give
- operational experience of DNSSEC.
-
-
-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", finally, is a DNS "client",
- i.e. an entity that sends DNS queries to authoritative nameservers
- and interpret the results.
-
-
-2. Motivation for signing the DNS root
-
- In the special case of the root zone there are very strong reasons
- to take a slow and conservative approach to any changes with
- operational impact. Signing the root is such a change.
-
- DNSSEC[RFC2535, RFC3090] has been in development for a number of
- years now and still has not reached the point where the last flag
- day is behind us.
-
- However, during the years of DNSSEC development and refinement
- [RFC2930, RFC3007, RFC3008, RFC3110, RFC3225, RFC3226, AD-secure,
- Opt-in, Wild-card-optimize], the Internet has matured and more and
- more businesses and other organizations have become dependent on
- the stability and constant availability of the Internet.
-
- It is therefore prudent to do everything in our power to ensure
- that the DNS infrastructure works as well as possible and, when
- appropriate and possible, adding enhancements and functionality.
-
- The time is now right for yet another step of improvement by
- signing the root zone. By doing that any Internet user that so
- wishes will obtain the ability of verifying responses received from
- the root nameservers.
-
- Since this is new operational ground the objective is not maximum
- security but rather an "Internet-wide" controlled experiment with a
- signed root zone, where the trade off is that we utilize the fact
- that there are operators in place that can help even though they
- are not sufficiently staffed to do off-line signing in a 24x7
- mode. For this reason it is fully possible to even do automatic
- signing, since the purpose is to ensure that DNSSEC works
- operationally with a signed root zone and gain experience from the
- exercise.
-
- It should be pointed out, however, that the experimental part is
- only the added DNSSEC records. The traditional records in the root
- zone remain unchanged and the new records will only be visible to
- DNSSEC-aware resolvers that explicitly ask to see these new
- records.
-
-
-2.1. Motivation for signing the root zone now
-
- The reason DNSSEC is not yet widely deployable is that the problem
- of key management remains unsolved, especially where communication
- between the zone administrators for a parent zone and child zone is
- required.
-
- However, during the past year a solution to this problem has been
- found (in the form of a new record type, DS aka Delegation Signer)
- [DS], discussed, implemented and tested. Therefore, it is finally
- reasonable to consider DNSSEC deployment to be a real possibility
- within the next 12 months.
-
- In the case of the root zone the particular importance of managing
- the transition with zero operational mistakes is a strong reason to
- separate the signing of the zone itself, with the associated key
- management issues, from the future management of signed delegations
- (of top level domains).
-
- Although support for Delegation Signer has been implemented and
- tested it is not yet generally available except experimentally. For
- this reason signed delegations for productions zones will have to
- wait a bit longer. Furthermore, it will take some time to ensure
- that the entire RSS aka Root Server System is capable of supporting
- the protocol changes that accompany the new support for Delegation
- Signer.
-
- By signing now it will be possible to work through the operational
- issues with signing the zone itself without at the same time having
- to manage the additional complexity of signed delegations. Also, by
- explicitly not supporting any signed delegations, it is also
- possible to recover in a graceful way should new operational
- problems turn up.
-
- Because of these operational and technical issues there is a
- "window of opportunity" to sign the root zone before the status of
- implementation of "full DNSSEC", including Delegation Signer
- support, change to "generally available", thereby increasing the
- pressure for signed delegations from the root zone.
-
-
-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
-
- * trust in the distribution method
-
- * trust in extra, out-of-band verification
-
- For any security apex, i.e. a node in the DNS hierarchy that issues
- out-of-band "trusted keys", it is of critical importance that this
- function produces a positive result (i.e. the resolver gains
- sufficient confidence in the keys to decide to trust them). The
- particular case of the root zone is no different, although possibly
- it is more crucial than many other security apexes.
-
- To ensure that the resulting trust is maximized it is necessary to
- work with all the parameters that are available. In the case of the
- key issuer there is the possibility of chosing a key issuer that
- has a large "trust base" (i.e. is already trusted by a large
- fraction of the resolver population). However, it is also possible
- to expand the aggregated trust base by using multiple simultaneous
- key issuers, as described in [Threshold-Validation].
-
- Furthermore, with multiple trusted keys it will be possible for a
- validating resolver to optimize for the "right compromise" between
-
- * maximum security (as expressed by all available signatures by all
- available keys verifying correctly
-
- * maximum redundancy (as in the DNS lookup being validated if there
- is any signature by any trusted key available)
-
- Without multiple, independent trusted keys the rollover operation
- will always be a dangerous operation where it is likely that some
- fraction of the resolver population lose their ability to verify
- lookups (and hence start to fail hard). I.e. the validating
- resolver will be forced to adopt the "maximum security" policy,
- since there is no alternative.
-
- With multiple, independent trusted keys, however, it is possible to
- design for improved redundancy by trusting lookups that are only
- validated against a subset of the available keys. This will make
- rollovers much less risky to the extent that it will be possible to
- "survive" even emergency rollovers without any immediate
- configuration chagnes in the validating resolver.
-
-
-4. Interim signing of the root zone
-
- At present all the authoritative servers for the root zone pull the
- zone from a primary master. I.e. any changes at the primary master
- will propagate via NOTIFY[RFC1996] and subsequent
- AXFR/IXFR[RFC1995, AXFR-clarify] to the slave servers.
-
- Between the primary master and the slaves transactions are signed
- with TSIG[RFC2845] signatures. This mechanism is already in place,
- and there is operational experience with periodic key rollover of
- the TSIG keys.
-
-
-4.1. Design philosophy
-
- By introducing a signing step into the distribution of the zone
- file complexity is increased. To avoid introducing new single
- points of failure it is therefore important to ensure that any
- added or changed steps are as redundant as possible.
-
- The assumption is that the operators of the root servers are
- trusted and that consistency of the zone among the root servers is
- a crucial property that MUST be preserved in emergencies.
-
- To ensure that consistency is maintained new single points of
- failure SHOULD NOT be introduced by the signing step. Therefore a
- structure where several parties have the ability to sign the zone
- is proposed. Furthermore, such a design helps avoid any individual
- party becoming a de facto single zone signing authority.
-
-
-4.2. Proposed new management structure for the root zone
-
- Taking into account the already existing infrastructure for
- management of TSIG keys and rollover of these keys the following
- structure is proposed:
-
- * Day-to-day signing of the root zone is performed by a subgroup of
- the root server operators referred to as "signing operators". For
- this task individual, per-operator, Zone Signing Keys, ZSKs, are
- used.
-
- * The set of Zone Signing Keys are signed by several Key Signing
- Keys, KSKs, at any particular time. The public part of KSKs in
- use have to be statically configured as "trusted keys" in all
- resolvers that want to be able to perform validation of
- responses.
-
- * Key rollover, the operation when an old KSK is exchanged for a
- new KSK, is managed with minimal overlap and on a frequent basis
- of no less than three times per year per KSK. The rollover
- schedule is chosen to be frequent enough to not make long-term
- trust possible while being low enough to not become operationally
- infeasible.
-
-
-4.2.1. Management and distribution of the zone file
-
- The present, unsigned zone is published by the official slaves, the
- "root nameservers", transferring the zone securely from a primary
- master and subsequently using the data to respond to queries. This
- mechanism is changed into:
-
- * The unsigned root zone is transferred securely from the primary
- master to a set of "signing primaries" managed by the operators
- participating in signing the zone. This is done via the
- traditional mechanisms NOTIFY + AXFR/IXFR + TSIG.
-
- * The root nameservers change their configuration so that they
- replace the present, single, primary master as the source of the
- zone with a set of multiple possible "signing primaries" as
- masters that provide the signed zone.
-
- * When a new, unsigned zone, is published by the primary master it
- will automatically be transferred to the pre-signing servers. The
- responsible operator will then sign the new zone and publish it
- from his signing primary. Since the serial number is higher than
- what the official root nameservers presently have the official
- root nameservers will all transfer the zone from this source
- (because of the redundant configuration with multiple possible
- masters for the signed zone).
-
- * The operators that participate in signing rotate the signing
- responsibility among themselves. Should the responsible operator
- be unable to do this for any reason then any of the others are
- able to do the signing instead. Traceability is maintained since
- the zone signing keys are individual.
-
- * To avoid having several "backup signing operators" possibly sign
- at exactly the same time backups are allocated "time windows"
- within which they are allowed to publish a signed zone.
-
- With N signers, each signer is assigned a unique number R in
- [1..N].
-
- T = 2*k*((S-R) mod N)
-
- T is time to wait in seconds, S current serial number. The length
- of the window is k, thereby separating each signing window with
- an interval where signing is not allowed.
-
- The constant k is used to create sufficient separation of the
- signers with respect to time used to sign and time needed to
- distribute the zone. A reasonable value for k would be in the
- order of 1800 seconds.
-
- * Because the digital signatures in the signed root zone MUST NOT
- expire it is necessary to ensure that the unsigned zone does
- change sufficiently often to cause new signing to occur within
- the validity period of the old signatures. This is most easily
- accomplished by a dummy update that only increments the serial
- number in the SOA record.
-
- This new requirement will not cause any operational problems,
- since in fact the root zone is maintained this way since several
- years back.
-
-
-4.2.2. Management of the Key Signing Keys
-
- Key Signing Keys, KSKs, are periodically issued by a several "Key
- Signing Key Holders", KSK holders, individually. These KSKs consist
- of a private part that should always be kept secret and a public
- part that should be published as widely as possible since it will
- be used as a "trusted key" in resolver configurations.
-
- The public part of each KSK should be included in the keyset for
- "." as described in [Threshold-Validation]. I.e. the keyset will be
- the union of the public parts of all KSKs and all ZSKs, Zone
- Signing Keys.
-
- * Each KSK holder should generate a sequence of KSKs where the
- public parts will be used to include in the keyset for "." and
- the private parts will be used for signing the keyset.
-
- * Each KSK holder should, on request from the signing operators,
- send in the public part of the KSK. The union of the public parts
- of KSKs and the corresponding public parts of ZSKs, as collected
- by the signing operators, constitute a "keyset".
-
- * Each KSK holder should, on request from the signing operators,
- sign the complete keyset with the private part of the associated
- KSK and send in the resulting signature to the signing operators
- for inclusion in the signed zone.
-
-
-4.2.3. Management of the Zone Signing Keys and the keyset signatures
-
- A subgroup of the root operators that choose to participate in
- signing the zone each hold an individual "Zone Signing Key",
- ZSK. The subgroup of operators may include all operators, but that
- is not necessary as long as a sufficient number to achieve
- redundancy in "signing ability" participates.
-
- * The complete keyset (i.e. all the public parts of KSKs and ZSKs)
- should be signed by each KSK holder individually, generating a
- new signature for the keyset which is sent back to the signing
- operators via an out-of-band mechanism.
-
- * The signing operators should verify each received signature
- against the corresponding key in the keyset and, unless invalid,
- accept the signature into the set of signatures associated with
- this keyset as described in [Threshold-Validation].
-
- * The signing operators should include one of the keysets together
- with all the KSK signatures in the zone file according to an
- agreed upon rotation schedule.
-
-
-4.2.4. Management of key rollover
-
- The Key Signing Keys should, for this interim scheme, be relatively
- short-lived and rolled over frequently. The direct intent is that
- it should not be possible to put long term trust in the keys.
- Therefore, by design, every resolver that chooses to configure
- these as "trusted keys" (to be able to validate lookups) will have
- to change the configuration periodically.
-
- This is, after all, only an interim method of root zone signing.
-
- * Key rollover is executed by changing from one signed keyset to
- another. I.e. from a keyset signed by one set of KSKs to a keyset
- signed by a partially different set of KSKs. By not rolling all
- the KSKs at the same time redundancy is improved.
-
- * Technically the signing operators are able to initiate key
- rollover, although except for the case of a suspected key
- compromise (with subsequent immediate key rollover) this ability
- should only be used according to an established schedule.
-
- * New Key Signing Keys will be published as widely as possible,
- however exactly how and where to publish the keys is by itself an
- area where it is necessary to acquire more experience. Especially
- for the case of individual hosts and other devices this will be a
- significant issue to deal with.
-
- * Since the keys expire within a few months the aim is to make it
- as difficult as possible to configure an interim key and then
- forget about it long enough to still trust an interim key when a
- long term design for signing the root zone emerges.
-
-
-4.2.5. The role of the KSK holder
-
- With multiple KSKs it is possible to have multiple individual KSK
- holders. Each will perform the role of authenticating the identity
- of the signing operators, through the act of signing the keyset
- that includes the operator Zone Signing Keys.
-
- The chain of authority that defines editorial control over the zone
- contents is entirely separate from this and is in no way affected.
-
- I.e. the KSK holder is only asserting identity of the holders of
- ZSKs and does not in any way take part in issues regarding zone
- contents. In this respect the role of a KSK holder is much like
- that of a public notary or a Certificate Authority.
-
- The primary function that the KSK holder is performing is adding
- trust to the authenticity of the Zone Signing Keys and this trust
- has to be propagated down to validating resolvers. Therefore an
- obvious key characteristic of a KSK holder is that it should
- already be trusted by as large a fraction of the "resolver
- population" as possible. In this document that fraction is referred
- to as the "trust base" of a KSK holder.
-
- The key characteristics of a KSK holder will be entities that
-
- * already are trusted by some part of the "resolver population",
- i.e. have a "trust base"
-
- * are multiple entities that complement each other (so that the
- aggregated "trust base" grows)
-
- * are willing to help work on methods for distributing their
- trusted keys to the resolvers (hard problem)
-
- The requirement on the individual KSK holders is that they must be
- able to
-
- * establish a secure out-of-band communication path in
- collaboration with the signing operators which will be used for
- authenticated exchange of the unsigned keyset and generated
- signatures
-
- * periodically generate strong keys using a good random number
- generator
-
- * manage their keys (i.e. use them for signing the operator keyset
- and keeping the private key appropriately secret)
-
-
-4.2.5.6. Suggestions for KSK holders
-
- Regional Internet Registries, RIRs, are suggested to be one
- suitable choice of KSK holders. However, since every KSK holder
- will act on its own there is no requirement that all RIRs
- participate, although more than one would be good. Other suitable
- KSK holders may exist and as long as the requirements are met more
- would be better within the packe size limitations that are
- discussed in [Threshold-Validation].
-
- The basis of the suggestion of RIRs is
-
- * their neutrality
-
- * their proven record of service to the Internet community
-
- * that they don't have the domain name system as their primary
- field of activity
-
- * their geographical diversity
-
- * the fact that they are, by definition, not a single entity, but
- rather a collective of organizations.
-
-
-5. Risk Analysis
-
- A change in the management of the root zone is always a risk. But
- that is all the more reason to do it carefully and after due
- consideration, rather than as a result of an immediate and urgent
- need. The gains of a signed root zone have to be judged against the
- added complexity of the signing step.
-
- However, added complexity, in one form or another, is basically
- unavoidable. It is possible to argue for or against implementation
- details, but in the end the benefits of a signed root will have to
- be compared against some amount of added complexity. If the cost or
- risk of this complexity is deemed to be too high, then it is not
- possible to sign the DNS root zone. If that is the conclusion; then
- it is obviously important to reach it as soon as possible.
-
- The same is true for the need for operational experience with a
- signed root zone. There is no method of acquiring this experience
- except by signing the root zone, so that is what is being proposed.
-
- Some identified scenarios:
-
-
-5.1. What will the consequences of a signed root zone be for old
- resolver software?
-
- Nameservers that are authoritative for signed zones only give out
- these signatures when explicitly asked for them. Therefore, the
- presence of signatures in the root zone will not have any impact at
- all on the majority of resolvers on the Internet that does not
- validate lookups.
-
-
-5.2. What happens if a signing operator fails to sign the zone on
- time?
-
- Literally nothing. I.e. the root zone that is published will be the
- version prior to the last change. This is not believed to be a
- major problem, since all changes to the data in the root zone are
- characterized by long overlaps in time. Furthermore every change is
- preceded by an administrative process that takes several days or
- even weeks. Because of this, a failure to install a new version of
- the root zone for even so long as a day will not noticeably change
- the turn-around time for changes in the root zone.
-
-
-5.3. What happens if several signing operators by mistake sign the
- same version?
-
- Literally nothing. One signing operator will be first, according to
- the mechanism designed to separate the different backup signing
- operators described in 3.3.1. The signed zone published by this
- operator will be the version of the signed root zone that all the
- root nameservers pick up.
-
- When the second signing operator signs the zone the serial number
- in the zone will be unchanged, and therefore the root nameservers
- will not pick this zone up but instead stay with the first version.
-
-
-5.4. What happens if the unsigned zone is compromised between the
- primary master and the signing primaries?
-
- This is basically the same threat as the zone being compromised
- between the primary master and the root servers in the traditional
- unsigned case. To guard against this possibility every zone
- transfer is already protected by a TSIG signature.
-
- Because of this the root zone file cannot get transferred to the
- signing primaries unless the transaction signature matches, thereby
- proving that the zone contents are uncompromised. The consequence
- is that if the zone transfers are somehow compromised in transit,
- they will not get signed and therefore the published root zone will
- remain the signed version of the last uncompromised transfer.
-
-
-5.5. What are the security implications for the new "signing
- primaries"? Will they not have to be as secure as the primary
- master is now?
-
- Yes. However, the entire root server system is based upon trust,
- i.e. the entire Internet is trusting the present root server system
- because there is no alternative to doing that. This proposal is not
- about changing the need for trust in the root server system. It is
- about providing a method of determining authenticity of data,
- something that is presently missing.
-
- The root operators are already trusted to provide a root server
- system based upon secure servers lacking validation mechanisms. It
- is therefore a bit difficult to argue for not trusting them to
- provide an improved system that adds exactly the lacking validation
- mechanisms on a basis of not trusting them to secure the servers
- involved. In both cases trust is involved, the difference is that
- in the latter case validation is possible.
-
- Furthermore, the proposed signing primaries will not need to have
- publicly known addresses (just as the present primary master is not
- publicly known), nor will they need to be able to communicate with
- anyone outside the well defined set of servers that are part of the
- root server system. Because of this it will be significantly easier
- to secure the signing primaries than the already present task of
- securing the DNS root nameservers.
-
-
-5.6. What happens if a Zone Signing Key is compromised?
-
- If this happens it is necessary to do an emergency rollover of the
- keyset that includes the compromised key. I.e. the old keyset (and
- its signatures) is replaced by a new keyset containing new ZSKs but
- the same, uncompromised, KSKs and its signatures. Then the root
- zone is re-signed using one of the new Zone Signing Keys.
-
- This problem is not unique to a signed root zone, it is inherent in
- any activity involving cryptographic keys.
-
- Also note that there will be no need to change any configuration in
- the resolver end. The rollover is an entirely atomic operation
- inside the management structure of the root zone.
-
-
-5.7. What happens if a Key Signing Key is compromised?
-
- Depending on the trust model used by individual validating
- resolvers one of two things will happen.
-
- Resolvers that through local policy have chosen to trust this KSK
- alone will need to change their configuration to instead trust
- other KSKs, either available from other KSK holders or a new
- trusted key made available by the same KSK holder that held the
- compromised key.
-
- Resolvers that have chosen to require multiple signatures by KSKs
- for the root zone will not have to do any emergency key rollover at
- all, since validation of lookups will still work, based upon the
- integrity of the other trusted keys that have not been compromised.
-
- In the management end it is necessary to do an emergency rollover
- of the keyset including the compromised key and the suggested
- method is by switching to a keyset that only changes the
- compromised KSK and the ZSKs and keeps all other KSKs. Such keysets
- should be prepared and signed in advance.
-
- The new signed keyset is added to the root zone and then the zone
- is re-signed using one of the new Zone Signing Keys. In this case,
- since a Key Signing Key is changed, every resolver that choose to
- trust that KSK holder will over time have to configure the new key
- to be able to validate lookups.
-
- This problem is not unique to a signed root zone, it is inherent in
- any activity involving cryptographic keys.
-
-
-5.8. Does the out-of-band communication between the signing operators
- and the RIRs holding the key-signing keys add a new failure mode?
-
- Yes. The traditional DNSSEC design assumes that (for an arbitrary
- zone, not particularly for the root zone) the key-signing key is
- managed by the same entity that manages the operator keys and hence
- no communication issue exists.
-
- In this case it is important that the signing operators do not hold
- the responsibility for the key-signing keys. The root server
- operators should only act as a "publishing service" for the root
- zone contents, not as the entity that verifies correctness of the
- published data.
-
- However, apart from established secure methods of out-of-band
- communication being available, there is also the very real
- possibility of managing these exchanges with actual eye-to-eye
- contact. Representatives for the RIRs and the root server operators
- already meet on a regular basis during IETF meetings and the
- different RIR meetings.
-
-
-6. Security Considerations
-
- Signing the DNS root zone is all about security. A signed root zone
- may aid applications and organizations all over the Internet in
- improving their security by enabling validation of DNS lookups.
-
- Signing the root zone does add a new management step and therefore
- it is important to ensure that possible failures in this management
- step does not leave the published root zone in a state that is
- actually worse than the original unsigned state.
-
- The various failure modes that have been identified all show this
- property of not being any worse than the unsigned case.
-
- There is however one scenario that changes drastically with the
- proposed distributed signing scheme and that is the consequences of
- one signing operator intentionally changing the contents of the
- root zone prior to the actual signing. In the unsigned case this
- will cause the root zone to become inconsistent (i.e. the responses
- vary depending upon which server it comes from), while in the
- signed case the root zone will remain consistent but with erroneous
- data in it.
-
- It is my belief (this is impossible to prove) that the risk of
- human error among the operators, however small, is still far
- greater than the risk of willful misconduct. Therefore, the
- proposed design that enforces consistency among the roots, is
- actually also an improvement in stability and security.
-
- Se further section 4 for a more complete risk analysis.
-
-
-7. IANA Considerations
-
- NONE.
-
-
-8. References
-
-8.1. Normative.
-
- [RFC2535] Domain Name System Security Extensions. D. Eastlake.
- March 1999.
-
- [RFC3090] DNS Security Extension Clarification on Zone Status.
- E. Lewis. March 2001.
-
- [RFC1995] Incremental Zone Transfer in DNS. M. Ohta. August 1996.
-
- [RFC1996] A Mechanism for Prompt Notification of Zone Changes
- (DNS NOTIFY). P. Vixie. August 1996.
-
- [RFC2845] Secret Key Transaction Authentication for DNS (TSIG).
- P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington.
- May 2000.
-
-8.2. Informative.
-
- [RFC2930] Secret Key Establishment for DNS (TKEY RR). D. Eastlake.
- September 2000.
-
- [RFC3007] Secure Domain Name System (DNS) Dynamic Update.
- B. Wellington. November 2000.
-
- [RFC3008] Domain Name System Security (DNSSEC) Signing Authority.
- B. Wellington. November 2000.
-
- [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.
-
- [RFC3226] DNSSEC and IPv6 A6 aware server/resolver message size
- requirements. O. Gudmundsson. December 2001.
-
- [Delegation-Signer] Delegation Signer Resource Record.
- O. Gudmundsson. October 2002. Work In Progress.
-
- [AXFR-clarify] draft-ietf-dnsext-axfr-clarify-NN.txt DNS Zone
- Transfer Protocol Clarifications. A. Gustafsson. March
- 2002. Work In Progress.
-
- [AD-secure] draft-ietf-dnsext-ad-is-secure-NN.txt Redefinition of
- DNS AD bit. B. Wellington, O Gudmundsson. June 2002.
- Work In Progress.
-
- [Opt-In] draft-ietf-dnsext-dnssec-opt-in-NN.txt DNSSEC Opt-In
- R. Arends, M Kosters, D. Blacka. June 2002. Work In
- Progress.
-
- [Wild-card-optimize] draft-olaf-dnsext-dnssec-wildcard-
- optimization-NN.txt DNSSEC Wildcard optimization.
- O. Kolkman, J. Ihren, R. Arends. September 2002.
- Work In Progress.
-
- [Threshold-Validation]
- draft-ihren-dnsop-threshold-validation-00.txt Threshold
- validation: A Mechanism for Improved Trust and Redundancy
- for DNSSEC Keys. J. Ihren. February 2003. Work In
- Progress.
-
-9. Acknowledgments.
-
- To help me produce this document I have received lots and lots of
- comments from many people around the Internet with suggestions for
- lots and lots sorely needed improvements. Among the folks who
- helped out are, in no particular order: Paul Vixie, Bill Manning,
- Ôlafur Gu\14mundsson, Rob Austein, Patrik F\84ltstr÷m, Olaf Kolkman,
- Harald Alvestrand, Suzanne Woolf, John M. Brown, Lars-Johan Liman
- and M\85ns Nilsson.
-
-
-10. Authors' Address
-
-Johan Ihr\89n
-Autonomica AB
-Bellmansgatan 30
-SE-118 47 Stockholm, Sweden
-johani@autonomica.se
+++ /dev/null
-DNSOP WG Edward Lewis
-INTERNET DRAFT NAI Labs
-Category: I-D March 2, 2001
-
- Handling of DNS Zone Signing Keys
- <draft-ietf-dnsop-keyhand-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.
-
-Comments should be sent to the authors or the DNSOP WG mailing list
-dnsop@cafax.se.
-
-This draft expires on September 2, 2001
-
-Copyright Notice
-
-Copyright (C) The Internet Society (1999-2001). All rights reserved.
-
-Abstract
-
-DNS Security Extensions require a greater interaction between zone
-administrations sharing a zone cut. The center of the interaction is
-the handling of the zone keys of the child and the signature applied
-by the parent. DNSSEC does not include a protocol for this, but the
-means of this interaction need definition to maintain the security of
-DNS.
-
-1 Introduction
-
-This document has existed for quite some time. The purpose of this
-document is to capture lessons learned regarding DNSSEC zone keys. In
-the past two years numerous workshops have been held, each adding to
-the community's lessons learned.
-
-In past editions of this document, the outline consisted of describing
-the lifecycle of a key and the steps needed to get it validated by the
-parent. In this edition, a new approach is being taken. The lessons
-learned are described without regard to fitting into an operations
-procedure. The hope is to develop a better explanation of the issues
-surrounding what will someday describe a "best current practice."
-
-2 Terminology
-
-Zone keys are explicitly defined in RFC 2535, but there have been
-certain phrases that are increasingly used that may cause confusion to
-new comers.
-
-A zone key really refers to two cryptographic values, called a public
-key and a private key. The two values always work in tandem, hence
-the singular reference. The phrase "signing with the zone key" refers
-to using the private key to generate digital signatures. The phrase
-"verifying with the zone key" refers to the use of the public key to
-verify the data and signature.
-
-3 Threats to Keys
-
-The threats to a zone key center on threats to the private key. There
-are three ways a zone key can be come useless to the owner (and
-possibly an advantage to an attacker). The private key could be come
-"exposed," "discovered," or "lost." The latter case, a lost key,
-refers to perhaps accidentally deleting the key from storage, and is a
-case that is of little concern. (Keys can be replaced easily.)
-
-An "exposed" key refers to a private key that is seen, or copied, by
-an unauthorized person. This could happen if the host holding the key
-is infiltrated or sloppy transferring of the key (such as in
-unencrypted email).
-
-A "discovered key" is one that is found through performing
-cryptographic analysis of the public key, data sets and signatures.
-Depending on various factors, such as algorithm and key size, a
-determined analyst can reverse engineer the private key.
-
-This latter loss is the most troublesome. This kind of loss is what
-creates the limited lifetime of a key. Because of this, there is a
-need to fully develop key changing (or rollover) procedures.
-
-Unfortunately, there is no current recommendation on how long it would
-take to discover a given private key. Such knowledge would be
-invaluable in the design on key handling procedures.
-
-4 "Lateral Signing"
-
-Lateral signing refers to the use of key-signing keys and data-signing
-keys to balance the need to change keys (avoiding discovery) and the
-need to configure new keys in resolvers.
-
-This approach has been developed for the use of TLDs in absence of a
-signed root zone. This approach is applicable anywhere in the DNS
-hierarchy, and will be needed by the root zone when it is signed.
-
-The thought is as follows. A zone assumes that the parent is not
-secured, hence must distribute a public key to all resolvers of
-interest. This key is a key-signing key, it will be used to sign as
-little as possible to minimize the risk of discovery. Other keys are
-used to sign the zone, with these keys changed roughly once a month.
-
-At any one time, the zone's key set will have the one key-signing key
-and some number of data-signing keys. The key-signing key will sign
-the zone key set, and the other key or keys, the zone data.
-
-A resolver would start with the key-signing key configured. When data
-arrives, it does so accompanied by a signature generated by a
-data-signing key. The resolver then retrieves the data-signing key as
-part of the zone key set, which is signed by the key-signing key.
-Hence the chain is from key-signing key to data-signing key (signed by
-key-signing key) to data (signed by data-signing key).
-
-The term "lateral" signing comes from the observation that the
-key-signing key and the data-signing key are from the same place in
-the hierarchy (same owner name).
-
-5 Getting Validation
-
-In order for DNSSEC to scale, zones will need to have their parents
-validate the zone keys. This process is the most difficult issue
-facing DNSSEC deployment.
-
-Summarizing this needed process, a child zone sends its zone key set
-to the parent, the parent signs it and returns the data to the child.
-This process is complicated by its volume (number of zones) and its
-repetitiveness due - to the key discovery problem.
-
-One important issue that has been raised regarding this process is
-what the parent does with the child's keys once they are signed. One
-school of thought is that the keys and signature are returned to the
-child and are forgotten by the parent. Another school of though is
-that the parent retains copies of the keys and signature, perhaps even
-entering them into the zone file.
-
-The former idea enables the child to "close the loop" security-wise by
-verifying that the parent signed the right keys. It might be possible
-for an attacker to intercept the submission and modify the keys.
-
-The latter idea leaves the parent better prepared for a key change in
-its zone. If the parent changes keys mid-month, or in an emergency,
-children zones (perhaps signed monthly) need to get the new
-signatures. On one workshop, this step was mishandled, resulting in
-the loss of many delegations.
-
-6 Changing Keys
-
-When the time comes to change a zone's keys, one issue is whether it
-is appropriate to retain old keys in the zone or to abruptly change
-the key set (with the exception of any key-signing key). The reason
-to retain old keys is to enable old but still valid signatures to be
-verified in caches. Arguments for abrupt change include the
-observation that this is the only way in which DNS can revoke
-signatures.
-
-8 Size and validity period
-
-An often-asked question is what is an appropriate key size. As
-mentioned earlier, a good guide is lacking. In general, per
-algorithm, a longer key compared to a shorter key is more difficult to
-discovery but takes longer to use. Longer keys can generally be used
-longer, but signing and verification are slower.
-
-The period of time in which a key should be used is an unknown
-quantity. This will likely be a decision based upon staffing, and on
-a calendar basis. Once a week is likely for zones requiring tight
-security, once a month for others.
-
-9 Random Numbers
-
-One easily overlooked issue is the source of random numbers. A good
-random number generator is needed to generate truly strong keys. In
-the worst case, a random number generator always returning the same
-number would result in the same pair of keys being generated. If a
-zone generates a pair of keys this way and an attacker gets hold of
-the same key generation software, it would be possible to discover the
-private key simply by generating a pair of keys. This, by the way,
-has already been observed in workshops.
-
-It is unfortunate that some current operating systems have poor random
-number generators. While this is improving, the machines used for key
-generation and use should be selected carefully.
-
-10 Dynamic Update
-
-Dynamic update raises an issue regarding the protection of private
-keys. As mentioned earlier, one threat is the exposure of the private
-key. This is possible of the private key is on the same machine as
-the name server, or even on any other reachable server. Therefore,
-conventional wisdom is to use non-network connected machines (perhaps
-behind a firewall) for all signing activity.
-
-Dynamic update requires the server to sign data submitted to it for a
-zone. This means the private key must be available to the name server
-(on the network).
-
-To counter this, a recommendation is offered to segregate dynamic
-update zones from static zones. This limits the risk to static data
-if a dynamic update zone key is exposed. In addition, some issues
-have been discovered with signed dynamic update zones, particularly
-the mechanism by which to refresh signatures, which also call for
-separating crucial static data from dynamic data.
-
-11 IANA Considerations
-
-This document does not place any requirements on the assigned numbers
-authority.
-
-12 Security Considerations
-
-This entire document is a note on security considerations. If the
-zone key is mishandled, in a way that compromises its security, then
-the security of its zone is compromised.
-
-13 References
-
-At some point.
-
-14 Author's Address
-
-Edward Lewis
-<lewis@tislabs.com>
-3060 Washington Rd (Rte 97)
-Glenwood, MD 21738
-+1(443)259-2352
-
-15 Acknowledgements
-
-The following individuals and groups have made significant input into
-the content of this document: the attendees of the NIC-SE work shop on
-DNSSEC, May 18 and 19, 1999, also Olafur Gudmundsson, and Brian
-Wellington.
-
-A second workshop held by the CAIRN research network September 29 and
-30th also provided input to this document. Dan Massey has provided
-input based upon this workshop and experience with DNSSEC in CAIRN.
-
-More workshops are to be acknowledged.
-
-16 Full Copyright Statement
-
-Copyright (C) The Internet Society (1999-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 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."
-
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-Edward Lewis NAI Labs
-Phone: +1 443-259-2352 Email: lewis@tislabs.com
-
-Dilbert is an optimist.
-
-Opinions expressed are property of my evil twin, not my employer.
-
-
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT David Conrad
-draft-ietf-dnsop-serverid-01.txt Nominum, Inc.
- November, 2002
-
- Identifying an Authoritative Name Server
-
-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
-
- A standardized mechanism to determine the identity of a name server
- responding to a particular query would be useful, particularly as a
- diagnostic aid. This document describes an identification convention
- used in one widely deployed implementation of the DNS protocol and
- proposes a slight modification to that convention aimed at addressing
- some implementation concerns.
-
-1. Introduction
-
- Determining the identity of the name server responding to a query has
- become more complex due primarily to the proliferation of various
- load balancing techniques. This document describes a convention used
- by one particular DNS server implementation to provide identifying
- information and proposes a slight modification to that convention to
- address concerns regarding implementation neutrality.
-
- Note that this document makes no value judgements as to whether or
- not the convention in current use is good or bad; it merely documents
-
-
-
-Expires May, 2003 [Page 1]
-\f
-draft-ietf-dnsop-serverid-01.txt May, 2002
-
-
- the covention's existence and proposes a slight redefinition of the
- convention to address non-technical implementation concerns.
-
-2. Rationale
-
- Identifying which name server is responding to queries is often
- useful, particularly in attempting to diagnose name server
- difficulties. However, relying on the IP address of the name server
- has become more problematic due the deployment of various load
- balancing solutions, including the use of shared unicast addresses as
- documented in [RFC3258].
-
- An unfortunate side effect of these load balancing solutions is that
- traditional methods of determining which server is responding can be
- unreliable. Specifically, non-DNS methods such as ICMP ping, TCP
- connections, or non-DNS UDP packets (e.g., as generated by tools such
- as "traceroute"), etc., can end up going to a different server than
- that which receives the DNS queries.
-
- This proposal makes the assumption that an identification mechanism
- that relies on the DNS protocol is more likely to be successful
- (although not guaranteed) in going to the same machine as a "normal"
- DNS query.
-
-3. Historical Conventions
-
- Recent versions of the commonly deployed Berkeley Internet Name
- Domain implementation of the DNS protocol suite from the Internet
- Software Consortium [BIND] support a way of identifying a particular
- server via the use of a standard, if somewhat unusual, DNS query.
- Specifically, a query to a late model 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 (defaulting to the value 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.
-
- 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 TXT RR for this name will return an administratively re-
- definable string which defaults to the version of the server
- responding.
-
-4. An Implementation Neutral Convention
-
- The previously described use of the CHAOS class "BIND." domain has
-
-
-
-Expires May, 2003 [Page 2]
-\f
-draft-ietf-dnsop-serverid-01.txt May, 2002
-
-
- (rightly) been viewed by many implementors as not being standardized
- nor being implementation neutral. As such, a standard mechanism to
- identify a particular machine among a shared unicast set of machines
- serving the same DNS data does not currently exist.
-
- Since a name server conforming to [RFC1034] and [RFC1035] should
- support the CHAOS class and the use of TXT resource record queries in
- the CHAOS class to derive information about a name server has been
- used in several independent name server implementations, the quickest
- way of supporting the identification of a particular name server out
- of a set of name servers all sharing the same unicast prefix would
- likely be to standardize on the BIND convention, albeit with a slight
- modification to address implementation neutrality concerns.
-
- The convention proposed here simply redefines the top level CHAOS
- domain to be "SERVER." instead of "BIND.". Since using the actual
- hostname may be considered an information leakage security risk, the
- use of the actual hostname of the server is discouraged and instead a
- unique per-server identifier should be used. As the BIND convention
- of "HOSTNAME" implies the use of a hostname, the domain name
- "ID.SERVER" is proposed. That is, a TXT RR query for "ID.SERVER." in
- the CHAOS class will return an administratively defined string that
- can be used to differentiate among multiple servers.
-
- To make this convention useful, DNS operators wishing to identify
- their servers uniquely MUST, for EACH server, put a unique string for
- the RDATA of the TXT record associated with the "ID.SERVER." domain
- in class CHAOS. For example, given two machines "a.example.com" and
- "b.example.com" that receive DNS queries at the same IP address, the
- name server administrator could include
-
- $ORIGIN SERVER.
- ID CH TXT "a"
-
- in the appropriate zone file on machine "a.example.com" and
-
- $ORIGIN SERVER.
- ID CH TXT "b"
-
- in the appropriate zone file on machine "b.example.com".
-
- Queries for TXT RRs of "id.server" in class CHAOS to the IP address
- serving both "a.example.com" and "b.example.com" should return "a" or
- "b" depending on which machine the query was routed.
-
- Implementors MUST provide a way to disable returning this identifying
- information. Implementors SHOULD provide a way to limit who can
- query for the identifying information.
-
-
-
-Expires May, 2003 [Page 3]
-\f
-draft-ietf-dnsop-serverid-01.txt May, 2002
-
-
- The use of other names in the CHAOS class "SERVER." domain are beyond
- the scope of this document.
-
-IANA Considerations
-
- The "SERVER." domain in the CHAOS class should be reserved by IANA
- and a registry should be created that reserves the "ID" name. In the
- future, requests may be submitted for other sub-domains of "SERVER.",
- e.g., "VERSION.SERVER." and the IANA should take appropriate action.
-
-Security Considerations
-
- Providing identifying information as to which server is responding
- can be seen as information leakage and thus a security risk. It may
- be appropriate to restrict who can query for the "ID.SERVER." domain.
- Filtering on source address would be one way in which restrictions
- can be applied.
-
- The identifer returned via an "ID.SERVER." query SHOULD NOT contain
- the hostname or other information that could be considered sensitive.
-
-Acknowledgements
-
- The technique for host identification documented here derive from
- practices implemented by Paul Vixie of the Internet Software
- Consortium in the Berkeley Internet Name Domain package. Useful
- comments on earlier drafts were provided by Bob Halley, Brian
- Wellington, Andreas Gustafsson, Ted Hardie, Chris Yarnell, and
- members of the ICANN Root Server System Advisory Council. Additional
- explanatory information provided due to questions received from Randy
- Bush.
-
-References
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specifications", RFC 1035, November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
- Shared Unicast Addresses", RFC 3258, April, 2002.
-
-Author's Address
-
-
-
-
-Expires May, 2003 [Page 4]
-\f
-draft-ietf-dnsop-serverid-01.txt May, 2002
-
-
- David Conrad
- Nominum, Inc.
- 2385 Bay Road
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6003
- Fax: +1 650 381 6055
- Email: david.conrad@nominum.com
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). 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."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May, 2003 [Page 5]
-\f
+++ /dev/null
-
-Internet Draft Johan Ihren
-draft-ietf-dnsop-v6-name-space-fragmentation-01.txt Autonomica AB
-March 2002
-Expires in six months
-
-
- IPv4-to-IPv6 migration and DNS namespace fragmentation
-
-
-Status of this Memo
-
- This memo provides information to the Internet community. It does
- no specify an Internet standard of any kind. This memo is still not
- in full conformance with all provisions of Section 10 of 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 memo documents some problems forseen in transitioning from a
- IPv4-only DNS hierarchy via a long period of mixture to an
- IPv6-mostly situation sometime in the future. The mixture period is
- expected to be very long, and hence design choices should very much
- take this into account, rather than just regard the transition as a
- relatively short period of pain.
-
- The main problem with transition that this paper focus on is what
- to do about the namespace fragmentation that may result from
- certain DNS data only being available over one type of transport
- (i.e. v4 or v6) which is thereby likely unavailable to hosts that
- can cannot utilize that transport.
-
- Two orthogonal issues are identified and discussed: deployment and
- use. The former while technically simple holds certain dangers that
- should be avoided. The "use" (as in performing DNS lookups) is much
- more complicated, and a suggested roadmap for this is presented.
-
-1. Terminology
-
- The key words "MUST", "SHALL", "REQUIRED", "SHOULD",
- "RECOMMENDED", and "MAY", when used un uppercase, in this document
- are to be interpreted as described in RFC 2119 [RFC2119].
-
- The phrase "v4 name server" indicates a name server available over
- IPv4 transport. It does not imply anything about what DNS data is
- served. Likewise, "v6 name server" indicates a name server
- available over IPv6 transport. In general this document only
- discuss transport issues and does not care exactly what is
- transported.
-
-
-2. Introduction to the problem of namespace fragmentation
-
- 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. This is not a scalable solution.
-
- 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 types of availability, depending on whether it is available
- only over IPv4 transport, only over IPv6 or both.
-
- The latter is the best situation, and a 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 namespace available to IPv4
- only hosts. I.e. during transition it is not acceptable to break
- the namespace that we presently have available for IPv4-only hosts.
-
-2.1. Namespace fragmentation vs. unreachability.
-
- Something that is presently not clear is whether it is actually
- necessary to provide access to the "Internet namespace" as defined
- by what is visble on the public v4 Internet also on v6 transport.
-
- The reason for the unclarity is that if one regards "the Internet"
- as the largest set of nodes that have a mutual 1-1 reachability for
- any pair of nodes over IP and adjust the "Internet namespace" to
- fit this set, then there is by definition no need to bridge or do
- any special tricks (since they can all reach each other anyhow).
-
- On the other hand, if we regard "the Internet" as the set of nodes
- that share a namespace that we can refer to as "the Internet
- namespace" regardless of whether they can all reach each other or
- not, then we have to ensure that this namespace is accessible to
- every node, regardless of its available transport.
-
- It is out of scope for this document to make a choice between the
- two alternatives, and therefore the rest of this document has to
- work from the assumption that the same namespace should, if
- possible, be made available to all nodes that claim to be part of
- the Internet.
-
-3. Consequences of deploying a "IPv6 root name server"
-
- If and when a root name server that is accessible over IPv6
- transport is deployed it will immediately for the first time become
- possible to change IPv6-only name servers to a "native
- configuration", i.e. to a configuration where they follow referrals
- directly from the root (which is now accessible to them because of
- the v6 transport).
-
- However, initially they will typically quite soon get a referral to
- a name server only available over IPv4 transport, and this will be
- impossible to follow, since there is no common transport available.
- Therefore the name it is trying to lookup will not get resolved and
- the result is that the v6-only name server cannot lookup the same
- set of domain names that its v4-only counterpart can.
-
- This is fragmentation of the namespace.
-
- Regardless of how this problem is handled it is important to
- realize that at first it will only concern the namespace as viewed
- from an IPv6-host. I.e. the IPv4 namespace will not (initially) be
- fragmented, and an important question is possibly how to keep it
- unfragmented.
-
-4. A taxonomy of alternatives to avoid fragmentation.
-
-4.1. Ignore the problem.
-
- It is possible to ignore the fragmentation issue. Whether that is
- an acceptable choice or not has to be very carefully considered. Is
- it reasonable to allow v4 only hosts to over time lose access to
- parts of the Internet namespace just because they are not
- "IPv6-aware"?
-
-4.2. DNS transport bridging.
-
- By providing some sort of "DNS transport bridging", i.e. create a
- fallback mechanism that enables a name server with only one type of
- transport to reach a name server only available over the other
- transport via some sort of proxy service it would be possible to
- unify the DNS zones available on each transport into a common
- namespace.
-
- The general consensus is that it is not possible to design such a
- bridging solution that works in both directions. However, it may be
- possible to design one that allows v6 clients to query v4 servers.
- See for instance [DNS-opreq] and [DNS-proxy] for more detailed
- discussions.
-
-4.3. Policy based avoidance of fragmentation.
-
- Today there are only a limited number of DNS zones on the public
- Internet that are only available over v6 transport, and they can
- mostly be regarded as "experimental". However, as soon as there is
- a root name server available over v6 transport it is reasonable to
- expect that it will become more common with v6-only zones over
- time.
-
- Such a development would erode the Internet namespace as viewed
- from an v4-only client. There are obviously strong reasons to find
- a mechanism to avoid this happening.
-
-4.3.1. Requirement of zone reachability over IPv4 transport.
-
- To ensure that all zones remain available over IPv4 transport one
- method would be to require that nameservers authoritative for a
- zone as part of the zone validation process ensure that there are
- IPv4 address records available for the name servers of any child
- delegations within the zone).
-
- I.e. the future policy could be:
-
- "Every delegation point delegated to nameservers available
- over v6 transport should have the same availability
- requirements for servers over both v4 and v6 transport as v4
- only zones have over v4 transport.
-
- I.e. if the parent requires "multiple nameservers" for a child,
- then the requirement becomes "multiple nameservers available over
- v4 transport plus multiple nameservers available over v6 transport"
-
- I.e. for given the domain EXAMPLE.COM with the following data
-
- $ORIGIN example.com.
- child.example.com. IN NS ns.example.com.
- child.example.com. IN NS dns.autonomica.se.
- ns.example.com. IN A 1.2.3.4
-
- the delegation of CHILD.EXAMPLE.COM is to the two name servers
- "ns.example.com" and "dns.autonomica.se". The first name server,
- "ns.example.com", obviously has an IPv4 address (as shown by the
- "glue" record on the last line).
-
- However, "ns.example.com" may have additional addresses assiciated
- with it. Also there is no way for the server loading the zone to
- know the address(es) of "dns.autonomica.se". Therefore, to find out
- all the publicly available addresses they have to be queried for.
-
- To ensure this the authoritative server will have to lookup the
- address records of the name servers that are part of any
- "delegation" points in the zone. However, this operation is very
- costly for large, delegation-dense zones and therefore it is likely
- that compromises a la
-
- * only validate on the master (this is likely always good practice)
-
- * validate as an offline process (i.e. not part of the zone loading)
-
- * only validate at time of delegation
-
- * never validate
-
- Clearly, as validation is relaxed the amount of errors will
- increase, so the sum of pain as usual remains mostly constant.
-
-4.3.2. Zone validation for non-recursive servers.
-
- Non-recursive authoritative servers are name servers that run
- without ever asking questions. A change in the zone validation
- requirements that force them to query for the addresses of name
- servers that are part of delegations in the zone change this, since
- they now have to query for these addresses.
-
- However, the main reason that it is important to be able to run
- without asking questions is to avoid "caching" possibly bogus
- answers. This need can be managed by requiring that a non recursive
- name server throw away the looked up address information after
- having used it for validation of the delegations in the zone.
-
-4.3.3. Future requirement of zone reachability over IPv6 transport.
-
- The immediate need for clarified policies for delegation is to
- ensure that IPv4 namespace does not start to fragment. Over time,
- however, it is reasonable to expect that it may become important to
- add a similar requirement to IPv6 namespace.
-
- I.e. an even more refined policy possible at some point in the
- future would be:
-
- "Every delegation point should have at least one name server
- for the child zone reachable over IPv4 transport (i.e. should
- have an A record) and at least one name server reachable over
- IPv6 transport (i.e. should have e.g. an AAAA record)".
-
-4.3.4. Implementation issues for new zone validation requirements.
-
- Exactly what action should be taken when a zone does not validate
- is not immediately clear. Immediate alternatives include:
-
- a) fail the entire parent zone (the extreme case, not suggested)
-
- b) load the zone but remove the delegation that failed validation
- (also drastic, and not suggested)
-
- c) load the entire zone but issue a warning message about the
- delegation that failed validation (more reasonable)
-
- Implementations should make it configurable what action to take. In
- the case of registries that have a business realtion to the child
- zone it is also in principle possible to work on the deployment of
- child zones over v6 transport by cost diffentiation for the
- customer.
-
-5. Overview of suggested transition method.
-
- By following the steps outlined below it will be possible to
- transition without outages or lack of service. The assumption is
- that the site has only v4 name servers or possibly v4 name servers
- plus v6 name server in a forwarding configuration. All DNS data is
- on the v4 name servers.
-
- 1) Do not change the method of resolution on any (recursive) name
- server. I.e. v4 servers go to the root and follow referrals
- while v6 servers go to their translator/forwarder which lookup
- the name and return the end result.
-
- 2) Start serving authoritative DNS data on v6 transport by
- providing name servers with v6 transport serving the zones. Add
- v6 address information to to the zones and as glue at the parent
- zone. Note that it is of crucial importance that the zone should
- have the same contents regardless of whether it is the v4
- version or the v6 version. Anything else will lead to confusion.
-
- 4) Wait for the announcement of the DNS root zone being available
- from a v6 name server.
-
- 5) Ensure that the entire path from the root down to the domain in
- question is reachable over both IPv4 and IPv6 transport.
-
- When this is accomplished it it possible to begin a migration of
- the lookup of selected services to be available over IPv6
- (i.e. typically by adding a IPv6 address record, eg. AAAA record,
- for a server of some sort).
-
-6. Security Considerations
-
- Much of the security of the Internet relies, often wrongly, but
- still, on the DNS. Thus, changes to the characteristics of the DNS
- may impact the security of Internet based services.
-
- Although it will be avoided, there may be unintended consequences
- as a result of operational deployment of RR types and protocols
- already approved by the IETF. When or if such consequences are
- identified, appropriate feedback will be provided to the IETF and
- the operational community on the efficacy of said interactions.
-
-7. Summary.
-
- The namespace fragmentation problem is identified and examined at
- some length.
-
- A solution based upon a change in the validation method of
- delegation points is suggested. This will both help keep the v4
- namespace unfragmented and may also help speed up deployment of
- DNS hierarchy in v6 space.
-
-
-
-9. References
-
- [RFC1034] Domain names - concepts and facilities.
- P.V. Mockapetris.
-
- [RFC1035] Domain names - implementation and specification.
- P.V. Mockapetris.
-
- [RFC2826] IAB Technical Comment on th Unique DNS Root
-
- [DNS-proxy] draft-durand-dns-proxy-00.txt
- Alain Durand
-
- [DNS-opreq] draft-ietf-ngtrans-dns-ops-req-02.txt
- Alain Durand
-
-
-A. Authors' Address
-
-Johan Ihren
-Autonomica
-Bellmansgatan 30
-SE-118 47 Stockholm, Sweden
-johani@autonomica.se
Mark Foster
Internet Draft Tom McGarry
-Document: <draft-ietf-enum-e164-gstn-np-03.txt> James Yu
+Document: <draft-ietf-enum-e164-gstn-np-05.txt> James Yu
NeuStar, Inc.
-Category: Informational March 1, 2001
+Category: Informational June 24, 2002
Number Portability in the GSTN: An Overview
implementations, are relevant topics for numerous areas of IP
telephony work-in-progress at IETF.
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 1]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+Foster,McGarry,Yu Expired on December 23, 2002 [Page 1]
+\f
+Number Portability in the GSTN: An Overview June 24, 2002
+
Table of Contents
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 ............ 18
+ 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 ....................................... 25
+ 12. Normative References ....................................... 24
13. Informative References ..................................... 25
- 14. Acknowledgement ............................................ 26
- 15. AuthorsÆ Addresses ......................................... 26
+ 14. Acknowledgement ............................................ 25
+ 15. AuthorsË Addresses ......................................... 25
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-
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 2]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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
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
+ 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
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
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 3]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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.
IN Intelligent Network
INAP Intelligent Network Application Part
INP Interim NP
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 4]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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-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
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
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 5]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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
phone number is called service provider portability (SPNP) also
known as "operator portability."
- The ability to change the subscriberÆs fixed service location while
+ 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
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 August 31, 2002 [Page 6]
-Number Portability in the GSTN: An Overview March 1, 2002
-
+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
Section 6.
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 7]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+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.
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 August 31, 2002 [Page 8]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+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
(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 August 31, 2002 [Page 9]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+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
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
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 10]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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
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 the first number out of an NPA+NXX
- code is ported out to another switch, that NPA+NXX is called
- "portable NPA+NXX."
+ 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
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 is ported or
- not. The other version is to check whether the dialed directory
- number belongs to any portable number range. 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.
+ 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
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 August 31, 2002 [Page 11]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+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
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 August 31, 2002 [Page 12]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+
+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
5.2 Europe
- One of the following three interfaces can be used to query an NPDB:
+ 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 ITU-TS MTP Levels 1 through 3, ITU-TS SCCP,
and ITU-TS TCAP.
- (c) ISUP triggerless translation. NP translations are performed
- transparently to the switching network by the signaling network
- (e.g. 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.
-
-
- Wireline switches have the choice of using either (a), (b), or (c);
+ 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
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
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 13]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
dialed wireless directory number has been ported out or not. In
this case, the interface to the internal NPDB is not subject to
standardization.
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
that has the routing information and is ready to route the call.
A number of triggering schemes may be employed that determine where
- in the call path the NPDB query is performed. In the U.S. an ôN-1ö
+ 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
the North America is very often referred to as the LRN scheme or
method.
-
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 14]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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
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
6.2 Europe
- In Europe, 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
-
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 15]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
- in the ISUP CdPN parameter to route the call to the New/Current
- Serving Network.
+ 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,
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.
- In addition to the addition of the routing prefix to the CdPN
- parameter, some other information may be added/modified as is listed
- in the draft ITU-T Recommendation Q.769.1 [ISUP]. Those
- enhancements in the ISUP to support number portability are briefly
- described below.
-
- Three methods can be used to transport the Directory Number (DN) and
- the Routing Number (RN):
+ 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 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.
- Spain uses "XXXXXX" as the routing prefix to identify the new
- serving network and uses a new NOA value of 126.
+ 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
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 16]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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
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 never passed across the national
- boundaries. For example, a UK routing prefix can only be used in
- UK, and would cause routing problem if it appears outside UK.
+ 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.
an internal NPDB is queried to retrieve the RN that then is
concatenated with the DN in the CdPN parameter.
- If 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.
+ 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.
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 17]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
7. NP Implementations for Geographic E.164 Numbers
+-------------+----------------------------------------------------+
+ 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 +
+-------------+----------------------------------------------------+
+ Austria + Uses onward routing at the donor network. Routing +
+ + prefix is "86xx" where "xx" identifies the +
- + + recipient switch. +
+ + + recipient network. +
+-------------+----------------------------------------------------+
+ Belgium + ACQ selected by the industry. Routing prefix is +
+ + "Cxxxx" where "xxxx" identifies the recipient +
+ 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 becomes technically +
+ + + to December 31, 1999 when NP became technically +
+ + possible. Regulator has not yet issued regulations +
+ + concerning this matter. +
+-------------+----------------------------------------------------+
+ France + Uses onward routing. Routing prefix is "Z0xxx" +
+ + where "xxx" identifies the recipient switch. +
+-------------+----------------------------------------------------+
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 18]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+ Germany + The originating network needs to do necessary +
+ + rerouting. Operators decide their own solution(s).+
+ + Deutsche Telekom uses ACQ. Routing prefix is +
+-------------+----------------------------------------------------+
+ 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. +
+ 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 +
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 19]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+ + network. But operators decide NP scheme to use. +
+ + Telia uses onward routing between operators. +
+-------------+----------------------------------------------------+
+ + 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. +
+-------------+----------------------------------------------------+
Porting the sub-blocks from the block holder enables block pooling.
Using the example above operator A is the block holder, as well as,
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 20]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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
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
- 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
+ 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
- complicate to deal with in a global environment. If an entity in
+ 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.
-
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 21]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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
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.
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. If the called directory is +1-
- 202-533-1234, and its associated routing number is +1-202-544-0000,
- the "tel" URL may look like tel:+1-202-533-1234;rn=+1-202-544-
- 0000;npdi=yes where "rn" stands for "routing number" and "npdi"
- stands for "NPDB dip indicator." "rn" and "npdi" will be two new
- parameters to be added as extensions to the "tel" URL to support NP.
- Since the "fax" URL is similar to the "tel" URL where NP can impact
- the fax calls as well as the telephone calls, the same extensions to
- the "tel" URL need to be applied to the "fax" URL as well. Please
- see [TELNP] for the proposed extensions to the "tel" URL to support
- NP and freephone service. Those extensions to the "tel" and "fax"
- URLs will be automatically supported by SIP because they can be
-
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 22]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
- carried as the optional parameters in the user portion of the "sip"
- 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
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 in the SIP INVITE message, it instead of
- the called directory number should be used for making routing
- decisions. If "rn" is not present, then the dialed directory number
- can be used as the routing number for making routing decisions.
+ 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
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 and collect the complete
+ 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
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
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 23]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
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 wireless networks), their ENUM records must be
+ 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
replace those from the old telephony service provider. To avoid the
NP impact on ENUM, it is recommended that the telephony service
providers use a different domain tree for their network-related
- service. For example, if e164.arpa is chosen for ôend userö ENUM, a
- domain tree different from e164.arpa should be used for ôcarrierö
+ 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
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
10. Security Considerations
This document does not raise any security issues.
-
11. IANA Considerations
This document introduces no new values for IANA registration.
-
-
-
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 24]
-Number Portability in the GSTN: An Overview March 1, 2002
-
12. Normative References
[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.
- [ISUP] ITU-T COM 11-R 162-E, Draft Recommendation Q.769.1,
- "Signaling System No. 7 - ISDN User Part Enhancements for the
- Support of Number Portability," May 1999.
+ [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 -
+ ISDN User Part Enhancements for the Support of Number
+ Portability," December 1999.
- [MNP] Draft GSM 03.66 V7.2.0 (1999-11) European Standard
+ [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
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-
- 02.txt, "URIs for Telephone Calls," February 17, 2002.
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 25]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+ 04.txt, "URIs for Telephone Calls," May 24, 2002.
- [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-08.txt, "SIP:
- Session Initiation Protocol," February 21, 2002.
-
- [TELNP] J. Yu, draft-yu-tel-url-04.txt, "Extensions to the "tel" and
- "fax" URLs to support Number Portability and Freephone
- Service," March 1, 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
- reference information on ISUP and MNP.
+ information on ISUP and MNP.
15. Authors' Addresses
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
Fax: +1-202-533-2987
Email: james.yu@neustar.biz
-
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 26]
-Number Portability in the GSTN: An Overview March 1, 2002
-
-
+
+
Full Copyright Statement
"Copyright (C) The Internet Society (2002). All Rights Reserved.
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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-Foster,McGarry,Yu Expired on August 31, 2002 [Page 27]
\ No newline at end of file
+Foster,McGarry,Yu Expired on August 31, 2002 [Page 27]
+\f
\ No newline at end of file
+++ /dev/null
-
-
-IPng Working Group Richard Draves
-Internet Draft Microsoft Research
-Document: draft-ietf-ipngwg-default-addr-select-06.txt September 28, 2001
-Category: Standards Track
-
- Default Address Selection for IPv6
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026 [1].
-
- 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 describes two algorithms, for source address selection
- and for destination address selection. The algorithms specify
- default behavior for all IPv6 implementations. They do not override
- choices made by applications or upper-layer protocols, nor do they
- preclude the development of more advanced mechanisms for address
- selection. The two algorithms share a common framework, including an
- optional mechanism for allowing administrators to provide policy
- that can override the default behavior. In dual stack
- implementations, the framework allows the destination address
- selection algorithm to consider both IPv4 and IPv6 addresses -
- depending on the available source addresses, the algorithm might
- prefer IPv6 addresses over IPv4 addresses, or vice-versa.
-
- All IPv6 nodes, including both hosts and routers, must implement
- default address selection as defined in this specification.
-
-1. Introduction
-
- The IPv6 addressing architecture [2] allows multiple unicast
- addresses to be assigned to interfaces. These addresses may have
- different reachability scopes (link-local, site-local, or global).
- These addresses may also be "preferred" or "deprecated" [3]. Privacy
- considerations have introduced the concepts of "public addresses"
-
-Draves Standards Track - Expires April 2002 1 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- and "temporary addresses" [4]. The mobility architecture introduces
- "home addresses" and "care-of addresses" [5]. In addition, multi-
- homing situations will result in more addresses per node. For
- example, a node may have multiple interfaces, some of them tunnels
- or virtual interfaces, or a site may have multiple ISP attachments
- with a global prefix per ISP.
-
- The end result is that IPv6 implementations will very often be faced
- with multiple possible source and destination addresses when
- initiating communication. It is desirable to have default
- algorithms, common across all implementations, for selecting source
- and destination addresses so that developers and administrators can
- reason about and predict the behavior of their systems.
-
- Furthermore, dual or hybrid stack implementations, which support
- both IPv6 and IPv4, will very often need to choose between IPv6 and
- IPv4 when initiating communication. For example, when DNS name
- resolution yields both IPv6 and IPv4 addresses and the network
- protocol stack has available both IPv6 and IPv4 source addresses. In
- such cases, a simple policy to always prefer IPv6 or always prefer
- IPv4 can produce poor behavior. As one example, suppose a DNS name
- resolves to a global IPv6 address and a global IPv4 address. If the
- node has assigned a global IPv6 address and a 169.254/16 auto-
- configured IPv4 address [6], then IPv6 is the best choice for
- communication. But if the node has assigned only a link-local IPv6
- address and a global IPv4 address, then IPv4 is the best choice for
- communication. The destination address selection algorithm solves
- this with a unified procedure for choosing among both IPv6 and IPv4
- addresses.
-
- This document specifies source address selection and destination
- address selection separately, but using a common framework so that
- together the two algorithms yield useful results. The algorithms
- attempt to choose source and destination addresses of appropriate
- scope and configuration status (preferred or deprecated).
- Furthermore, this document suggests a preferred method, longest
- matching prefix, for choosing among otherwise equivalent addresses
- in the absence of better information.
-
- The framework also has policy hooks to allow administrative override
- of the default behavior. For example, using these hooks an
- administrator can specify a preferred source prefix for use with a
- destination prefix, or prefer destination addresses with one prefix
- over addresses with another prefix. These hooks give an
- administrator flexibility in dealing with some multi-homing and
- transition scenarios, but they are certainly not a panacea.
-
- The selection rules specified in this document MUST NOT be construed
- to override an application or upper-layer's explicit choice of a
- legal destination or source address.
-
-
-
-
-Draves Standards Track - Expires April 2002 2 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
-1.1. Conventions used 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. Framework
-
- Our framework for address selection derives from the most common
- implementation architecture, which separates the choice of
- destination address from the choice of source address. Consequently,
- the framework specifies two separate algorithms for these tasks. The
- algorithms are designed to work well together and they share a
- mechanism for administrative policy override.
-
- In this implementation architecture, applications use APIs [8] like
- getaddrinfo() that return a list of addresses to the application.
- This list might contain both IPv6 and IPv4 addresses (sometimes
- represented as IPv4-mapped addresses). The application then passes a
- destination address to the network stack with connect() or sendto().
- The application might use only the first address in the list, or it
- might loop over the list of addresses to find a working address. In
- any case, the network layer is never in a situation where it needs
- to choose a destination address from several alternatives. The
- application might also specify a source address with bind(), but
- often the source address is left unspecified. Therefore the network
- layer does often choose a source address from several alternatives.
-
- As a consequence, we intend that implementations of getaddrinfo()
- will use the destination address selection algorithm specified here
- to sort the list of IPv6 and IPv4 addresses that they return.
- Separately, the IPv6 network layer will use the source address
- selection algorithm when an application or upper-layer has not
- specified a source address. Application of this framework to source
- address selection in an IPv4 network layer may be possible but this
- is not explored further here.
-
- Well-behaved applications should iterate through the list of
- addresses returned from getaddrinfo() until they find a working
- addresses.
-
- The algorithms use several criteria in making their decisions. The
- combined effect is to prefer destination/source address pairs for
- which the two addresses are of equal scope or type, prefer smaller
- scopes over larger scopes for the destination address, prefer non-
- deprecated source addresses, avoid the use of transitional addresses
- when native addresses are available, and all else being equal prefer
- address pairs having the longest possible common prefix. For source
- address selection, public addresses [4] are preferred over temporary
- addresses. In mobile situations [5], home addresses are preferred
- over care-of addresses. If an address is simultaneously a home
- address and a care-of address (indicating the mobile node is "at
- home" for that address), then the home/care-of address is preferred
-
-Draves Standards Track - Expires April 2002 3 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- over addresses that are solely a home address or solely a care-of
- address.
-
- The framework optionally allows for the possibility of
- administrative configuration of policy that can override the default
- behavior of the algorithms. The policy override takes the form of a
- configurable table that specifies precedence values and preferred
- source prefixes for destination prefixes. If an implementation is
- not configurable, or if an implementation has not been configured,
- then the default policy table specified in this document SHOULD be
- used.
-
-2.1. Scope Comparisons
-
- Multicast destination addresses have a 4-bit scope field that
- controls the propagation of the multicast packet. The IPv6
- addressing architecture defines scope field values for interface-
- local (0x1), link-local (0x2), subnet-local (0x3), admin-local
- (0x4), site-local (0x5), organization-local (0x8), and global (0xE)
- scopes [9].
-
- Use of the source address selection algorithm in the presence of
- multicast destination addresses requires the comparison of a unicast
- address scope with a multicast address scope. We map unicast link-
- local to multicast link-local, unicast site-local to multicast site-
- local, and unicast global scope to multicast global scope. For
- example, unicast site-local is equal to multicast site-local, which
- is smaller than multicast organization-local, which is smaller than
- unicast global, which is equal to multicast global.
-
- We write Scope(A) to mean the scope of address A. For example, if A
- is a link-local unicast address and B is a site-local multicast
- address, then Scope(A) < Scope(B).
-
- This mapping implicitly conflates unicast site boundaries and
- multicast site boundaries [9].
-
-2.2. IPv4 Addresses and IPv4-Mapped Addresses
-
- The destination address selection algorithm operates on both IPv6
- and IPv4 addresses. For this purpose, IPv4 addresses should be
- represented as IPv4-mapped addresses [2]. For example, to lookup the
- precedence or other attributes of an IPv4 address in the policy
- table, lookup the corresponding IPv4-mapped IPv6 address.
-
- IPv4 addresses are assigned scopes as follows. IPv4 auto-
- configuration addresses [6], which have the prefix 169.254/16, are
- assigned link-local scope. IPv4 private addresses [10], which have
- the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site-
- local scope. IPv4 loopback addresses [11, section 4.2.2.11], which
- have the prefix 127/8, are assigned link-local scope (analogously to
- the treatment of the IPv6 loopback address [9, section 4]). Other
- IPv4 addresses are assigned global scope.
-
-Draves Standards Track - Expires April 2002 4 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- IPv4 addresses should be treated as having "preferred" configuration
- status.
-
-2.3. IPv6 Addresses with Embedded IPv4 Addresses
-
- IPv4-compatible addresses [2] and 6to4 addresses [12] contain an
- embedded IPv4 address. For the purposes of this document, these
- addresses should be treated as having global scope.
-
- IPv4-compatible addresses should be treated as having "preferred"
- configuration status.
-
-2.4. Loopback Address and Other Format Prefixes
-
- The loopback address should be treated as having link-local
- scope [9, section 4] and "preferred" configuration status.
-
- NSAP addresses and other addresses with as-yet-undefined format
- prefixes should be treated as having global scope and "preferred"
- configuration status. Later standards may supersede this treatment.
-
-2.5. Policy Table
-
- The policy table is a longest-matching-prefix lookup table, much
- like a routing table. Given an address A, a lookup in the policy
- table produces two values: a precedence value Precedence(A) and a
- classification or label Label(A).
-
- The precedence value Precedence(A) is used for sorting destination
- addresses. If Precedence(A) > Precedence(B), we say that address A
- has higher precedence than address B, meaning that our algorithm
- will prefer to sort destination address A before destination address
- B.
-
- The label value Label(A) allows for policies that prefer a
- particular source address prefix for use with a destination address
- prefix. The algorithms prefer to use a source address S with a
- destination address D if Label(S) = Label(D).
-
- IPv6 implementations SHOULD support configurable address selection
- via a mechanism at least as powerful as the policy tables defined
- here. If an implementation is not configurable or has not been
- configured, then it SHOULD operate according to the algorithms
- specified here in conjunction with the following default policy
- table:
-
- Prefix Precedence Label
- ::1/128 50 0
- ::/0 40 1
- 2002::/16 30 2
- ::/96 20 3
- ::ffff:0:0/96 10 4
-
-
-Draves Standards Track - Expires April 2002 5 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
-
- One effect of the default policy table is to prefer using native
- source addresses with native destination addresses, 6to4 [12] source
- addresses with 6to4 destination addresses, and v4-compatible [2]
- source addresses with v4-compatible destination addresses. Another
- effect of the default policy table is to prefer communication using
- IPv6 addresses to communication using IPv4 addresses, if matching
- source addresses are available.
-
- Policy table entries for scoped address prefixes MAY be qualified
- with an optional zone index. If so, a prefix table entry only
- matches against an address during a lookup if the zone index also
- matches the address's zone index.
-
-2.6. Common Prefix Length
-
- We define the common prefix length CommonPrefixLen(A, B) of two
- addresses A and B as the length of the longest prefix (looking at
- the most significant, or leftmost, bits) that the two addresses have
- in common. It ranges from 0 to 128.
-
-3. Candidate Source Addresses
-
- The source address selection algorithm uses the concept of a
- "candidate set" of potential source addresses for a given
- destination address. We write CandidateSource(A) to denote the
- candidate set for the address A.
-
- It is RECOMMENDED that the candidate source addresses be the set of
- unicast addresses assigned to the interface that will be used to
- send to the destination. (The "outgoing" interface.) On routers, the
- candidate set MAY include unicast addresses assigned to any
- interface that forwards packets, subject to the restrictions
- described below.
-
- Discussion: The Neighbor Discovery Redirect mechanism [13]
- requires that routers verify that the source address of a packet
- identifies a neighbor before generating a Redirect, so it is
- advantageous for hosts to choose source addresses assigned to the
- outgoing interface. Implementations that wish to support the use
- of global source addresses assigned to a loopback interface should
- behave as if the loopback interface originates and forwards the
- packet.
-
- In some cases the destination address may be qualified with a zone
- index or other information that will constrain the candidate set.
-
- For multicast and link-local destination addresses, the set of
- candidate source addresses MUST only include addresses assigned to
- interfaces belonging to the same link as the outgoing interface.
-
-
-
-
-Draves Standards Track - Expires April 2002 6 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- Discussion: The restriction for multicast destination addresses is
- necessary because currently-deployed multicast forwarding
- algorithms use Reverse Path Forwarding (RPF) checks.
-
- For site-local destination addresses, the set of candidate source
- addresses MUST only include addresses assigned to interfaces
- belonging to the same site as the outgoing interface.
-
- In any case, anycast addresses, multicast addresses, and the
- unspecified address MUST NOT be included in a candidate set.
-
- If an application or upper-layer specifies a source address that is
- not in the candidate set for the destination, then the network layer
- MUST treat this is an error. The specified source address may
- influence the candidate set, by affecting the choice of outgoing
- interface. If the application or upper-layer specifies a source
- address that is in the candidate set for the destination, then the
- network layer MUST respect that choice. If the application or upper-
- layer does not specify a source address, then the network layer uses
- the source address selection algorithm specified in the next
- section.
-
-4. Source Address Selection
-
- The source address selection algorithm chooses a source address for
- use with a destination address D. It is specified here in terms of
- the pair-wise comparison of addresses SA and SB. The pair-wise
- comparison can be used to select an address from the set
- CandidateSource(D).
-
- This source address selection algorithm only applies to IPv6
- destination addresses, not IPv4 addresses.
-
- The pair-wise comparison consists of eight rules, which should be
- applied in order. If a rule chooses an address, then the remaining
- rules are not relevant and should be ignored. Subsequent rules act
- as tie-breakers for earlier rules. If the eight rules fail to choose
- an address, some unspecified tie-breaker should be used.
-
- Rule 1: Prefer same address.
- If SA = D, then choose SA. Similarly, if SB = D, then choose SB.
-
- Rule 2: Prefer appropriate scope.
- If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then choose SB
- and otherwise choose SA.
- Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then
- choose SA and otherwise choose SB.
-
- Rule 3: Avoid deprecated addresses.
- The addresses SA and SB have the same scope. If one of the source
- addresses is "preferred" and one of them is "deprecated", choose the
- one that is preferred.
-
-
-Draves Standards Track - Expires April 2002 7 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- Rule 4: Prefer home addresses.
- If SA is simultaneously a home address and care-of address and SB is
- not, then prefer SA. Similarly, if SB is simultaneously a home
- address and care-of address and SA is not, then prefer SB.
- If SA is just a home address and SB is just a care-of address, then
- prefer SA. Similarly, if SB is just a home address and SA is just a
- care-of address, then prefer SB.
- An implementation may support a per-connection configuration
- mechanism (for example, a socket option) to reverse the sense of
- this preference and prefer care-of addresses over home addresses.
-
- Rule 5: Prefer outgoing interface.
- If SA is assigned to the interface that will be used to send to D
- and SB is assigned to a different interface, then prefer SA.
- Similarly, if SB is assigned to the interface that will be used to
- send to D and SA is assigned to a different interface, then prefer
- SB.
-
- Rule 6: Prefer matching label.
- If Label(SA) = Label(D) and Label(SB) <> Label(D), then choose SA.
- Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then
- choose SB.
-
- Rule 7: Prefer public addresses.
- If SA is a public address and SB is a temporary address, then prefer
- SA. Similarly, if SB is a public address and SA is a temporary
- address, then prefer SB.
- An implementation may support a per-connection configuration
- mechanism (for example, a socket option) to reverse the sense of
- this preference and prefer temporary addresses over public
- addresses.
-
- This rule avoids applications potentially failing due to the
- relatively short lifetime of temporary addresses or due to the
- possibility of the reverse lookup of a temporary address either
- failing or returning a randomized name. Implementations for which
- privacy considerations outweigh these application compatibility
- concerns MAY reverse the sense of this rule and by default prefer
- temporary addresses over public addresses.
-
- Rule 8: Use longest matching prefix.
- If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA.
- Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
- choose SB.
-
- Rule 8 may be superseded if the implementation has other means of
- choosing among source addresses. For example, if the implementation
- somehow knows which source address will result in the "best"
- communications performance.
-
- Rule 2 (prefer appropriate scope) MUST be implemented and given high
- priority because it can affect interoperability.
-
-
-Draves Standards Track - Expires April 2002 8 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
-5. Destination Address Selection
-
- The destination address selection algorithm takes a list of
- destination addresses and sorts the addresses to produce a new list.
- It is specified here in terms of the pair-wise comparison of
- addresses DA and DB, where DA appears before DB in the original
- list.
-
- The algorithm sorts together both IPv6 and IPv4 addresses. To find
- the attributes of an IPv4 address in the policy table, the IPv4
- address should be represented as an IPv4-mapped address.
-
- We write Source(D) to indicate the selected source address for a
- destination D. For IPv6 addresses, the previous section specifies
- the source address selection algorithm. Source address selection for
- IPv4 addresses is not specified in this document.
-
- We say that Source(D) is undefined if there is no source address
- available for destination D. For IPv6 addresses, this is only the
- case if CandidateSource(D) is the empty set.
-
- The pair-wise comparison of destination addresses consists of ten
- rules, which should be applied in order. If a rule determines a
- result, then the remaining rules are not relevant and should be
- ignored. Subsequent rules act as tie-breakers for earlier rules.
-
- Rule 1: Avoid unusable destinations.
- If DB is known to be unreachable or if Source(DB) is undefined, then
- sort DA before DB. Similarly, if DA is known to be unreachable or if
- Source(DA) is undefined, then sort DB before DA.
-
- Discussion: An implementation may know that a particular
- destination is unreachable in several ways. For example, the
- destination may be reached through a network interface that is
- currently unplugged. For example, the implementation may retain
- for some period of time information from Neighbor Unreachability
- Detection [13]. In any case, the determination of unreachability
- for the purposes of this rule is implementation-dependent.
-
- Rule 2: Prefer matching scope.
- If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)),
- then sort DA before DB. Similarly, if Scope(DA) <> Scope(Source(DA))
- and Scope(DB) = Scope(Source(DB)), then sort DB before DA.
-
- Rule 3: Avoid deprecated addresses.
- If Source(DA) is deprecated and Source(DB) is not, then sort DB
- before DA. Similarly, if Source(DA) is not deprecated and Source(DB)
- is deprecated, then sort DA before DB.
-
-
-
-
-
-
-Draves Standards Track - Expires April 2002 9 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- Rule 4: Prefer home addresses.
- If Source(DA) is simultaneously a home address and care-of address
- and Source(DB) is not, then sort DA before DB. Similarly, if
- Source(DB) is simultaneously a home address and care-of address and
- Source(DA) is not, then sort DB before DA.
- If Source(DA) is just a home address and Source(DB) is just a care-
- of address, then sort DA before DB. Similarly, if Source(DA) is just
- a care-of address and Source(DB) is just a home address, then sort
- DB before DA.
-
- Rule 5: Prefer matching label.
- If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB),
- then sort DA before DB. Similarly, if Label(Source(DA)) <> Label(DA)
- and Label(Source(DB)) = Label(DB), then sort DB before DA.
-
- Rule 6: Prefer higher precedence.
- If Precedence(DA) > Precedence(DB), then sort DA before DB.
- Similarly, if Precedence(DA) < Precedence(DB), then sort DB before
- DA.
-
- Rule 7: Prefer native transport.
- If DA is reached via an encapsulating transition mechanism (eg, IPv6
- in IPv4) and DB is not, then sort DB before DA. Similarly, if DB is
- reached via encapsulation and DA is not, then sort DA before DB.
-
- Discussion: 6-over-4 [14], ISATAP [15], and configured
- tunnels [16] are examples of encapsulating transition mechanisms
- for which the destination address does not have a specific prefix
- and hence can not be assigned a lower precedence in the policy
- table. An implementation MAY generalize this rule by using a
- concept of interface preference, and giving virtual interfaces
- (like the IPv6-in-IPv4 encapsulating interfaces) a lower
- preference than native interfaces (like ethernet interfaces).
-
- Rule 8: Prefer smaller scope.
- If Scope(DA) < Scope(DB), then sort DA before DB. Similarly, if
- Scope(DA) > Scope(DB), then sort DB before DA.
-
- Rule 9: Use longest matching prefix.
- If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB,
- Source(DB)), then sort DA before DB. Similarly, if
- CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)),
- then sort DB before DA.
-
- Rule 10: Otherwise, leave the order unchanged.
- Sort DA before DB.
-
- Rules 9 and 10 may be superseded if the implementation has other
- means of sorting destination addresses. For example, if the
- implementation somehow knows which destination addresses will result
- in the "best" communications performance.
-
-
-
-Draves Standards Track - Expires April 2002 10 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
-6. Interactions with Routing
-
- This specification of source address selection assumes that routing
- (more precisely, selecting an outgoing interface on a node with
- multiple interfaces) is done before source address selection.
- However, implementations may use source address considerations as a
- tiebreaker when choosing among otherwise equivalent routes.
-
- For example, suppose a node has interfaces on two different links,
- with both links having a working default router. Both of the
- interfaces have preferred global addresses. When sending to a global
- destination address, if there's no routing reason to prefer one
- interface over the other, then an implementation may preferentially
- choose the outgoing interface that will allow it to use the source
- address that shares a longer common prefix with the destination.
-
- Implementations may also use the choice of router to influence the
- choice of source address. For example, suppose a host is on a link
- with two routers. One router is advertising a global prefix A and
- the other router is advertising global prefix B. Then when sending
- via the first router, the host may prefer source addresses with
- prefix A and when sending via the second router, prefer source
- addresses with prefix B.
-
-7. Implementation Considerations
-
- The destination address selection algorithm needs information about
- potential source addresses. One possible implementation strategy is
- for getaddrinfo() to call down to the network layer with a list of
- destination addresses, sort the list in the network layer with full
- current knowledge of available source addresses, and return the
- sorted list to getaddrinfo(). This is simple and gives the best
- results but it introduces the overhead of another system call. One
- way to reduce this overhead is to cache the sorted address list in
- the resolver, so that subsequent calls for the same name do not need
- to resort the list.
-
- Another implementation strategy is to call down to the network layer
- to retrieve source address information and then sort the list of
- addresses directly in the context of getaddrinfo(). To reduce
- overhead in this approach, the source address information can be
- cached, amortizing the overhead of retrieving it across multiple
- calls to getaddrinfo(). In this approach, the implementation may not
- have knowledge of the outgoing interface for each destination, so it
- MAY use a looser definition of the candidate set during destination
- address ordering.
-
- In any case, if the implementation uses cached and possibly stale
- information in its implementation of destination address selection,
- or if the ordering of a cached list of destination addresses is
- possibly stale, then it should ensure that the destination address
- ordering returned to the application is no more than one second out
- of date. For example, an implementation might make a system call to
-
-Draves Standards Track - Expires April 2002 11 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- check if any routing table entries or source address assignments
- that might affect these algorithms have changed. Another strategy is
- to use an invalidation counter that is incremented whenever any
- underlying state is changed. By caching the current invalidation
- counter value with derived state and then later comparing against
- the current value, the implementation could detect if the derived
- state is potentially stale.
-
-8. Security Considerations
-
- This document has no direct impact on Internet infrastructure
- security.
-
- Note that most source address selection algorithms, including the
- one specified in this document, expose a potential privacy concern.
- An unfriendly node can infer correlations among a target node's
- addresses by probing the target node with request packets that force
- the target host to choose its source address for the reply packets.
- (Perhaps because the request packets are sent to an anycast or
- multicast address, or perhaps the upper-layer protocol chosen for
- the attack does not specify a particular source address for its
- reply packets.) By using different addresses for itself, the
- unfriendly node can cause the target node to expose the target's own
- addresses.
-
-9. Examples
-
- This section contains a number of examples, first of default
- behavior and then demonstrating the utility of policy table
- configuration. These examples are provided for illustrative
- purposes; they should not be construed as normative.
-
-9.1. Default Source Address Selection
-
- The source address selection rules, in conjunction with the default
- policy table, produce the following behavior:
-
- Destination: 2001::1
- Sources: 3ffe::1 vs fe80::1
- Result: 3ffe::1 (prefer appropriate scope)
-
- Destination: 2001::1
- Sources: fe80::1 vs fec0::1
- Result: fec0::1 (prefer appropriate scope)
-
- Destination: fec0::1
- Sources: fe80::1 vs 2001::1
- Result: 2001::1 (prefer appropriate scope)
-
- Destination: ff05::1
- Sources: fe80::1 vs fec0::1 vs 2001::1
- Result: fec0::1 (prefer appropriate scope)
-
-
-Draves Standards Track - Expires April 2002 12 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- Destination: 2001::1
- Sources: 2001::1 (deprecated) vs 2002::1
- Result: 2001::1 (prefer same address)
-
- Destination: fec0::1
- Sources: fec0::2 (deprecated) vs 2001::1
- Result: fec0::2 (prefer appropriate scope)
-
- Destination: 2001::1
- Sources: 2001::2 vs 3ffe::2
- Result: 2001::2 (longest-matching-prefix)
-
- Destination: 2001::1
- Sources: 2001::2 (care-of address) vs 3ffe::2 (home address)
- Result: 3ffe::2 (prefer home address)
-
- Destination: 2002:836b:2179::1
- Sources: 2002:836b:2179::d5e3:7953:13eb:22e8 (temporary) vs 2001::2
- Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label)
-
- Destination: 2001::d5e3:0:0:1
- Sources: 2001::2 vs 2001::d5e3:7953:13eb:22e8 (temporary)
- Result: 2001::2 (prefer public address)
-
-9.2. Default Destination Address Selection
-
- The destination address selection rules, in conjunction with the
- default policy table and the source address selection rules, produce
- the following behavior:
-
- Sources: 2001::2 or fe80::1 or 169.254.13.78
- Destinations: 2001::1 vs 131.107.65.121
- Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
- 169.254.13.78) (prefer matching scope)
-
- Sources: fe80::1 or 131.107.65.117
- Destinations: 2001::1 vs 131.107.65.121
- Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src
- fe80::1) (prefer matching scope)
-
- Sources: 2001::2 or fe80::1 or 10.1.2.4
- Destinations: 2001::1 vs 10.1.2.3
- Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer
- higher precedence)
-
- Sources: 2001::2 or fec0::2 or fe80::2
- Destinations: 2001::1 vs fec0::1 vs fe80::1
- Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then
- 2001::1 (src 2001::2) (prefer smaller scope)
-
- Sources: 2001::2 (care-of address) or 3ffe::1 (home address) or
- fec0::2 (care-of address) or fe80::2 (care-of address)
- Destinations: 2001::1 vs fec0::1
-
-Draves Standards Track - Expires April 2002 13 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home
- address)
-
- Sources: 2001::2 or fec0::2 (deprecated) or fe80::2
- Destinations: 2001::1 vs fec0::1
- Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid
- deprecated addresses)
-
- Sources: 2001::2 or 3f44::2 or fe80::2
- Destinations: 2001::1 vs 3ffe::1
- Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest
- matching prefix)
-
- Sources: 2002:836b:4179::2 or fe80::2
- Destinations: 2002:836b:4179::1 vs 2001::1
- Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src
- 2002:836b:4179::2) (prefer matching label)
-
- Sources: 2002:836b:4179::2 or 2001::2 or fe80::2
- Destinations: 2002:836b:4179::1 vs 2001::1
- Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src
- 2002:836b:4179::2) (prefer higher precedence)
-
-9.3. Configuring Preference for IPv6 vs IPv4
-
- The default policy table gives IPv6 addresses higher precedence than
- IPv4 addresses. This means that applications will use IPv6 in
- preference to IPv4 when the two are equally suitable. An
- administrator can change the policy table to prefer IPv4 addresses
- by giving the ::ffff:0.0.0.0/96 prefix a higher precedence:
-
- Prefix Precedence Label
- ::1/128 50 0
- ::/0 40 1
- 2002::/16 30 2
- ::/96 20 3
- ::ffff:0:0/96 100 4
-
- This change to the default policy table produces the following
- behavior:
-
- Sources: 2001::2 or fe80::1 or 169.254.13.78
- Destinations: 2001::1 vs 131.107.65.121
- Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
- 169.254.13.78) (prefer matching scope)
-
- Sources: fe80::1 or 131.107.65.117
- Destinations: 2001::1 vs 131.107.65.121
- Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1
- (src fe80::1) (prefer matching scope)
-
-
-
-
-Draves Standards Track - Expires April 2002 14 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- Sources: 2001::2 or fe80::1 or 10.1.2.4
- Destinations: 2001::1 vs 10.1.2.3
- New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2)
- (prefer higher precedence)
-
-9.4. Configuring Preference for Scoped Addresses
-
- The destination address selection rules give preference to
- destinations of smaller scope. For example, a site-local destination
- will be sorted before a global scope destination when the two are
- otherwise equally suitable. An administrator can change the policy
- table to reverse this preference and sort global destinations before
- site-local destinations, and site-local destinations before link-
- local destinations:
-
- Prefix Precedence Label
- ::1/128 50 0
- ::/0 40 1
- fec0::/10 37 1
- fe80::/10 33 1
- 2002::/16 30 2
- ::/96 20 3
- ::ffff:0:0/96 10 4
-
- This change to the default policy table produces the following
- behavior:
-
- Sources: 2001::2 or fec0::2 or fe80::2
- Destinations: 2001::1 vs fec0::1 vs fe80::1
- New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then
- fe80::1 (src fe80::2) (prefer higher precedence)
-
- Sources: 2001::2 (deprecated) or fec0::2 or fe80::2
- Destinations: 2001::1 vs fec0::1
- Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2)
- (avoid deprecated addresses)
-
-9.5. Configuring a Multi-Homed Site
-
- Consider a site A that has a business-critical relationship with
- another site B. To support their business needs, the two sites have
- contracted for service with a special high-performance ISP. This is
- in addition to the normal Internet connection that both sites have
- with different ISPs. The high-performance ISP is expensive and the
- two sites wish to use it only for their business-critical traffic
- with each other.
-
- Each site has two global prefixes, one from the high-performance ISP
- and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48
- from the high-performance ISP and prefix 2007:0:aaaa::/48 from its
- normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high-
-
-
-
-Draves Standards Track - Expires April 2002 15 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All
- hosts in both sites register two addresses in the DNS.
-
- The routing within both sites directs most traffic to the egress to
- the normal ISP, but the routing directs traffic sent to the other
- site's 2001 prefix to the egress to the high-performance ISP. To
- prevent unintended use of their high-performance ISP connection, the
- two sites implement ingress filtering to discard traffic entering
- from the high-performance ISP that is not from the other site.
-
- The default policy table and address selection rules produce the
- following behavior:
-
- Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a
- Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b
- Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b
- (src 2001:aaaa:aaaa::a) (longest matching prefix)
-
- In other words, when a host in site A initiates a connection to a
- host in site B, the traffic does not take advantage of their
- connections to the high-performance ISP. This is not their desired
- behavior.
-
- Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a
- Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c
- Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then
- 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)
-
- In other words, when a host in site A initiates a connection to a
- host in some other site C, the reverse traffic may come back through
- the high-performance ISP. Again, this is not their desired behavior.
-
- This situation demonstrates the limitations of the longest-matching-
- prefix heuristic in multi-homed situations.
-
- However, the administrators of sites A and B can achieve their
- desired behavior via policy table configuration. For example, they
- can use the following policy table:
-
- Prefix Precedence Label
- ::1 50 0
- 2001:aaaa:aaaa::/48 45 5
- 2001:bbbb:bbbb::/48 45 5
- ::/0 40 1
- 2002::/16 30 2
- ::/96 20 3
- ::ffff:0:0/96 10 4
-
- This policy table produces the following behavior:
-
- Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a
- Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b
-
-
-Draves Standards Track - Expires April 2002 16 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then
- 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence)
-
- In other words, when a host in site A initiates a connection to a
- host in site B, the traffic uses the high-performance ISP as
- desired.
-
- Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a
- Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c
- New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then
- 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)
-
- In other words, when a host in site A initiates a connection to a
- host in some other site C, the traffic uses the normal ISP as
- desired.
-
-References
-
- 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP
- 9, RFC 2026, October 1996.
-
- 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
- RFC 2373, July 1998.
-
- 3 S. Thompson, T. Narten, "IPv6 Stateless Address Autoconfig-
- uration", RFC 2462 , December 1998.
-
- 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address
- Autoconfiguration in IPv6", RFC 3041, January 2001.
-
- 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-
- mobileip-ipv6-14.txt, July 2001.
-
- 6 S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local
- Addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt, July 2001.
-
- 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- 8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket
- Interface Extensions for IPv6", RFC 2553, March 1999.
-
- 9 S. Deering et. al, "IP Version 6 Scoped Address Architecture",
- draft-ietf-ipngwg-scoping-arch-02.txt, March 2001.
-
- 10 Y. Rekhter et. al, "Address Allocation for Private Internets",
- RFC 1918, February 1996.
-
- 11 F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC
- 1812, June 1995.
-
-
-
-
-Draves Standards Track - Expires April 2002 17 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
-
- 12 B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4
- Clouds", RFC 3056, February 2001.
-
- 13 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for
- IP Version 6", RFC 2461, December 1998.
-
- 14 B. Carpenter and C. Jung, "Transmission of IPv6 over IPv4 Domains
- without Explicit Tunnels", RFC 2529, March 1999.
-
- 15 F. Templin, "Intra-Site Automatic Tunnel Addressing Protocol
- (ISATAP)", draft-ietf-ngtrans-isatap-01.txt, May 2001.
-
- 16 R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6
- Hosts and Routers", RFC 1933, April 1996.
-
-Acknowledgments
-
- The author would like to acknowledge the contributions of the IPng
- Working Group, particularly Marc Blanchet, Brian Carpenter, Matt
- Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun
- Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Erik Nordmark, Ken
- Powell, Markku Savela, Pekka Savola, Dave Thaler, Mauro Tortonesi,
- Ole Troan, and Stig Venaas.
-
-Author's Address
-
- Richard Draves
- Microsoft Research
- One Microsoft Way
- Redmond, WA 98052
- Phone: +1 425 706 2268
- Email: richdr@microsoft.com
-
-Revision History
-
-Changes from draft-ietf-ipngwg-default-addr-select-05
-
- Clarified the first destination-address selection rule, avoiding
- unusable destination addresses.
-
- Added a new destination-address selection rule, to prefer native
- transport over transition mechanisms that use encapsulation.
-
-Changes from draft-ietf-ipngwg-default-addr-select-04
-
- Clarified candidate set formation for routers.
-
- Added some explanatory discussion to the candidate set section.
-
- Replaced usages of scope id with zone index.
-
-
-
-Draves Standards Track - Expires April 2002 18 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- Augmented the first destination-address selection rule, to avoid
- destination addresses for which the current next-hop neighbor is
- known to be unreachable.
-
-Changes from draft-ietf-ipngwg-default-addr-select-03
-
- Reversed the treatment of temporary addresses, so that unless an
- application specifies otherwise public addresses are preferred over
- temporary addresses.
-
- Added text clarifying our expectation that applications should
- iterate through the list of possible destination addresses until
- finding a working address.
-
- Removed references to getipnodebyname().
-
-Changes from draft-ietf-ipngwg-default-addr-select-02
-
- Changed scope treatment of IPv4-compatible and 6to4 addresses, so
- they are always considered to be global. Removed mention of IPX
- addresses.
-
- Changed home address rules to favor addresses that are
- simultaneously home and care-of addresses, over addresses that are
- just home addresses or just care-of addresses.
-
- Combined SrcLabel & DstLabel in the policy table into a single Label
- attribute.
-
- Added mention of the invalidation counter technique in the
- implementation section.
-
-Changes from draft-ietf-ipngwg-default-addr-select-01
-
- Added Examples section, demonstrating default behavior and some
- policy table configuration scenarios.
-
- Removed many uses of MUST. Remaining uses concern the candidate set
- of source addresses and the source address selection rule that
- prefers source addresses of appropriate scope.
-
- Simplified the default policy table. Reordered the source address
- selection rules to reduce the influence of policy labels. Added more
- destination address selection rules.
-
- Added scoping of v4-compatible and 6to4 addresses based on the
- embedded IPv4 address.
-
- Changed references to anonymous addresses to use the new term,
- temporary addresses.
-
- Clarified that a user-level implementation of destination address
- ordering, which does not have knowledge of the outgoing interface
-
-Draves Standards Track - Expires April 2002 19 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- for each destination, may use a looser definition of the candidate
- set.
-
- Clarified that an implementation should prevent an application or
- upper-layer from choosing a source address that is not in the
- candidate set and not prevent an application or upper-layer from
- choosing a source address that is in the candidate set.
-
- Miscellaneous editorial changes, including adding some missing
- references.
-
-Changes from draft-ietf-ipngwg-default-addr-select-00
-
- Changed the candidate set definition so that the strong host model
- is recommended but not required. Added a rule to source address
- selection to prefer addresses assigned to the outgoing interface.
-
- Simplified the destination address selection algorithm, by having it
- use source address selection as a subroutine.
-
- Added a rule to source address selection to handle anonymous/public
- addresses.
-
- Added a rule to source address selection to handle home/care-of
- addresses.
-
- Changed to allow destination address selection to sort both IPv6 and
- IPv4 addresses. Added entries in the default policy table for IPv4-
- mapped addresses.
-
- Changed default precedences, so v4-compatible addresses have lower
- precedence than 6to4 addresses.
-
-Changes from draft-draves-ipngwg-simple-srcaddr-01
-
- Added framework discussion.
-
- Added algorithm for destination address ordering.
-
- Added mechanism to allow the specification of administrative policy
- that can override the default behavior.
-
- Added section on routing interactions and TBD section on mobility
- interactions.
-
- Changed the candidate set definition for source address selection,
- so that only addresses assigned to the outgoing interface are
- allowed.
-
- Changed the loopback address treatment to link-local scope.
-
-
-
-
-Draves Standards Track - Expires April 2002 20 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
-Changes from draft-draves-ipngwg-simple-srcaddr-00
-
- Minor wording changes because DHCPv6 also supports "preferred" and
- "deprecated" addresses.
-
- Specified treatment of other format prefixes; now they are
- considered global scope, "preferred" addresses.
-
- Reiterated that anycast and multicast addresses are not allowed as
- source addresses.
-
- Recommended that source addresses be taken from the outgoing
- interface. Required this for multicast destinations. Added analogous
- requirements for link-local and site-local destinations.
-
- Specified treatment of the loopback address.
-
- Changed the second selection rule so that if both candidate source
- addresses have scope greater or equal than the destination address
- and only of them is preferred, the preferred address is chosen.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Draves Standards Track - Expires April 2002 21 \f
-draft-ietf-ipngwg-default-addr-select-06 September 28, 2001
-
-
- Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Draves Standards Track - Expires April 2002 22 \f
\ No newline at end of file
+++ /dev/null
-
-IPNG Working Group R.E. Gilligan
-INTERNET-DRAFT: draft-ietf-ipngwg-rfc2553bis-10.txt Cache Flow
-Obsoletes RFC 2553 S. Thomson
- Cisco
- J. Bound
- J. McCann
- Hewlett-Packard
- W. R. Stevens
- December 2002
-
-
- Basic Socket Interface Extensions for IPv6
-
- <draft-ietf-ipngwg-rfc2553bis-10.txt>
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- This document is a submission by the Internet Protocol IPv6 Working
- Group of the Internet Engineering Task Force (IETF). Comments should
- be submitted to the ipng@sunroof.eng.sun.com mailing list.
-
- 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
-
- The de facto standard application program interface (API) for TCP/IP
- applications is the "sockets" interface. Although this API was
- developed for Unix in the early 1980s it has also been implemented on
- a wide variety of non-Unix systems. TCP/IP applications written
- using the sockets API have in the past enjoyed a high degree of
- portability and we would like the same portability with IPv6
- applications. But changes are required to the sockets API to support
- IPv6 and this memo describes these changes. These include a new
- socket address structure to carry IPv6 addresses, new address
- conversion functions, and some new socket options. These extensions
- are designed to provide access to the basic IPv6 features required by
- TCP and UDP applications, including multicasting, while introducing a
- minimum of change into the system and providing complete
- compatibility for existing IPv4 applications. Additional extensions
- for advanced IPv6 features (raw sockets and access to the IPv6
- extension headers) are defined in another document [4].
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 1]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-Table of Contents:
-
-1. Introduction.................................................3
-2. Design Considerations........................................3
-2.1 What Needs to be Changed....................................4
-2.2 Data Types..................................................5
-2.3 Headers.....................................................5
-2.4 Structures..................................................5
-3. Socket Interface.............................................5
-3.1 IPv6 Address Family and Protocol Family.....................6
-3.2 IPv6 Address Structure......................................6
-3.3 Socket Address Structure for 4.3BSD-Based Systems...........6
-3.4 Socket Address Structure for 4.4BSD-Based Systems...........7
-3.5 The Socket Functions........................................8
-3.6 Compatibility with IPv4 Applications........................9
-3.7 Compatibility with IPv4 Nodes...............................9
-3.8 IPv6 Wildcard Address......................................10
-3.9 IPv6 Loopback Address......................................11
-3.10 Portability Additions.....................................11
-4. Interface Identification....................................13
-4.1 Name-to-Index..............................................14
-4.2 Index-to-Name..............................................14
-4.3 Return All Interface Names and Indexes.....................14
-4.4 Free Memory................................................15
-5. Socket Options..............................................15
-5.1 Unicast Hop Limit..........................................15
-5.2 Sending and Receiving Multicast Packets....................16
-5.3 IPV6_V6ONLY option for AF_INET6 Sockets....................18
-6. Library Functions...........................................18
-6.1 Protocol-Independent Nodename and Service Name Translation.19
-6.2 Socket Address Structure to Node Name and Service Name.....23
-6.3 Address Conversion Functions...............................25
-6.4 Address Testing Macros.....................................26
-7. Summary of New Definitions..................................27
-8. Security Considerations.....................................29
-Changes from RFC 2553..........................................29
-Acknowledgments................................................29
-References.....................................................30
-Authors' Addresses.............................................31
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 2]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-1. Introduction
-
-While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits long.
-The socket interface makes the size of an IP address quite visible to an
-application; virtually all TCP/IP applications for BSD-based systems
-have knowledge of the size of an IP address. Those parts of the API
-that expose the addresses must be changed to accommodate the larger IPv6
-address size. IPv6 also introduces new features (e.g., traffic class
-and flowlabel), some of which must be made visible to applications via
-the API. This memo defines a set of extensions to the socket interface
-to support the larger address size and new features of IPv6. It defines
-"basic" extensions that are of use to a broad range of applications. A
-companion document, the "advanced" API [4], covers extensions that are
-of use to more specialized applications, examples of which include
-routing daemons, and the "ping" and "traceroute" utilities.
-
-The development of this API was started in 1994 in the IETF IPng working
-group. The API has evolved over the years, published first in RFC 2133,
-then again in RFC 2553, and reaching its final form in this document.
-
-As the API matured and stabilized, it was incorporated into the Open
-Group's Networking Services (XNS) specification, issue 5.2, which was
-subsequently incorporated into a joint Open Group/IEEE/ISO standard [3].
-
-Effort has been made to ensure that this document and [3] contain the
-same information with regard to the API definitions. However, the
-reader should note that this document is for informational purposes
-only, and that the official standard specification of the sockets API is
-[3].
-
-It is expected that any future standardization work on this API would be
-done by the Open Group Base Working Group [6].
-
-It should also be noted that this document describes only those portions
-of the API needed for IPv4 and IPv6 communications. Other potential
-uses of the API, for example the use of getaddrinfo() and getnameinfo()
-with the AF_UNIX address family, are beyond the scope of this document.
-
-
-
-2. Design Considerations
-
-There are a number of important considerations in designing changes to
-this well-worn API:
-
- - The API changes should provide both source and binary
- compatibility for programs written to the original API. That
- is, existing program binaries should continue to operate when
- run on a system supporting the new API. In addition, existing
- applications that are re-compiled and run on a system supporting
- the new API should continue to operate. Simply put, the API
- changes for IPv6 should not break existing programs. An additional
- mechanism for implementations to verify this is to verify the new
- symbols are protected by Feature Test Macros as described in [3].
- (Such Feature Test Macros are not defined by this RFC.)
-
- - The changes to the API should be as small as possible in order
- to simplify the task of converting existing IPv4 applications to
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 3]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- IPv6.
-
- - Where possible, applications should be able to use this
- API to interoperate with both IPv6 and IPv4 hosts. Applications
- should not need to know which type of host they are
- communicating with.
-
- - IPv6 addresses carried in data structures should be 64-bit
- aligned. This is necessary in order to obtain optimum
- performance on 64-bit machine architectures.
-
-Because of the importance of providing IPv4 compatibility in the API,
-these extensions are explicitly designed to operate on machines that
-provide complete support for both IPv4 and IPv6. A subset of this API
-could probably be designed for operation on systems that support only
-IPv6. However, this is not addressed in this memo.
-
-
-
-2.1 What Needs to be Changed
-
-The socket interface API consists of a few distinct components:
-
- - Core socket functions.
-
- - Address data structures.
-
- - Name-to-address translation functions.
-
- - Address conversion functions.
-
-The core socket functions -- those functions that deal with such things
-as setting up and tearing down TCP connections, and sending and
-receiving UDP packets -- were designed to be transport independent.
-Where protocol addresses are passed as function arguments, they are
-carried via opaque pointers. A protocol-specific address data structure
-is defined for each protocol that the socket functions support.
-Applications must cast pointers to these protocol-specific address
-structures into pointers to the generic "sockaddr" address structure
-when using the socket functions. These functions need not change for
-IPv6, but a new IPv6-specific address data structure is needed.
-
-The "sockaddr_in" structure is the protocol-specific data structure for
-IPv4. This data structure actually includes 8-octets of unused space,
-and it is tempting to try to use this space to adapt the sockaddr_in
-structure to IPv6. Unfortunately, the sockaddr_in structure is not
-large enough to hold the 16-octet IPv6 address as well as the other
-information (address family and port number) that is needed. So a new
-address data structure must be defined for IPv6.
-
-IPv6 addresses are scoped [2] so they could be link-local, site,
-organization, global, or other scopes at this time undefined. To
-support applications that want to be able to identify a set of
-interfaces for a specific scope, the IPv6 sockaddr_in structure must
-support a field that can be used by an implementation to identify a set
-of interfaces identifying the scope for an IPv6 address.
-
-The IPv4 name-to-address translation functions in the socket interface
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 4]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-are gethostbyname() and gethostbyaddr(). These are left as is, and new
-functions are defined which support both IPv4 and IPv6.
-
-The IPv4 address conversion functions -- inet_ntoa() and inet_addr() --
-convert IPv4 addresses between binary and printable form. These
-functions are quite specific to 32-bit IPv4 addresses. We have designed
-two analogous functions that convert both IPv4 and IPv6 addresses, and
-carry an address type parameter so that they can be extended to other
-protocol families as well.
-
-Finally, a few miscellaneous features are needed to support IPv6. A new
-interface is needed to support the IPv6 hop limit header field. New
-socket options are needed to control the sending and receiving of IPv6
-multicast packets.
-
-The socket interface will be enhanced in the future to provide access to
-other IPv6 features. Some of these extensions are described in [4].
-
-
-
-
-2.2 Data Types
-
-The data types of the structure elements given in this memo are intended
-to track the relevant standards. uintN_t means an unsigned integer of
-exactly N bits (e.g., uint16_t). The sa_family_t and in_port_t types
-are defined in [3].
-
-
-
-2.3 Headers
-
-When function prototypes and structures are shown we show the headers
-that must be #included to cause that item to be defined.
-
-
-
-2.4 Structures
-
-When structures are described the members shown are the ones that must
-appear in an implementation. Additional, nonstandard members may also
-be defined by an implementation. As an additional precaution
-nonstandard members could be verified by Feature Test Macros as
-described in [3]. (Such Feature Test Macros are not defined by this
-RFC.)
-
-The ordering shown for the members of a structure is the recommended
-ordering, given alignment considerations of multibyte members, but an
-implementation may order the members differently.
-
-
-
-3. Socket Interface
-
-This section specifies the socket interface changes for IPv6.
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 5]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-3.1 IPv6 Address Family and Protocol Family
-
-A new address family name, AF_INET6, is defined in <sys/socket.h>. The
-AF_INET6 definition distinguishes between the original sockaddr_in
-address data structure, and the new sockaddr_in6 data structure.
-
-A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-Like most of the other protocol family names, this will usually be
-defined to have the same value as the corresponding address family name:
-
- #define PF_INET6 AF_INET6
-
-The AF_INET6 is used in the first argument to the socket() function to
-indicate that an IPv6 socket is being created.
-
-
-
-3.2 IPv6 Address Structure
-
-A new in6_addr structure holds a single IPv6 address and is defined as a
-result of including <netinet/in.h>:
-
- struct in6_addr {
- uint8_t s6_addr[16]; /* IPv6 address */
- };
-
-This data structure contains an array of sixteen 8-bit elements, which
-make up one 128-bit IPv6 address. The IPv6 address is stored in network
-byte order.
-
-The structure in6_addr above is usually implemented with an embedded
-union with extra fields that force the desired alignment level in a
-manner similar to BSD implementations of "struct in_addr". Those
-additional implementation details are omitted here for simplicity.
-
-An example is as follows:
-
-struct in6_addr {
- union {
- uint8_t _S6_u8[16];
- uint32_t _S6_u32[4];
- uint64_t _S6_u64[2];
- } _S6_un;
-};
-#define s6_addr _S6_un._S6_u8
-
-
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
-In the socket interface, a different protocol-specific data structure is
-defined to carry the addresses for each protocol suite. Each protocol-
-specific data structure is designed so it can be cast into a protocol-
-independent data structure -- the "sockaddr" structure. Each has a
-"family" field that overlays the "sa_family" of the sockaddr data
-structure. This field identifies the type of the data structure.
-
-The sockaddr_in structure is the protocol-specific address data
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 6]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-structure for IPv4. It is used to pass addresses between applications
-and the system in the socket functions. The following sockaddr_in6
-structure holds IPv6 addresses and is defined as a result of including
-the <netinet/in.h> header:
-
- struct sockaddr_in6 {
- sa_family_t sin6_family; /* AF_INET6 */
- in_port_t sin6_port; /* transport layer port # */
- uint32_t sin6_flowinfo; /* IPv6 flow information */
- struct in6_addr sin6_addr; /* IPv6 address */
- uint32_t sin6_scope_id; /* set of interfaces for a scope */
- };
-
-This structure is designed to be compatible with the sockaddr data
-structure used in the 4.3BSD release.
-
-The sin6_family field identifies this as a sockaddr_in6 structure. This
-field overlays the sa_family field when the buffer is cast to a sockaddr
-data structure. The value of this field must be AF_INET6.
-
-The sin6_port field contains the 16-bit UDP or TCP port number. This
-field is used in the same way as the sin_port field of the sockaddr_in
-structure. The port number is stored in network byte order.
-
-The sin6_flowinfo field is a 32-bit field intended to contain flow-
-related information. The exact way this field is mapped to or from a
-packet is not currently specified. Until such time as its use is
-specified, applications should set this field to zero when constructing
-a sockaddr_in6, and ignore this field in a sockaddr_in6 structure
-constructed by the system.
-
-The sin6_addr field is a single in6_addr structure (defined in the
-previous section). This field holds one 128-bit IPv6 address. The
-address is stored in network byte order.
-
-The ordering of elements in this structure is specifically designed so
-that when sin6_addr field is aligned on a 64-bit boundary, the start of
-the structure will also be aligned on a 64-bit boundary. This is done
-for optimum performance on 64-bit architectures.
-
-The sin6_scope_id field is a 32-bit integer that identifies a set of
-interfaces as appropriate for the scope [2] of the address carried in
-the sin6_addr field. The mapping of sin6_scope_id to an interface or
-set of interfaces is left to implementation and future specifications on
-the subject of scoped addresses.
-
-Notice that the sockaddr_in6 structure will normally be larger than the
-generic sockaddr structure. On many existing implementations the
-sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-being 16 bytes. Any existing code that makes this assumption needs to
-be examined carefully when converting to IPv6.
-
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
-The 4.4BSD release includes a small, but incompatible change to the
-socket interface. The "sa_family" field of the sockaddr data structure
-was changed from a 16-bit value to an 8-bit value, and the space saved
-used to hold a length field, named "sa_len". The sockaddr_in6 data
-structure given in the previous section cannot be correctly cast into
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 7]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-the newer sockaddr data structure. For this reason, the following
-alternative IPv6 address data structure is provided to be used on
-systems based on 4.4BSD. It is defined as a result of including the
-<netinet/in.h> header.
-
- struct sockaddr_in6 {
- uint8_t sin6_len; /* length of this struct */
- sa_family_t sin6_family; /* AF_INET6 */
- in_port_t sin6_port; /* transport layer port # */
- uint32_t sin6_flowinfo; /* IPv6 flow information */
- struct in6_addr sin6_addr; /* IPv6 address */
- uint32_t sin6_scope_id; /* set of interfaces for a scope */
- };
-
-The only differences between this data structure and the 4.3BSD variant
-are the inclusion of the length field, and the change of the family
-field to a 8-bit data type. The definitions of all the other fields are
-identical to the structure defined in the previous section.
-
-Systems that provide this version of the sockaddr_in6 data structure
-must also declare SIN6_LEN as a result of including the <netinet/in.h>
-header. This macro allows applications to determine whether they are
-being built on a system that supports the 4.3BSD or 4.4BSD variants of
-the data structure.
-
-
-
-3.5 The Socket Functions
-
-Applications call the socket() function to create a socket descriptor
-that represents a communication endpoint. The arguments to the socket()
-function tell the system which protocol to use, and what format address
-structure will be used in subsequent functions. For example, to create
-an IPv4/TCP socket, applications make the call:
-
- s = socket(AF_INET, SOCK_STREAM, 0);
-
-To create an IPv4/UDP socket, applications make the call:
-
- s = socket(AF_INET, SOCK_DGRAM, 0);
-
-Applications may create IPv6/TCP and IPv6/UDP sockets (which may also
-handle IPv4 communication as described in section 3.7) by simply using
-the constant AF_INET6 instead of AF_INET in the first argument. For
-example, to create an IPv6/TCP socket, applications make the call:
-
- s = socket(AF_INET6, SOCK_STREAM, 0);
-
-To create an IPv6/UDP socket, applications make the call:
-
- s = socket(AF_INET6, SOCK_DGRAM, 0);
-
-Once the application has created a AF_INET6 socket, it must use the
-sockaddr_in6 address structure when passing addresses in to the system.
-The functions that the application uses to pass addresses into the
-system are:
-
- bind()
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 8]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- connect()
- sendmsg()
- sendto()
-
-The system will use the sockaddr_in6 address structure to return
-addresses to applications that are using AF_INET6 sockets. The
-functions that return an address from the system to an application are:
-
- accept()
- recvfrom()
- recvmsg()
- getpeername()
- getsockname()
-
-No changes to the syntax of the socket functions are needed to support
-IPv6, since all of the "address carrying" functions use an opaque
-address pointer, and carry an address length as a function argument.
-
-
-
-3.6 Compatibility with IPv4 Applications
-
-In order to support the large base of applications using the original
-API, system implementations must provide complete source and binary
-compatibility with the original API. This means that systems must
-continue to support AF_INET sockets and the sockaddr_in address
-structure. Applications must be able to create IPv4/TCP and IPv4/UDP
-sockets using the AF_INET constant in the socket() function, as
-described in the previous section. Applications should be able to hold
-a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets
-simultaneously within the same process.
-
-Applications using the original API should continue to operate as they
-did on systems supporting only IPv4. That is, they should continue to
-interoperate with IPv4 nodes.
-
-
-
-3.7 Compatibility with IPv4 Nodes
-
-The API also provides a different type of compatibility: the ability for
-IPv6 applications to interoperate with IPv4 applications. This feature
-uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing
-architecture specification [2]. This address format allows the IPv4
-address of an IPv4 node to be represented as an IPv6 address. The IPv4
-address is encoded into the low-order 32 bits of the IPv6 address, and
-the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4-
-mapped addresses are written as follows:
-
- ::FFFF:<IPv4-address>
-
-These addresses can be generated automatically by the getaddrinfo()
-function, as described in Section 6.1.
-
-Applications may use AF_INET6 sockets to open TCP connections to IPv4
-nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-destination's IPv4 address as an IPv4-mapped IPv6 address, and passing
-that address, within a sockaddr_in6 structure, in the connect() or
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 9]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-sendto() call. When applications use AF_INET6 sockets to accept TCP
-connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the
-system returns the peer's address to the application in the accept(),
-recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded
-this way.
-
-Few applications will likely need to know which type of node they are
-interoperating with. However, for those applications that do need to
-know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
-provided.
-
-
-
-3.8 IPv6 Wildcard Address
-
-While the bind() function allows applications to select the source IP
-address of UDP packets and TCP connections, applications often want the
-system to select the source address for them. With IPv4, one specifies
-the address as the symbolic constant INADDR_ANY (called the "wildcard"
-address) in the bind() call, or simply omits the bind() entirely.
-
-Since the IPv6 address type is a structure (struct in6_addr), a symbolic
-constant can be used to initialize an IPv6 address variable, but cannot
-be used in an assignment. Therefore systems provide the IPv6 wildcard
-address in two forms.
-
-The first version is a global variable named "in6addr_any" that is an
-in6_addr structure. The extern declaration for this variable is defined
-in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_any;
-
-Applications use in6addr_any similarly to the way they use INADDR_ANY in
-IPv4. For example, to bind a socket to port number 23, but let the
-system select the source address, an application could use the following
-code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_any; /* structure assignment */
- . . .
- if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
-The other version is a symbolic constant named IN6ADDR_ANY_INIT and is
-defined in <netinet/in.h>. This constant can be used to initialize an
-in6_addr structure:
-
- struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-Note that this constant can be used ONLY at declaration time. It can
-not be used to assign a previously declared in6_addr structure. For
-example, the following code will not work:
-
- /* This is the WRONG way to assign an unspecified address */
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 10]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-Be aware that the IPv4 INADDR_xxx constants are all defined in host byte
-order but the IPv6 IN6ADDR_xxx constants and the IPv6 in6addr_xxx
-externals are defined in network byte order.
-
-
-
-3.9 IPv6 Loopback Address
-
-Applications may need to send UDP packets to, or originate TCP
-connections to, services residing on the local node. In IPv4, they can
-do this by using the constant IPv4 address INADDR_LOOPBACK in their
-connect(), sendto(), or sendmsg() call.
-
-IPv6 also provides a loopback address to contact local TCP and UDP
-services. Like the unspecified address, the IPv6 loopback address is
-provided in two forms -- a global variable and a symbolic constant.
-
-The global variable is an in6_addr structure named "in6addr_loopback."
-The extern declaration for this variable is defined in <netinet/in.h>:
-
- extern const struct in6_addr in6addr_loopback;
-
-Applications use in6addr_loopback as they would use INADDR_LOOPBACK in
-IPv4 applications (but beware of the byte ordering difference mentioned
-at the end of the previous section). For example, to open a TCP
-connection to the local telnet server, an application could use the
-following code:
-
- struct sockaddr_in6 sin6;
- . . .
- sin6.sin6_family = AF_INET6;
- sin6.sin6_flowinfo = 0;
- sin6.sin6_port = htons(23);
- sin6.sin6_addr = in6addr_loopback; /* structure assignment */
- . . .
- if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
- . . .
-
-The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined in
-<netinet/in.h>. It can be used at declaration time ONLY; for example:
-
- struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to
-a previously declared IPv6 address variable.
-
-
-
-3.10 Portability Additions
-
-One simple addition to the sockets API that can help application writers
-is the "struct sockaddr_storage". This data structure can simplify
-writing code that is portable across multiple address families and
-platforms. This data structure is designed with the following goals.
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 11]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- - Large enough to accommodate all supported protocol-specific address
- structures.
-
- - Aligned at an appropriate boundary so that pointers to it can be cast
- as pointers to protocol specific address structures and used to
- access the fields of those structures without alignment problems.
-
-
-The sockaddr_storage structure contains field ss_family which is of type
-sa_family_t. When a sockaddr_storage structure is cast to a sockaddr
-structure, the ss_family field of the sockaddr_storage structure maps
-onto the sa_family field of the sockaddr structure. When a
-sockaddr_storage structure is cast as a protocol specific address
-structure, the ss_family field maps onto a field of that structure that
-is of type sa_family_t and that identifies the protocol's address
-family.
-
-An example implementation design of such a data structure would be as
-follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE 128 /* Implementation specific max size */
-#define _SS_ALIGNSIZE (sizeof (int64_t))
- /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t) +
- _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
- sa_family_t ss_family; /* address family */
- /* Following fields are implementation specific */
- char __ss_pad1[_SS_PAD1SIZE];
- /* 6 byte pad, this is to make implementation
- /* specific pad up to alignment field that */
- /* follows explicit in the data structure */
- int64_t __ss_align; /* field to force desired structure */
- /* storage alignment */
- char __ss_pad2[_SS_PAD2SIZE];
- /* 112 byte pad to achieve desired size, */
- /* _SS_MAXSIZE value minus size of ss_family */
- /* __ss_pad1, __ss_align fields is 112 */
-};
-
-The above example implementation illustrates a data structure which will
-align on a 64-bit boundary. An implementation-specific field
-"__ss_align" along with "__ss_pad1" is used to force a 64-bit alignment
-which covers proper alignment good enough for the needs of sockaddr_in6
-(IPv6), sockaddr_in (IPv4) address data structures. The size of padding
-field __ss_pad1 depends on the chosen alignment boundary. The size of
-padding field __ss_pad2 depends on the value of overall size chosen for
-the total size of the structure. This size and alignment are represented
-in the above example by implementation specific (not required) constants
-_SS_MAXSIZE (chosen value 128) and _SS_ALIGNSIZE (with chosen value 8).
-Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 12]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-112) are also for illustration and not required. The derived values
-assume sa_family_t is 2 bytes. The implementation specific definitions
-and structure field names above start with an underscore to denote
-implementation private namespace. Portable code is not expected to
-access or reference those fields or constants.
-
-On implementations where the sockaddr data structure includes a "sa_len"
-field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
- (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE -
- (sizeof (uint8_t) + sizeof (sa_family_t) +
- _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
- uint8_t ss_len; /* address length */
- sa_family_t ss_family; /* address family */
- /* Following fields are implementation specific */
- char __ss_pad1[_SS_PAD1SIZE];
- /* 6 byte pad, this is to make implementation
- /* specific pad up to alignment field that */
- /* follows explicit in the data structure */
- int64_t __ss_align; /* field to force desired structure */
- /* storage alignment */
- char __ss_pad2[_SS_PAD2SIZE];
- /* 112 byte pad to achieve desired size, */
- /* _SS_MAXSIZE value minus size of ss_len, */
- /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
-
-
-4. Interface Identification
-
-This API uses an interface index (a small positive integer) to identify
-the local interface on which a multicast group is joined (Section 5.3).
-Additionally, the advanced API [4] uses these same interface indexes to
-identify the interface on which a datagram is received, or to specify
-the interface on which a datagram is to be sent.
-
-Interfaces are normally known by names such as "le0", "sl1", "ppp2", and
-the like. On Berkeley-derived implementations, when an interface is
-made known to the system, the kernel assigns a unique positive integer
-value (called the interface index) to that interface. These are small
-positive integers that start at 1. (Note that 0 is never used for an
-interface index.) There may be gaps so that there is no current
-interface for a particular positive interface index.
-
-This API defines two functions that map between an interface name and
-index, a third function that returns all the interface names and
-indexes, and a fourth function to return the dynamic memory allocated by
-the previous function. How these functions are implemented is left up
-to the implementation. 4.4BSD implementations can implement these
-functions using the existing sysctl() function with the NET_RT_IFLIST
-command. Other implementations may wish to use ioctl() for this
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 13]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-purpose.
-
-
-
-4.1 Name-to-Index
-
-The first function maps an interface name into its corresponding index.
-
- #include <net/if.h>
-
- unsigned int if_nametoindex(const char *ifname);
-
-If ifname is the name of an interface, the if_nametoindex() function
-shall return the interface index corresponding to name ifname;
-otherwise, it shall return zero. No errors are defined.
-
-
-
-4.2 Index-to-Name
-
-The second function maps an interface index into its corresponding name.
-
- #include <net/if.h>
-
- char *if_indextoname(unsigned int ifindex, char *ifname);
-
-When this function is called, the ifname argument shall point to a
-buffer of at least IF_NAMESIZE bytes. The function shall place in this
-buffer the name of the interface with index ifindex. (IF_NAMESIZE is
-also defined in <net/if.h> and its value includes a terminating null
-byte at the end of the interface name.) If ifindex is an interface
-index, then the function shall return the value supplied in ifname,
-which points to a buffer now containing the interface name. Otherwise,
-the function shall return a NULL pointer and set errno to indicate the
-error. If there is no interface corresponding to the specified index,
-errno is set to ENXIO. If there was a system error (such as running out
-of memory), errno would be set to the proper value (e.g., ENOMEM).
-
-
-
-4.3 Return All Interface Names and Indexes
-
-The if_nameindex structure holds the information about a single
-interface and is defined as a result of including the <net/if.h> header.
-
- struct if_nameindex {
- unsigned int if_index; /* 1, 2, ... */
- char *if_name; /* null terminated name: "le0", ... */
- };
-
-The final function returns an array of if_nameindex structures, one
-structure per interface.
-
- #include <net/if.h>
-
- struct if_nameindex *if_nameindex(void);
-
-The end of the array of structures is indicated by a structure with an
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 14]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-if_index of 0 and an if_name of NULL. The function returns a NULL
-pointer upon an error, and would set errno to the appropriate value.
-
-The memory used for this array of structures along with the interface
-names pointed to by the if_name members is obtained dynamically. This
-memory is freed by the next function.
-
-
-
-4.4 Free Memory
-
-The following function frees the dynamic memory that was allocated by
-if_nameindex().
-
- #include <net/if.h>
-
- void if_freenameindex(struct if_nameindex *ptr);
-
-The ptr argument shall be a pointer that was returned by if_nameindex().
-After if_freenameindex() has been called, the application shall not use
-the array of which ptr is the address.
-
-
-
-5. Socket Options
-
-A number of new socket options are defined for IPv6. All of these new
-options are at the IPPROTO_IPV6 level. That is, the "level" parameter
-in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using
-these options. The constant name prefix IPV6_ is used in all of the new
-socket options. This serves to clearly identify these options as
-applying to IPv6.
-
-The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-related constants defined in this section are obtained by including the
-header <netinet/in.h>.
-
-
-
-5.1 Unicast Hop Limit
-
-A new setsockopt() option controls the hop limit used in outgoing
-unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and
-it is used at the IPPROTO_IPV6 layer. The following example illustrates
-how it is used:
-
- int hoplimit = 10;
-
- if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, sizeof(hoplimit)) == -1)
- perror("setsockopt IPV6_UNICAST_HOPS");
-
-When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option
-value given is used as the hop limit for all subsequent unicast packets
-sent via that socket. If the option is not set, the system selects a
-default value. The integer hop limit value (called x) is interpreted as
-follows:
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 15]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
-The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine
-the hop limit value that the system will use for subsequent unicast
-packets sent via that socket. For example:
-
- int hoplimit;
- socklen_t len = sizeof(hoplimit);
-
- if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
- (char *) &hoplimit, &len) == -1)
- perror("getsockopt IPV6_UNICAST_HOPS");
- else
- printf("Using %d for hop limit.\n", hoplimit);
-
-
-
-5.2 Sending and Receiving Multicast Packets
-
-IPv6 applications may send multicast packets by simply specifying an
-IPv6 multicast address as the destination address, for example in the
-destination address argument of the sendto() function.
-
-Three socket options at the IPPROTO_IPV6 layer control some of the
-parameters for sending multicast packets. Setting these options is not
-required: applications may send multicast packets without using these
-options. The setsockopt() options for controlling the sending of
-multicast packets are summarized below. These three options can also be
-used with getsockopt().
-
- IPV6_MULTICAST_IF
-
- Set the interface to use for outgoing multicast packets.
- The argument is the index of the interface to use.
- If the interface index is specified as zero, the system
- selects the interface (for example, by looking up the
- address in a routing table and using the resulting interface).
-
- Argument type: unsigned int
-
- IPV6_MULTICAST_HOPS
-
- Set the hop limit to use for outgoing multicast packets.
- (Note a separate option - IPV6_UNICAST_HOPS - is
- provided to set the hop limit to use for outgoing
- unicast packets.)
-
- The interpretation of the argument is the same
- as for the IPV6_UNICAST_HOPS option:
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 16]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- If IPV6_MULTICAST_HOPS is not set, the default is 1
- (same as IPv4 today)
-
- Argument type: int
-
- IPV6_MULTICAST_LOOP
-
- If a multicast datagram is sent to a group to which the sending host
- itself belongs (on the outgoing interface), a copy of the datagram is
- looped back by the IP layer for local delivery if this option is set to
- 1. If this option is set to 0 a copy is not looped back. Other option
- values return an error of EINVAL.
-
- If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same as
- IPv4 today).
-
- Argument type: unsigned int
-
-The reception of multicast packets is controlled by the two setsockopt()
-options summarized below. An error of EOPNOTSUPP is returned if these
-two options are used with getsockopt().
-
- IPV6_JOIN_GROUP
-
- Join a multicast group on a specified local interface.
- If the interface index is specified as 0,
- the kernel chooses the local interface.
- For example, some kernels look up the multicast group
- in the normal IPv6 routing table and use the resulting interface.
-
- Argument type: struct ipv6_mreq
-
- IPV6_LEAVE_GROUP
-
- Leave a multicast group on a specified interface.
- If the interface index is specified as 0, the system
- may choose a multicast group membership to drop by
- matching the multicast address only.
-
- Argument type: struct ipv6_mreq
-
-The argument type of both of these options is the ipv6_mreq structure,
-defined as a result of including the <netinet/in.h> header;
-
- struct ipv6_mreq {
- struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
- unsigned int ipv6mr_interface; /* interface index */
- };
-
-Note that to receive multicast datagrams a process must join the
-multicast group to which datagrams will be sent. UDP applications must
-also bind the UDP port to which datagrams will be sent. Some processes
-also bind the multicast group address to the socket, in addition to the
-port, to prevent other datagrams destined to that same port from being
-delivered to the socket.
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 17]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-5.3 IPV6_V6ONLY option for AF_INET6 Sockets
-
-This socket option restricts AF_INET6 sockets to IPv6 communications
-only. As stated in section <3.7 Compatibility with IPv4 Nodes>,
-AF_INET6 sockets may be used for both IPv4 and IPv6 communications. Some
-applications may want to restrict their use of an AF_INET6 socket to
-IPv6 communications only. For these applications the IPV6_V6ONLY socket
-option is defined. When this option is turned on, the socket can be
-used to send and receive IPv6 packets only. This is an IPPROTO_IPV6
-level option. This option takes an int value. This is a boolean
-option. By default this option is turned off.
-
- Here is an example of setting this option:
-
- int on = 1;
-
- if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
- (char *)&on, sizeof(on)) == -1)
- perror("setsockopt IPV6_V6ONLY");
- else
- printf("IPV6_V6ONLY set\n");
-
-Note - This option has no effect on the use of IPv4 Mapped addresses
-which enter a node as a valid IPv6 addresses for IPv6 communications as
-defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].
-
-An example use of this option is to allow two versions of the same
-server process to run on the same port, one providing service over IPv6,
-the other providing the same service over IPv4.
-
-
-
-
-6. Library Functions
-
-New library functions are needed to perform a variety of operations with
-IPv6 addresses. Functions are needed to lookup IPv6 addresses in the
-Domain Name System (DNS). Both forward lookup (nodename-to-address
-translation) and reverse lookup (address-to-nodename translation) need
-to be supported. Functions are also needed to convert IPv6 addresses
-between their binary and textual form.
-
-We note that the two existing functions, gethostbyname() and
-gethostbyaddr(), are left as-is. New functions are defined to handle
-both IPv4 and IPv6 addresses.
-
-The commonly used function gethostbyname() is inadequate for many
-applications, first because it provides no way for the caller to specify
-anything about the types of addresses desired (IPv4 only, IPv6 only,
-IPv4-mapped IPv6 are OK, etc.), and second because many implementations
-of this function are not thread safe. RFC 2133 defined a function named
-gethostbyname2() but this function was also inadequate, first because
-its use required setting a global option (RES_USE_INET6) when IPv6
-addresses were required, and second because a flag argument is needed to
-provide the caller with additional control over the types of addresses
-required. The gethostbyname2() function was deprecated in RFC 2553 and
-is no longer part of the basic API.
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 18]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-6.1 Protocol-Independent Nodename and Service Name Translation
-
-Nodename-to-address translation is done in a protocol-independent
-fashion using the getaddrinfo() function.
-
- #include <sys/socket.h>
- #include <netdb.h>
-
-
- int getaddrinfo(const char *nodename, const char *servname,
- const struct addrinfo *hints, struct addrinfo **res);
-
- void freeaddrinfo(struct addrinfo *ai);
-
- struct addrinfo {
- int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, .. */
- int ai_family; /* AF_xxx */
- int ai_socktype; /* SOCK_xxx */
- int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
- socklen_t ai_addrlen; /* length of ai_addr */
- char *ai_canonname; /* canonical name for nodename */
- struct sockaddr *ai_addr; /* binary address */
- struct addrinfo *ai_next; /* next structure in linked list */
- };
-
- The getaddrinfo() function translates the name of a service location
- (for example, a host name) and/or a service name and returns a set of
- socket addresses and associated information to be used in creating a
- socket with which to address the specified service.
-
- The nodename and servname arguments are either null pointers or
- pointers to null-terminated strings. One or both of these two
- arguments must be a non-null pointer.
-
- The format of a valid name depends on the address family or families.
- If a specific family is not given and the name could be interpreted
- as valid within multiple supported families, the implementation will
- attempt to resolve the name in all supported families and, in absence
- of errors, one or more results shall be returned.
-
- If the nodename argument is not null, it can be a descriptive name or
- can be an address string. If the specified address family is AF_INET,
- AF_INET6, or AF_UNSPEC, valid descriptive names include host names.
- If the specified address family is AF_INET or AF_UNSPEC, address
- strings using Internet standard dot notation as specified in
- inet_addr() are valid. If the specified address family is AF_INET6
- or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
- valid.
-
- If nodename is not null, the requested service location is named by
- nodename; otherwise, the requested service location is local to the
- caller.
-
- If servname is null, the call shall return network-level addresses
- for the specified nodename. If servname is not null, it is a null-
- terminated character string identifying the requested service. This
- can be either a descriptive name or a numeric representation suitable
- for use with the address family or families. If the specified address
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 19]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
- specified as a string specifying a decimal port number.
-
- If the argument hints is not null, it refers to a structure
- containing input values that may direct the operation by providing
- options and by limiting the returned information to a specific socket
- type, address family and/or protocol. In this hints structure every
- member other than ai_flags, ai_family, ai_socktype and ai_protocol
- shall be set to zero or a null pointer. A value of AF_UNSPEC for
- ai_family means that the caller shall accept any address family. A
- value of zero for ai_socktype means that the caller shall accept any
- socket type. A value of zero for ai_protocol means that the caller
- shall accept any protocol. If hints is a null pointer, the behavior
- shall be as if it referred to a structure containing the value zero
- for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
- for the ai_family field.
-
- Note:
-
- 1. If the caller handles only TCP and not UDP, for example, then the
- ai_protocol member of the hints structure should be set to
- IPPROTO_TCP when getaddrinfo() is called.
-
- 2. If the caller handles only IPv4 and not IPv6, then the ai_family
- member of the hints structure should be set to AF_INET when
- getaddrinfo() is called.
-
- The ai_flags field to which hints parameter points shall be set to
- zero or be the bitwise-inclusive OR of one or more of the values
- AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
- AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
-
- If the AI_PASSIVE flag is specified, the returned address information
- shall be suitable for use in binding a socket for accepting incoming
- connections for the specified service (i.e. a call to bind()). In
- this case, if the nodename argument is null, then the IP address
- portion of the socket address structure shall be set to INADDR_ANY
- for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the
- AI_PASSIVE flag is not specified, the returned address information
- shall be suitable for a call to connect() (for a connection-mode
- protocol) or for a call to connect(), sendto() or sendmsg() (for a
- connectionless protocol). In this case, if the nodename argument is
- null, then the IP address portion of the socket address structure
- shall be set to the loopback address. This flag is ignored if the
- nodename argument is not null.
-
- If the AI_CANONNAME flag is specified and the nodename argument is
- not null, the function shall attempt to determine the canonical name
- corresponding to nodename (for example, if nodename is an alias or
- shorthand notation for a complete name).
-
- If the AI_NUMERICHOST flag is specified, then a non-null nodename
- string supplied shall be a numeric host address string. Otherwise, an
- [EAI_NONAME] error is returned. This flag shall prevent any type of
- name resolution service (for example, the DNS) from being invoked.
-
- If the AI_NUMERICSERV flag is specified, then a non-null servname
- string supplied shall be a numeric port string. Otherwise, an
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 20]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- [EAI_NONAME] error shall be returned. This flag shall prevent any
- type of name resolution service (for example, NIS+) from being
- invoked.
-
- If the AI_V4MAPPED flag is specified along with an ai_family of
- AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
- on finding no matching IPv6 addresses (ai_addrlen shall be 16).
-
- For example, when using the DNS, if no AAAA records are found
- then a query is made for A records and any found are returned as
- IPv4-mapped IPv6 addresses.
-
- The AI_V4MAPPED flag shall be ignored unless ai_family equals
- AF_INET6.
-
- If the AI_ALL flag is used with the AI_V4MAPPED flag, then
- getaddrinfo() shall return all matching IPv6 and IPv4 addresses.
-
- For example, when using the DNS, queries are made for both AAAA
- records and A records, and getaddrinfo() returns the combined
- results of both queries. Any IPv4 addresses found are returned
- as IPv4-mapped IPv6 addresses.
-
- The AI_ALL flag without the AI_V4MAPPED flag is ignored.
-
- Note:
-
- When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and
- AI_ALL flags will only be used if AF_INET6 is supported.
-
- If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
- returned only if an IPv4 address is configured on the local system,
- and IPv6 addresses shall be returned only if an IPv6 address is
- configured on the local system. The loopback address is not
- considered for this case as valid as a configured address.
-
- For example, when using the DNS, a query for AAAA records
- should occur only if the node has at least one IPv6 address
- configured (other than IPv6 loopback) and a query for A records
- should occur only if the node has at least one IPv4 address
- configured (other than the IPv4 loopback).
-
- The ai_socktype field to which argument hints points specifies the
- socket type for the service, as defined for socket(). If a specific
- socket type is not given (for example, a value of zero) and the
- service name could be interpreted as valid with multiple supported
- socket types, the implementation shall attempt to resolve the service
- name for all supported socket types and, in the absence of errors,
- all possible results shall be returned. A non-zero socket type value
- shall limit the returned information to values with the specified
- socket type.
-
- If the ai_family field to which hints points has the value AF_UNSPEC,
- addresses shall be returned for use with any address family that can
- be used with the specified nodename and/or servname. Otherwise,
- addresses shall be returned for use only with the specified address
- family. If ai_family is not AF_UNSPEC and ai_protocol is not zero,
- then addresses are returned for use only with the specified address
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 21]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- family and protocol; the value of ai_protocol shall be interpreted as
- in a call to the socket() function with the corresponding values of
- ai_family and ai_protocol .
-
- The freeaddrinfo() function frees one or more addrinfo structures
- returned by getaddrinfo(), along with any additional storage
- associated with those structures (for example, storage pointed to by
- the ai_canonname and ai_addr fields; an application must not
- reference this storage after the associated addrinfo structure has
- been freed). If the ai_next field of the structure is not null, the
- entire list of structures is freed. The freeaddrinfo() function must
- support the freeing of arbitrary sublists of an addrinfo list
- originally returned by getaddrinfo().
-
- Functions getaddrinfo() and freeaddrinfo() must be thread-safe.
-
- A zero return value for getaddrinfo() indicates successful
- completion; a non-zero return value indicates failure. The possible
- values for the failures are listed below under Error Return Values.
-
- Upon successful return of getaddrinfo(), the location to which res
- points shall refer to a linked list of addrinfo structures, each of
- which shall specify a socket address and information for use in
- creating a socket with which to use that socket address. The list
- shall include at least one addrinfo structure. The ai_next field of
- each structure contains a pointer to the next structure on the list,
- or a null pointer if it is the last structure on the list. Each
- structure on the list shall include values for use with a call to the
- socket() function, and a socket address for use with the connect()
- function or, if the AI_PASSIVE flag was specified, for use with the
- bind() function. The fields ai_family, ai_socktype, and ai_protocol
- shall be usable as the arguments to the socket() function to create a
- socket suitable for use with the returned address. The fields ai_addr
- and ai_addrlen are usable as the arguments to the connect() or bind()
- functions with such a socket, according to the AI_PASSIVE flag.
-
- If nodename is not null, and if requested by the AI_CANONNAME flag,
- the ai_canonname field of the first returned addrinfo structure shall
- point to a null-terminated string containing the canonical name
- corresponding to the input nodename; if the canonical name is not
- available, then ai_canonname shall refer to the nodename argument or
- a string with the same contents. The contents of the ai_flags field
- of the returned structures are undefined.
-
- All fields in socket address structures returned by getaddrinfo()
- that are not filled in through an explicit argument (for example,
- sin6_flowinfo) shall be set to zero.
-
- Note: This makes it easier to compare socket address structures.
-
- Error Return Values:
-
- The getaddrinfo() function shall fail and return the corresponding
- value if:
-
- [EAI_AGAIN] The name could not be resolved at this time. Future
- attempts may succeed.
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 22]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- [EAI_BADFLAGS] The flags parameter had an invalid value.
-
- [EAI_FAIL] A non-recoverable error occurred when attempting to
- resolve the name.
-
- [EAI_FAMILY] The address family was not recognized.
-
- [EAI_MEMORY] There was a memory allocation failure when trying to
- allocate storage for the return value.
-
- [EAI_NONAME] The name does not resolve for the supplied parameters.
- Neither nodename nor servname were supplied. At least one
- of these must be supplied.
-
- [EAI_SERVICE] The service passed was not recognized for the specified
- socket type.
-
- [EAI_SOCKTYPE] The intended socket type was not recognized.
-
- [EAI_SYSTEM] A system error occurred; the error code can be found in
- errno.
-
-The gai_strerror() function provides a descriptive text string
-corresponding to an EAI_xxx error value.
-
-
- #include <netdb.h>
-
- const char *gai_strerror(int ecode);
-
-The argument is one of the EAI_xxx values defined for the getaddrinfo()
-and getnameinfo() functions. The return value points to a string
-describing the error. If the argument is not one of the EAI_xxx values,
-the function still returns a pointer to a string whose contents indicate
-an unknown error.
-
-
-
-6.2 Socket Address Structure to Node Name and Service Name
-
-The getnameinfo() function is used to translate the contents of a socket
-address structure to a node name and/or service name.
-
- #include <sys/socket.h>
- #include <netdb.h>
-
- int getnameinfo(const struct sockaddr *sa, socklen_t salen,
- char *node, socklen_t nodelen,
- char *service, socklen_t servicelen,
- int flags);
-
-The getnameinfo() function shall translate a socket address to a node
-name and service location, all of which are defined as in getaddrinfo().
-
-The sa argument points to a socket address structure to be translated.
-
-The salen argument holds the size of the socket address structure
-pointed to by sa.
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 23]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-If the socket address structure contains an IPv4-mapped IPv6 address or
-an IPv4-compatible IPv6 address, the implementation shall extract the
-embedded IPv4 address and lookup the node name for that IPv4 address.
-
- Note: The IPv6 unspecified address ("::") and the IPv6
- loopback address ("::1") are not IPv4-compatible addresses.
- If the address is the IPv6 unspecified address ("::"), a
- lookup is not performed, and the [EAI_NONAME] error is returned.
-
-If the node argument is non-NULL and the nodelen argument is nonzero,
-then the node argument points to a buffer able to contain up to nodelen
-characters that receives the node name as a null-terminated string. If
-the node argument is NULL or the nodelen argument is zero, the node name
-shall not be returned. If the node's name cannot be located, the numeric
-form of the node's address is returned instead of its name.
-
-If the service argument is non-NULL and the servicelen argument is non-
-zero, then the service argument points to a buffer able to contain up to
-servicelen bytes that receives the service name as a null-terminated
-string. If the service argument is NULL or the servicelen argument is
-zero, the service name shall not be returned. If the service's name
-cannot be located, the numeric form of the service address (for example,
-its port number) shall be returned instead of its name.
-
-The arguments node and service cannot both be NULL.
-
-The flags argument is a flag that changes the default actions of the
-function. By default the fully-qualified domain name (FQDN) for the host
-shall be returned, but:
-
- - If the flag bit NI_NOFQDN is set, only the node name portion of the
- FQDN shall be returned for local hosts.
-
- - If the flag bit NI_NUMERICHOST is set, the numeric form of the
- host's address shall be returned instead of its name, under all
- circumstances.
-
- - If the flag bit NI_NAMEREQD is set, an error shall be returned if the
- host's name cannot be located.
-
- - If the flag bit NI_NUMERICSERV is set, the numeric form of the
- service address shall be returned (for example, its port number)
- instead of its name, under all circumstances.
-
- - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the
- scope identifier shall be returned (for example, interface index)
- instead of its name. This flag is ignored if the sa argument is
- not an IPv6 address.
-
- - If the flag bit NI_DGRAM is set, this indicates that the service is
- a datagram service (SOCK_DGRAM). The default behavior shall assume that
- the service is a stream service (SOCK_STREAM).
-
-Note:
-
- 1. The three NI_NUMERICxxx flags are required to support the "-n"
- flags that many commands provide.
- 2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6 port
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 24]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- numbers (for example, [512,514]) that represent different services
- for UDP and TCP.
-
-The getnameinfo() function shall be thread safe.
-
-A zero return value for getnameinfo() indicates successful completion; a
-non-zero return value indicates failure.
-
-Upon successful completion, getnameinfo() shall return the node and
-service names, if requested, in the buffers provided. The returned names
-are always null-terminated strings.
-
-Error Return Values:
-
-The getnameinfo() function shall fail and return the corresponding value
-if:
-
- [EAI_AGAIN] The name could not be resolved at this time.
- Future attempts may succeed.
-
- [EAI_BADFLAGS] The flags had an invalid value.
-
- [EAI_FAIL] A non-recoverable error occurred.
-
- [EAI_FAMILY] The address family was not recognized or the address
- length was invalid for the specified family.
-
- [EAI_MEMORY] There was a memory allocation failure.
-
- [EAI_NONAME] The name does not resolve for the supplied parameters.
- NI_NAMEREQD is set and the host's name cannot be located, or
- both nodename and servname were null.
-
- [EAI_OVERFLOW] An argument buffer overflowed.
-
- [EAI_SYSTEM] A system error occurred. The error code can be found in
- errno.
-
-
-
-6.3 Address Conversion Functions
-
-The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4
-address between binary and text form. IPv6 applications need similar
-functions. The following two functions convert both IPv6 and IPv4
-addresses:
-
- #include <arpa/inet.h>
-
- int inet_pton(int af, const char *src, void *dst);
-
- const char *inet_ntop(int af, const void *src,
- char *dst, socklen_t size);
-
-The inet_pton() function shall convert an address in its standard text
-presentation form into its numeric binary form. The af argument shall
-specify the family of the address. The AF_INET and AF_INET6 address
-families shall be supported. The src argument points to the string
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 25]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-being passed in. The dst argument points to a buffer into which the
-function stores the numeric address; this shall be large enough to hold
-the numeric address (32 bits for AF_INET, 128 bits for AF_INET6). The
-inet_pton() function shall return 1 if the conversion succeeds, with the
-address pointed to by dst in network byte order. It shall return 0 if
-the input is not a valid IPv4 dotted-decimal string or a valid IPv6
-address string, or -1 with errno set to EAFNOSUPPORT if the af argument
-is unknown.
-
-If the af argument of inet_pton() is AF_INET, the src string shall be in
-the standard IPv4 dotted-decimal form:
-
- ddd.ddd.ddd.ddd
-
-where "ddd" is a one to three digit decimal number between 0 and 255.
-The inet_pton() function does not accept other formats (such as the
-octal numbers, hexadecimal numbers, and fewer than four numbers that
-inet_addr() accepts).
-
-If the af argument of inet_pton() is AF_INET6, the src string shall be
-in one of the standard IPv6 text forms defined in Section 2.2 of the
-addressing architecture specification [2].
-
-The inet_ntop() function shall convert a numeric address into a text
-string suitable for presentation. The af argument shall specify the
-family of the address. This can be AF_INET or AF_INET6. The src
-argument points to a buffer holding an IPv4 address if the af argument
-is AF_INET, or an IPv6 address if the af argument is AF_INET6; the
-address must be in network byte order. The dst argument points to a
-buffer where the function stores the resulting text string; it shall not
-be NULL. The size argument specifies the size of this buffer, which
-shall be large enough to hold the text string (INET_ADDRSTRLEN
-characters for IPv4, INET6_ADDRSTRLEN characters for IPv6).
-
-In order to allow applications to easily declare buffers of the proper
-size to store IPv4 and IPv6 addresses in string form, the following two
-constants are defined in <netinet/in.h>:
-
- #define INET_ADDRSTRLEN 16
- #define INET6_ADDRSTRLEN 46
-
-The inet_ntop() function shall return a pointer to the buffer containing
-the text string if the conversion succeeds, and NULL otherwise. Upon
-failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
-ENOSPC if the size of the result buffer is inadequate.
-
-
-
-6.4 Address Testing Macros
-
-The following macros can be used to test for special IPv6 addresses.
-
- #include <netinet/in.h>
-
- int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
- int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *);
- int IN6_IS_ADDR_MULTICAST (const struct in6_addr *);
- int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *);
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 26]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *);
- int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *);
-
- int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
- int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
- int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *);
-
-The first seven macros return true if the address is of the specified
-type, or false otherwise. The last five test the scope of a multicast
-address and return true if the address is a multicast address of the
-specified scope or false if the address is either not a multicast
-address or not of the specified scope.
-
-Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
-only for the two types of local-use IPv6 unicast addresses (Link-Local
-and Site-Local) defined in [2], and that by this definition, the
-IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback address
-(::1). These two macros do not return true for IPv6 multicast addresses
-of either link-local scope or site-local scope.
-
-
-
-7. Summary of New Definitions
-
-The following list summarizes the constants, structure, and extern
-definitions discussed in this memo, sorted by header.
-
- <net/if.h> IF_NAMESIZE
- <net/if.h> struct if_nameindex{};
-
- <netdb.h> AI_ADDRCONFIG
- <netdb.h> AI_ALL
- <netdb.h> AI_CANONNAME
- <netdb.h> AI_NUMERICHOST
- <netdb.h> AI_NUMERICSERV
- <netdb.h> AI_PASSIVE
- <netdb.h> AI_V4MAPPED
- <netdb.h> EAI_AGAIN
- <netdb.h> EAI_BADFLAGS
- <netdb.h> EAI_FAIL
- <netdb.h> EAI_FAMILY
- <netdb.h> EAI_MEMORY
- <netdb.h> EAI_NONAME
- <netdb.h> EAI_OVERFLOW
- <netdb.h> EAI_SERVICE
- <netdb.h> EAI_SOCKTYPE
- <netdb.h> EAI_SYSTEM
- <netdb.h> NI_DGRAM
- <netdb.h> NI_NAMEREQD
- <netdb.h> NI_NOFQDN
- <netdb.h> NI_NUMERICHOST
- <netdb.h> NI_NUMERICSERV
- <netdb.h> struct addrinfo{};
-
- <netinet/in.h> IN6ADDR_ANY_INIT
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 27]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
- <netinet/in.h> IN6ADDR_LOOPBACK_INIT
- <netinet/in.h> INET6_ADDRSTRLEN
- <netinet/in.h> INET_ADDRSTRLEN
- <netinet/in.h> IPPROTO_IPV6
- <netinet/in.h> IPV6_JOIN_GROUP
- <netinet/in.h> IPV6_LEAVE_GROUP
- <netinet/in.h> IPV6_MULTICAST_HOPS
- <netinet/in.h> IPV6_MULTICAST_IF
- <netinet/in.h> IPV6_MULTICAST_LOOP
- <netinet/in.h> IPV6_UNICAST_HOPS
- <netinet/in.h> IPV6_V6ONLY
- <netinet/in.h> SIN6_LEN
- <netinet/in.h> extern const struct in6_addr in6addr_any;
- <netinet/in.h> extern const struct in6_addr in6addr_loopback;
- <netinet/in.h> struct in6_addr{};
- <netinet/in.h> struct ipv6_mreq{};
- <netinet/in.h> struct sockaddr_in6{};
-
- <sys/socket.h> AF_INET6
- <sys/socket.h> PF_INET6
- <sys/socket.h> struct sockaddr_storage;
-
-The following list summarizes the function and macro prototypes
-discussed in this memo, sorted by header.
-
- <arpa/inet.h> int inet_pton(int, const char *, void *);
- <arpa/inet.h> const char *inet_ntop(int, const void *,
- char *, socklen_t);
-
- <net/if.h> char *if_indextoname(unsigned int, char *);
- <net/if.h> unsigned int if_nametoindex(const char *);
- <net/if.h> void if_freenameindex(struct if_nameindex *);
- <net/if.h> struct if_nameindex *if_nameindex(void);
-
- <netdb.h> int getaddrinfo(const char *, const char *,
- const struct addrinfo *,
- struct addrinfo **);
- <netdb.h> int getnameinfo(const struct sockaddr *, socklen_t,
- char *, socklen_t, char *, socklen_t, int);
- <netdb.h> void freeaddrinfo(struct addrinfo *);
- <netdb.h> const char *gai_strerror(int);
-
- <netinet/in.h> int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
- <netinet/in.h> int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 28]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-8. Security Considerations
-
-IPv6 provides a number of new security mechanisms, many of which need to
-be accessible to applications. Companion memos detailing the extensions
-to the socket interfaces to support IPv6 security are being written.
-
-
-
-Changes from RFC 2553
-
- 1. Add brief description of the history of this API and its
- relation to the Open Group/IEEE/ISO standards.
-
- 2. Alignments with [3].
-
- 3. Removed all references to getipnodebyname() and
- getipnodebyaddr(), which are deprecated in favor
- of getaddrinfo() and getnameinfo().
-
- 4. Added IPV6_V6ONLY IP level socket option to permit nodes
- to not process IPv4 packets as IPv4 Mapped addresses
- in implementations.
-
- 5. Added SIIT to references and added new contributors.
-
- 6. In previous versions of this specification, the sin6_flowinfo
- field was associated with the IPv6 traffic class and flow label,
- but its usage was not completely specified. The complete
- definition of the sin6_flowinfo field, including its association
- with the traffic class or flow label, is now deferred to a
- future specification.
-
-
-
-
-Acknowledgments
-
-This specification's evolution and completeness were significantly
-influenced by the efforts of Richard Stevens, who has passed on.
-Richard's wisdom and talent made the specification what it is today.
-The co-authors will long think of Richard with great respect.
-
-Thanks to the many people who made suggestions and provided feedback to
-this document, including:
-
-Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew
-Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis
-Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino, Marc
-Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji
-Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald,
-Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne, Craig
-Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos, Keith
-Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey Thompson, Dean
-D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl
-Williams, Kazu Yamamoto, Vlad Yasevich, Stig Venaas, and Brian Zill.
-
-The getaddrinfo() and getnameinfo() functions are taken from an earlier
-Internet Draft by Keith Sklower. As noted in that draft, William Durst,
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 29]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-Steven Wise, Michael Karels, and Eric Allman provided many useful
-discussions on the subject of protocol-independent name-to-address
-translation, and reviewed early versions of Keith Sklower's original
-proposal. Eric Allman implemented the first prototype of getaddrinfo().
-The observation that specifying the pair of name and service would
-suffice for connecting to a service independent of protocol details was
-made by Marshall Rose in a proposal to X/Open for a "Uniform Network
-Interface".
-
-Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker
-made many contributions to this document. Ramesh Govindan made a number
-of contributions and co-authored an earlier version of this memo.
-
-
-
-References
-
- [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
- Specification", RFC 2460 Draft Standard.
-
- [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
- RFC 2373, July 1998 Draft Standard.
-
- [3] 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 9945 (pending final approval by ISO)
-
- http://www.opengroup.org/austin
-
- [4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
- [5] E. Nordmark "Stateless IP/ICMP Translation Algorithm (SIIT)"
- RFC 2765, February 2000.
-
- [6] The Open Group Base Working Group
- http://www.opengroup.org/platform/base.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 30]
-
-
-INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-10.txt December 2002
-
-
-Authors' Addresses
-
-Bob Gilligan
-Cacheflow, Inc.
-650 Almanor Ave.
-Sunnyvale, CA 94086
-Telephone: 408-220-2084 (voice)
- 408-220-2250 (fax)
-Email: gilligan@cacheflow.com
-
-Susan Thomson
-Cisco Systems
-499 Thornall Street, 8th floor
-Edison, NJ 08837
-Telephone: 732-635-3086
-Email: sethomso@cisco.com
-
-Jim Bound
-Hewlett-Packard Company
-110 Spitbrook Road ZKO3-3/W20
-Nashua, NH 03062
-Telephone: 603-884-0062
-Email: Jim.Bound@hp.com
-
-Jack McCann
-Hewlett-Packard Company
-110 Spitbrook Road ZKO3-3/W20
-Nashua, NH 03062
-Telephone: 603-884-2608
-Email: Jack.McCann@hp.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-rfc2553bis-10.txt Expires June 2003 [Page 31]
-
+++ /dev/null
-Network Working Group Alain Durand
-INTERNET-DRAFT SUN Microsystems, inc.
-October 25, 2002 Jun-ichiro itojun Hagino
-Expires April 2002 IIJ Research Laboratory
- Dave Thaler
- Microsoft
-
-
-
-
- Well known site local unicast addresses
- to communicate with recursive DNS servers
- <draft-ietf-ipv6-dns-discovery-07.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 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 a "work in progress".
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
-
-
-Abstract
-
- This documents specifies 3 well known addresses to configure stub
- resolvers on IPv6 nodes to enable them to communicate with recursive
- DNS server with minimum configuration in the network and without
- running a discovery protocol on the end nodes. This method may be
- used when no other information about the addresses of recursive DNS
- servers is available. Implementation of stub resolvers using this as
- default configuration must provide a way to override this.
-
-
-
-Copyright notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-
-1. Introduction
-
- RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or
- more IPv6 address and default routes.
-
- However, for a node to be fully operational on a network, many other
- parameters are needed, such as the address of a name server that
- offer recursive service (a.k.a. recursive DNS server), mail relays,
- web proxies, etc. Except for name resolution, all the other services
- are usually described using names, not addresses, such as
- smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping
- reasons, a node needs to be configured with the IP address (and not
- the name) of a recursive DNS server. As IPv6 addresses look much
- more complex than IPv4 ones, there is some incentive to make this
- configuration as automatic and simple as possible.
-
- Although it would be desirable to have all configuration parameters
- configured/discovered automatically, it is common practice in IPv4
- today to ask the user to do manual configuration for some of them by
- entering server names in a configuration form. So, a solution that
- will allow for automatic configuration of the recursive DNS server is
- seen as an important step forward in the autoconfiguration story.
-
- The intended usage scenario for this proposal is a home or enterprise
- network where IPv6 nodes are plugged/unplugged with minimum
- management and use local resources available on the network to
- autoconfigure. This proposal is also useful in cellular networks
- where all mobile devices are included within the same site.
-
- 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 [KEYWORDS].
-
-
-
-
-2. Well known addresses vs discovery
-
- Some of the discussions in the past around DNS server discovery have
- been trying to characterize the solution space into stateless versus
- stateful or server oriented versus severless. It is not absolutely
- clear how much state if any needs to be kept to perform DNS server
- discovery, and, although the semantic differences between a router
- and a server are well understood from a conceptual perspective, the
- current implementations tend to blur the picture. In another attempt
- to characterize different approaches, one can look at how much
- intelligence a client needs to have in order to use the service.
-
- One avenue is to ask the IPv6 node to participate in a discovery
- protocol, such as SLP or DHCP, learn the address of the server and
- send packets to this server. Another one is to configure the IPv6
- node with well known addresses and let the local routing system
- forward packets to the right place. This document explores this
- later avenue of configuration using well known addresses that does
- not require participation of the end node in any discovery mechanism.
-
-
-
-
-
-3. Reserved prefix and addresses
-
- The mechanism described here is:
- - intended for ongoing use and not not just for bootstrapping
- - intended to populate a stub resolver's list of available
- recursive servers only if that list is otherwise unpopulated
- - providing reliability through redundancy using three unicast
- addresses.
-
-
-3.1 Stub resolver configuration
-
- This memo reserved three well known IPv6 site local addresses.
-
- In the absence of any other information about the addresses of
- recursive DNS servers, IPv6 stub-resolvers MAY use any of those three
- IPv6 addresses in their list of candidate recursive DNS servers.
-
-
-3.2 Recursive DNS servers configuration
-
- Within sites, one or more recursive DNS server SHOULD be configured
- with any of those three addresses. It is RECOMMENDED that large sites
- deploy 3 recursive DNS servers, one for each reserved address. Small
- site could use only one recursive DNS server and assign the 3
- addresses to it.
-
-
-3.3 Rationale for the choice of three addresses
-
- Three was chosen based on common practice in many places in the
- industry. While it's true that if the first one fails, that it's
- unlikely the second one will succeed (due to there really being no
- DNS server at all), using multiple addresses is important so that
- when ones do exist, the host can fail over to a second server more
- quickly than routing converges. Three servers is a compromise between
- extra reliability and increased complexity (maintaining additional
- servers, having multiple entries in the routing system, additional
- delays before the stub resolver returns an error,...).
-
- Another reason to have multiple addresses is to avoid the need to use
- of anycast addresses to achieve reliability through redundancy. On
- top of the classic problems (TCP sessions, ICMP messages,...) using
- an anycast address would hide the real locations of the recursive DNS
- servers to the stub resolver, prohibiting it to keep track of which
- servers are performing correctly. For this particular matter, using
- well known addresses is no different than configuring the stub
- resolver with regular addresses taken from the local site.
-
-
-3.4 Implementation considerations
-
- Stub resolver implementation MAY be configured by default using those
- addresses. However, implementing only the mechanism described in this
- memo may end up causing some interoperability problems when operating
- in networks where no recursive DNS server is configured with any of
- the well known addresses. Thus, stub resolvers MUST implement
- mechanisms for overriding this default, for example: manual
- configuration, L2 mechanisms and/or DHCPv6.
-
-
-
-
-4. Routing
-
- A solution to enable the stub resolvers to reach the recursive DNS
- servers is to inject host routes in the local routing system.
- Examples of methods for injecting host routes and a brief discussion
- of their fate sharing properties are presented here:
-
- a) Manual injection of routes by a router on the same subnet.
- If the node running the recursive DNS server goes down, the router
- may or may not be notified and keep announcing the route.
-
- b) Running a routing protocol on the same node running the DNS
- resolver.
- If the process running the recursive DNS server dies, the routing
- protocol may or may not be notified and keep announcing the route.
-
- c) Running a routing protocol within the same process running the
- recursive DNS server.
- If the recursive DNS server and the routing protocol run in
- separated threads, similar concerns as above are true.
-
- d) Developing an "announcement" protocol that the recursive DNS
- server could use to advertize the host route to the nearby router.
- Details of such a protocol are out of scope of this document, but
- something similar to [MLD] is possible. However, the three first
- mechanisms should cover most cases.
-
- An alternate solution is to configure a link with the well known
- prefix and position the three recursive DNS servers on that link.
- The advantage of this method is that host routes are not necessary ,
- the well known prefix is advertised to the routing system by the
- routers on the link. However, in the event of a problem on the
- physical link, all resolvers will become unreachable.
-
- IANA considerations for this prefix are covered in Section 6.
-
-
-
-5. Site local versus global scope considerations
-
- The rationales for having a site local prefix are:
-
- -a) Using a site local prefix will ensure that the traffic to the
- recursive DNS servers stays local to the site. This will prevent
- the DNS requests from accidentally leaking out of the site.
- However, the local resolver can implement a policy to forward DNS
- resolution of non-local addresses to an external DNS resolver.
-
- -b) Reverse DNS resolution of site local addresses is only
- meaningful within the site. Thus, making sure that such queries
- are first sent to a recursive DNS server located within the site
- perimeter increase their likelihood of success.
-
-
-
-
-6. Examples of use
-
- This section presents example scenarios showing how the mechanism
- described in this memo can co-exist with other techniques, namely
- manual configuration and DHCPv6 discovery.
-
- Note: those examples are just there to illustrate some usage
- scenarios and in no way do they suggest any recommended practices.
-
-
-6.1 Simple case, general purpose recursive DNS server
-
- This example shows the case of a network that manages one recursive
- DNS server and a large number of nodes running DNS stub resolvers.
- The recursive DNS server is performing (and caching) all the
- recursive queries on behalf of the stub resolvers. The recursive DNS
- server is configured with an IPv6 address taken from the prefix
- delegated to the site and with the 3 well known addresses defined in
- this memo. The stub resolvers are either configured with the "real"
- IPv6 address of the recursive DNS server or with the well known site
- local unicast addresses defined in this memo.
-
- --------------------------------------------
- | |
- | --------------------- |
- | |DNS stub resolver | |
- | |configured with the| |
- | |"real" address of | |
- | |the recursive DNS | |
- | |server | |
- | --------------------- |
- | ----------- | |
- | |recursive| | |
- | |DNS |<---------- |
- | |server |<---------------- |
- | ----------- | |
- | ---------------------- |
- | |DNS stub resolver | |
- | |configured with 3 | |
- | |well known addresses| |
- | ---------------------- |
- | |
- --------------------------------------------
-
- (The recursive DNS server is configured to listen both on
- its IPv6 address and on the well known address)
-
-
-6.2 Three recursive DNS servers
-
- This is a similar example as above, except that three recursive DNS
- resolvers are configured instead of just one.
-
- -------------------------------------------
- | |
- | --------------------- |
- | |DNS stub resolver | |
- | |configured with the| |
- | |"real" address of | |
- | |the recursive DNS | |
- | |server | |
- | --------------------- |
- | | |
- | ----------- | |
- | |recursive| | |
- | |DNS |<---------| |
- | |server 1 |<---------|------ |
- | ----------- | | |
- | | | |
- | ----------- | | |
- | |recursive| | | |
- | |DNS |<---------| | |
- | |server 2 |<---------|-----| |
- | ----------- | | |
- | | | |
- | ----------- | | |
- | |recursive| | | |
- | |DNS |<---------- | |
- | |server 3 |<---------------| |
- | ----------- | |
- | ---------------------- |
- | |DNS stub resolver | |
- | |configured with 3 | |
- | |well known addresses| |
- | ---------------------- |
- | |
- -------------------------------------------
-
- (The recursive DNS server is configured to listen both on
- its IPv6 address and on the well known address)
-
-
-6.3 DNS forwarder
-
- A drawback of the choice of site local scope for the reserved
- addresses for recursive DNS server is that, in the case of a
- home/small office network connected to an ISP, DNS traffic cannot be
- sent directly to the ISP recursive DNS server without having the ISP
- and all its customers share the same definition of site.
-
- In this scenario, the home/small office network is connected to the
- ISP router (PE) via an edge router (CPE).
-
- -------------
- / |
- -------- ----- / |
- |ISP PE| |CPE| / Customer |
- | |===========| |====< site |
- | | | | \ |
- -------- ----- \ |
- \ |
- -------------
-
-
- The customer router CPE could be configured on its internal interface
- with one of the reserved site local addresses and listen for DNS
- queries. It would be configured to use one (or several) of the well
- known site local unicast addresses within the ISP's site to send its
- own queries to. It would act as a DNS forwarder, forwarding queries
- received on its internal interface to the ISP's recursive DNS server.
-
- -------------
- / |
- ---------- -------------- / |
- |ISP | | CPE| / Customer |
- |DNS |===========| DNS|====< site |
- |server | <------|---forwarder|-----\---- |
- ---------- -------------- \ |
- \ |
- -------------
-
- In this configuration, the CPE is acting as a multi-sited router.
-
-
-6.4 DNS forwarder with DHCPv6 interactions
-
- In this variant scenario, DHCPv6 is be used between the PE and CPE to
- do prefix delegation [DELEG] and recursive DNS server discovery.
-
- -------------
- / |
- -------- -------------- / |
- |ISP | |customer CPE| / Customer |
- |DHCPv6|===========| DHCPv6|====< site |
- |server| <------|------client| \ |
- -------- -------------- \ |
- \ |
- -------------
-
- This example will show how DHCPv6 and well known site local unicast
- addresses cooperate to enable the internal nodes to access DNS.
-
- The customer router CPE is configured on its internal interface with
- one of the reserved site local addresses and listen for DNS queries.
- It would act as a DNS forwarder, as in 5.2, forwarding those queries
- to the recursive DNS server pointed out by the ISP in the DHCPv6
- exchange.
-
- -------------
- / |
- ---------- -------------- / |
- |ISP | |customer CPE| / Customer |
- |DNS |===========| DNS|====< site |
- |resolver| <------|---forwarder|-----\---- |
- ---------- -------------- \ |
- \ |
- -------------
-
-
- The same CPE router could also implement a local DHCPv6 server and
- advertizes itself as DNS forwarder.
-
- -------------
- / |
- -------- -------------- / Customer |
- |ISP PE| |customer CPE| / site |
- | |===========|DHCPv6 |====< |
- | | |server------|-----\---> |
- -------- -------------- \ |
- \ |
- -------------
-
-
-
- Within the site:
-
- a) DHCPv6 aware clients use DHCPv6 to obtain the address of the
- DNS forwarder...
-
- -------------
- / |
- ---------- -------------- / Customer |
- |ISP | |customer CPE| / site |
- |DNS |===========| DNS|====< |
- |resolver| <------|---forwarder|-----\----DHCPv6 |
- ---------- -------------- \ client |
- \ |
- -------------
- (The address of the DNS forwarder is acquired via DHCPv6.)
-
-
- b) other nodes simply send their DNS request to the reserved site
- local addresses.
-
- -------------
- / |
- ---------- -------------- / customer |
- |ISP | |customer CPE| / site |
- |DNS |===========| DNS|====< |
- |resolver| <------|---forwarder|-----\----non DHCPv6|
- ---------- -------------- \ node |
- \ |
- -------------
- (Internal nodes use the reserved site local unicast address.)
-
-
- A variant of this scenario is the CPE can decide to pass the global
- address of the ISP recursive DNS server in the DHCPv6 exchange with
- the internal nodes.
-
-
-
-7. IANA considerations
-
- The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out
- of the site local fec0::/10 prefix.
-
- The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2
- and fec0:000:0000:ffff::3 are to be reserved for recursive DNS server
- configuration.
-
- All other addresses within the fec0:0000:0000:ffff::/64 are reserved
- for future use and are expected to be assigned only with IESG
- approval.
-
-
-
-
-8. Security Considerations
-
- Ensuring that queries reach a legitimate DNS server relies on the
- security of the IPv6 routing infrastructure. The issues here are the
- same as those for protecting basic IPv6 connectivity.
-
- IPsec/IKE can be used as the well known addresses are used as unicast
- addresses.
-
- The payload can be protected using standard DNS security techniques.
- If the client can preconfigure a well known private or public key
- then TSIG [TSIG] can be used with the same packets presented for the
- query. If this is not the case, then TSIG keys will have to be
- negotiated using [TKEY]. After the client has the proper key then
- the query can be performed.
-
- The use of site local addresses instead of global addresses will
- ensure the DNS queries issued by host using this mechanism will not
- leak out of the site.
-
-
-
-
-9. References
-
- [KEYWORDS]
- Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [ADDRCONF]
- Thomson, S., and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC 2462, December 1998.
-
- [MLD]
- Deering, S., Fenner, W., Haberman, B.,
- "Multicast Listener Discovery (MLD) for IPv6",
- RFC2710, October 1999.
-
- [TSIG]
- Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC2845, May 2000.
-
- [TKEY]
- D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)",
- RFC2930, September 2000.
-
- [DHCPv6]
- Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and
- Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6
- (DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress),
- Februray 2002.
-
- [DELEG]
- Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6",
- draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress),
- February 2002.
-
-
-
-
-10. Authors' Addresses
-
- Alain Durand
- SUN microsystems, inc.
- 17 Network Circle, UMPK 17-202
- Menlo Park, CA 94025
- Email: Alain.Durand@sun.com
-
- Jun-ichiro itojun HAGINO
- Research Laboratory, Internet Initiative Japan Inc.
- Takebashi Yasuda Bldg.,
- 3-13 Kanda Nishiki-cho,
- Chiyoda-ku, Tokyo 101-0054, JAPAN
- Email: itojun@iijlab.net
-
- Dave Thaler
- Microsoft
- One Microsoft Way
- Redmond, CA 98052, USA
- Email: dthaler@microsoft.com
-
-
-
-
-11. 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 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+++ /dev/null
-Network Working Group Keith Moore
-Internet-Draft University of Tennessee
-14 November 2001
-Expires: 14 May 2002
-
-
- 6to4 and DNS
-
- draft-ietf-ngtrans-6to4-dns-00.txt
-
- 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.
-
- Comments regarding this internet-draft should be sent to the
-mailing list of the IETF ngtrans working group. Refer to the IETF web
-site at http://www.ietf.org/ for current contact information for IETF
-working groups. Please include the document identifier
-"draft-ietf-ngtrans-6to4-dns-00.txt" in any comments regarding this
-document.
-
- This document supersedes draft-moore-6to4-dns-02.txt.
-
-Abstract
-
- This memo discusses several potential mechanisms for locating the
-DNS servers which provide "reverse lookup" of 6to4 addresses.
-
- Please note that this is a preliminary draft which only attempts to
-outline possible means of solving the problem, for purpose of
-discussion. This version of the proposal is NOT rigorously specified,
-and the author claims significant expertise in neither DNS nor anycast.
-Nevertheless, it is hoped that these proposals are sufficiently detailed
-to allow reviewers to make a first-order assessment of their viability.
-
-
-
-Moore Expires 14 May 2002 [Page 1]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
-The assistance of appropriate experts in drafting future revisions of
-these proposals would be most welcome.
-
-1. Introduction
-
- 6to4 [1] defines a mechanism for allowing sites to communicate
-using IPv6 over the public IPv4 Internet. It does so by assigning a
-block of IPv6 addresses corresponding to any "public" (globally-scoped)
-IPv4 address, and a means of tunneling IPv6 traffic destined for such
-addresses over the IPv4 Internet. In this way, any site which is
-connected to the IPv4 Internet and which has at least one global IPv4
-address assigned to it, can communicate with IPv6.
-
- The advantage of 6to4 is that it decouples deployment of IPv6 by
-the core of the network (e.g. Internet Service Providers or ISPs) from
-deployment of IPv6 at the edges (e.g. customer sites), allowing each
-site or ISP to deploy IPv6 support in its own time frame according to
-its own priorities. With 6to4, the edges may communicate with one
-another using IPv6 even if one or more of their ISPs do not yet provide
-native IPv6 service. In addition, the principal cost of the 6to4
-transition mechanism is borne by those who benefit from it.
-
- However, the ability to perform so-called "reverse lookups" (IP
-address to domain name lookups) in DNS requires that there be a
-delegation path for the IP address being queried, from the DNS root to
-the servers for the DNA zone which provides PTR the records for that IP
-address. For ordinary IPv6 addresses, the necessary DNS servers and
-records for IPv6 reverse lookups would be maintained by the each
-organization to which an address block is delegated; the delegation path
-of DNS records reflects the delegation of address blocks themselves.
-However, for IPv6 addresses beginning with the 6to4 address prefix, the
-DNS records would need to reflect IPv4 address delegation. Since the
-entire motivation of 6to4 is to decouple site deployment of IPv6 from
-infrastructure deployment of IPv6, such records cannot be expected to be
-present for a site using 6to4 - especially for a site whose ISP did not
-yet support IPv6 in any form.
-
- This memo discusses several potential mechanisms for locating the
-DNS servers which are assumed to provide "reverse lookup" of 6to4
-addresses.
-
-1.1. Notation
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119.
-
-
-
-
-
-Moore Expires 14 May 2002 [Page 2]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
- The characters "{" and "}" are used to indicate protocol elements
-where literal DNS labels or addresses would appear in actual use;
-neither these delimiters nor the text appearing within are to be
-interpreted literally.
-
-2. Design Goals
-
- An ideal solution to this problem would have several
-characteristics:
-
-- Minimal impact on existing software and operations.
-
-- Reasonable efficiency for lookup of names corresponding to 6to4
- addresses.
-
-- Minimal effort in deployment of DNS support.
-
-- Costs borne primarily by those who immediately benefit.
-
-- Does not adversely affect security of DNS queries.
-
-- Any assumptions made by client or server software as to the
- location of authoritative DNS server(s) for reverse lookup of a
- 6to4 address, are made only if no explicit referral information is
- present.
-
- No attempt has yet been made to establish relative importance of
-these goals.
-
-3. Methods of Inferring Delegation Paths
-
- The author has identified two methods of inferring delegation paths
-in the absence of explicit delegation information (NS or DNAME records)
-for reverse lookups of IPv6 addresses in the DNS. The first is to
-assume that the default DNS servers for reverse lookup of a 6to4 address
-are the same servers that are responsible for reverse lookup of the
-corresponding IPv4 address. The second is to assume that the default
-DNS servers for reverse lookup of a 6to4 address are reachable via some
-well-known anycast address which is derivable from the 6to4 prefix.
-While it might be possible to employ both of these methods, or use them
-in some combination, at first glance it seems better to choose one
-method or the other.
-
- In both methods, the actual PTR records for 6to4 addresses are
-explicitly maintained by the site to which that portion of 6to4 space is
-assigned (i.e. the site to whom the corresponding portion of IPv4 space
-- perhaps as little as a single IPv4 address - is assigned). This
-proposal never makes assumptions about the mapping between specific 6to4
-
-
-
-Moore Expires 14 May 2002 [Page 3]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
-addresses and specific host names.
-
- Note also that both methods infer NS records, rather than DNAME
-records [2], for query referral. This is because it seems undesirable
-for any automatically generated resource record, or a resource record
-which is assumed by a third party, to make assumptions about a different
-organization's domain name space. In other words, while it might seem
-fairly safe to say
-
- "If there are PTR resource records for an address in this portion of
- 6to4 space, they will be found on the same servers as the PTR records
- for the corresponding portions of IPv4 space"
-
-it may not be safe to say
-
- "If there are PTR records for an address in this portion of 6to4 space,
- those records will be named after the DNS name(s) of the server(s) used
- for the same portion of IPv4 space".
-
-
-3.1 6to4 NS records derived from IPv4 NS records
-
- This method assumes that the default DNS servers for reverse lookup
-of a 6to4 address are the same servers that are responsible for reverse
-lookup of the corresponding IPv4 address. In effect, if there is a NS
-resource record that refers reverse queries for a portion of IPv4
-address space to some set of DNS servers, we want to behave (in the
-absence of explicit records to the contrary) as if there is a similar NS
-record for the portion of IPv6 address space corresponding to those IPv4
-addresses.
-
- More formally, for every resource record of the form:
-
-{address-bits}.IN-ADDR.ARPA. NS some-domain.example.com.
-
-we want to have the effect of also having a resource record of the form:
-
-{address-bits}.\[x2002].IP6.ARPA. NS some-domain.example.com.
-
-unless the lookup for the IPv6 address can be fulfilled by explicit (NS
-or DNAME) resource records. The following sections discuss various ways
-of producing the effect. The NS records so generated or assumed (by
-whatever means) are termed "pseudo-records" to distinguish them from
-explicitly-supplied NS records.
-
- Note that due to the different ways of representing {address-bits}
-in DNS labels between IPv4 and IPv6, and the different ways of referring
-queries in each address space, a transformation (to be specified later)
-
-
-
-Moore Expires 14 May 2002 [Page 4]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
-will be required. The TTLs of the NS pseudo-records so generated should
-be no larger than those of the NS records from which they were derived;
-in some cases it may be desirable to make them smaller.
-
- This method has the advantage that 6to4 sites do not need to
-establish new DNS servers, nor to get those servers to answer to new
-addresses, in order to implement reverse lookup service for 6to4
-addresses. It need only add the appropriate resource records to its
-existing DNS servers which perform those functions for IPv4. However,
-this method only works for sites that already operate their own DNS
-servers which provide reverse lookup for IPv4 addresses. Specifically,
-sites with only a single IPv4 address may form a significant population
-of 6to4 users, but such sites are unlikely to operate their own DNS
-servers for reverse lookups of IPv4 addresses.
-
-3.2 6to4 NS records inferred from 6to4 prefix
-
- This method assumes that the default DNS servers for reverse lookup
-of a 6to4 address are reachable at a local (to the destination network)
-anycast address which is derived from the 6to4 prefix.
-
- More formally, in the absence of any explicit DNAME or NS resource
-records for the suffix {IPv4-address}.\[x2002].IP6.ARPA, resource
-records of the form
-
-{IPv4-address}.\[x2002].IP6.ARPA. NS {label}
-{label} AAAA 2002:{IPv4-address}:{suffix}
-
-are inferred. Here, {IPv4-address} is a 32-bits of IPv4 address
-represented as a bit-string label, {label} is a domain-name which is
-created for the purpose of associating a 6to4 address with its DNS
-servers (since NS records must refer to a DNS name rather than an IPv6
-address), and {suffix} is a well-known constant bit pattern (to be
-determined) which is treated as an anycast address by the 6to4 network.
-The 6to4 network then establishes one or more DNS servers to listen to
-that anycast address which will answer reverse lookup queries.
-
- Note that if a site uses more than one 6to4 prefix (because it has
-more than one IPv4 address assigned to it), its DNS servers which are
-responsible for reverse lookups will be required to accept queries at
-multiple addresses.
-
- A variant of this method would be to define a set of suffixes for
-this purpose, rather than a single suffix, and to infer a set of AAAA
-records (one for each of the suffixes) rather than a single AAAA record.
-This would allow a 6to4 site to establish multiple servers for reverse
-lookups without having to arrange for anycast access. (One difficulty
-with using anycast is in arranging for the hosts to respond to Neighbor
-
-
-
-Moore Expires 14 May 2002 [Page 5]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
-Solicitation queries at those addresses only when the DNS servers on
-those hosts are correctly operating. Absent such a mechanism, client-
-based fail-over between separate addresses appears more reliable, if
-slower, than server selection by anycast.)
-
-3.3 DNS-based Multihoming
-
- With either of these methods, sites which have multiple IPv4
-address blocks and which wish to run "multihomed 6to4" may still do so
-by installing their own DNAME records. That is, if an organization is
-assigned {IPv4-prefix-1} and {IPv4-prefix-2}, it may still maintain the
-address-to-name mappings of its 6to4 hosts in a single DNS zone, by
-creating DNAME records of the form:
-
-{IPv4-prefix-1}.\[x2002].IP6.ARPA DNAME ip6dns.example.com.
-{IPv4-prefix-2}.\[x2002].IP6.ARPA DNAME ip6dns.example.com.
-
-on the appropriate DNS servers. A similar technique can be used to
-allow a site to share a single set of PTR records between 6to4 and
-native prefixes (and thus ease the transition from 6to4 to native),
-provided that the "locally assigned" bits of each 6to4 address will also
-fit within the space remaining after each of the "native" prefixes.
-
-4 Methods of adapting existing software to infer delegation paths
-
- The following paragraphs detail several possible techniques which
-might allow existing platforms to infer these delegation paths with
-varying degrees of disruption. They are not mutually-exclusive; it is
-possible to employ more than of these techniques. Some of them are less
-attractive than others. At present the purpose of this document is to
-outline several possible approaches, and serve as a focal point of
-discussion, rather than to categorically recommend any particular
-approach.
-
- Most of these implementation methods can be used with either method
-of inferring NS records - either deriving them from v4 NS records
-(section 3.1) or using an anycast address (section 3.2).
-
-4.1. Explicit delegation of NS records for 6to4 address lookup
-
- This implementation method makes no changes to any DNS client or
-server software. Rather, it expects that the root servers, ISPs DNS
-servers, and the DNS servers of other organizations which delegate IPv4
-address space, will be populated with similar NS records which refer
-reverse lookup queries from 6to4 space.
-
- Unless and until the assignee of the IPv4 address requested that
-IPv6 queries be referred to different servers (i.e. that new DNAME or NS
-
-
-
-Moore Expires 14 May 2002 [Page 6]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
-RRs be installed), any changes made to the NS records for IPv4 addresses
-would also need to be reflected in the corresponding NS records for IPv6
-addresses in 6to4 space.
-
- As stated above, this technique requires no software changes to
-either DNS server or client software. However, it would certainly
-require changes to the software used by registries, ISPs, and other
-networks, to maintain the DNS records needed to provide reverse lookups.
-
- This implementation method may be used with either method of
-inferring NS records. In other words, either new NS records could
-either be derived from existing NS records for IPv4 addresses, or new NS
-and AAAA records could be created assuming that servers would be
-established at one or more suffixes within a 6to4 subnet prefix. In
-either case a site must be allowed to change the records associated with
-its 6to4 prefix after they are established.
-
- This implementation method avoids kludges to DNS software but is
-assumed to be difficult to deploy, as it requires several different
-organizations to explicitly support 6to4.
-
-4.2. Pseudo-records generated by DNS servers for the IPv4 zones
-
- In this technique, the authoritative DNS servers for IN-ADDR.ARPA
-and its subdomains would be modified to return "psuedo-records" for any
-query of type PTR or NS which matched a name of the form
-"{something}.\[x2002].IP6.ARPA".
-
- In particular,
-
-- if the server had explicit records matching the label of a PTR
- query, those records would be returned and no pseudo-records would
- be returned;
-
-- if the server had explicit NS records matching the label or a
- suffix of the label of an NS or PTR query, those records would be
- returned and no pseudo-records would be returned;
-
-- (if the method in section 3.1 were used) otherwise, if the server
- had NS records matching {something}.IN-ADDR.ARPA, or matching any
- IPv4 address prefix of {something}.IN-ADDR.ARPA, NS pseudo-records
- corresponding to the longest matching prefixes would be returned.
- The pseudo-records so returned would be marked authoritative, and
- their TTLs would be no larger than the TTLs of the explicit records
- from which the pseudo-records were derived.
-
-- (if the method in section 3.2 is used) otherwise, the server would
- return a NS pseudo-record corresponding to the 6to4 prefix, which
-
-
-
-Moore Expires 14 May 2002 [Page 7]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
- pointed to a label for which one or more AAAA pseudo-records
- containing the well-known address(es) for reverse lookups at that
- prefix. The AAAA addresses would be returned as additional
- information in response to the NS or PRT query, but would
- necesarily also be obtainable from a separate AAAA or A6 query for
- any {label} returned in an NS pseudo-record.
-
- This technique is assumed to be somewhat easier to deploy than the
-previous one, because it automates the generation of the pseudo-records
-and avoids the need for each organization that delegates IPv4 space to
-change its DNS maintenance procedures. However, it still requires
-changes to DNS servers, and it requires those organizations to upgrade
-their DNS servers to include those changes, before the change will be
-useful. It also requires cooperation on behalf of the owner of the DNS
-servers providing lookup for an IPv4 address, which might not be the
-same party that is using the corresponding 6to4 addresses.
-
-4.3. Pseudo-records generated by DNS resolvers
-
- In this technique, DNS servers which act as resolvers behave as if
-pseudo-records had been returned to them when some kinds of queries
-fail. In some cases they may return pseudo-records when a query fails.
-
- When such a resolver received a PTR or NS query for a label that
-had a \[x2002].IP6.ARPA suffix, it would first attempt to satisfy that
-query from its cache, or failing that, by forwarding the query to an
-upstream server. If that query failed due to a "no such domain" error,
-the resolver would then attempt to find the server for the
-{something}.\[x2002].IP6.ARPA label by (if the method in section 3.1 is
-used) issuing an NS query for {something}.IN-ADDR.ARPA, or (if the
-method in section 3.2 is used) inferring NS and AAAA records based on
-the 6to4 prefix of the address.
-
- If the method in section 3.1 were used, and the original query was
-for PTR records, and one or more NS records were found for
-{something}.IN-ADDR.ARPA, the resolver would then forward the original
-query for {something}.\[x2002].IP6.ARPA to one or more of those servers,
-and return the results from one of the forwarded queries if any were
-successful. If the original query was for NS records, and one or more
-NS records were found for {something}.IN-ADDR.ARPA, the resolver would
-then return the pseudo-records corresponding to the IN-ADDR.ARPA
-domains. Those pseudo-records would NOT be marked as authoritative, and
-the resolver would NOT cache those records.
-
- Similarly, if the method in section 3.2 were used, the resolver
-would return NS and AAAA pseudo-records derived from the IPv6 address
-being queried.
-
-
-
-
-Moore Expires 14 May 2002 [Page 8]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
- Note that while the DNS resolver effectively behaves as if pseudo-
-records had been returned to it by other servers, it MUST NOT cache
-those pseudo-records. However, it MAY cache the actual NS or PTR
-records returned by those servers and use such cached data to generate
-additional pseudo-records.
-
- This technique requires changes to DNS resolver software, and
-requires that sites using IPv6 and wishing to communicate with 6to4
-sites, upgrade their DNS resolvers to include this change. However it
-does not require changes of IPv6 hosts.
-
-4.4 Pseudo-records generated by DNS query libraries
-
- In this technique, the run-time library used on a host by
-applications is modified to process DNS queries in the following manner:
-
- If the query is of type PTR or NS, and the label queried has a
-suffix of \[x2002].IP6.ARPA, or if the query is otherwise intended to
-perform an reverse lookup, and the address being looked up is a 6to4
-address, an attempt is first made to look up the address via normal
-means. If this attempt failed due to the lack of any delegation of the
-6to4 prefix, NS and perhaps AAAA pseudo-records are inferred according
-to sections 3.1 and/or 3.2 (whichever ends up being chosen).
-
- If the method in section 3.1 is chosen, a query is made
-(internally) for NS records corresponding to the embedded IPv4 address.
-If this secondary query is successful, the original DNS query for the
-6to4 address is re-issued to the servers which are authoritative for
-that IPv4 address; the result is determined from the response to that
-query.
-
- This technique requires changes to DNS query libraries (or
-applications), and requires that hosts and/or applications using IPv6,
-and which wish to communicate with hosts and/or applications at 6to4
-sites, upgrade their DNS libraries to include this change.
-
-5. Author's Recommendations
-
- For the purpose of facilitating discussion, the author tentatively
-recommends that the following combination of methods be used:
-
- Locations of DNS servers to be used for reverse lookups should be
-obtained in the following manner:
-
-- First, attempt to perform the lookup in the normal way used for any
- IPv6 address, by issuing a query for {address}.ip6.arpa. If the
- result of this query is one or more PTR records, these results are
- used and the lookup is complete.
-
-
-
-Moore Expires 14 May 2002 [Page 9]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
-- Else, if the result of this query indicates that lookups for a
- prefix of the queried IPv6 address, greater than or equal to 48
- bits in length, have explicitly been delegated, but the query could
- not be completed due to some error, the error is returned and the
- lookup is complete.
-
-- Else, the method of inferring NS and AAAA records described in
- section 3.2 is used, with two or three well-known suffixes chosen
- rather than a single anycast address. Assigning two or three well-
- known suffixes rather than a single suffix allows a small site to
- provide redundant servers for reverse lookup without having to
- implement anycast.
-
- This method is recommended both in preference to, and instead of,
- the method in section 3.1 because it is anticipated that many 6to4
- sites will be using a single IPv4 address and will not have reverse
- lookup for that IPv4 address delegated to their name servers. (In
- other words, NS records delegating the reverse lookup of 32-bit
- IPv4 prefixes are assumed to be rare.)
-
- Implementation of the above algorithm should be provided by both
-host-based DNS query libraries and (as a configuration option) by
-resolver servers. Thus, if either the host-based query library (for
-dynamically-linked applications) or the local resolver server has been
-upgraded to infer delegation of 6to4 addresses, applications on that
-host will be able to perform lookups of 6to4 addresses in the absence of
-explicit delegation.
-
- This compromise largely preserves the favorable deployment
-characteristics of 6to4 - namely, that hosts and networks can use 6to4
-without explicit support from the existing IPv4 network infrastructure.
-Implementing the algorithm in both query libraries in resolvers allows
-existing IPv6 hosts and applications to lookup 6to4 addresses without
-having to upgrade all of their hosts, while still allowing lookups for
-single hosts and small sites which cannot reconfigure their DNS resolver
-servers. However it does require that all IPv6 sites - not just those
-on 6to4 networks - upgrade their query libraries and/or resolvers if
-they wish to perform reverse lookups on 6to4 addresses.
-
- Meanwhile, root servers, regional address registries, and ISPs are
-encouraged to populate and maintain the \[x2002].IP6.ARPA zone to refer
-queries for 6to4 addresses to the same servers as are used to look up
-the corresponding IPv4 addresses in the IN-ADDR.ARPA zone.
-
-6. Security Considerations
-
- The use of well-known address suffixes for DNS servers would allow
-hosts that could choose their own addresses to provide inverse name
-
-
-
-Moore Expires 14 May 2002 [Page 10]
-\f6to4 and DNS INTERNET-DRAFT 14 November 2001
-
-
-lookups in the absence of explicit delegation by the network
-administrators. For this reason, it is necessary to check for explicit
-delegation of reverse lookup service before using results obtained from
-queries to well-known addresses.
-
- In addition, sites running 6to4 which do not provide reverse lookup
-service at each of the well-known address suffixes, should take measures
-to prevent ordinary hosts from assuming the role of DNS servers. For
-example, a site might make a decision to disallow those addresses being
-used by ordinary hosts and to filter any traffic originating from those
-addresses which were not assigned to DNS servers.
-
- Pseudo-records that are automatically derived from other DNS
-records cannot be signed using DNSSEC, even if the explicit records from
-which the pseudo-records are derived are signed. Since explicit records
-take precedence over pseudo-records, a host or application SHOULD NOT
-trust a signed NS record referring a query for some portion of IPv4
-space as evidence of authoritative referral to the corresponding portion
-of 6to4 space unless it has evidence that there are no explicit records
-present for that portion of 6to4 space.
-
-7. Author's Address
-
-Keith Moore
-University of Tennessee, Knoxville
-1122 Volunteer Blvd, Suite 203
-Knoxville TN, 37996-3450
-USA
-email: moore@cs.utk.edu
-
-
-8. References
-
-[1]. Carpenter, B., Moore, K. Connection of IPv6 Domains via IPv4
- Clouds. RFC 3056, February 2001.
-
-[2]. Crawford, M., Huitema, C., Thomson, S. DNS Extensions to Support
- IPv6 Address Aggregation and Renumbering. RFC 2874, July 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Moore Expires 14 May 2002 [Page 11]
-\f
+++ /dev/null
-Internet Engineering Task Force Alain Durand
-INTERNET-DRAFT SUN Microsystems
-November 20, 2001 Johan Ihren
-Expires May 21, 2002 Autonomica AB
-
-
-
- NGtrans IPv6 DNS operational requirements and roadmap
-
- draft-ietf-ngtrans-dns-ops-req-03.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 IPv6 DNS operational requirements and
- deployment roadmap steps. It is the result of discussion from members
- of the IPv6, NGtrans, DNSop and DNSext working groups. The DNS is
- looked as a critical part of the Internet infrastructure and is used
- for much more purposes than name to address resolution. Thus a
- smooth operation of the DNS is critical in the IPv6 transition.
-
- Discussion of this memo should happen in the NGtrans mailing list.
-
- 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].
-
-
-
-
-1. DNS issues in a mixed IPv4/IPv6 environment
-
-
- IPv4 and IPv6 are two versions of the same original concept, but they
- are not "binary compatible". That is, a datagram send by one version
- of IP cannot be received by the other. Several things can go wrong
- when operating DNS in a mixed environment IPv4 and IPv6.
-
-
-1.1 Following the referral chain
-
- The caching resolver that tries to lookup 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
- a type of transport that is unavailable, 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 and the complete
- DNS hierarchy 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.
-
-
-1.2 Examples of problems for an IPv6 only resolver
-
- This problem shows for IPv6 only resolver trying to fetch data from a
- zone that is served by IPv6 servers when somewhere in the referral
- chain, the list of name servers pointed at does not contain any IPv6
- reachable server.
-
- Hints for the root:
-
- X.ROOT-SERVERS.NET IN A 100.100.100.101
- X.ROOT-SERVERS.NET IN AAAA 3ffe:ffff:100:100::1
-
- In the root zone:
-
- org. IN NS dot-org.X.ROOT-SERVERS.NET
- dot-org.X.ROOT-SERVERS.NET IN A 100.100.100.102
-
- In the .org zone:
-
- foobar.org. IN NS ns.foobar.org
- ns.foobar.org IN A 200.200.200.201
- ns.foobar.org IN AAAA 3ffe:ffff:200:200::201
-
- In the foobar.org zone:
-
- www.foorbar.org IN AAAA 3ffe:ffff:200:200::202
-
- Although the zone foobar.org and the root are served by an IPv6
- server, an IPv6 only resolver can not resolve www.foobar.org because
- there is no IPv6 server for the parent zone .org.
-
-
-1.3 Examples of problems for an IPv4 only resolver
-
- Another instance of the problem shows for an IPv4 only MTA trying to
- send mail to someone in an IPv6 only domain which has made provision
- to have an IPv4 reachable MX.
-
- In the .org zone:
-
- foobar.org. IN NS ns.foobar.org
- ns.foobar.org IN AAAA 3ffe:ffff:200:200::201
-
- 3rd_party_dualstack_mail.org. IN NS ns.3rd_party_dualstack.org.
- ns.3rd_party_dualstack.org. IN A 100.100.100.103
-
- in the foobar.org zone:
-
- foobar.org IN MX 10 mail6.foobar.org.
- foobar.org IN MX 20 mail4.3rd_party_dualstack.org.
- mail6.foobar.org. IN AAAA 3ffe:ffff:200:200::202
-
- in the 3rd_party_dualstack_mail.org zone:
-
- mail4.3rd_party_dualstack.org. IN A 100.100.100.104
-
- An IPv4 only host cannot get the information about the IPv4 MX relay
- mail4.3rd_party_dualstack_mail.org because the foobar.org zone is not
- served by an IPv4 DNS server.
-
-
-
-2. Fundamental requirements
-
-
-2.1 Uniqueness of the DNS root
-
- [RFC2826] requires the existence of a globally unique public name
- space derived from a unique root. This root is valid for both IPv4
- and IPv6.
-
- --------------------------------------------------------------------
- Requirement 1:
-
- The public DNS has a unique root valid for IPv4 & IPv6.
- --------------------------------------------------------------------
-
-
-2.2 DNS should be an IP version agnostic application
-
- Although DNS is regarded as a key component of the Internet
- infrastructure, it is an application at layer 7 of OSI model and
- should be independent from particular protocol choice at the network
- layer. Some record type, like CNAME or MX are clearly IP version
- agnostic. Even data like A, AAAA or PTR records contained in the DNS
- may be relevant to particular applications requesting then regardless
- of the IP version used during the queries. Also, [RFC2826] states, "A
- DNS name can be passed from one party to another without altering the
- semantic intent of the name." So, this is not because a particular
- host can only communicate with a certain version of IP that it should
- be prevented to query information regarding the over version of IP.
- Another way of saying this is to say that the DNS data are
- independent of the particular version of IP used to carry them.
-
- --------------------------------------------------------------------
- Requirement 2:
-
- Any node SHOULD be able to query any data from the DNS regardless of
- the IP versions used for the transport of the queries and responses
- issued by the various parties in place.
- --------------------------------------------------------------------
-
-
-2.3 Transition is a long journey
-
- It is usually believed that transition can happen simultaneously following
- two main scenarios.
-
- - Incremental deployment on existing network.
-
- This needs to be done without disturbing IPv4 service. This
- strategy relies heavily on dual-stack nodes and tunnels. It is
- foreseen that this scenario is likely to happen in corporate
- networks.
-
- - Large scale deployment of new infrastructure
-
- This scenario envision large to very large networks where public
- IPv4 address space is not available and private address is not
- practical. Nodes in this scenario will very likely be IPv6-only
- or IPv6-mostly (getting an IPv4 address only on demand). Note
- that those networks will still need to communicate with the rest
- of the Internet.
-
- Given the two above scenarios, the requirements discussed in this
- memo are not targeted at transitioning the DNS from IPv4 only to IPv6
- only, but more at the transition of IPv4 only to a mixed environment,
- where some systems will be IPv4 only, some will be IPv6 only and
- others will be dual-stacked.
-
- It is generally admitted that, the burden of transition should be
- placed on the new IPv6 systems and their local IPv6 infrastructure.
- Ad-hoc administrative practices such as a local dual stack resolver
- or locally Local dual stack resolver or locally administered NAT-PT
- translator [RFC2766] could enable networks where some dual stacks
- node are available to query IPv4 only DNS servers. (Note that NAT-PT
- would have to be modified for that purpose as it translate AAAA
- queries into A queries.) Administrative practices requiring any zone
- served by IPv6 only servers to be also served by IPv4 servers would
- enable IPv4 only resolvers to perform DNS queries for those zones.
-
- However, the requirements described here are looking at solving the
- long term problem. Although dual stack networks will be common in the
- early days of transition, IPv6 only networks would eventually be a
- reality and solutions describe above would not be practical.
-
-
- --------------------------------------------------------------------
- Requirement 3:
-
- A global bridging system IS REQUIRED to enable networks operating
- with only one version of IP to query zones of the public DNS that are
- only served by systems operating only with the over version of IP.
- --------------------------------------------------------------------
-
- The choice and the details of this bridging system are beyond the
- scope of this document and should be discussed in the DNSop and
- DNSext working groups. It can be the case that a general purpose,
- ubiquitous translator will be the right thing or that a DNS specific
- solution must be developed. If new pieces of protocols are needed in
- the resolvers, due to the extraordinary amount of time it takes to
- define then, implement them, test them, ship them into existing
- products and get them deployed, works should start as soon as
- possible.
-
-
-
-3. Bridging system requirements
-
-
- Even though bridging has to work both ways, it is not strictly
- necessary to use the same technique in each direction. That is, it is
- perfectly acceptable to build two different mechanisms, one to enable
- IPv4 only hosts to query IPv6 only DNS servers and one for IPv6 only
- hosts to query IPv4 only DNS servers. It is also possible that part
- of the bridging system consists of a set of administrative procedures
- required to operate DNS zones.
-
-
-3.1 IPv4 contraints
-
- Due to the very large IPv4 deployment phase, any solution that will
- require any change either on binaries or configurations on every IPv4
- resolvers is out of scope.
-
-
-3.2 Scaling the bridging system
-
- The bridging system that enable a resolver to query data from a
- server which use a different IP version will have to be in place for
- a long time. It will be a key part of the general IPv6 transition and
- will heavily be used.
-
- --------------------------------------------------------------------
- Requirement 4:
-
- The bridging system SHOULD have good scaling properties.
- --------------------------------------------------------------------
-
-
-3.3 Scaling even more the bridging system
-
- Auto configuration is the tendency for end systems. Resolver SHOULD
- have a way to discover the bridging system components. This
- discovery mechanism SHOULD also have good scaling properties.
-
- --------------------------------------------------------------------
- Requirement 5:
-
- The discovery mechanism of the bridging system SHOULD have good
- scaling properties.
- --------------------------------------------------------------------
-
-
-3.3 Scope of the bridging system
-
- The bridging systems SHOULD be able to bridge any zones. In
- particular, until there is an IPv6 root name server, the bridging
- systems SHOULD be able to bridge the IPv4 root.
-
- --------------------------------------------------------------------
- Requirement 6:
- All zones (even the root) SHOULD be reachable via the bridging
- system.
- --------------------------------------------------------------------
-
-
-3.4 Security matters
-
- Being a critical piece of the Internet infrastructure, the DNS is a
- potential value target and thus should be protected. Great care
- should be used not to introduce new security issues while designing
- the bridging system.
-
- --------------------------------------------------------------------
- Requirement 7:
-
- The bridging system SHOULD NOT introduce new security hazards.
- --------------------------------------------------------------------
-
-
-3.5 bridging from IPv4
-
- Although the details of the bridging systems are beyond the scope of
- this document, it may be the case that there is no general solution
- to allow an unmodified IPv4 resolver to query an IPv6 only name
- server. In that would be the case, the IPv4 to IPv6 bridging system
- could consist of an operational procedure:
-
- --------------------------------------------------------------------
- Possible operational procedure to bridge from IPv4 to IPv6:
-
- Any zone SHOULD be served by at least one IPv4 DNS server.
- --------------------------------------------------------------------
-
-
-
-4. Roadmap for DNS service in a mixed environment IPv4/IPv6
-
-
-4.1 Bridging system
-
- A bridging system satisfying all the above requirements SHOULD be in
- place as early as possible to allow large scale IPv6 only DNS
- deployment.
-
- --------------------------------------------------------------------
- Roadmap step 1:
-
- A robust, scalable bridging system should be defined, agreed and put
- in place as soon as possible.
- --------------------------------------------------------------------
-
-
-4.2 Root name service accessible via IPv6
-
- The first DNS query a caching resolver will send is directed to a
- root name server. This, if the configuration of the bridging system
- is derived automatically from the DNS itself, there is a strong
- requirement to make root name service available over IPv6 transport.
- If the configuration is derived any other way or is done manually,
- there is a possibility to operate the system without an IPv6
- accessible root in certain cases. However, as this document does not
- want to preclude any particular implementation of the bridging system
- at this point, it is highly recommended that some IPv6 enable root
- name server be in place as early as possible. It is an important
- step to show that IPv6 DNS deployment is possible.
-
- --------------------------------------------------------------------
- Roadmap step 2:
-
- The root SHOULD have at least one IPv6 name server.
- --------------------------------------------------------------------
-
-
-4.3 TLDs servers accessible via IPv6
-
- Having the capability to query a root name server using IPv6 is just
- the first step. The next one is to query a TLD for a NS record
- pointing to a domain name. Again, although not strictly necessary
- from a technical perspective, it is important to make sure that some
- TLD servers are accessible from the beginning via IPv6 so at least
- some label strings are resolvable with IPv6 transport without
- resorting to the bridging system.
-
- Also note that great care should be taken when adding IPv6 glue in
- the TLD delegation by the root.
-
- --------------------------------------------------------------------
- Roadmap step 3:
-
- Each TLD zone SHOULD have at least one IPv6 name server.
- --------------------------------------------------------------------
-
-
-4.4 IPv6 glue at TLD registries.
-
- Whenever glue is needed, it is necessary for domains delegated under
- a TLD to be able to specify an IPv6 name server address to the TLD
- registry. This is not so much a protocol issue but a management and
- procedural issue.
-
- --------------------------------------------------------------------
- Roadmap step 4:
-
- Domains registering under TLDs SHOULD be able to specify IPv6 glue
- wherever they are specifying IPv4 glue today.
- --------------------------------------------------------------------
-
-
-4.5 Reverse path DNS servers
-
- Reverse DNS queries should also be supported in IPv6, for the same
- reasons as direct queries. Today's resolvers do reverse nibbles
- queries under the ip6.int tree. [RFC3152] has deprecated ip6.int,
- thus reverse DNS queries MUST be moved to ip6.arpa. So, although
- again not strictly speaking a technical requirement, it is important
- to have at least one server for ip6.arpa accessible via IPv6.
-
- --------------------------------------------------------------------
- Roadmap step 5:
-
- The ip6.arpa zone SHOULD have at least one IPv6 server.
- --------------------------------------------------------------------
-
-
-
-5. Security considerations
-
-
- Any bridging system, acting as open relay, could be misused to create
- denial of service attacks on external DNS servers. Some provision
- SHOULD be made in the design of those relay to deal with this issue.
-
-
-
-6 Authors addresses
-
-
- Alain Durand
- SUN Microsystems, Inc
- 901 San Antonio Road
- MPK17-202
- Palo Alto, CA 94303-4900
- USA
- Mail: Alain.Durand@sun.com
-
- Johan Ihren
- Autonomica AB
- Bellmansgatan 30
- SE-118 47 Stockholm, Sweden
- johani@autonomica.se
-
-
-
-7. 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 199
-
- [RFC3152] Bush, R.,
- "Delegation of IP6.ARPA",
- RFC 3152, August 2001
-
- [RFC2826] Internet Architecture Board,
- "IAB Technical Comment on the Unique DNS Root",
- RFC 2826, May 2000
-
- [RFC2766] Tsirtsis, G., Srisuresh, P.,
- "Network Address Translation - Protocol Translation (NAT-PT)",
- RFC 2766, February 2000
-
-
-
-
-
-
-
-
-
-
Secure Shell Working Group J. Schlyter
-Internet-Draft Carlstedt Research &
-Expires: October 1, 2003 Technology
- W. Griffin
- Network Associates Laboratories
- April 2, 2003
+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-04.txt
+ Using DNS to Securely Publish SSH Key Fingerprints
+ draft-ietf-secsh-dns-05.txt
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on October 1, 2003.
+ This Internet-Draft will expire on March 5, 2004.
Copyright Notice
-Schlyter & Griffin Expires October 1, 2003 [Page 1]
-Internet-Draft DNS and SSH fingerprints April 2003
+Schlyter & Griffin Expires March 5, 2004 [Page 1]
+
+Internet-Draft DNS and SSH Fingerprints September 2003
Table of Contents
2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4
2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4
- 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 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
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
Normative References . . . . . . . . . . . . . . . . . . . . 8
Informational References . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
-Schlyter & Griffin Expires October 1, 2003 [Page 2]
+Schlyter & Griffin Expires March 5, 2004 [Page 2]
-Internet-Draft DNS and SSH fingerprints April 2003
+Internet-Draft DNS and SSH Fingerprints September 2003
1. Introduction
- The SSH [5] protocol provides secure remote login and other secure
+ 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.
+ connection relies on the server authenticating itself to the client
+ as well as the user authenticating itself to the server.
- Server authentication is normally done by presenting the fingerprint
- of an unknown public key to the user for verification. If the user
- decides 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
- accepts the presented key.
+ 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 [4] to verify the lookup.
+ and using DNSSEC [5] to verify the lookup.
In order to distribute the fingerprint using DNS, this document
- defines a new DNS resource record to carry the fingerprint.
+ defines a new DNS resource record, "SSHFP", to carry the fingerprint.
Basic understanding of the DNS system [1][2] and the DNS security
- extensions [4] is assumed by this document.
+ 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
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
- matches the algorithm and fingerprint of one of the SSHFP resource
+ 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.
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 [5] uses local files to store keys
+ 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
- configurable policy will allow administrators to determine which
-Schlyter & Griffin Expires October 1, 2003 [Page 3]
+Schlyter & Griffin Expires March 5, 2004 [Page 3]
-Internet-Draft DNS and SSH fingerprints April 2003
+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.
A message digest of the public key, using the message digest
algorithm specified in the SSHFP fingerprint type, MUST match the
- SSH FP fingerprint.
+ SSHFP fingerprint.
2.4 Authentication
- A public key verified using this method MUST only be trusted if the
- SSHFP resource record (RR) used for verification was authenticated by
- a trusted SIG RR.
+ 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 [8], SIG(0) [9] or IPsec [7],
+ use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
between themselves and the entity performing the signature
validation.
The RR type code for the SSHFP RR is TBA.
-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.
+Schlyter & Griffin Expires March 5, 2004 [Page 4]
-Schlyter & Griffin Expires October 1, 2003 [Page 4]
+Internet-Draft DNS and SSH Fingerprints September 2003
-Internet-Draft DNS and SSH fingerprints April 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
1 RSA
2 DSS
- Reserving other types requires IETF consensus.
+ Reserving other types requires IETF consensus [4].
3.1.2 Fingerprint Type Specification
0 reserved
1 SHA-1
- Reserving other types requires IETF consensus. For interoperability
- reasons, as few fingerprint types as possible should be reserved.
- The only reason to reserve additional types is to increase security.
+ Reserving other types requires IETF consensus [4].
-3.1.3 Fingerprint
+ For interoperability reasons, as few fingerprint types as possible
+ should be reserved. The only reason to reserve additional types is
+ to increase security.
- The fingerprint is calculated over the public key blob as described
- in [6].
+3.1.3 Fingerprint
- The message-digest algorithm is presumed to produce an opaque octet
- string output which is placed as-is in the RDATA fingerprint field.
+Schlyter & Griffin Expires March 5, 2004 [Page 5]
+Internet-Draft DNS and SSH Fingerprints September 2003
-Schlyter & Griffin Expires October 1, 2003 [Page 5]
-Internet-Draft DNS and SSH fingerprints April 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 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:
+ 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
the fingerprint with something learned through a secured channel, the
connection is vulnerable to a man-in-the-middle attack.
- The approach suggested here shifts the burden of key checking from
- each user of a machine to the key checking performed by the
- administrator of the DNS recursive server used to resolve the host
- information. Hopefully, by reducing the number of times that keys
- need to be verified by hand, each verification is performed more
- completely. Furthermore, by requiring an administrator do the
- checking, the result may be more reliable than placing this task in
- the hands of an application user.
-
The overall security of using SSHFP for SSH host key verification is
- dependent on detailed aspects of how verification is done in SSH
- implementations. 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.
+ 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,
- we can implement SSH host key revocation by removing the
+ 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
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
- against a local database before verifying the key via the fingerprint
- returned from DNS. This would help prevent an attacker from injecting
-Schlyter & Griffin Expires October 1, 2003 [Page 6]
+Schlyter & Griffin Expires March 5, 2004 [Page 6]
-Internet-Draft DNS and SSH fingerprints April 2003
+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.
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 [10]
+ 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.
1 is RSA
2 is DSA
- Adding new reservations requires IETF consensus.
+ 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.
+ Adding new reservations requires IETF consensus [4].
-Normative References
+Schlyter & Griffin Expires March 5, 2004 [Page 7]
-Schlyter & Griffin Expires October 1, 2003 [Page 7]
+Internet-Draft DNS and SSH Fingerprints September 2003
-Internet-Draft DNS and SSH fingerprints April 2003
+Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
- [4] Eastlake, D., "Domain Name System Security Extensions", RFC
+ [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.
- [5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH
- Protocol Architecture", draft-ietf-secsh-architecture-13 (work
- in progress), September 2002.
+ [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.
- [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
+ [7] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Transport Layer Protocol",
- draft-ietf-secsh-transport-15 (work in progress), September
- 2002.
+ draft-ietf-secsh-transport-16 (work in progress), July 2003.
Informational References
- [7] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
+ [8] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
Roadmap", RFC 2411, November 1998.
- [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+ [9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
- [9] Eastlake, D., "DNS Request and Transaction Signatures (
+ [10] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
- [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic
+ [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
-Authors' Addresses
-
- Jakob Schlyter
- Carlstedt Research & Technology
- Stora Badhusgatan 18-20
- Goteborg SE-411 21
- Sweden
-
- EMail: jakob@crt.se
- URI: http://www.crt.se/~jakob/
-Schlyter & Griffin Expires October 1, 2003 [Page 8]
-Internet-Draft DNS and SSH fingerprints April 2003
- Wesley Griffin
- Network Associates Laboratories
- 15204 Omega Drive Suite 300
- Rockville, MD 20850
- USA
- EMail: wgriffin@tislabs.com
- URI: http://www.nailabs.com/
-Appendix A. Acknowledgements
- The authors gratefully acknowledges, in no particular order, the
- contributions of the following persons:
+Schlyter & Griffin Expires March 5, 2004 [Page 8]
- Martin Fredriksson
+Internet-Draft DNS and SSH Fingerprints September 2003
- Olafur Gudmundsson
-
- Edward Lewis
-
- Bill Sommerfeld
+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 October 1, 2003 [Page 9]
+Schlyter & Griffin Expires March 5, 2004 [Page 9]
-Internet-Draft DNS and SSH fingerprints April 2003
+Internet-Draft DNS and SSH Fingerprints September 2003
Intellectual Property Statement
-Schlyter & Griffin Expires October 1, 2003 [Page 10]
+Schlyter & Griffin Expires March 5, 2004 [Page 10]
-Internet-Draft DNS and SSH fingerprints April 2003
+Internet-Draft DNS and SSH Fingerprints September 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-Schlyter & Griffin Expires October 1, 2003 [Page 11]
+Schlyter & Griffin Expires March 5, 2004 [Page 11]
+++ /dev/null
-Internet Engineering Task Force Kamal Janardhan
-Internet-Draft Levon Esibov
-November 13, 2001 Expires: May 13 2002
-
- DNS Stale Resource Records Removal Mechanism
- <draft-janardhan-dnsext-aging-00.txt>
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance
-with all provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering
-Task Force (IETF), its areas, and its working groups. Note that
-other groups may also distribute working documents as
-Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six
-months and may be updated, replaced, or obsoleted by other
-documents at any time. It is inappropriate to use Internet-
-Drafts as reference material or to cite them other than as
-"work in progress."
-
-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 (2001). All Rights Reserved.
-
-
-Abstract
-
-The Dynamic DNS Update Protocol assumes that the devices/applications
-performing dynamic registration of the DNS records will delete the
-records from the DNS database when the records become invalid. Initial
-deployment of the devices supporting the Dynamic DNS Update protocol
-indicated that there are multiple legitimate scenarios when records
-dynamically registered in DNS are not removed from the database by the
-devices that originally registered them. This can result in a
-substantial number of stale records. This document describes a
-mechanism to clean up these stale records.
-
-
-1. Introduction
-
-The Dynamic DNS Update Protocol assumes that the entities performing
-dynamic registration of the DNS records will delete the records from
-the DNS database when the records become invalid. Initial deployment of
-the devices supporting the Dynamic DNS update protocol indicated that
-there are multiple legitimate scenarios when records dynamically
-registered in DNS, are not removed from the database by the devices
-that originally registered them. Such scenarios are more likely to
-
-
-
-Esibov, Janardhan [Page 1]
-
-
-INTERNET-DRAFT Stale Records Removal November 2001
-
-
-
-occur in a network that has mobile devices. For example if a device is
-unexpectedly unplugged from the network (and is never connected back
-into the network) after it registered its DNS resource record in a DNS
-database, its record will remain in the DNS database infinitely until
-administrator manually deletes the record. This can result in a
-substantial number of stale records.
-Presence of these stale resource records results in use of the
-information that is not current when a DNS server responds to
-queries and causes space consumption in the database. It also may
-prevent other devices from registering new DNS records with the
-same owner-name. This document describes a mechanism to clean up
-these stale resource records.
-
-The goal of the protocol described in this document is to enable
-removal of the stale DNS records from the DNS database without
-modifications to the DNS wire format and without modification to the
-meaning of the currently used fields in the DNS wire format.
-
-It is not a goal of this protocol to ensure the immediate removal of
-stale records. The goal is to ensure that stale records are eventually
-removed without the administrator's involvement.
-
-
-2. Aging and removal of stale records protocol
-
-2.1 Client requirements of this protocol
-
-Each client performing dynamic DNS registration/update of a resource
-record MUST periodically repeat the dynamic update requests for each
-record it dynamically registered/updated, even when record itself is
-not modified.
-
-2.2 Server requirements of this protocol
-Every DNS server hosting a primary DNS zone MUST maintain a timestamp
-for each record in such zone. The timestamp contains the value
-corresponding to a moment of time when the resource record was last
-updated. Every time a server processes a Dynamic Update request for a
-record or a Dynamic Update Request containing a prerequisite section
-that requires existence of that resource record, the server MUST
-update the timestamp of the record that is supposed to be removed by
-this mechanism. Thus, the server MUST update the timestamp of a
-resource record even when the resource record specified in the dynamic
-update request is identical to the record stored by the
-DNS server. An exception to this rule is allowed to suppress an
-unnecessarily large number of consecutive dynamic updates for the same
-record, that could be caused by poorly written applications or by attackers
-initiating Denial of Service attacks. For this purpose
-DNS servers MAY be configured to not update a recordÆs timestamp for
-a short period of time after previous update to the timestamp. We refer
-to this time period as a NoRefresh Interval.
-
-Notice that some records in a zone may not be subjected to cleanup
-procedure described below. Such records, for example, may include those
-manually created by an administrator. Such records MUST
-be properly marked as different. A way to mark this difference could
-
-
-Esibov, Janardhan [Page 2]
-
-
-INTERNET-DRAFT Stale Records Removal November 2001
-
-
-be to use the timestamp field by assigning it some special value.
-
-Update of a timestamp, but not any other field of a record, MUST NOT
-cause SOA serial number modification. The timestamp is not propagated
-from the primary to secondary DNS servers during zone transfers. The
-advantage of this behavior is that it doesnÆt require any changes to
-the wire format of the records in the zone transfer and there is no
-increase in network traffic caused by frequent updates to the
-timestamp on the primary server.
-The disadvantage of this behavior is that if the primary server
-becomes unavailable, and secondary server for the zone is configured as
-a new primary, then it will not be able to perform
-removal of the stale records unless it loads the zone data from the file
-imported from the previously primary DNS server.
-
-Each DNS server performing removal of the stale records MUST be
-configured with a time interval called Refresh Interval. Any resource
-record that is configured to remain in the database
-until the administrator removes it, i.e. a record that is configured
-to be removed by the clean-up operation, is declared to be stale
-when its timestamp has not been updated for a period of time
-exceeding Refresh Interval. The DNS server MUST determine whether a
-resource record is stale by comparing a value of its timestamp to
-the result of subtraction of the Refresh Interval from the current
-time. If the timestamp is less than the result of subtraction of
-the Refresh Interval from the current time, then the record is stale.
-Each primary DNS server MUST periodically review the DNS database to
-find the stale records and remove them from the database.
-
-Notice that if a DNS server is configured to not update a recordÆs
-timestamp for a short period of time after the timestamp was updated
-last time, as mentioned above, then DNS server MUST determine whether
-a resource record is stale by comparing a value of its timestamp to
-the result of subtraction of the sum of the Refresh and NoRefresh
-Intervals from the current time. If the timestamp is less than the
-result of subtraction of the Refresh and NoRefresh Intervals
-from the current time, then the record is stale. In the rest of the
-examples used in this document, for simplicity, it is assumed that
-the DNS server is not configured with NoRefresh Interval.
-
-To prevent deletion of the valid records, the Refresh Interval
-specified for any primary DNS zone MUST be longer than longest interval
-between two consecutive Dynamic Update requests for the
-same resource record sent by a device. For example, if a DNS
-client performs periodic registration of a DNS record as often or
-less than once a week, then the Refresh Interval of a zone
-hosting that record MUST be longer than one week. It is a DNS server
-administratorÆs responsibility to set the appropriate Refresh Interval.
-
-There are some scenrios when a primary DNS server may not always
-be able to update the timestamps at the clients request for e.g.
-the server is temporarily offline. For this reason, a DNS server
-MUST NOT perform removal of the stale records for the length
-of the Refresh Interval after the server has retined to online
-status. This ensures a period of time when the server is
-available for records' timestamps to be refreshed to prevent
-
-
-
-Esibov, Janardhan [Page 3]
-
-
-INTERNET-DRAFT Stale Records Removal November 2001
-
-
-
-records that could not be refreshed from being incorrectly removed.
-
-
-3. Example Section
-The following scenario illustrates the stale records removal protocol.
-Two clients, A and B, are configured to perform Dynamic Update of the
-DNS host resource records for the names a.example.com and b.example.com
-respectively. These clients are configured to repeat dynamic updates
-of the resource records every 24 hours. DNS server hosting a primary
-copy of a zone example.com, which is authoritative for the names
-a.example.com and b.example.com, is configured with Refresh Interval set
-to 72 hours (3 days). The server is also configured to perform removal
-of the stale DNS resource records every 168 hours (1 week) starting
-at 23:00 on 11/1/2001.
-
-On 11/5/2001 at 17:00 client A registers a host resource record with
-name a.example.com. The DNS server accepts Dynamic Update of the
-record. The DNS server associates a timestamp with this record which
-contains the value 17:00 on 11/5/2001. This client will repeat
-registration on a daily basis and the recordÆs timestamp will be
-updated to 17:00 on 11/6/2001, 17:00 on 11/7/2001, 17:00
-on 11/8/2001 and so on and so forth.
-
-On 11/8/2001 at 11:00 client B registers a host resource record
-with name b.example.com. The DNS server accepts registration of the
-record. The DNS server associates a timestamp with this record which
-contains the value æ11:00 on 11/7/2001Æ. This client will repeat
-registration on a daily basis until further notice and the recordÆs
-timestamp will be updated to 11:00 on 11/9/2001, 11:00 on 11/10/2001,
-11:00 on 11/11/2001 and so on until otherwise specified.
-
-On 11/8/2001 at 23:00 the DNS server starts review of the timestamps
-of the records in its primary DNS zones and deletes the stale
-records from the zones. Since the Refresh Interval is set to 72
-hours, any record with a timestamp containing a value less than
-23:00 on 11/5/2001 is declared stale and is removed from the DNS
-zone. Since at that moment, the timestamps of the records
-a.example.com and b.example.com contain 17:00 on 11/8/2001 and
-11:00 on 11/8/2001 respectively, both of which are greater than 23:00
-on 11/5/2001, they are not removed from the DNS zone.
-
-As time goes on, client A continues to send period dynamic
-update requests for the host resource record for a.example.com on
-a daily basis. In contrast, client B is unexpectedly disconnected
-from the network on 11/12/2001 at 18:00. From that time onwards,
-client B doesnÆt send dynamic update requests for the record
-b.example.com to the primary DNS server, and as a result the
-timestamp value of the b.example.com record is not updated after
-that moment and contains the last updated value of 11:00 on
-11/12/2001.
-
-On 11/15/2001 at 23:00 the DNS server starts review of the
-timestamps of the records in its primary DNS zones and deletes the
-stale records. Since the Refresh Interval is set to 72 hours,
-any record with a timestamp containing value less than 23:00
-on 11/12/2001 is declared stale and is removed from the DNS zone.
-
-
-Esibov, Janardhan [Page 4]
-
-
-INTERNET-DRAFT Stale Records Removal November 2001
-
-
-At this point the timestamp of the record a.example.com contains the
-value of 17:00 on 11/15/2001 and therefore the record
-is preserved in the zone. At the same time, the timestamp of the
-record b.example.com contains the value of 11:00 on 11/12/2001 and
-therefore it is declared to be stale and the DNS
-server removes it from the DNS zone and updates the SOA serial number.
-Subsequently, the deletion of the record propagates to the secondary
-DNS servers for this zone.
-
-4. Implementation recommendations
-
-It is advisable that in early implementations of this mechanism,
-the default be that the stale records removal mechanism is disabled.
-Before enabling this stale record removal mechanism on a server
-an administrator must ensure that the resource records hosted
-by the server are periodically refreshed by the clients within
-a period less than Refresh Interval of the zone to prevent accidental
-deletion of the resource records.
-
-
-5. Security Considerations
-
-Implementation of the stale record removal mechanism does not introduce
-additional security concerns.
-
-To suppress possible denial of service attacks which could be organized
-by sending a continuous flux of dynamic update requests for the existing
-record, a DNS server may suppress such requests for a short period of
-time after the last update of the timestamp. This does not, however,
-worsen a scenario of repeated dynamic update requests for new records,
-which is possible with the dynamic DNS update protocol.
-
-If an attacker can prevent dynamic update requests intended to update
-the timestamp from reaching the destination DNS server, the record may
-eventually be incorrectly removed from a DNS zone because it is stale.
-This however, does not worsen similar attacks where the original dynamic
-update request is prevented from reaching a destination DNS server and
-creating a new record in a DNS zone which results in the same name
-resolution problems.
-
-
-8. Acknowledgements
-
-The authors of this document would like to thank the following people
-for their contribution to this specification: Stuart Kwan, James Gilroy,
-and Eyal Schwartz.
-
-
-Esibov, Janardhan [Page 5]
-
-
-INTERNET-DRAFT Stale Records Removal November 2001
-
-
-7. References
-
-[RFC2136] D. Eastlake 3rd "Secure Domain Name System Dynamic Update"
- RFC 2136, April 1997
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
-[RFC1035] - Domain Names - Implementation and Specifications,
- P.Mockapetris, November 1987.
-
-9. Author's Addresses
-
-Kamal Janardhan
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-USA
-kamaljan@microsoft.com
-
-Levon Esibov
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-USA
-levone@microsoft.com
-
-10. 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.
-
-
-11. Full Copyright Statement
-Copyright (C) The Internet Society (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 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
-
-
-Esibov, Janardhan [Page 6]
-
-
-INTERNET-DRAFT Stale Records Removal November 2001
-
-
-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."
\ No newline at end of file
+++ /dev/null
-
-
- Individual Submission
- Internet Draft
- Jae-Hoon Jeong
- Jung-Soo Park
- Kyeong-Jin Lee
- Hyoung-Jun Kim
- <draft-jeong-hmipv6-dns-optimization-00.txt> ETRI
- Expires: August 2003 February 2003
-
-
- The Autoconfiguration of Recursive DNS Server and the Optimization of
- DNS Name Resolution in Hierarchical Mobile IPv6
-
-
- Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026 except that the right to
- produce derivative works is not granted [1].
-
- 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 provides the mechanism for the autoconfiguration of
- recursive DNS server in mobile node and the optimization of DNS name
- resolution in the hierarchical mobile IPv6 networks. Whenever the
- mobile node moves into a new MAP domain, the region managed by
- another MAP, in the hierarchical mobile IPv6 networks, it detects the
- addresses of recursive DNS servers which are placed in the region and
- replaces the old ones with the new ones for DNS name resolution. This
- allows the time for DNS name resolution much reduced by using the
- nearest DNS recursive server which exists in the region. Therefore,
- the mechanism of this document can optimize the DNS name resolution.
-
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 1]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- Conventions used 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 [2].
-
- Table of Contents
-
- 1. Terminology....................................................2
- 2. Introduction...................................................2
- 3. Overview.......................................................3
- 4. HMIPv6 extension - Advertisement of Recursive DNS Server.......4
- 5. Neighbor Discovery extension - RDNSS option message format.....4
- 6. RDNSS selection by the Mobile Node.............................5
- 7. Detection of RDNSS failure.....................................6
- 8. Security Considerations........................................6
- 9. References.....................................................6
- 10. Author's Addresses............................................7
-
- 1. Terminology
-
- This memo uses the terminology described in [3]. In addition, a new
- term is defined below:
-
- Recursive DNS Server (RDNSS) A Recursive DNS Server is a name server
- that offers the recursive service of
- DNS name resolution.
-
- 2. Introduction
-
- RFC 2462 [4] provides a way to autoconfigure either fixed or mobile
- nodes with one or more IPv6 addresses and default routes.
-
- For the support of the various services in the Internet, not only the
- configuration of IP address in network interface, but also that of
- the recursive DNS server for DNS name resolution are necessary.
-
- Up to now, many mechanisms to autoconfigure recursive DNS server in
- nodes have been proposed [5][6].
-
- This document suggests not only the autoconfiguration of recursive
- DNS server in mobile node that moves within the hierarchical mobile
- IPv6 networks [3], but also the optimization of the DNS name
- resolution in such networks. Whenever the mobile node moves into a
- new MAP (Mobility Anchor Point) domain, the region managed by another
- MAP, in the hierarchical mobile IPv6 networks, it detects the
- addresses of recursive DNS servers which are placed in the region and
- replaces the old ones with the new ones for DNS name resolution. This
- allows the time for DNS name resolution much reduced by using the
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 2]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- nearest DNS recursive server which exists in the region. Like this,
- because the mobile nodes use the recursive DNS server in the same
- domain instead of the fixed recursive DNS server, the DNS name
- resolution of the mobile nodes can be optimized.
-
- 3. Overview
-
- +-------+ +--------+
- | HA |---| RDNSS1 |
- +-------+ +--------+
- |
- | +----+
- | | CN |
- | +----+
- +-----+ |
- | |
- | +---+
- | |
- +-------+
- | MAP | RCoA
- +-------+
- | |
- | +--------+
- | |
- | |
- +-----+ +-----+ +--------+
- | AR1 | | AR2 |---| RDNSS2 |
- +-----+ +-----+ +--------+
-
- +----+
- | MN |
- +----+ ------------>
- Movement
-
- Figure 1: Optimization of DNS Name Resolution in HMIPv6 domain
-
- Whenever a mobile node enters into a new MAP domain of the visited
- network, it receives the RA message including MAP option from Access
- Router (AR) and performs the local binding update with the new MAP.
- If the list of the addresses of the recursive DNS server (RDNSS) is
- included in the RA message with the MAP option, the mobile node can
- detect the new RDNSSs and select one of them for the DNS name
- resolution. Like Figure 1, this scheme can reduce considerably the
- time of the name resolution between the mobile node and the RDNSS.
- Because the mobile node uses the nearest RDNSS in the same MAP domain,
- RDNSS2, instead of the RDNSS in its home network, RDNSS1. When the
- mobile node moves into another MAP domain, it replaces the old RDNSS
- with the new RDNSS for the succeeding name resolutions.
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 3]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- 4. HMIPv6 extension - Advertisement of Recursive DNS Server
-
- Because this document considers only router advertisement for MAP
- discovery, all ARs belonging to the MAP domain MUST advertise the
- MAP's IP address.
-
- The information of the RDNSS in the MAP domain is stored in the MAP
- by the network administrator and advertised as a new option through
- the RA message with MAP option. There MAY be more than one RDNSS in a
- MAP domain. A MAP advertises the RA message including the list of
- RDNSSs in the same domain with MAP option. The RA message with MAP
- and RDNSS options is propagated from the MAP to the mobile node
- through certain (configured) router interfaces within the hierarchy
- of routers. This would require manual configuration of the MAP and
- RDNSS options in the MAP and also the routers receiving the MAN and
- RDNSS options to allow them to propagate the options on certain
- interfaces.
-
- Finally, the mobile node listening to RA messages receives the new RA
- message and checks if the MAP is new or not. If the MAP is a new one,
- the mobile node perceives it has moved into another MAP domain and
- performs both the local binding update with the new MAP and the
- update of the list of RDNSSs in the configuration of name resolution
- with the new ones. From the next name resolution, the mobile node
- uses the new RDNSSs.
-
-
- 5. Neighbor Discovery extension - RDNSS option message format
-
- The mechanism of this document needs a new option in Neighbor
- Discovery [7].
-
- 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( = 3) | Pref | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + IPv6 Address for RDNSS +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 4]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- Fields:
-
- Type Message type. TBA.
-
- Length 8-bit unsigned integer. The length of the
- option (including the type and length fields)
- in units of 8 octets. The default value is 3.
- The value 0 is invalid. Nodes MUST silently
- discard an ND packet that contains an option with
- length zero.
-
- Pref The preference of an RDNSS. A 4 bit unsigned
- integer. A decimal value of 15 indicates the
- highest preference. A decimal value of 0
- indicates that the RDNSS can not be used.
-
- IPv6 Address for RDNSS
- The RDNSS IPv6 address. The scope of the address
- can be any scope.
- i.e., link-local, site-local and global.
- The prefix of the address is be /64.
-
- When advertising more than one RDNSS, as many RDNSS options as the
- number of RDNSSs are included in an RA message.
-
- 6. RDNSS selection by the Mobile Node
-
- When a mobile node perceives multiple RDNSSs through RA message, it
- stores the RDNSSs in order into the configuration the resolver on the
- node uses for DNS name resolution on the basis of the value of "Pref"
- field and the prefix of "IPv6 Address for RDNSS" field in the RDNSS
- option. The following algorithm is simply based on the rule of
- selecting the nearest possible RDNSS, providing that its preference
- value did not reach the maximum value of 15. When the distances are
- the same, this algorithm uses the preference value to order the
- RDNSSs. The mobile node operation is shown below:
-
- 1) Receive and parse all RDNSS options
-
- 2) Arrange RDNSSs in an ascending order, starting with the nearest
- RDNSS and store them in the configuration for DNS name resolution
- used by resolver. (i.e., the longest prefix matching between the
- "IPv6 Address for RDNSS" field and mobile node's On-link CoA
- (LCoA) MAY be used to decide the distance between mobile node and
- RDNSS, how far away the mobile node is from the RDNSS.)
-
- 3) For each RDNSS entry, check the following;
- - If the value of "Pref" field is set to zero, exclude the RDNSS
- entry from the list of RDNSSs of the configuration for DNS name
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 5]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- resolution.
-
- Whenever the resolver on the mobile node performs the name resolution,
- it refers to the address(es) of RDNSS in the configuration for name
- resolution according to the current rule of selecting an RDNSS,
- namely from the 1st RDNSS.
-
- 7. Detection of RDNSS failure
-
- A MAP placed in a MAP domain checks periodically if the RDNSSs
- registered in the MAP are alive. Whenever the MAP detects the failure
- of any RDNSS, it advertises the failure down to the hierarchy with a
- new RA message including an RDNSS option of which "Pref" field has
- zero for the RDNSS. When a mobile node receives the RA message, it
- perceives that the RDNSS is out of work or the path to the RDNSS is
- broken and excludes the RDNSS from the configuration for name
- resolution.
-
- The dynamic detection of RDNSS failure in a MAP can be done by simply
- pinging the RDNSS periodically (e.g., every ten seconds). If no
- response is received, the MAP MAY try to aggressively ping the RDNSS
- for a short period of time (e.g., once every 5 seconds for 15
- seconds); if no response is received, an RDNSS option MAY be sent
- with a preference value of zero.
-
- 8. Security Considerations
-
- In order to guarantee the secure communication between routers, the
- router advertisements sent between routers SHOULD be authenticated by
- AH or ESP [3]. This security is essentially related to Neighbor
- Discovery protocol security [7].
-
- 9. References
-
- [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
- 9, RFC 2026, October 1996.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997
-
- [3] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier,
- "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-
- ietf-mobileip-hmipv6-07.txt, October 2002.
-
- [4] S. Thomson and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC2462.
-
-
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 6]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- [5] A. Durand, J. itojun and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- draft-ietf-ipv6-dns-discovery-07.txt, October 25 2002.
-
- [6] Luc Beloeil, "IPv6 Router Advertisement DNS resolver Option",
- draft-beloeil-ipv6-dns-resolver-option-01.txt, January 2003.
-
- [7] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for
- IP version 6", RFC 2461.
-
- 10. Author's Addresses
-
- Jae-Hoon Jeong
- ETRI / PEC
- 161 Gajong-Dong, Yusong-Gu
- Daejon 305-350
- Korea
-
- Phone: +82 42 860 1664
- EMail: paul@etri.re.kr
-
- Jung-Soo Park
- ETRI / PEC
- 161 Gajong-Dong, Yusong-Gu
- Daejon 305-350
- Korea
-
- Phone: +82 42 860 6514
- EMail: pjs@etri.re.kr
-
- Kyeong-Jin Lee
- ETRI / PEC
- 161 Gajong-Dong, Yusong-Gu
- Daejon 305-350
- Korea
-
- Phone: +82 42 860 6484
- EMail: leekj@etri.re.kr
-
- Hyoung-Jun Kim
- ETRI / PEC
- 161 Gajong-Dong, Yusong-Gu
- Daejon 305-350
- Korea
-
- Phone: +82 42 860 6576
- EMail: khj@etri.re.kr
-
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 7]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT H. Kitamura
-<draft-kitamura-ipv6-name-auto-reg-02.txt> NEC Corporation
-Expires in six months 1 July 2002
-
- Domain Name Auto-Registration for Plugged-in IPv6 Nodes
- <draft-kitamura-ipv6-name-auto-reg-02.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.
-
-Abstract
-
- This document describes a scheme of "Domain Name Auto-Registration
- for Plugged-in IPv6 Nodes" mechanism that makes it possible to
- register both regular and inverse domain name information of plugged-
- in IPv6 nodes to DNS servers automatically.
-
- Since IPv6 addresses are too long to remember and EUI64-based
- addresses are too complicated to remember, there are strong
- requirements to use logical names that are easy to remember instead
- of IPv6 addresses to specify IPv6 nodes and to register domain name
- information of plugged-in IPv6 nodes automatically.
-
- In order to meet the requirements, a mechanism is proposed as one of
- the IPv6 auto-configuration (plug and play) functions. After the
- Address Autoconfiguration [ADDR-AUTO] has been executed, it works as
- a succeeding plug and play mechanism.
-
- This document clarifies problems that we meet when we apply the
- Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
- information registration mechanisms. This document proposes the
- Domain Name Auto-Registration mechanism as a solution to these
- problems.
-
-
-
-H. Kitamura [Page 1]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- The Domain Name Auto-Registration mechanism, in addition to its main
- functionality, provides two types of additional benefits.
-
- One is that IP address information that should be registered to the
- DNS is collected automatically. The mechanism can also be used under
- (non plug and play) manual configuration situations in a different
- manner from its main functionality. Under such situations, network
- administrators meet a problem that it is not easy to collect IP
- address information to register to the DNS. The mechanism solves it.
-
- The other is that a plugged-in IPv6 node can obtain its domain name
- information (FQDN and DNS zone suffix) without having new functions
- installed into it. By simply executing inverse DNS name resolving
- procedures with its IPv6 address argument, the plugged-in IPv6 node
- can obtain its FQDN and DNS zone suffix with ease.
-
-
-1. Introduction
-
- This document describes a scheme of "Domain Name Auto-Registration
- for Plugged-in IPv6 Nodes" mechanism that makes it possible to
- register both regular and inverse domain name information of plugged-
- in IPv6 nodes to DNS servers automatically.
-
- In order to specify destination nodes to communicate, SOME
- identifiers are necessary for users. Since IPv6 addresses are too
- long to remember and EUI64-based addresses are too complicated to
- remember, they are not suitable for such identifiers. Logical names
- are suitable identifiers because they are easy to remember.
- Therefore, there are strong requirements to use logical names instead
- of IPv6 addresses to specify IPv6 destination nodes and to register
- domain name information of plugged-in IPv6 nodes automatically.
-
- In order to meet the requirements, a mechanism is proposed as one of
- the IPv6 auto-configuration (plug and play) functions. After the
- Address Autoconfiguration [ADDR-AUTO] has been executed, it works as
- a succeeding plug and play mechanism.
-
- It is known that the Dynamic Updates in the DNS [DYN-DNS] have
- already been defined and that they can help automatic domain name
- information registration mechanisms. However, some problems need to
- be solved to apply this idea to actual situations.
-
- This document clarifies problems that we meet when we apply the
- Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
- information registration mechanisms. This document proposes the
- Domain Name Auto-Registration mechanism as a solution to these
- problems.
-
-
-
-H. Kitamura [Page 2]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- Basic target situations for the mechanism are plug and play
- situations. Accordingly, it has been designed for plugged-in IPv6
- nodes under plug and play situations.
-
- We have to consider the following issues to design the "Domain Name
- Auto-Registration for Plugged-in IPv6 Nodes" mechanism.
-
- 1. Plugged-in IPv6 nodes do not have sufficient capability to show
- their preferences. In most cases, it is difficult for plugged-in
- IPv6 nodes to show their preferences for their domain names.
-
- 2. Since it is not easy to install new function to all IPv6 nodes, it
- is desirable to achieve the mechanism without installing new
- functions into plugged-in IPv6 nodes.
-
- 3. It is essential to have (register) SOME domain name for a
- plugged-in node. It is NOT main concern for a plugged-in node
- which actual name is assigned to it.
-
- Thus, the idea of "default domain name" is introduced. When a new
- plugged-in IPv6 node appears, its appearance is automatically
- detected and a default domain name is selected for it, and both
- regular and inverse information of the default domain name are
- registered to appropriate DNS servers.
-
- This document does not deal with cases where IPv6 nodes want to
- register domain names that they absolutely prefer. Such cases do not
- fall within the target range of plug and play situations; they will
- be supported under manual configuration situations.
-
- There are various types of plugged-in IPv6 nodes that can/cannot show
- their preferences for their domain names. In order to meet various
- plug and play situations, this document considers several cases.
-
- The Domain Name Auto-Registration mechanism is basically designed for
- domain name registrations for global unicast addresses. By setting
- the query scope of the target DNS server appropriately, the mechanism
- will be able to be applied to domain name registrations for site-
- local and link-local scope unicast addresses.
-
- The Domain Name Auto-Registration mechanism, in addition to its main
- functionality, provides two types of additional benefits.
-
- One is that IP address information that should be registered to the
- DNS is collected automatically. The mechanism can also be used under
- (non plug and play) manual configuration situations in a different
- manner from its main functionality. Under such situations where
- network is maintained by administrators manually, administrators meet
-
-
-
-H. Kitamura [Page 3]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- a problem that it is not easy to collect IP address information to
- register to the DNS. The mechanism solves the problem, and IP address
- information to register to the DNS is collected automatically.
-
- Under manual configuration situations, the automatic DNS registration
- procedure that is the last procedure of the mechanism can be replaced
- by the administrators' manual registration (not by the Dynamic
- Updates).
-
-
- The other is that a plugged-in IPv6 node can obtain its domain name
- information (FQDN and DNS zone suffix) with ease. The plugged-in IPv6
- nodes know its IPv6 address that are automatically configured by the
- Address Autoconfiguration [ADDR-AUTO]. By simply executing inverse
- DNS name resolving procedures with the IPv6 address argument, the
- plugged-in IPv6 node can obtain information on its domain names (FQDN
- and DNS zone suffix) easily. Since all IPv6 nodes have DNS name
- resolving functions for both regular and inverse queries, this
- procedure can be achieved without installing new functions into IPv6
- nodes.
-
-
-2. Problems in applying the Dynamic Updates mechanism
-
- This section clarifies problems that we meet when we apply the
- Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
- information registration mechanisms.
-
- 1: Ordinary DNS servers accept Dynamic Updates messages only from
- trusted nodes.
-
- Since it is difficult for plugged-in IPv6 nodes to become trusted
- nodes of the DNS servers, Dynamic Updates messages from plugged-in
- IPv6 nodes are usually not accepted by the DNS servers.
-
- 2: It is difficult for plugged-in IPv6 nodes to know the location of
- the appropriate DNS server to register their domain name
- information to.
- ([DNS-DISC] discusses on issues of this type.)
-
- 3: It is difficult for plugged-in IPv6 nodes to prepare sufficient
- domain name information to register. They need to know their DNS
- zone suffix information to prepare FQDN for registration, but it
- is difficult for them to acquire it.
- ([DNS-DISC] also discusses on issues of this type.)
-
- 4: There is no explicit method to avoid duplicated, conflicting name
- registrations.
-
-
-
-H. Kitamura [Page 4]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- When a DNS server receives Dynamic Updates messages that are
- correctly formatted and authenticated, the server accepts them and
- updates DNS database with them without checking for duplication.
- (It is essentially difficult for a DNS server to distinguish
- overwrite (update) registrations from duplicate registrations.)
-
- 5: Basically, there is no mechanism to control (restrict) the number
- of issued Dynamic Updates messages for plugged-in nodes.
-
- In order to minimize the effects of malicious or misconfigured
- registration requests, it is necessary to control them.
-
- 6: It is not clear when domain name registration requests must be
- issued. It is necessary to define trigger timings to start
- registrations.
-
-
-3. Basic Design of the Domain Name Auto-Registration
-
- This section describes the basic design of the Domain Name Auto-
- Registration mechanism. The mechanism solves all of the above-
- mentioned problems.
-
-
-3.1 Design Policies
-
- The Domain Name Auto-Registration mechanism is composed of two new
- functions. One is the "Detector" function, which detects appearances
- of new plugged-in IPv6 nodes. The other is the "Registrar" function,
- which registers detected domain name information to DNS servers.
- These functions are introduced into the IPv6 network system to
- achieve the mechanism.
-
- There are several reasons why the mechanism is implemented as two
- functions.
-
- 1. To make the mechanism easy to control
-
- By concentrating administrative operations only on the Registrar
- side, administrative costs are reduced and the mechanism is
- basically maintained by administering only Registrars.
-
- The number of DNS servers' trusted nodes that require much
- administrative operation is reduced.
-
- Since registration information is aggregated at Registrars, it
- becomes easy to control registrations and minimize the effects of
- malicious or misconfigured registration requests.
-
-
-
-H. Kitamura [Page 5]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- 2. To make Detector easy to implement
-
- There are certain constraints in placing Detectors on the IPv6
- network. Thus, it is necessary for Detectors to be simple enough
- to be installed on IPv6 nodes of any type.
-
- This need is filled by putting all the intelligent operations into
- Registrars.
-
- Furthermore, the system becomes well balanced since intelligent
- operations are not placed on each end link.
-
- 3. To make the mechanism flexible and enable it to be applied
- to various environments (office networks, home networks, etc.)
-
- If the mechanism is applied to home networks, Registrars can be
- placed at the Provider side, and Detectors can be placed at the
- User side.
-
-
- Figure 1 and 2 show typical examples that indicate locations where
- Detector and Registrar functions are placed on the IPv6 network.
-
- Figure 1 shows a case for a single link, and Figure 2 shows a case
- for multiple links.
-
-
-
-
- | +------------+
- | | DNS Server |
- +-+-+ %%%%%%%%%%%% ############# +------+-----+
- | R | % Detector % # Registrar # /
- +-+-+ %%%%%%%%%%%% ############# +---+
- | | | /
- ----+---------+-------+------+---------------+-----
- |
- +===========+
- | Plugged-in|
- | IPv6 Node |
- +===========+
-
- Fig. 1 Single-Link Case Example
-
-
-
-
-
-
-
-
-H. Kitamura [Page 6]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- +------------+
- | DNS Server |
- ############# +------+-----+
- # Registrar # /
- ############# +---+
- | /
- ----+-----------+------------+-------+------
- | |
- +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%%
- | R1| % Detector1 % | R2| % Detector2 %
- +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%%
- | | | |
- ----+-----+-----+----- ----+-----+-----+-----
- | |
- +===========+ +===========+
- | Plugged-in| | Plugged-in|
- | IPv6 Node | | IPv6 Node |
- +===========+ +===========+
-
- Fig. 2 Multiple-Link Case Example
-
-
- One Registrar can take charge of multiple Detectors, and one
- Registrar can cover multiple DNS zones.
-
- Multiple Detectors can provide detected information for one DNS zone.
- If the corresponding Registrars of these Detectors are different,
- multiple Registrars can cover one DNS zone.
-
- Therefore, Registrars must be designed to support both cases.
-
-
-
-3.2 Detector Function
-
- The role of a "Detector" is to detect appearances of new plugged-in
- IPv6 nodes and to send the detected information to a "Registrar"
- without applying any selection rules to it.
-
- Detectors are NOT required to perform any "intelligent" operations.
-
- A Detector knows the location of its corresponding Registrar. (This
- location is configured manually.) Detected information must be sent
- securely from the Detector to the Registrar by using some kind of
- secure communication method (e.g., [TSIG]-like authentication, IPsec
- (AH, ESP), [TLS]).
-
-
-
-
-
-H. Kitamura [Page 7]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- Since a Detector must be placed where appearances of new plugged-in
- IPv6 nodes can be detected, the Detector location is restricted.
-
- In typical cases, appearances are detected by watching for DAD
- packets that are issued from plugged-in IPv6 nodes (see section 3.4).
- So, the Detector must be placed where it can listen to link-local
- scope multicast packets. In other words, a Detector must be placed on
- each link to achieve the mechanism.
-
- The Detector function can be implemented on routers, because its
- operations are simple and lightweight and routers are located at
- suitable places for listening to link-local scope multicast packets
- that are issued from plugged-in IPv6 nodes.
-
- In order to identify Detectors, each Detector must have its own
- Detector ID. Since a Detector is placed on each link, the Detector's
- IP address that is connected to its watching link can be used for the
- Detector ID. (Default Address Selection for IPv6 [DEF-ADDR] algorithm
- is also applied here.) When a Detector sends detected information to
- a Registrar, the Detector ID is attached to it.
-
- In order to meet "temporary address" [RFC3041] issues (see section
- 5), a link-layer address of a detected IP address is also attached to
- detected information.
-
- Some simple protocol is necessary to send detected information from
- the Detector to the Registrar. In Appendix A, [HTTP]-based or [TLS-
- HTTP]-based simple protocol is shown.
-
-3.3 Registrar Function
-
- The role of a "Registrar" is to prepare appropriate domain name
- information for registration and to register it by sending Dynamic
- Update messages to the corresponding "DNS servers".
-
- Appropriate domain name information for registration is created from
- detected information that is sent from the Detector. Some sort of
- intelligent algorithm is necessary in such procedures. One of the
- roles of the algorithm is to minimize the effects of malicious or
- misconfigured registration requests.
-
- Registrars are required to perform "intelligent" operations.
-
- By using some sort of algorithm, the Registrar verifies (checks)
- whether detected information must be registered (see section 3.5).
- After the verification procedures are completed, the Registrar
- selects a "default domain name" for the detected information.
-
-
-
-
-H. Kitamura [Page 8]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- In order to prepare appropriate domain name information, the
- Registrar must know the appropriate DNS zone suffix for detected
- information. (The suffix is configured manually.) The DNS zone suffix
- depends on the Detector ID information.
-
- A Registrar must know the locations of "DNS servers" that correspond
- to detected information for registration (both regular DNS zone
- prefix and its inverse zone). Registrars must be trusted nodes of the
- DNS servers and Dynamic Update messages must be sent securely from
- the Registrar to the DNS servers by using some sort of secure
- communication methods. The [TSIG] technique would be suitable for
- authenticating the messages.
-
- A Registrar has a database table to manage such knowledge. The
- following elements are managed in the database table:
- Detector IDs, DNS zone suffixes, locations of DNS servers, applied
- algorithms (naming rules, how to deal with link-local or site-local
- scope addresses, etc.) and keys for secure communications.
-
- A Registrar can be placed anywhere in the IPv6 network, because the
- Registrar communicates only with Detectors and DNS servers, all
- communications are unicast.
-
- In order to optimize the communication path for packets between them,
- the Registrar is usually placed in the network upstream from the
- Detectors (see Fig.2).
-
- Detected information that is sent from Detectors is aggregated at the
- Registrar.
-
- The Registrar may frequently execute inverse DNS name resolving
- procedures to verify (check) whether detected information must be
- registered. It is recommended to put a DNS cache server function on
- the same node where the Registrar is placed to reduce inverse DNS
- name resolving traffic (see section 3.5).
-
-3.4 Methods of Detecting Appearances of New Plugged-in IPv6 Nodes
-
- In order to detect appearances of new plugged-in IPv6 nodes, the
- Detector must watch or receive packets from new plugged-in nodes.
- Accordingly, detection methods on the Detector are categorized into
- two types.
-
- One is detection of the appearance of "standard" plugged-in nodes
- that do not issue special packets to show their appearance. The other
- is detection of the appearance of "active" plugged-in nodes that
- issue special packets to show their appearance.
-
-
-
-
-H. Kitamura [Page 9]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- We can assume there will be complex cases in which standard and
- active plugged-in nodes are mixed together. For purposes of
- simplification, such cases are not discussed here.
-
-3.4.1 Detecting Appearance of "Standard" Plugged-in IPv6 Nodes
-
- In this case, plugged-in nodes do NOT issue special dedicated packets
- to show their appearance. (Current standard networks are composed of
- such nodes.) So, the Detector must watch for packets that are issued
- somewhere from new plugged-in nodes.
-
- The initial procedure for a standard plugged-in IPv6 node is to auto-
- configure its address and do DAD (Duplicate Address Detection) [ADDR-
- AUTO].
-
- DAD packets have sufficient characteristics for an appearance-
- detection method, because they are issued only when IPv6 nodes are
- plugged in, and address information for the plugged-in IPv6 nodes is
- included in DAD packets.
-
- By watching for only DAD packets, the Detector can detect appearances
- of new plugged-in IPv6 nodes, and DAD packets become triggers to
- start Domain Name Auto-Registration.
-
- This method enables the mechanism to function without introducing new
- protocols and without installing new functions into plugged-in IPv6
- nodes.
-
-
- DAD packets are issued not only for global addresses but also for
- link-local or site-local scope addresses. All detected information is
- sent to the Registrar, and the manner of dealing with information for
- non-global addresses is determined by Registrar algorithms that are
- indicated by Detector IDs of the detected information.
-
-
- This method works effectively on ordinary IPv6 links where DAD
- packets are issued. However, on extraordinary IPv6 links where DAD
- packets are not issued, it does not work. On such links, there must
- be another initial procedure that substitutes the DAD function. Such
- a procedure can be used as a trigger for a detection method on
- extraordinary IPv6 links.
-
- (IP addresses can be assigned by other methods (e.g., DHCP). Domain
- name registration mechanisms for such cases will be discussed in
- further revised documents.)
-
-
-
-
-
-H. Kitamura [Page 10]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
-3.4.2 Detecting Appearance of "Active" Plugged-in Nodes
-
- In this case, plugged-in nodes issue special dedicated packets to
- show their appearance. The Detector must listen for and receive
- packets from the new plugged-in nodes.
-
- Since plugged-in nodes do not know the location of the Detector,
- anycast or multicast packets are used for the special dedicated
- packets.
-
- In this method, plugged-in nodes can actively show their preference
- for their domain names. However, it will be difficult to show their
- preference under plug and play situations.
-
- In order to achieve the method, new protocols must be defined and new
- functions must be installed into plugged-in IPv6 nodes.
- (This will be discussed further in other documents.)
-
-3.5 Methods of Controlling Registration
-
- If received Dynamic Update messages are correctly formatted and
- authenticated, the DNS server accepts them without checking for any
- duplication, because the DNS server can not distinguish overwrite
- (update) registrations from duplicate registrations. It is difficult
- to achieve a mechanism for avoiding duplicated registrations on the
- DNS server side.
-
- Therefore, registrations by the Dynamic Update messages must be
- controlled on the Registrar side. This control mechanism also helps
- to minimize the effects of malicious or misconfigured registration
- requests.
-
- Plugged-in nodes may switch on and off frequently and issue DAD
- packets frequently. Since the Detector sends detected information
- without applying any selection rules to it, all detected information
- is sent to the Registrar. Thus, the Registrar must have some
- information verification mechanism to avoid duplicated registrations.
-
- All candidate information (detected addresses) for registration is
- checked by using inverse DNS resolving queries of them. If there is
- FQDN information that matches the detected address, such registration
- candidates are not registered.
-
- Only when FQDN information for it is NOT found and it is verified
- that the detected information is based on first appearance of the
- plugged-in node, appropriate domain name information for registration
- is prepared and both regular and inverse domain name information for
- it are registered to the DNS servers by the Dynamic Update messages.
-
-
-
-H. Kitamura [Page 11]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- By using this verification mechanism, the Registrar does not have to
- have a local database to maintain the status of the detected
- information and no DNS registration inconsistency problems are
- caused.
-
- By restricting the number of Dynamic Update messages that are sent
- from the Registrar per unit of time, the effects of malicious or
- misconfigured registration requests are minimized.
-
-
-3.6 Naming Rules for Default Domain Names
-
- This section describes a method of setting "default domain names" for
- plugged-in nodes.
-
- A fully qualified "default domain name" is composed of a node's
- original prefix part and a DNS zone suffix part that is the same for
- each site or link.
-
- Since a DNS zone suffix is given to the Registrar manually, only the
- naming rules for a node's original prefix are discussed here. A
- naming rule algorithm for a node's prefix is given to the Registrar
- manually.
-
- It is not necessary to define naming rules for a node's prefix
- explicitly in this document. Each site can define its own naming
- rules (algorithms) per link according to site policy.
-
- This document shows some example naming rules for a node's prefix
- name.
-
- 1. Prefix Letter(s) + Number
-
- This is the easiest rule. First, prefix letter(s) that depends on
- each link (Detector ID) is/are selected, and the following number
- is selected after that.
-
- The following numbers comprise sequential numbers. In order to
- achieve this, the Registrar must remember the last selected
- number.
-
- There are some situations where using sequential numbers is not
- favorable because the next number could be easily predicted. In
- those cases, random numbers can be used, which makes it necessary
- to implement the Registrar with a duplicate number check
- mechanism.
-
-
-
-
-
-H. Kitamura [Page 12]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- 2. Predefined Names
-
- The Registrar prepares predefined names (e.g., names of flowers)
- that are used for prefix names for plugged-in nodes. Random or
- sequential numbers can be used to prepare predefined names.
-
- This method can be used for an environment where the number of
- plugged-in nodes can be estimated and the number is not
- excessively large.
-
- 3. Use Preferences of Plugged-in Nodes.
-
- The Registrar inquires the preference or property of a plugged-in
- node, and uses the obtained information as a hint to define a
- prefix name for the plugged-in node.
-
- There are two types of methods for plugged-in nodes to indicate
- their preference or property.
-
-
- One is "passive" indication. Plugged-in nodes do NOT become an
- initiator to indicate their preferences. The Registrar becomes an
- initiator and issues query packets to plugged-in nodes. Existing
- protocol (e.g., Node Information Query [NIQ], SNMP) is used for
- it.
-
- For a detected global address, the Registrar can use Node
- Information Query [NIQ] to obtain hint information to define a
- name for the plugged-in node.
-
- By using [SNMP], the Registrar can also obtain hint information to
- define a name for the plugged-in node. Plugged-in nodes use parts
- of MIB to indicate their preferences or properties. It is possible
- to define a special MIB for this purpose. Also, some parts of
- currently existing MIB can be used for it. Most plugged-in nodes
- have already set some property information (OS type, version,
- etc.) to their MIB when they are plugged in. Such information can
- be used for a hint to define a prefix name. (The Registrar must
- have an appropriate read access right to such MIB information.)
-
- The other is "active" indication. Plugged-in nodes become an
- initiator to indicate their preferences and issue special
- dedicated packets for it. Since plugged-in nodes do not know the
- location of the Detector or Registrar, anycast or multicast
- packets are used for them. It is possible to attach name
- preference information to packets that are used for showing the
- appearance of plugged-in nodes. The Registrar can receive such
- information via the Detector.
-
-
-
-H. Kitamura [Page 13]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- In order to achieve the "active" indication method, new protocols
- must be defined and new functions must be installed into plugged-
- in IPv6 nodes.
- (This will be discussed further in other documents.)
-
-
-4. Procedures of the Domain Name Auto-Registration
-
- Figure 3 shows an example of typical Domain Name Auto-Registration
- procedures at IPv6 links where DAD packets are issued. DAD packets
- are used for the appearance detection method (for standard plugged-in
- IPv6 nodes).
-
- Plugged-in Router Detector Registrar DNS servers
- IPv6 Node
- | link local | | | |
- (a)|---DAD NS--->----------->| | |
- (b)| no NA | | | |
- (c)| | |----------->| |
- | | | | |
- | global | | | |
- (d)|(----RS--->)| | | |
- (e)|<----RA-----| | | |
- (f)|---DAD NS--->----------->| | |
- (g)| no NA | | | |
- (h)| | |----------->| |
- | | | | |
- (i)| | | |----------->|
- (j)| | | |<-----------|
- | | | | |
- (k)|(<-----------------------------------)| |
- (l)|(----------------------------------->)| |
- | | | | |
- (m)| | | |----------->|
- (n)| | | |<-----------|
- | | | | |
- (o)| | | |----------->|
- (p)| | | |<-----------|
- (q)| | | |----------->|
- (r)| | | |<-----------|
- | | | | |
-
- Fig. 3 Example of Typical Auto-Registration Procedures
-
- (a) and (b) are DAD procedures for the link-local address of the
- Plugged-in Node. (b) is a procedure to verify that there is no NA
- (reply to NS) and the link-local address is not duplicated on the
- link.
-
-
-
-H. Kitamura [Page 14]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- The Detector watches (a) and (b), and detects the appearance of new
- plugged-in IPv6 nodes. (c) is a procedure for sending the detected
- information, to which the Detector ID is attached. The scope of the
- detected address is not checked at the Detector.
-
- After the Registrar receives the detected information by the
- procedure (c), the scope of the detected address and the decision
- algorithm (which depends on the Detector ID) are checked on the
- Registrar.
-
- In typical cases, the decision algorithm shows that link-local
- addresses are not candidates for registration. In such cases, the
- detected information for the link-local address is discarded at this
- point.
-
- (d)(e)(f) and (g) are DAD procedures for the global address of the
- Plugged-in Node. (d) is an optional procedure. (g) is a procedure to
- verify that there is no NA (reply to NS) and that the global address
- is not duplicated.
-
- The Detector watches (f) and (g), and detects the appearance of new
- plugged-in IPv6 nodes. (h) is a procedure for sending the detected
- information, to which the Detector ID is attached.
-
- After the Registrar receives the detected information by the
- procedure (h), the scope of the detected address and decision
- algorithm (which depends on Detector ID) are checked on the
- Registrar.
-
- In typical cases, the decision algorithm shows that global addresses
- are candidates for registration. In such cases, check procedures to
- avoid duplicated registrations are started at this point.
-
- (i) and (j) are check procedures to verify that the detected address
- is must be registered to the DNS. The Registrar checks for the
- existence of FQDN information for the detected address by executing
- "inverse DNS name resolving" procedures with the detected address
- argument.
-
- If the existence of FQDN information for the detected address is
- verified, such detected address information for registration is
- canceled and discarded at this point.
-
- If the existence is not verified, the Registrar starts preparing
- "default domain name" information for the candidate IPv6 address. DNS
- zone suffix information that depends on the Detector ID is taken from
- the Registrar's manually configured database table, and the naming
- rule algorithm that depends on the Detector ID is also taken from it.
-
-
-
-H. Kitamura [Page 15]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- By following the defined naming rule algorithm, the plugged-in node's
- prefix name is selected.
-
- (k) and (l) are optional procedures for preparing "default domain
- name." If the naming rule that is applied for the detected address
- stipulates inquiring the preference or property of the node, (k) and
- (l) are executed and such information is obtained by the Registrar.
- The obtained information is used as a hint to select the prefix name
- of the plugged-in node.
-
- A candidate "default domain name" for the detected address is
- prepared here.
-
- (m) and (n) are check procedures to verify that the candidate
- "default domain name" is not used by anyone. The Registrar checks for
- the existence of the candidate "default domain name" by executing
- "regular DNS name resolving" procedures with the candidate "default
- domain name."
-
- If the existence is not verified, it becomes fully qualified "default
- domain name." If the existence is verified, the Registrar restarts
- and repeats preparing a candidate "default domain name" for the
- detected address.
-
-
- After fully qualified "default domain name" information to register
- is prepared, (o)(p)(q) and (r) are executed to register both regular
- and inverse domain name information to the DNS servers by the Dynamic
- Update messages.
-
- (Under manual configuration situations, (o)(p)(q) and (r) procedures
- are replaced by the administrators' manual registration (not by the
- Dynamic Updates).)
-
-
-5. Treatment of "Temporary Addresses" in the Mechanism
-
- "Temporary address" is defined in [RFC3041]. Temporary addresses are
- detected in this mechanism, because DAD packets are issued when
- temporary address are generated.
-
- There are two views whether domain names for temporary addresses
- should be registered to the DNS or not.
-
- One view is that domain names for temporary addresses should NOT be
- registered to the DNS, because temporary addresses are temporary and
- they are introduced to lessen privacy concerns.
-
-
-
-
-H. Kitamura [Page 16]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- The other view is domain names for temporary addresses should be
- registered to the DNS. [RFC3041] discusses on this issue at section 4
- of [RFC3041]. In order to meet conventional inverse-DNS-based
- "authentication," nodes could register temporary addresses in the DNS
- using random names. The Domain Name Auto-Registration mechanism can
- provide a solution for this issue.
-
- Since there are two views for domain names registration of temporary
- addresses, which view should be chosen is depends on site policies.
-
-
-
-5.1 How to Distinguish "Temporary Addresses" from Public Addresses
-
- In order to apply above discussed policies, it is necessary to
- distinguish "temporary addresses" from public addresses.
-
- Only with IP address information, it is difficult to tell that a
- detected address is a temporary address or a public addresses. So,
- link-layer address information is utilized to achieve this operation
- (see section 3.2).
-
- By utilizing link-layer address information, we can easily tell that
- a detected address is a EUI64-based address or not. (This operation
- is called a "EUI64 check" operation.)
-
- If a detected address is a EUI64-based, it is not a temporary
- address. It is a normal target address for the Domain Name Auto-
- Registration mechanism.
-
- If not, it must be a either temporary address or manually configured
- address. We can assume that a domain name for a manually configured
- address must have been registered in the DNS manually.
-
- In the mechanism, an IP address whose domain name has been already
- registered does not become a candidate. It is verified by "inverse
- DNS name resolving" check procedures (see (i) and (j) procedures in
- Figure 3).
-
- By applying a "EUI64 check" operation after "inverse DNS name
- resolving" check procedures, we can assume that non EUI64-based
- address must be a temporary address. Since temporary addresses are
- distinguished from public addresses, we can apply above discussed
- policies to temporary addresses.
-
-
-
-
-
-
-
-H. Kitamura [Page 17]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
-6. Security Considerations
-
- After the Address Autoconfiguration [ADDR-AUTO] has been executed,
- the Domain Name Auto-Registration works as a succeeding of the plug
- and play mechanism. The plugged-in IPv6 nodes' appearances detection
- method is depend on the Address Autoconfiguration.
-
- Thus, the items that are described in the Security Considerations
- section of the Address Autoconfiguration [ADDR-AUTO] are also
- applicable to this document.
-
- In addition, the following security issues are considered.
-
- Since the Detector must send detected information to the Registrar
- securely, some sort of secure communication method (e.g., [TSIG]-like
- authentication, IPsec (AH, ESP), [TLS]) must be used.
-
- The Registrars must be trusted nodes of the DNS servers and Dynamic
- Update messages must be sent securely from the Registrar to the DNS
- servers by using some sort of secure communication method. The [TSIG]
- technique would be suitable for authenticating the messages.
-
- In order to minimize the effects of malicious or misconfigured
- registration requests, the Registrar restricts the number of Dynamic
- Update messages that are sent from the Registrar per unit of time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-H. Kitamura [Page 18]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
-Appendix A. HTTP-based simple protocol between Detector and Registrar
-
- a. Design of HTTP parameters
-
- - Request Parameters
- method = <registration protocol>
- detectorID = <detector identifier(address)>
- IP-address = <detected IP address>
- link-layer-address = <detected link-layer address>
- source = <source type>
- time-detected = <detected time>
-
- - Response Parameters
- result = <result>
- address = <registered address>
- hostname = <registered hostname>
- namehint = <name hint>
- error = <error>
- time-accepted = <accepted time>
-
- b. Message Examples
-
- - Request message
- POST /cgi-bin/registrar.cgi HTTP/1.1
- Host: registrar-host
- Content-Length: mmm
- User-Agent: DAD-detector
- Content-type: application/x-pnp-dnar
-
- method=register/2.0
- detectorID=3ffe:xxxx::2a0:c9ff:fea6:7ff1
- IP-address=3ffe:yyyy::202:b3ff:fe2d:68c0
- link-layer-address=00:00:4c:zz:zz:zz
- source=DAD-detector
- time-detected=1013078377
-
- - Response message
- HTTP/1.1 200 OK
- Content-Type : text/plain
- Content-Length : nnn
- Connection : close
-
- result=REGISTER
- address=3ffe:yyyy::202:b3ff:fe2d:68c0
- hostname=host.example.com
- namehint=none
- time-accepted=1013078378
-
-
-
-
-H. Kitamura [Page 19]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
-References
-
- [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification," RFC2460, December 1998.
-
- [ND] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
- for IP Version 6 (IPv6)," RFC 2461, December 1998.
-
- [ADDR-AUTO] S. Thomson, T. Narten, "IPv6 Stateless Address
- Autoconfiguration," RFC2462, December 1998.
-
- [DYN-DNS] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic
- Updates in the Domain Name System," RFC 2136, April 1997.
-
- [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, D. and B.
- Wellington, "Secret Key Transaction Signatures for DNS
- (TSIG)," RFC 2845, May 2000.
-
- [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
- RFC2246, January 1999
-
- [DNS-SIG0] D. Eastlake, "DNS Request and Transaction Signatures
- ( SIG(0)s)," RFC2931, September 2000.
-
- [DYN-DNSSEC] B. Wellington, "Secure Domain Name System (DNS) Dynamic
- Update," RFC3007, November 2000.
-
- [DNSSEC] B. Wellington, "Domain Name System Security (DNSSEC) Signing
- Authority," RFC 3008, November 2000.
-
- [SNMP] J. Case, K. McCloghrie, M. Rose, S.Waldbusser, "Protocol
- Operations for Version 2 of the Simple Network Management
- Protocol (SNMPv2)," RFC1905, January 1996.
-
- [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless
- Address Autoconfiguration in IPv6," RFC3041, January 2001
-
- [HTTP] R. Fielding, et al, "Hypertext Transfer Protocol -- HTTP/1.1"
- RFC2616, June 1999
-
- [TLS-HTTP] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1"
- RFC2817, May 2000
-
-
-
-
-
-
-
-
-
-H. Kitamura [Page 20]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration July 2002
-
-
- [DNS-DISC] A. Durand, J. Hagino, D. Thaler, "Well known site local
- unicast addresses for DNS resolver,"
- <draft-ietf-ipv6-dns-discovery-05.txt>, June 2002
-
- [DEF-ADDR] R. Draves, "Default Address Selection for IPv6,"
- <draft-ietf-ipngwg-default-addr-select-08.txt>, June 2002
-
-
- [NIQ] M. Crawford, "IPv6 Node Information Queries,"
- <draft-ietf-ipngwg-icmp-name-lookups-09.txt>, May 2001
-
-
-
-
-
-
-Author's Address:
-
- Hiroshi Kitamura
- NEC Corporation
- Development Laboratories
- (Igarashi Building 4F) 11-5, Shibaura 2-Chome,
- Minato-Ku, Tokyo 108-8557, JAPAN
-
- Phone: +81 (3) 5476-1071
- Fax: +81 (3) 5476-1005
- Email: kitamura@da.jp.nec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-H. Kitamura [Page 21]
+++ /dev/null
-INTERNET-DRAFT John C. Klensin
-December 13, 2000
-Expires June 2000
-
- Reflections on the DNS, RFC 1591, and Categories of Domains
- draft-klensin-1591-reflections-02.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance
- with all provisions of Section 10 of RFC2026 except that the
- right to produce derivative works is not granted.
-
- 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 document is purely informational, for comment, and to stimulate
-other discussions: it is not expected to be, or evolve into, a
-standard of any form.
-
-
-0. Abstract
-
-RFC 1591, "Domain Name System Structure and Delegation" [1] laid out
-the basic administrative design and principles for the allocation and
-administration of domains, from the top level down. It was written
-before the introduction of the world wide web and rapid growth of the
-Internet put significant market, social, and political pressure on
-domain name allocations. In recent years, 1591 has been cited by all
-sides in various debates, and attempts have been made by various
-bodies to update it or adjust its provisions, sometimes under
-pressures that have arguably produced policies that are less well
-thought out than the original. Some of those efforts have begun from
-misconceptions about the provisions of 1591 or the motivation for
-those provisions. The current directions of ICANN and other groups
-who now determine DNS policy directions appear to be drifting away
-from policies and philosophy of 1591. This document is being
-published primarily for historical context and comparative purposes,
-essentially to document some thoughts about how 1591 might have been
-interpreted and adjusted by the IANA and ICANN to better reflect
-today's world while retaining characteristics and policies that have
-proven to be effective in supporting Internet growth and stability.
-An earlier variation of this memo was submitted to ICANN as a comment
-on its evolving TLD policies.
-
-
-1. Introduction
-
-RFC1591 has been heavily discussed and referenced in the last year or
-two, especially in discussions within ICANN and its predecessors
-about the creation, delegation, and management of top-level domains.
-In particular, the ICANN Domain Name Supporting Organization (DNSO),
-and especially its ccTLD constituency, have been the home of many
-discussions in which 1591 and interpretations of it have been cited
-in support of a variety of sometimes-contradictory positions. During
-that period, other discussions have gone on to try to reconstruct the
-thinking that went into RFC 1591. Those in turn have led me and
-others to muse on how that original thinking might relate to some of
-the issues being raised. 1591 is, I believe, one of Jon Postel's
-masterpieces, drawing together very different philosophies (e.g., his
-traditional view that people are basically reasonable and will do the
-right thing if told what it is with some stronger mechanisms when
-that model is not successful) into a single whole.
-
-RFC 1591 was written in the context of the assumption that what it
-described as generic TLDs would be bound to policies and categories
-of registration (see the "This domain is intended..." text in
-section 2) while ccTLDs were expected to be used primarily to support
-users and uses within and for a country and its residents. The
-notion that different domains would be run in different ways --albeit
-within the broad contexts of "public service on behalf of the
-Internet community" and "trustee... for the global Internet
-community"-- was considered a design feature and a safeguard against
-a variety of potential abuses. Obviously the world has changed in
-many ways in the six or seven years since 1591 was written. In
-particular, the Internet has become more heavily used and, because
-the design of the world wide web has put domain names in front of
-users, top-level domain names and registrations in them have been
-heavily in demand: not only has the number of hosts increased
-dramatically during that time, but the ratio between registered
-domain names and physical hosts has increased very significantly.
-
-The issues 1591 attempted to address when it was written and those we
-face today have not changed significantly in principle. But one
-alternative to present trends would be to take a step back to refine
-it into a model that can function effectively today. Therefore, it
-may be useful to try to reconstruct 1591's principles and think about
-their applicability today as a model that could continue to be
-applied: not because it is historically significant, but because many
-of its elements have proven to work reasonably well, even in
-difficult situations. In particular, for many domains (some in
-1591's "generic" list and others in its "country code" category) the
-notion of "public service" --expected then to imply being carried out
-at no or minimal cost to the users, not merely on a non-profit
-basis-- has yielded to profitability calculations. And, in most of
-the rest, considerations of at least calculating and recovering costs
-have crept in. While many of us feel some nostalgia for the old
-system, it is clear that its days are waning if not gone: perhaps the
-public service notions as understood when 1591 was written just don't
-scale to rapid internet growth and very large numbers of
-registrations.
-
-In particular, some ccTLDs have advertised for registrations outside
-the designated countries (or other entities), while others have made
-clear decisions to allow registrations by non-nationals. These
-decisions and others have produced protests from many sides,
-suggesting, in turn, that a recategorization is in order. For
-example, we have heard concerns by governments and managers of
-traditional, "public service", in-country, ccTLDs about excessive
-ICANN interference and fears of being forced to conform to
-internationally-set policies for dispute resolution when their
-domestic ones are considered more appropriate. We have also heard
-concerns from registrars and operators of externally-marketed ccTLDs
-about unreasonable government interference and from gTLD registrars
-and registries about unreasonable competition from aggressively
-marketed ccTLDs. The appropriate distinction is no longer between
-what RFC 1591 described as "generic" TLDs (but which were really
-intended to be "purpose-specific", a term I will use again below) and
-ccTLDs but among:
-
- (i) true "generic" TLDs, in which any registration is acceptable
- and, ordinarily, registrations from all sources are actively
- promoted. This list currently includes (the formerly
- purpose-specific) COM, NET, and ORG, and some ccTLDs. There have
- been proposals from time to time for additional TLDs of this
- variety in which, as with COM (and, more recently, NET and ORG)
- anyone (generally subject only to name conflicts and national
- law) could register who could pay the fees.
-
- (ii) purpose-specific TLDs, in which registration is accepted
- only from organizations or individuals meeting particular
- qualifications, but where those qualifications are not tied to
- national boundaries. This list currently includes INT, EDU, the
- infrastructure domain ARPA, and, arguably, the specialized US
- Government TLDs MIL and GOV. There have been proposals from
- time to time for other international TLDs of this variety, e.g.,
- for medical entities such as physicians and hospitals and for
- museums. ICANN has recently approved several TLDs of this type
- and describes them as "sponsored" TLDs.
-
- (iii) Country domains, operated according to the original
- underlying assumptions of 1591, i.e., registrants are largely
- expected to be people or other entities within the country.
- While external registrations might be accepted by some of these,
- the country does not aggressively advertise for such
- registrations, nor does anyone expect to derive significant fee
- revenue from them. All current domains in this category are
- ccTLDs, but not all ccTLDs are in this category.
-
-These categories are clearly orthogonal to the association between
-the use of the IS 3166-1 registered code list [2] and two-letter
-"country" domain names. If that relationship is to be maintained
-(and I believe it is desirable), the only inherent requirement is
-that no two-letter TLDs be created except from that list (in order to
-avoid future conflicts). ICANN should control the allocation and
-delegation of TLDs using these, and other, criteria, but only
-registered 3166-1 two letter codes should be used as two-letter TLDs.
-
-
-2. Implications of the Categories
-
-If we had adopted this type of three-way categorization and could
-make it work, I believe it would have presented several opportunities
-for ICANN and the community more generally to reduce controversies
-and move forward. Of course, there will be cases where the
-categorization of a particular domain and its operating style will
-not be completely clear-cut (see section 3, below). But having ICANN
-work out procedures for dealing with those (probably few) situations
-appears preferable to strategies that would tend to propel ICANN into
-areas that are beyond its competence or that might require
-significant expansion of its mandate.
-
-First, the internally-operated ccTLDs (category iii above) should not
-be required to have much interaction with ICANN or vice versa. Once
-a domain of this sort is established and delegated, and assuming that
-the "admin contact in the country" rule is strictly observed, the
-domain should be able to function effectively without ICANN
-intervention or oversight. In particular, while a country might
-choose to adopt the general ICANN policies about dispute resolution
-or name management, issues that arise in these areas might equally
-well be dealt with exclusively under applicable national laws. If a
-domain chooses to use ICANN services that cost resources to provide,
-it should contribute to ICANN's support, but, if it does not, ICANN
-should not presume to charge it for other than a reasonable fraction
-of the costs to ICANN of operating the root, root servers, and any
-directory systems that are generally agreed upon to be necessary and
-in which the domain participates.
-
-By contrast, ccTLDs operated as generic domains ought to be treated
-as generic domains. ICANN dispute resolution and name management
-policies and any special rules developed to protect the Internet
-public in multiple registrar or registry situations should reasonably
-apply.
-
-3. Telling TLD types apart
-
-If appropriate policies are adopted, ccTLDs operated as generic
-domains (category (i) above) and those operated as country domains
-(category (iii) above) ought to be able to be self-identified. There
-are several criteria that could be applied to make this
-determination. For example, either a domain is aggressively seeking
-outside registrations or it is not and either the vast majority of
-registrants in a domain are in-country or they are not. One could
-also think of this as the issue of having some tangible level of
-presence in the jurisdiction - e.g., is the administrative contact
-subject, in practical terms, to the in-country laws, or are the
-registration rules such that it is reasonably likely that a court in
-the jurisdiction of the country associated with the domain can
-exercise jurisdiction and enforce a judgment against the registrant.
-
-One (fairly non-intrusive) rule ICANN might well impose on all
-top-level domains is that they identify and publish the policies they
-intend to use. E.g., registrants in a domain that will use the laws
-of one particular country to resolve disputes should have a
-reasonable opportunity to understand those policies prior to
-registration and to make other arrangements (e.g., to register
-elsewhere) if that mechanism for dispute resolution is not
-acceptable. Giving IANA (as the root registrar) incorrect
-information about the purpose and use of a domain should be subject
-to challenge, and should be grounds for reviewing the appropriateness
-of the domain delegation, just as not acting consistently and
-equitably provides such grounds under the original provisions of RFC
-1591.
-
-In order to ensure the availability of accurate and up-to-date
-registration information the criteria must be consistent, and
-consistent with more traditional gTLDs, for all nominally country
-code domains operating as generic TLDs.
-
-
-4. The role of ICANN in country domains
-
-ICANN (and IANA) should, as described above, have as little
-involvement as possible in the direction of true country [code]
-domains (i.e., category (iii)). There is no particular reason why
-these domains should be subject to ICANN regulation beyond the basic
-principles of 1591 and associated arrangements needed to ensure
-Internet interoperability and stability.
-
-ICANN's avoiding such involvement strengthens it: the desirability of
-avoiding collisions with national sovereignty, determinations about
-government legitimacy, and the authority of someone purportedly
-writing on behalf of a government, is as important today as it was
-when 1591 was written. The alternatives take us quickly from
-"administration" into "internet governance" or, in the case of
-determining which claimant is the legitimate government of a country,
-"international relations", and the reasons for not moving in that
-particular direction are legion.
-
-5. The role of governments
-
-The history of IANA strategy in handling ccTLDs included three major
-"things to avoid" considerations:
-
- * Never get involved in determining which entities were countries
- and which ones were not.
-
- * Never get involved in determining who was, or was not, the
- legitimate government of a country. And, more generally, avoid
- deciding what entity --government, religion, commercial,
- academic, etc.-- has what legitimacy or rights.
-
- * If possible, never become involved in in-country disputes.
- Instead, very strongly encourage internal parties to work
- problems out among themselves. At most, adopt a role as
- mediator and educator, rather than judge, unless abuses are very
- clear and clearly will not be settled by any internal mechanism.
-
-All three considerations were obviously intended to avoid IANA's
-being dragged into a political morass in which it had (and, I
-suggest, has) no competence to resolve the issues and could only get
-bogged down. The first consideration was the most visible (and the
-easiest) and was implemented by strict adherence to the ISO 3166
-registered Country Code list. If an entity had a code, it was
-eligible to be registered with a TLD (although IANA was free to apply
-other criteria-most of them stated in 1591). If it did not, there
-were no exceptions: the applicant's only recourse was a discussion
-with the 3166 Registration Authority (now Maintenance Agency, often
-known just as "3166/MA") or the UN Statistical Office (now Statistics
-Bureau), not with IANA.
-This, obviously, is also the argument against use of the "reserved"
-list, at least without explicit agreement with 3166/MA: since IANA
-(or ICANN) can ask that a name be placed on that list, there is no
-rule of an absolute determination by an external organization.
-Purported countries can come to ICANN, insist on having delegations
-made and persuade ICANN to ask that the names be reserved. Then,
-since the reserved name would exist, they could insist that the
-domain be delegated. Worse, someone could use another organization
-to request reservation of the name by 3166/MA; once it was reserved,
-ICANN might be hard-pressed not to do the delegation. Of course,
-ICANN could (and probably would be forced to) adopt additional
-criteria other than appearance on the "reserved list" in order to
-delegate such domains. But those criteria would almost certainly be
-nearly equivalent to determining which applicants were legitimate and
-stable enough to be considered a country, the exact decision process
-that 1591 strove to avoid.
-
-The other two considerations were more subtle and not always
-successful: from time to time, both before and after the formal
-policy shifted toward "governments could have their way", IANA
-received letters from people purporting to be competent government
-authorities asking for changes. Some of them turned out later to not
-have that authority or appropriate qualifications. The assumption of
-1591 itself was that, if the "administrative contact in country" rule
-was strictly observed, as was the rule that delegation changes
-requested by the administrative contact would be honored, then, if a
-government _really_ wanted to assert itself, it could pressure the
-administrative contact into requesting the changes it wanted, using
-whatever would pass for due process in that country. And the ability
-to apply that process and pressure would effectively determine who
-was the government and who wasn't, and would do so far more
-effectively than any IANA evaluation of, e.g., whether the letterhead
-on a request looked authentic (and far more safely for ICANN than
-asking the opinion of any particular other government or selection of
-governments).
-
-Specific language in 1591 permitted IANA to adopt a "work it out
-yourselves; if we have to decide, we will strive for a solution that
-is not satisfactory to any party" stance. That approach was used
-successfully, along with large doses of education, on many occasions
-over the years, to avoid IANA's having to assume the role of judge
-between conflicting parties.
-
-Similar principles could be applied to the boundary between country-
-code-based generic TLDs and country domains. Different countries,
-under different circumstances, might prefer to operate the ccTLD
-either as a national service or as a profit center where the
-"customers" were largely external. Whatever decisions were made
-historically, general Internet stability argues that changes should
-not be made lightly. At the same time, if a government wishes to
-make a change, the best mechanism for doing so is not to involve
-ICANN in a potential determination of legitimacy (or even to have the
-GAC try to formally make that decision for individual countries) but
-for the relevant government to use its own procedures to persuade the
-administrative contact to request the change and for IANA to promptly
-and efficiently carry out requests made by administrative contacts.
-
-
-6. Implications for the current DNSO structure.
-
-The arguments by some of the ccTLD administrators that they are
-different from the rest of the ICANN and DNSO structures are (in this
-model) correct: they are different. The ccTLDs that are operating as
-generic TLDs should be separated from the ccTLD constituency and
-joined to the gTLD constituency. The country ccTLDs should be
-separated from ICANN's immediate Supporting Organization structure,
-and operate in a parallel and advisory capacity to ICANN, similar to
-the arrangements used with the GAC. The DNSO and country TLDs should
-not be required to interact with each other except on a mutually
-voluntary basis and, if ICANN needs interaction or advice from some
-of all of those TLDs, it would be more appropriate to get it in the
-form of an advisory body like the GAC rather than as DNSO
-constituency.
-
-7. References
-
-[1] Postel, Jon. Domain Name System Structure and Delegation,
- RFC 1591. USC Information Sciences Institute: March 1994.
-
-[2] ISO 3166. Codes for the identification of names of countries (??)
-
-8. Acknowledgements and disclaimer
-
-These reflections have been prepared in my individual capacity and do
-not necessarily reflect the views of my past or present employers.
-Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
-Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
-suggestions or offered editorial comments about earlier versions of
-this document. Those comments contributed significantly to whatever
-clarity the document has, but the author bears responsibility for the
-selection of comments which were ultimately incorporated and the way
-in which the conclusions were presented.
-
-9. Security Considerations
-
-This memo addresses the context for a set of administrative decisions
-and procedures, and does not raise or address security issues.
-
-
-10. Author's address
-
-John C Klensin
-1770 Massachusetts Ave, Suite 322
-Cambridge, MA 02140, USA
-klensin@jck.com
+++ /dev/null
-INTERNET-DRAFT John C. Klensin
-February 25, 2002
-Expires July 2002
-
-
- Role of the Domain Name System
- draft-klensin-dns-role-02.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 document represents a summary of the personal opinions of the
-author on the subject covered and is not intended to evolve into a
-standard of any kind.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-
-
-0. Abstract
-
-The original function and purpose of the DNS is reviewed, and
-contrasted with some of the functions into which it is being forced
-today and some of the newer demands being placed upon it or suggested
-for it. A framework for an alternative to placing these additional
-stresses on the DNS is then outlined. This document and that
-framework are not a proposed solution, only a strong suggestion that
-the time has come to begin thinking more broadly about the problems
-we are encountering and possible approaches to solving them.
-
-A mailing list has been initiated for discussion of this draft, its
-successors, and closely-related issues at ietf-irnss@lists.elistx.com.
-See http://lists.elistx.com/archives/ for subscription and archival
-information.
-
-Table of Contents
-
-0. Abstract
-1. History
-1.1 Context for DNS development
-1.2 Review of the DNS and its role as designed
-1.3 The web and user-visible domain names
-1.4 A pessimistic history of the evolution of Internet applications
- protocols.
-2. Signs of DNS overloading
-3. The search system story.
-3.1 Overview
-3.2 Some details and comments.
-4. Examining internationalization
-4.1. ASCII isn't just because of English
-4.2. The "ASCII Encoding" approaches
-4.3. "Nameprep" and its complexities
-4.4 The UCS Stability Problem
-4.5. Audiences, end users, and the UI problem
-4.6 Business cards and other natural uses of natural languages
-4.7 ASCII encodings and the Roman keyboard assumption
-4.8 A pessimistic summary of IDN WG directions
-5. The Key Controversies
-5.1. One directory or many
-5.2 Why not a proposal?
-6. Security Considerations
-7. References
-7.1. Normative References
-7.2. Explanatory and Informative References
-8. Acknowledgements
-10. Culprit address
-
-
-1. History
-
-Several of the comments that follow are somewhat revisionist. Good
-design and engineering often requires a level of intuition by the
-designers about things that will be necessary in the future; the
-reasons for some of these design decisions are not made explicit at
-the time because no one is able to articulate them. The discussion
-below reconstructs some of the decisions about the Internet's primary
-namespace (the "Class=IN" DNS) in the light of subsequent development
-and experience. In addition, the historical reasons for particular
-decisions about the Internet were often severely underdocumented
-contemporaneously and, not surprisingly, different participants have
-different recollections about what happened and what was considered
-important. Consequently, the quasi-historical story below is just
-one story. There may be (indeed, almost certainly are) other stories
-about how we got to where we are today, but they probably don't, of
-themselves, invalidate the inferences and conclusions.
-
-1.1 Context for DNS development
-
-During the entire post-startup-period life of the ARPANET and nearly
-the first decade or so of operation of the Internet, the list of host
-names and their mapping to and from addresses was maintained in a
-frequently-updated "host table" [RFC625, 811, 952]. The names
-themselves were restricted to a subset of ASCII chosen to avoid
-ambiguities in printed form, to permit interoperation with systems
-using other character codings (notably EBCDIC), and to avoid the
-"national use" code positions of ISO 646 [IS646]. This table was
-just a list with a common format that was eventually agreed-upon;
-sites were expected to frequently obtain copies of, and install, new
-versions. The host tables themselves were introduced to
-
- * Eliminate the requirement for people to remember host numbers
- (addresses). Despite apparent experience to the contrary in the
- conventional telephone system, numeric numbering systems, including
- the numeric host number strategy, did not (and do not) work well for
- more than a (large) handful of hosts.
-
- * Provide stability when addresses changed. Since addresses --to
- some degree in the ARPANET and more importantly in the contemporary
- Internet-- are a function of network topology and routing, they
- often had to be changed when connectivity or topology changed. The
- names could be kept stable even as addresses changed.
-
- * Some hosts (so-called "multihomed" ones) needed multiple
- addresses to reflect different types of connectivity and topology.
- Again, the names were very useful for avoiding the requirement that
- would otherwise exist for users and other hosts to track these
- multiple host numbers and addresses and the topological
- considerations for selecting one over others.
-
-Toward the end of that long (in network time) period, the community
-concluded that the host table model did not scale adequately and that
-it would not adequately support new service variations. A working
-group was created, and the DNS was the result of that effort. The
-role of the DNS was to preserve the capabilities of the host table
-arrangements (especially unique, unambiguous, host names), provide for
-addition of additional services (e.g., the special record types for
-electronic mail routing which quickly followed introduction of the
-DNS), and to do so on the base of a robust, hierarchical, distributed,
-name lookup system. That system also permitted distribution of name
-administration, rather than requiring that each host be entered into a
-single, central, table by a central administration.
-
-1.2 Review of the DNS and its role as designed
-
-The DNS was designed primarily to identify network resources.
-Although there was speculation about including, e.g., personal names
-and email addresses, it was not designed primarily to identify people,
-brands, etc. At the same time, the system was designed with the
-flexibility to accomodate new data types and structures, both through
-the addition of new record types to the initial "INternet" class, and,
-potentially, through the introduction of new classes. Since the
-appropriate identifiers and content of those future extensions could
-not be anticipated, the design provided that these fields could
-contain any (binary) information, not just the` restricted text forms
-of the host table.
-
-However, the DNS as-used is intimately tied to the applications and
-application protocols that utilize it, often at a fairly low level.
-
-In particular, despite the ability of the protocols and data
-structures themselves to accomodate any binary representation, DNS
-names as used are historically not [even] ASCII, but a very
-restricted subset of it, a subset that derives primarily from the
-original host table naming rules. Selection of that subset was
-driven in part by human factors considerations, including a desire to
-eliminate possible ambiguities in an international context. Hence
-character codes that had international variations in interpretation
-were excluded, the underscore character and case distinctions were
-eliminated as being confusing (in the underscore's case, with the
-hyphen character) when written or read by people, and so on. These
-considerations appear to be very similar to those that resulted in
-similarly restricted character sets being used as protocol elements
-in many ITU and ISO protocols (cf. [X29]).
-
-Another assumption was that there would be a high ratio of physical
-hosts to second level domains and, more generally, that the system
-would be deeply hierarchical, with most systems (and names) at the
-third level or below and a large ratio of names representing physical
-hosts to total names. There are domains that follow this model: many
-university and corporate domains use fairly deep hierarchies, as do a
-few country code TLDs (".US" is an excellent example). However, the
-RIPE hostcount list is now showing a count of SOA records that is
-approaching (and may have passed) the number of distinct hosts.
-While recent experience has shown that the DNS is robust enough
---given contemporary machines as servers and current bandwidth
-norms-- to be able to continue to operate reasonably well when those
-historical assumptions are not met (e.g., with a huge, flat,
-structure under ".COM"), it is still useful to remember that the
-system could have been designed to work optimally with a flat
-structure (and very large zones) rather than a deeply hierarchical
-one, and was not.
-
-Similarly, despite some early speculation about entering people's
-names and email addresses into the DNS directly, with the sole
-exception (at least in the "IN" class) of one field of the SOA
-record, electronic mail addresses in the Internet have preserved the
-original, pre-DNS, "user at location" conceptual format rather than a
-flatter or strictly faceted one. Location, in that instance, is a
-reference to a host.
-
-Both the DNS architecture itself and the two-level provisions for
-email and similar functions (e.g., see the finger protocol), also
-anticipated a relatively high ratio of users to actual hosts. Despite
-the observation in RFC 1034 that the DNS was expected to grow to be
-proportional to the number of users (section 2.3), it has never been
-clear that the DNS was seriously designed for, or could, scale to the
-order of magnitude of number of users (or, more recently, products or
-document objects), rather than that of physical hosts.
-
-Like the host table before it, the DNS has provided criticial
-uniqueness for names and universal accessibility to them as part of
-overall "single internet" and "end to end" models (cf [RFC2826]).
-However, there are many signs that, as new uses evolve and original
-assmumptions are abused, the system is being stretched to, or beyond,
-its practical limits.
-
-The original design effort that led to the DNS included examination
-of the directory technologies available at the time. The working
-group concluded that the DNS design, with its simplifying assumptions
-and restricted capabilities, would be feasible to deploy and make
-adequately robust, which the more comprehensive directory approaches
-were not. At the same time, some of the participants feared that the
-limitations might cause future problems; this document essentially
-takes the position that they were probably correct. On the other
-hand, directory technology and implementations have evolved
-significantly in the ensuing years: it may be time to revisit the
-assumptions, either in the context of the two- (or more) level
-mechanism contemplated by the rest of this document or, even more
-radically, as a path toward a DNS replacement.
-
-
-1.3 The web and user-visible domain names
-
-From the standpoint of the integrity of the domain name system --and
-scaling of the Internet, including optimal accessibility to content--
-the web design decision to use "A record" domain names, rather than
-some system of indirection, has proven to be a serious mistake in
-several respects. Convenience of typing, and the desire to make
-domain names out of easily-remembered product names, has led to a
-flattening of the DNS, with many people now perceiving that
-second-level names under COM (or in some countries, second- or
-third-level names under the relevant ccTLD) are all that is
-meaningful (this perception has been reinforced by some domain name
-registrars who have been anxious to "sell" additional names). And,
-of course, the perception that one needs a top-level domain per
-product, rather than a (usually organizational) collection of network
-resources has led to a rapid acceleration in the number of names
-being registered, a phenonenum that has clearly benefited registrars
-charging on a per-name basis, "cybersquatters", and others in the
-business of "selling" names, but has not obviously benefitted the
-Internet as a whole.
-
-The emphasis on second-level domain names has also created a problem
-for the trademark community. Since the Internet is international,
-and names are being populated in a flat and unqualified space,
-similarly-named entities are in conflict even if there would
-ordinarily be no chance of confusing them in the marketplace. The
-problem appears to be unsolvable except by a choice between draconian
-measures --possibly including significant changes to the underlying
-legislation and conventions-- and a situation in which the "rights"
-to a name are typically not settled using the subtle and traditional
-product (or industry) type and geopolitical scope rules of the
-trademark system but by depending largely on main force, e.g., the
-organization with the greatest resources to invest in defending (or
-attacking) names will ultimately win out. The latter raises not only
-important issues of equity, but the risk of backlash as the numerous
-small players are forced to relinquish names they find attractive and
-to adopt less-desirable naming conventions.
-
-Independent of these sociopolitical problems, content distribution
-issues have made it clear that it should be possible for an
-organization to have copies of data it wishes to make available
-distributed around the network, with a user who asks for the
-information by name getting the topologically-closest copy. This is
-not possible with simple, as-designed, use of the DNS: DNS names
-identify target resources or, in the case of email "MX" records, a
-preferentially-ordered list of resources "closest" to a target (not
-to the source/user). Several technologies (and, in some cases,
-corresponding business models) have arisen to work around these
-problems, including intercepting and altering DNS requests so as to
-point to other locations,
-
-While additional implications are still being discovered and
-seriously evaluated, it appears, not surprisingly, that rewriting DNS
-names in the middle of the network, or trying to give them different
-values or interpretations depending on the topological location of
-the user trying to resolve the name interferes, in the general case,
-with end-to-end applications. These problems occur even if the
-rewriting machinery is accompanied by additional workarounds for
-particular applications: security associations and applications that
-need to identify "the same host" as the applications for which these
-tools have been designed often run into one problem or another.
-
-
-1.4 A pessimistic history of the evolution of Internet applications
-protocols.
-
-At the applications level, few of the protocols in active, widespread
-use on the Internet reflect the either contemporary knowledge in
-computer science or human factors or experience accumulated through
-deployment and use. Instead, protocols tend to be deployed at a
-just-past-prototype level, typically including the types of expedient
-compromises typical with prototypes. If they prove useful, the
-nature of the network permit very rapid dissemination (i.e., they
-fill a vacuum, even if a vacuum that no one previously knew existed).
-But, once the vacuum is filled, the installed base provides its own
-inertia: unless the design is so seriously faulty as to prevent
-effective use (or there is a widely-perceived sense of impending
-disaster unless the protocol is replaced), future developments must
-maintain backward compatibility and workarounds for problematic
-characteristics rather than benefiting from redesign in the light of
-experience. Applications that are "almost good enough" prevent
-development and deployment of high-quality replacements.
-
-
-2. Signs of DNS overloading
-
-Parts of the historical discussion above identify areas in which it
-is becoming clear that the DNS is becoming overloaded (semantically
-if not in the mechanical ability to resolve names). While we seem to
-still be well within the "just about good enough" range -- current
-mechanisms and proposals to deal with these problems are all focused
-on patching or working around limitations within the DNS rather than
-dramatic rethinking -- the number of these issues that are arising
-at the same time may argue for rethinging mechanisms and
-relationships, not just more patches and kludges. For example:
-
-o While technical approaches such as larger and higher-powered
-servers and more bandwidth, and legal/political mechanisms such as
-dispute resolution policies, have arguably kept the problems from
-becoming critical, the DNS has not proven adequately responsive to
-business and individual needs to describe or identify things (such as
-product names and names of individuals) other than strict network
-resources.
-
-o While stacks have been modified to better handle multiple addresses
-on a physical interface and some protocols have been extended to
-include DNS names for determining context, the DNS doesn't deal
-especially well with high-multiple names per host (needed for web
-hosting facilities with multiple domains on a server).
-
-o Efforts to add names deriving from languages or character sets
-based on other than simple ASCII and English-like names (see below),
-or even to utilize complex company or product names without the use
-of hierarchy have created apparent requirements for names (labels)
-that are over 63 octets long. This requirement will undoubtedly
-increase over time; while there are workarounds to accomodate longer
-names, they impose their own restrictions and cause their own
-problems.
-
-o Increasing commercialization of the Internet, and visibility of
-domain names that are assumed to match names of companies or
-products, has turned the DNS and DNS names into a trademark
-battleground. The traditional trademark system in (at least) most
-countries makes careful distinctions about fields of applicability.
-When the space is flattened, without differentiators by either
-geography or industry sector, not only are there likely conflicts
-between "Joe's Pizza" (of Boston) and "Joe's Pizza" (of San
-Francisco) but between both and "Joe's Auto Repair" (of Los Angeles):
-all three would like to control "Joes.com" (and would prefer, if it
-were permitted by DNS naming rules, to spell it as "Joe's.com" and
-have both resolve the same way) and may claim trademark rights to do
-so, even though conflict or confusion would not occcur with
-traditional trademark principles.
-
-o Many organizations wish to have different web sites under the same
-URL and domain name. Sometimes this is to create local variations
---the Widget Company might want to present different material to a UK
-user relative to a US one-- and sometimes it is to provide higher
-performance by supplying information from the server topologically
-closest to the user. Arguably, the name resolution mechanism should
-provide information about multiple sites that can provide information
-associated with the same name and sufficient attributes associated
-with each of those sites to permit applications to make sensible
-choices, or should accept client-site attributes and utilize them in
-the search process. Or, it should be able to return different
-answers based on the location or identity of the requestor. While
-there are some tricks that can provide partial simulations of this
-type of function, DNS responses cannot be reliably conditioned in
-this way.
-
-o Many existing and proposed systems for "finding things on the
-Internet" require a true search capability in which near matches can
-be reported to the user, or to some user agent with an apppropriate
-rule-set, and queries may be slightly ambiguous or fuzzy. The DNS
-can accomodate only one set of (quite rigid) matching rules. Current
-proposals to permit different rules in different localities help to
-identify the problem, but, if applied directly to the DNS, either
-don't provide the level of flexibility that would be desirable or
-tend to isolate different parts of the Internet from each other (or
-both). Fuzzy or ambiguous searches are desirable for (at least)
-resolution of business names that might have spelling variations and
-for names that can be resolved into different sets of glyphs
-depending on context. This goes beyond "mere" canonicalization
-differences (different ways of representing the same character or
-ordering the same string) and into such relationships as the use of
-different alphabets for the same language, Kanji-Hiragana
-relationships, Simplified and Traditional Chinese, etc.
-
-o The historical DNS and applications that make assumptions about how
-it works impose significant risk (or forces technical kludges and
-consequent odd restrictions), when one considers adding mechanisms
-for use with various multi-character-set and multilingual
-"internationalization" systems. Cf RFC 2825.
-
-o In order to provide proper functionality to the Internet, the DNS
-must have a single unique root (see RFC 2826 for a discussion of this
-issue). There are many desires for local treatment of names or
-character sets that cannot be accomodated without either multiple
-roots (e.g., a separate root for multilingual names) or mechanisms
-that would have similar effects in terms of Internet fragmentation
-and isolation.
-
-o For some purposes, it is desirable to be able to search targets
-(i.e., by value, not just by name (label)). One might, for example,
-want to locate all of the host (and virtual host) names which cause
-mail to be directed to a given server via MX records. The DNS does
-not support this capability and it can be simulated only by
-extracting all of the relevant records (perhaps by zone transfer if
-the source doesn't prohibit that through access lists) and then
-searching a file built from those records.
-
-o Finally, as additional types of personal or identifying information
-are added to the DNS, issues of protection of that information and
-making different information available based on the credentials and
-authorization of the source of the inquiry. As with site locational
-and proximity information (as discussed above), the DNS protocols
-make the mechanisms needed to do this quite difficult if not
-impossible.
-
-In each of these cases, it is, or might be, possible to devise ways
-to trick the DNS system into supporting mechanisms that were not
-designed into it. Several ingenious solutions have been proposed in
-many of these areas already, and some have been deployed into the
-marketplace with some success.
-
-Several of the above problems are addressed well by a good directory
-system (supported by the LDAP protocol or some protocol more
-precisely suited to these specific applications) or searching
-environment (such as common web search engines) although not by the
-DNS. Given the difficulty of deploying new applications discussed
-above, an important question is whether the tricks and kludges are
-bad enough, or will scale up to bad enough, that new solutions are
-needed and can be deployed.
-
-
-
-3. The search system story.
-
-3.1 Overview
-
-The constraints of the DNS argue for introducing an intermediate
-protocol mechanism, referred to here as a "search layer". The
-terms "directory" and "directory system" are used interchangably with
-"searchable system" in this document although the latter is far more
-precise. Search layer proposals would use a two (or more) -stage
-lookup, not unlike several of the proposals for internationalized
-names in the DNS (see section 4), but all operations but the final
-one would involving searching other systems, rather than looking up
-identifiers in the DNS itself. This would permit us to relax several
-constraints and produce a more comprehensive system.
-
-Ultimately, many of the issues with domain names arise as the result
-of people attempting to use the DNS as a directory. While there has
-not been enough pressure/demand to justify a change to date, it has
-already been quite clear that, as a directory system, the DNS is a
-good deal less than ideal. This document suggests that there
-actually is a requirement for a directory system, and that the right
-solution to a searchable system requirement is a searchable system,
-not a series of DNS patches, kludges, or workarounds.
-
-In particular...
-
-o A directory system would not require imposition of particular
-length limits on names.
-
-o A directory system could permit explicit association of attributes
-of, e.g., language and country, with a name, without having to
-utilize trick encodings to incorporate that information in DNS labels
-(or creating artificial hierarchy for doing so).
-
-o There is considerable experience (albeit not much of it very
-successful) in doing fuzzy and "sonex" (similar-sounding) matching in
-directory systems. Moreover, it is plausible to think about
-different matching rules for different areas and sets of names so
-that these can be adapted to local cultural requirements.
-Specifically, it might be possible to have a single form of a name in
-a directory, but to have great flexibility about what queries matched
-that name (and even have different variations in different areas).
-Of course, the more flexibility one provides, the greater the
-possibility of real or imagined trademark conflicts, but we would
-have the opportunity to design a directory structure that dealt with
-those issues in an intelligent way, while DNS constraints arguably
-make a general and equitable DNS-only solution impossible.
-
-o If a directory system is used to translate to DNS names, and then
-DNS names are looked up in the normal fashion, it may be possible to
-relax several of the constraints that have been traditional (and
-perhaps necessary) with the DNS. For example, reverse-mapping of
-addresses to directory names may not be a requirement, since the DNS
-name(s) would (continue to) uniquely identify the host.
-
-o Solutions to multilingual transcription problems that are common in
-"normal life" (e.g., two-sided business cards to be sure that a
-recipient trying to contact a person can access romanized spellings
-and numbers when the original language may not be comprehensible to
-that recipient) can be easily handled in a directory system by
-inserting both sets of entries.
-
-o One can easily imagine a directory system that would return, not a
-single name, but a set of names paired with network-locational
-information or other context-establishing attributes. This type of
-information might be of considerable use in resolving the "nearest
-(or best) server for a particular named resource" problems that are a
-significant concern for organizations hosting web and other sites
-that are accessed from a wide range of locations and subnets.
-
-o Names bound to countries and languages might help to manage
-trademark realities, while use of the DNS in trademark-significant
-areas tends to require worldwide "flattening" of the trademark
-system.
-
-3.2 Some details and comments.
-
-Almost any internationalization (i18n) proposal for names that are
-in, or map into, the DNS will require changing DNS resolver API calls
-("gethostbyname" or equivalent or adding some pre-resolution
-preparation mechanism) in almost all Internet applications -- whether
-to cause the API to take a different character set (no matter how it
-is then mapped into the bits used in the DNS or another system), to
-accept or return more arguments with qualifying or identifying
-information, or otherwise. Once applications must be opened to make
-such changes, it is a relatively small matter to switch from calling
-into the DNS to calling a directory service and then the DNS (in many
-situations, both actions could be accomplished in a single API call).
-
-A directory approach can be consistent both with "flat" models and
-multi-attribute ones. The DNS requires strict hierarchies, limiting
-its ability to handle differentiation among names by their
-properties. By contrast, modern directories can utilize
-independently-searched attributes and other structured schema to
-provide flexibilities not present in a strictly hierarchical system.
-
-There is a strong argument for a single directory structure (implying
-a need for mechanisms for registration, delegation, etc.). But it is
-not a strict requirement, especially if in-depth case analysis and
-design work leads to the conclusion that reverse-mapping to directory
-names is not a requirement (see section 4).
-
-Conversely, there is a case to be made for, e.g., faceted systems in
-which most of the facets use restricted vocabularies. Such systems
-could be designed to avoid the need for procedures to ensure
-uniqueness across, or even within, providers and databases of the
-faceted entities being searched for. (Cf. [DNS-Search] for further
-discussion.)
-
-While the discussion above includes very general comments about
-attributes, it appears that only a very small number of attributes
-would be needed. The list would almost certainly include country and
-language for IDN purposes and might require "charset" if we cannot
-agree on a character set and encoding. Trademark issues might
-motivate "commercial" and "non-commercial" (or other) attributes if
-they would be helpful in bypassing trademark problems. And
-applications to resource location might argue for a few other
-attributes (as outlined above).
-
-
-4. Examining internationalization
-
-Much of the thinking underlying this document has been driven by
-considerations of internationalizing the DNS or, more specifically,
-providing access to the functions of the DNS from languages and
-naming systems that cannot be accurately expressed in ASCII (or in
-the traditional DNS subset of ASCII). Much of this work has been
-done in the "IETF Internationalized Access to Domain Names" (IDN)
-Working Group. This section contains an evaluation of what that
-group has learned and how that learning might reasonably impact
-IETF's next steps. It assumes familiarity with the work and
-terminology of that working group.
-
-When the IDN effort started, several of us made the observation that
-the first important task for the WG was an undocumented one: to
-increase the understanding of the complexities of the problem
-sufficiently that naive solutions could be rejected and people could
-go to work on the harder problems. That has clearly been
-accomplished. With the exception of some continuing background noise,
-the simplistic approaches, with promises of one-year deployment, have
-just disappeared and almost no one thinks the issues are simple any
-more.
-
-But some of the lessons learned are quite painful and should give us
-pause, both generally and in the context of the remarks above:
-
-4.1. ASCII isn't just because of English
-
-The hostname rules chosen in the mid-70s weren't just "ASCII because
-English uses ASCII", although that was a starting point. We have
-discovered that almost every other script (and, I think, even ASCII if
-we permit the rest of the characters specified in to ISO 646
-International Reference Version) is more complex than hostname-
-restricted-ASCII. In some cases, with a broader selection of scripts,
-case mapping works from one case to the other, but is not reversible.
-In others, there are conventions about alternate ways to represent
-characters (in the language, not [just] in character coding) that work
-most of the time, but not always. And there are issues in coding,
-with Unicode/10646 [UNICODE, IS10646] providing different ways to
-represent the same character (I am using that word, rather than
-"glyph", deliberately here). And, in still others, there are
-questions as to whether two glphs "match", which may be a
-distance-function question, not one with a binary answer. We have
-tried to solve this set of problems with "nameprep" (see below).
-
-4.2. The "ASCII Encoding" approaches
-
-While the DNS can handle arbitrary binary strings without known
-internal problems (see [RFC2181]), some restrictions are imposed by
-the requirement that text be interpreted in a case-independent way
-([RFC1034], [RFC1035]). More important, most internet applications
-assume the hostname-restricted (so-called "LDH) syntax specified in
-the hosttable RFCs and as "prudent" in RFC 1035. Many conforming
-implementations of those applications may exhibit unpredicted behavior
-if those assumptions are not met. To avoid these potential problems,
-the work of the IDN WG has focused on "ASCII-Compatible Encodings"
-(ACE), which preserve the LDH conventions in the DNS itself (and for
-implementations of applications that have not been upgraded) while
-permitting newer implementations to recognize the special codings and
-map them into non-ASCII characters. These approaches are, however,
-not problem-free. Among other issues, they rely on what is ultimately
-a heuristic to determine whetehr a DNS lablel is to be considered as
-an IDN or interpreted as an actual LDH name in its own right. And,
-while all determination of whether a particular query matches a stored
-object are traditionally made by DNS servers, the ACE systems, when
-combined with the complexities of international scripts and names,
-require that much of the matching work be abstracted into a separate,
-client-side, "preparation" process.
-
-4.3. "Nameprep" and its complexities
-
-The model for getting around the various problems described above and
-elsewhere has evolved into a notion that all strings are to be placed
-into the DNS only after being passed through a string preparation
-function that eliminates or rejects spurious character codes, maps
-some characters onto others, performs some sequence canonicalization,
-and generally creates forms that can be accurately compared. The
-impact of this process on host-table-subset ASCII is trivial and
-essentially adds only overhead. For other scripts, the impact is, of
-necessity, quite significant.
-
-Defining that process was quite complex and, as of the time of this
-writing, remains controversial. Although the general notion
-was simple, the devil is often in the details, and there are many
-details. A design team worked on it for months, with considerable
-effort placed into clarifying and fine-tuning the protocol. Despite
-general agreement that the IETF would avoid getting into the business
-of defining character sets, character codings, and the associated
-conventions, the group several times took excursions into
-special treatment of code positions to more nearly match the
-distinctions of Unicode with user-perceptions about similarities and
-differences between characters. The IETF-specific code position work
-has been removed from the protocol draft, but the fact that the
-temptation has been strong may indicate problems we haven't solved to
-everyone's satisfaction.
-
-There have also been controversies about how far one should go in
-these processes of preparation and transformation and,
-ultimately, about the validity of various analogies. Is stripping of
-vowels in Arabic or Hebrew analogous to case-mapping? Matching of
-characters that appear to be the same but that are assigned to
-different code points? Mapping of Traditional and Simplified Chinese
-characters? Matching of Serbo-Croatian words whether written in
-Roman-derived or Cyrillic characters?
-
-At the same time, the nameprep work has been extremely useful, both
-in identifying many of the problem code points and issues and
-providing a reasonable set of rules. The problem is arguably not
-with nameprep, but with the DNS-imposed requirement that nameprep, as
-with all other parts of the matching and comparison process, yield a
-binary "match or no match" answer, rather than, e.g., a value on a
-similarity scale that can be evaluated by the user or by user-driven
-heuristic functions.
-
-
-4.4 The UCS Stability Problem
-
-ISO 10646 basically defines only code points, and not rules for using
-or comparing the characters. This is a long- standing issue with
-standards coming out of ISO/IEC JTC1/SC2; internationalization issues,
-as contrasted with character-listing and code point assignment issues,
-have just not been effectively dealt with in that group. The Unicode
-Technical Committee has defined some rules for canonicalization and
-comparision, many of which have been factored into the "nameprep"
-work, but it is not straightforward to make or define those rules in a
-sufficiently precise and permanent fashion that the DNS can depend on
-them. Perhaps more important, our nameprep efforts have identified
-several areas in which the UTC rules do not adequately define things
-to make matching precise and unambiguous. For example, it is tempting
-to define some rules on the basis of membership in particular scripts,
-or for punctuation characters, but there is not precise definition of
-what characters belong to which script or which ones are, or are not,
-punctuation. That raises two issues: whether trying to do precise
-matching at the character set level is actually possible (addressed
-below) and whether driving toward more precision could create issues
-that cause instability in the implementation and resolution models.
-
-In addition, JTC1 has recently assigned some (most?) of these issues
-to JTC1/SC22/WG20 (the Internationalization WG within the
-subcommittee that deals with programming languages, systems, and
-environments). WG20 is historically strong and deals with
-internationalization issues thoughtfully and in depth. Whether or
-not they get it right, assignment of these matters to WG20
-significantly increases the risk of an eventual ISO standard that
-specifies different behavior from the UTC specification.
-
-4.5. Audiences, end users, and the UI problem
-
-Part of what has "caused" the DNS i18n problem, as well as the DNS
-trademark problem and several others, is that we have stopped thinking
-about "identifiers for objects", which normal people are not expected
-to see, and started thinking about "names" -- strings that are
-expected not only to be readable, but to have linguistically-sensible
-and culturally-dependent meaning to non-specialist users.
-
-The IDN WG, and others, have attempted to avoid addressing the
-implications of that transition by taking "someone else's problem"
-approaches or by suggesting that we can adopt conventions to which
-people will just become accustomed. I suggest that neither will work
-acceptably:
-
-
- * If we want to make it a problem in a different part of the
- UI structure, we need to figure out where it goes in order
- to have proof of concept of our solution. Unlike those
- whose sole [business] model is the selling or registering of
- names, any solution IETF produces actually needs to work, in
- applications context, as seen by the end user.
-
- * The "they will get used to our conventions and adapt"
- principle is fine if we are writing rules for programming
- languages or an API. But the conventions we are talking
- about aren't part of a semi-mathematical system, they are
- deeply ingrained in culture. No matter how often we tell an
- English-speaking American that the Internet requires that the
- correct spelling of "colour" be used, he or she isn't going to be
- convinced. Getting a French-speaker in Lyon to use exactly
- the same lexical conventions as a French-speaker in Quebec
- in order to accomodate the decisions of the IETF or of a
- registrar or registry is just not likely. "Montreal" is
- either a misspelling or an anglicization (anglicisation?) of
- Montrëal (with an acute accent mark over the "e"), but we
- are as unlikely to get global agreement on a rule that will
- determine whether the two forms should match --and that
- won't astonish end users and speakers of one language or the
- other-- as we are to get agreement on whether "misspelling"
- or "anglicization" is the greater travesty.
-
-More generally, it is not clear that the outcome of any conceivable
-nameprep-like process is going to be good enough. In the use of
-human languages by humans, we have many cases in which things that do
-not match are nonetheless interpreted as matching. The
-Norwegian/Danish glyph "\97" (lower case 'o' with forward slash) and
-the German glyph "§" (lower case 'o' with umlaut) are clearly
-different and no matching program should yield an "equal" comparison.
-But they are more similar than either of them is to, e.g., "e", and
-humans are able to mentally make the correction in context and can be
-surprised if computers cannot do so.
-
-This text uses examples in Roman scripts because it is being written
-in English and those examples are relatively easy to render. But one
-of the important lessons of the IDN discussions of the recent years is
-that problems like this exist in almost every language and script.
-Each one has its idiosyncracies, and each set of idiosyncracies is
-tied to common usage and cultural issues that are deeply embedded. As
-long as a schoolchild in the US can get a bad grade on a spelling test
-for using a perfectly valid British spelling, or one in France or
-Germany can get a poor grade for leaving off a diacritical mark, or
-one in Egypt or Israel will find it acceptable to write a word with or
-without vowels or stress marks, but, if they are included, that they
-must be the correct ones, there are issues with the relevant language.
-We are dealing with culture, not identifier symbol-strings for geeks
-or computers, and the recent efforts have made it ever more clear
-that, if we ignore that distinction, we are solving an insufficient
-problem.
-
-
-4.6 Business cards and other natural uses of natural languages
-
-We have some established local conventions in the world for dealing
-with multilingual situations. Looking at them may be helpful. If
-one visits a country where the language is different from ones own,
-business cards are often printed on two sides, one side in each
-language. This is usually a high-tolerance situation: exact
-translations are often not possible, and people typically smile at
-errors, appreciate the effort, and move on. The DNS situation
-differs from this in at least two ways: since we need a global
-solution, the business card would need a number of sides
-approximating the number of languages in the world, which is probably
-impossible without violating laws of physics. And the opportunities
-for tolerance don't exist: the DNS requires a exact match or the
-lookup fails.
-
-4.7 ASCII encodings and the Roman keyboard assumption
-
-Part of the argument for ACE-based solutions is that they provide an
-escape for multilingual environments when applications have not been
-upgraded. When an older application encounters an ACE-based name,
-the assumption is that the (admittedly ugly) ASCII string will be
-displayed and can be typed in. This argument is reasonable from the
-standpoint of mixtures of Latin-based alphabets, but may not be
-relevant if user-level systems and devices are involved that do not
-support the entry of Roman-based characters or which cannot
-conveniently render such characters.
-
-4.8 A pessimistic summary of IDN WG directions
-
-It appears, from the cases above and others, that none of the
-intra-DNS-based solutions for "multilingual names" are workable. They
-just rest on too many assumptions that do not appear to be feasible --
-that people will adapt deeply-entrenched language habits to
-conventions laid down to make the lives of computers easy; that we can
-make "freeze it now, no need for changes in these areas" decisions
-about Unicode and nameprep; that ACE will smooth over applications
-problems, even in environments without the ability to key or render
-roman-based glyphs (or where user experience is such that they cannot
-easily be told apart); that the Unicode Consortium will never decide
-to repair an error in a way that creates a risk of DNS
-incompatibility; that we can either deploy EDNS or that long names
-aren't really important; that Chinese computer users (and others) will
-either give up their local or IS 2022-based character coding solutions
-(for which UTC adding large fractions of a million new code points is
-almost certainly a necessary, but probably not sufficient condition)
-or build leakproof boundary conversion mechanisms; that out of band or
-contextual information will always be sufficient for the "map glyph
-onto script" problem; and so on. In each case, we can get about 80%
-or 90%, but it is not clear that is going to be good enough. For
-example, suppose someone can spell her name 90% correctly: is that
-likely to be considered adequate?
-
-
-5. The Key Controversies
-
-5.1. One directory or many
-
-As suggested in some of the text above, it is an open question as to
-whether the needs of the community would be best served by a single
-directory with universal applicability, a single directory but
-locally-tailored search (and, most important, matching) functions, or
-multiple, locally-determined, directories. Each has its attractions.
-Any but the first would essentially prevent reverse-mapping
-(determination of the user-visible name of the host or resource from
-target information such as an address or DNS name). But reverse
-mapping has become less useful over the years --at least to users--
-as we have assigned more and more names per host address.
-
-Locally-tailored search and mappings would permit national variations
-on interpretation of which strings matched which other ones, an
-arrangement that is especially important when different localities
-apply different rules to, e.g., matching of characters with and
-without diacriticals. But, of course, this implies that a URL may
-evaluate properly or not depending on either settings on a client
-machine or the network connectivity of the user, which is not, in
-general, a desirable situation.
-
-And, of course, completely separate directories would permit
-translation and transliteration functions to be embedded in the
-directory, giving much of the Internet a different appearance
-depending on which directory was chosen. The attractions of this are
-obvious, but, unless things were very carefully designed to preserve
-uniqueness and precise identities at the right points (which may or
-may not be possible), such a system would have many of the
-difficulties associated with multiple roots.
-
-5.2 Why not a proposal?
-
-As this document has gone through various preliminary drafts and
-reviews, the question has been raised as to whether it should contain
-a specific proposal: a specific directory mechanism, schema, and so
-on. It deliberately does not take that step. It has been difficult
-to get directory systems deployed in significant ways in the Internet
-infrastructure, partially because we have a surplus of options.
-There are also some approaches that could be used to implement the
-general concepts described here, such as the Common Name Resolution
-Protocol [RFC2972], which some would not consider directory protocols
-at all. Consequently, it appeared better to present the general
-concepts and arguments here and leave the specifics to other sources,
-documents, and proposals.
-
-
-6. Security Considerations
-
-The set of proposals implied by this document suggests an interesting
-set of security issues (i.e., nothing important is ever easy). A
-directory system used for this purpose would presumably need to be as
-carefully protected against unauthorized changes as the DNS itself.
-There also might be new opportunities for problems in an arrangement
-involving two or more [sub]layers; but those problems are not more
-severe than a two-stage lookup in the DNS.
-
-
-7. References
-
-7.1. Normative References
-
-None
-
-7.2. Explanatory and Informative References
-
-[ASCII]
-
-[IS646]
-
-[IS10646]
-
-[UNICODE]
-
-[DNS-Search] draft-klensin-dns-search-02/03.txt, work in progress.
-
-[RFC625] RFC 625 On-line hostnames service. M.D. Kudlick, E.J.
-Feinler. Mar-07-1974.
-
-[RFC811] RFC 811 Hostnames Server. K. Harrenstien, V. White, E.J.
-Feinler. Mar-01-1982.
-
-[RFC952] RFC 952 DoD Internet host table specification. K.
-Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985.
-
-[RFC882] RFC 882 Domain names: Concepts and facilities. P.V.
-Mockapetris. Nov-01-1983.
-
-[RFC883] RFC 883 Domain names: Implementation specification. P.V.
-Mockapetris. Nov-01-1983.
-
-[RFC1035] RFC 1035 Domain names - implementation and specification.
-P.V. Mockapetris. Nov-01-1987.
-
-[RFC1591] RFC 1591 Domain Name System Structure and Delegation. J.
-Postel. March 1994.
-
-[RFC2181] RFC 2181 Clarifications to the DNS Specification. R. Elz, R.
-Bush. July 1997.
-
-[RFC2825] RFC 2825 A Tangled Web: Issues of I18N, Domain Names, and
-the Other Internet protocols. IAB, L. Daigle, ed.. May 2000.
-
-[RFC2826] RFC 2826 IAB Technical Comment on the Unique DNS Root. IAB.
-May 2000.
-
-[RFC2972] RFC 2972 Context and Goals for Common Name Resolution. N.
-Popp, M. Mealling, L. Masinter, K. Sollins. October 2000.
-
-[X29] International Telecommuncations Union, "Recommendation X.29:
-Procedures for the exchange of control information and user data
-between a Packet Assembly/Disassembly (PAD) facility and a packet mode
-DTE or another PAD", December 1997.
-
-
-8. Acknowledgements
-
-Many people have contributed to versions of this document or the
-thinking that went into it. The author would particularly like to
-thank Harald Alvestrand, Leslie Daigle, Patrik Faltstrom, Eric A.
-Hall, and Paul Hoffman for challenging the assumptions of earlier
-versions and suggesting ways to improve them.
-
-
-10. Culprit address
-
-John C Klensin
-1770 Massachusetts Ave, #322
-Cambridge, MA 02140
-klensin+srch@jck.com
-
-Expires July 2002
+++ /dev/null
-
-Internet Engineering Task Force E. Lewis
-Internet-Draft ARIN
-February 4, 2003 Expires: August 4, 2003
-
- Clarifying the Role of Wild Card Domains
- in the Domain Name System
- <draft-lewis-dns-wildcard-clarify-00.txt>
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- 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
-
-The definition of wild cards is recast from the original in RFC 1034,
-in words that are more specific and in line with RFC 2119. This document
-is meant to supplement the definition in RFC 1034 and to alter neither
-the spirit nor intent of that definition.
-
-1 Introduction
-
-The first section of this document will give a crisp overview of what
-is begin defined, as well as the motivation for what amounts to a
-simple rewording of an original document. An example is included to
-help orient the reader.
-
-Wild card domain names are defined in Section 4.3.3. of RFC 1034 as
-"instructions for synthesizing RRs." [RFC1034] The meaning of this is
-that a specific, special domain name is used to construct responses in
-instances in which the query name is not otherwise represented in a zone.
-
-A wild card domain name has a specific range of influence on query names
-(QNAMEs) within a given class, which is rooted at the domain name
-containing the wild card label, and is limited by explicit entries, zone
-cuts and empty non-terminal domains (see section 1.3 of this document).
-
-Note that a wild card domain name has no special impact on the search
-for a query type (QTYPE). If a domain name is found that matches the
-QNAME (exact or a wild card) but the QTYPE is not found at that point,
-the proper response is that there is no data available. The search
-does not continue on to seek other wild cards that might match the QTYPE.
-To illustrate, a wild card owning an MX RR does not 'cover' other names
-in the zone that own an A RR.
-
-Why is this document needed? Empirical evidence suggests that the
-words in RFC 1034 are not clear enough. There exist a number of
-implementations that have strayed from the definition. There also
-exists a misconception of operators that the wild card can be used to
-add a specific RR type to all names, such as the MX RR example listed
-above. This document is also needed as input to efforts to extend
-DNS, such as the DNS Security Extensions [RFC 2535]. Lack of a clear
-base specification has proven to result in extension documents that
-have unpredictable consequences. (This is true in general, not just
-for DNS.)
-
-1.1 Existence
-
-The notion that a domain name 'exists' will arise numerous times in this
-discussion. RFC 1034 raises the issue of existence in a number of places,
-usually in reference to non-existence and often in reference to processing
-involving wild card domain names. RFC 1034 does contain algorithms that
-describe how domain names impact the preparation of an answer and does
-define wild cards as a means of synthesizing answers.
-
-To help clarify the topic of wild cards, a positive definition of existence
-is needed. To complicate matters, though, there needs to be a recognition
-that existence is relative. To an authoritative server, a domain name
-exists if the domain name plays a role following the algorithms of
-preparing a response. To a resolver, a domain name exists if there is
-any data available corresponding to the name. The difference between the
-two is the synthesis of records according to a wild card.
-
-For the purposes of this document, the point of view of an authoritative
-server is adopted. A domain name is said to exist if it plays a role in
-the execution of the algorithms in RFC 1034.
-
-1.2 An Example
-
-For example, consider this wild card domain name: *.example. Any query
-name under example. is a candidate to be matched (answered) by this wild
-card. Although any name is a candidate, not all queries will match.
-
-To further illustrate this, consider this example:
-
- $ORIGIN example.
- @ IN SOA
- NS
- NS
- * TXT "this is a wild card"
- MX 10 mailhost.example.
- host1 A 10.0.0.1
- _ssh._tcp.host1 SRV
- _ssh._tcp.host2 SRV
- subdel NS
-
-The following queries would be synthesized from the wild card:
- QNAME=host3.example. QTYPE=MX, QCLASS=IN
- the answer will be a "host.example. IN MX ..."
- QNAME=host3.example. QTYPE=A, QCLASS=IN
- the answer will be a "host.example. IN NXT ..."
- because there is no A RR set at '*'
-
-The following queries would not be synthesized from the wild card:
- QNAME=host1.example., QTYPE=MX, QCLASS=IN
- because host1.example. exists
- QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
- because _tcp.host1.example. exists (without data)
- QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
- because host2.example. exists (without data)
- QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
- because subdel.example. exists and is a zone cut
-
-To the server, the following domains are considered to exist in the zone:
-*, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, _ssh._tcp.host2,
-and subdel. To a resolver, many more domains appear to exist via the
-synthesis of the wild card.
-
-1.3 Empty Non-terminals
-
-Empty non-terminals are domain names that have no data but have
-subdomains. This is defined 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. According to the definition of existence in
-this document, empty non-terminals do exist at the server.
-
-Carefully 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 [RFC 1035]. 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
-down. As RFC 1034 also defines "an authoritative name error indicating
-that the name does not exist" in section 4.3.1, this is not the intent
-of the original document.
-
-RFC1034's wording is to be clarified by adding the following paragraph:
-
- A node is considered to have an impact on the algorithms of 4.3.2
- if it is a leaf node with any resource sets or an interior node,
- with or without a resource set, that has a subdomain that is a leaf
- node with a resource set. A QNAME and QCLASS matching an existing
- node never results in a response return code of authoritative name
- error.
-
-As an aside, an "authoritative name error" has been called NXDOMAIN in
-some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned
-to such an error by at least one implementation of DNS.
-
-1.3 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 the document entitled
-"Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]
-
-Requirements are denoted by paragraphs that begin with with the following
-convention: 'R'<sect>.<count>.
-
-2 Defining the Wild Card Domain Name
-
-A wild card domain name is defined by having the initial label be:
-
- 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
-This defines domain names that may play a role in being a wild card, that
-is, being a source for synthesized answers. Domain names conforming to
-this definition that appear in queries and RDATA sections do not have
-any special role. These cases will be described in more detail in
-following sections.
-
-R2.1 A domain name that is to be interpreted as a wild card MUST begin
- with a label of '0000 0001 0010 1010' in binary.
-
-The first octet is the normal label type and length for a 1 octet long
-label, the second octet is the ASCII representation [RFC 20] for the
-'*' character. In RFC 1034, ASCII encoding is assumed to be the character
-encoding.
-
-In the master file formats used in RFCs, a "*" is a legal representation
-for the wild card label. Even if the "*" is escaped, it is still
-interpreted as the wild card when it is the only character in the label.
-
-R2.2. A server MUST treat a wild card domain name as the basis of
- synthesized answers regardless of any "escape" sequences in
- the input format.
-
-RFC 1034 and RFC 1035 ignore the case in which a domain name might be
-"the*.example.com." The interpretation is that this domain name in a
-zone would only match queries for "the*.example.com" and not have any
-other role.
-
-Note: By virtue of this definition, a wild card domain name may have a
-subdomain. The subdomain (or sub-subdomain) itself may also be a wild
-card. E.g., *.*.example. is a wild card, so is *.sub.*.example.
-More discussion on this is given in Appendix A.
-
-3 Defining Existence
-
-As described in the Introduction, a precise definition of existence is
-needed.
-
-R3.1 An authoritative server MUST treat a domain name as existing during
- the execution of the algorithms in RFC 1034 when the domain name
- conforms to the following definition. A domain name is defined
- to exist if the domain name owns data and/or has a subdomain that
- exists.
-
-Note that at a zone boundary, the domain name owns data, including the
-NS RR set. At the delegating server, the NS RR set is not authoritative,
-but that is of no consequence here. The domain name owns data, therefore,
-it exists.
-
-R3.2 An authoritative server MUST treat a domain name that has neither
- a resource record set nor a subdomain as nonexistent when executing
- the algorithm in section 4.3.2. of RFC 1034.
-
-4 Impact of a Wild Card Domain In a Query Message
-
-When a wild card domain name appears in a question, e.g., the query name
-is "*.example.", the response in no way differs from any other query.
-In other words, the wild card label in a QNAME has no special meaning,
-and query processing will proceed using '*' as a literal query name.
-
-R4.1 A wild card domain name acting as a QNAME MUST be treated as any
- other QNAME, there MUST be no special processing accorded it.
-
-If a wild card domain name appears in the RDATA of a CNAME RR or any
-other RR that has a domain name in it, the same rule applies. In the
-instance of a CNAME RR, the wild card domain name is used in the same
-manner of as being the original QNAME. For other RR's, rules vary
-regarding what is done with the domain name(s) appearing in them,
-in no case does the wild card hold special meaning.
-
-R4.2 A wild card domain name appearing in any RR's RDATA MUST be treated
- as any other domain name in that situation, there MUST be no special
- processing accorded it.
-
-5 Impact of a Wild Card Domain On a Response
-
-The description of how wild cards impact response generation is in RFC
-1034, 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 wild card. The algorithm is directly
-quoted in lines that begin with a '#' sign. Commentary is interleaved.
-
-[Note that are no requirements specifically listed in this section. The
-text here is explanatory and interpretative. There is no change to
-the algorithm specified in RFC 1034.]
-
-The context of part 'c' is that the search is progressing label by label
-through the QNAME. (Note that the data being searched is the authoritative
-data in the server, the cache is searched in step 4.) Step 3's part 'a'
-covers the case that the QNAME has been matched in full, regardless of the
-presence of a CNAME RR. Step 'b' covers crossing a cut point, resulting
-in a referral. All that is left is to look for the wild card.
-
-Step 3 of the algorithm also assumes that the search is looking in the
-zone closest to the answer, i.e., in the same class as QCLASS and as
-close to the authority as possible on this server. If the zone is not
-the authority, then a referral is given, possibly one indicating lameness.
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if a
-# the "*" label exists.
-
-The above paragraph refers to finding the domain name that exists in the
-zone and that most encloses the QNAME. Such a domain name will mark the
-boundary of candidate wild card domain names that might be used to
-synthesize an answer. (Remember that at this point, if the most enclosing
-name is the same as the QNAME, part 'a' would have recorded an exact
-match.) The existence of the enclosing name means that no wild card name
-higher in the tree is a candidate to answer the query.
-
-Once the closest enclosing node is identified, there's the matter of what
-exists below it. It may have subdomains, but none will be closer to the
-QNAME. One of the subdomains just might be a wild card. If it exists,
-this is the only wild card eligible to be used to synthesize an answer
-for the query. Even if the closest enclosing node conforms to the syntax
-rule in section 2 for being a wild card domain name, the closest enclosing
-node is not eligible to be a source of a synthesized answer.
-
-The only wild card domain name that is a candidate to synthesize an answer
-will be the "*" subdomain of the closest enclosing domain name. Three
-possibilities can happen. The "*" subdomain does not exist, the "*"
-subdomain does but does not have an RR set of the same type as the QTYPE,
-or it exists and has the desired RR set.
-
-For the sake of brevity, the closest enclosing node can be referred to as
-the "closest encloser."
-
-To illustrate, using the example in section 1.2 of this document, the
-following chart shows QNAMEs and the closest enclosers. In Appendix A
-there is another chart showing unusual cases.
-
- QNAME Closest Encloser Wild Card Source
- host3.example. example. *.example.
- _telnet._tcp.host1.example. _tcp.host1.example. no wild card
- _telnet._tcp.host2.example. host2.example. no wild card
- _telnet._tcp.host3.example. example. *.example.
- _chat._udp.host3.example. example. *.example.
-
-Note that host1.subdel.example. is in a subzone, so the search for it ends
-in a referral in part 'b', thus does not enter into finding a closest
-encloser.
-
-The fact that a closest encloser will be the only superdomain that
-can have a candidate wild card will have an impact when it comes to
-designing authenticated denial of existence proofs. (This concept
-is not introduced until DNS Security Extensions are considered in
-upcoming sections.)
-
-# 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.
-
-The above passage says that if there is not even a wild card domain name
-to match at this point (failing to find an explicit answer elsewhere),
-we are to return an authoritative name error at this point. If we were
-following a CNAME, the specification is unclear, but seems to imply that
-a no error return code is appropriate, with just the CNAME RR (or sequence
-of CNAME RRs) in the answer section.
-
-# 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.
-
-This final paragraph covers the role of the QTYPE in the process. Note
-that if no resource record set matches the QTYPE the result is that no data
-is copied, but the search still ceases ("Go to step 6.").
-
-6 Authenticated Denial and Wild Cards
-
-In unsecured DNS, the only concern when there is no data to return to
-a query is whether the domain name from which the answer comes exists or
-not, whether or not a name error is indicated in the return code. In
-either case the answer section is empty or contained just a sequence of
-CNAME RR sets.
-
-In securing DNS, authenticated denial of existence is a service that is
-provided. The chosen solution to provide this service is to generate
-resource records indicating what is protected in a zone and to digitally
-sign these.
-
-The resource records that do this, as defined in RFC 2535, are NXT RRs.
-
-There are three points to consider when clarifying the topic of wild card
-domain names. One is the construction of the records. The second is
-the inclusion of records in responses. The third is the interpretation
-of the records in a response by the resolver.
-
-6.1 Preparing Wild Card Domain Name Owned Non-existence Proofs
-
-During the creation of the authenticated denial records, the wild card
-domain name plays no special role, in the same manner as the wild card
-domain name playing no special role in a query.
-
-There is one consideration with regards to preparing non-existence
-proofs.
-
-R6.1 Any mechanism used to provide authenticated denial MUST reveal the
- closest enclosing existing domain for the query. If this is not
- provided, the resolver will not be able to ascertain the identity
- of an appropriate wild card domain name.
-
-6.2 Role of Wild Cards in Answers
-
-There are three cases to address. The first is synthesizing from wild card
-domain name with data, the second is negatively synthesizing from an
-existing wild card, and the third is denying that neither an exact match,
-referral, nor wild card exist to answer the query.
-
-6.2.1 Synthesizing From a Wild Card
-
-When preparing an answer from a wild card domain name, the answer needs
-to include proof that the exact match of the QNAME and QCLASS does not
-exist. This is needed because synthesis of the answer replaces the "*"
-label with the QNAME without securing the result. The resolver will
-realize that the answer was derived from a wild card, but cannot
-detect whether an exact match was maliciously omitted.
-
-R6.2 When synthesizing a positive answer from a wild card domain name, the
- answer MUST include proof that the exact match for the QNAME and
- QCLASS does not exist.
-
-6.2.2. Synthesizing Negatively From a Wild Card
-
-When synthesizing a negative answer that is derived from a wild card,
-meaning that a wild card matched the QNAME (no exact match happened for
-QNAME) but that there is no match for QTYPE there, two negative answers
-are needed, possibly one. As in 6.2.1, a proof that the exact match
-failed is needed. A second proof is needed to show that the wild card
-domain name does not have the QTYPE. Depending on the method of
-authenticated denial, these this could be possible with one statement.
-
-R6.3 When synthesizing a negative answer from a wild card domain name,
- the answer MUST include proof that the exact match of the QNAME
- and QCLASS does not exist and that the QTYPE matches no RR set at
- the wild card. If this answer can be optimized, an implementation
- SHOULD reduce the number of records included in the response.
-
-6.2.3. Answering With an Authoritative Name Error
-
-When answering with a result code of a name error, the answer needs to
-provide proof that neither the exact match for QNAME and QCLASS exists
-nor that a wild card domain name exists as a subdomain of the closest
-enclosing domain name.
-
-R6.4 When preparing a reply with an authoritative name error, the answer
- MUST include proof that the exact match for the QNAME and QCLASS
- does not exist and that no wild card is available to provide a match.
-
-6.2.4. The Remaining Case
-
-When answering negatively because there is a match for QNAME and QCLASS
-but no match for the QTYPE, only a proof for that is needed. Just as
-the search does not proceed onto a search for the wild card in this
-case, neither does the construction of the negative answer proof.
-
-R6.5 When preparing a reply in which there is an exact match of the
- QNAME and QCLASS, but there is no RR set matching the QTYPE,
- the reply SHOULD NOT contain any proof regarding the wild card
- domain name.
-
-6.3 Interpreting Negative Answers Involving Wild Cards
-
-There are two requirements for resolvers when it comes to handling
-negative answers generated as described in section 6.2.
-
-R6.6 A resolver MUST be able to identify negative answer data that
- indicate when a match for QNAME and QCLASS does not exist.
-
-R6.7 From a negative answer, a resolver MUST be able to determine
- the closest enclosing domain name in a negative answer and
- MUST be able to process a negative answer involving the one
- wild card domain name that is a candidate to provide a
- synthesized answer.
-
-6.4 Authenticated Denial, Wild Card Domain Names, and Opt-In
-
-When considering the Opt-In proposal [WIP], it is wise to not combine
-a zone that adheres to both opt-in and that has a wild card domain
-name. The reason is rooted in that the synthesis of an answer is done
-by substituting the QNAME for the wild card domain name in the answer.
-Because this is unsecured, and the is ambiguity regarding whether a
-negative proof can be provided for the exact match (when it is outside
-the opt-in secured area), a definitive proof of authenticated denial
-is not possible.
-
-7 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 system, security
-of the system, and extending the system more predictable.
-
-8 References
-
-Normative References
-
-[RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
-[RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
- Nov-01-1987
-[RFC 1035] Domain Names - Implementation and Specification, P.V
- Mockapetris, Nov-01-1987
-[RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
- Bradner, March 1997
-
-Non-normative References
-
-[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie,
- Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
-[RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
-[WIP] DNSSEC Opt-In, Internet Draft, R. Arends, M. Kosters, D. Blacka, 2002
-
-9 Other Contributing to This Document
-
-Others who have directly caused text to appear in the document: Paul Vixie
-and Olaf Kolkman. Many others have indirect influences on the content.
-
-10 Editor
-
-Name: Edward Lewis
-Title: Research Engineer
-Affiliation: ARIN
-Email: edlewis@arin.net
-Phone: +1-703-227-9854
-
-Appendix A: Subdomains of Wild Card Domain Names
-
-In reading the definition of section 2 carefully, it is possible to
-rationalize unusual names as legal. In the example given, *.example.
-could have subdomains of *.sub.*.example. and even the more direct
-*.*.example. (The implication here is that these domain names own
-explicit resource records sets.) Although defining these names is not
-easy to justify, it is important that implementations account for the
-possibility. This section will give some further guidance on handling
-these names.
-
-The first thing to realize is that by all definitions, subdomains of
-wild card domain names are legal. In analyzing them, one realizes
-that they cause no harm by their existence. Because of this, they are
-allowed to exist, i.e., there are no special case rules made to disallow
-them. The reason for not preventing these names is that the prevention
-would just introduce more code paths to put into implementations.
-
-The concept of "closest enclosing" existing names is important to keep in
-mind. It is also important to realize that a wild card domain name can
-be a closest encloser of a query name. For example, if *.*.example. is
-defined in a zone, and the query name is a.*.example., then the closest
-enclosing domain name is *.example. Keep in mind that the closest
-encloser is not eligible to be a source of synthesized answers, just the
-subdomain of it that has the first label "*".
-
-To illustrate this, the following chart shows some matches. Assume that
-the names *.example., *.*.example., and *.sub.*.example. are defined
-in the zone.
-
- QNAME Closest Encloser Wild Card Source
- a.example. example. *.example.
- b.a.example. example. *.example.
- a.*.example. *.example. *.*.example.
- b.a.*.example. *.example. *.*.example.
- b.a.*.*.example. *.*.example. no wild card
- a.sub.*.example. sub.*.example. *.sub.*.example.
- b.a.sub.*.example. sub.*.example. *.sub.*.example.
- a.*.sub.*.example. *.sub.*.example. no wild card
- *.a.example. example. *.example.
- a.sub.b.example. example. *.example.
-
-Recall that the closest encloser itself cannot be the wild card. Therefore
-the match for b.a.*.*.example. has no applicable wild card.
-
-Finally, if a query name is sub.*.example., any answer available will come
-from an exact name match for sub.*.example. No wild card synthesis is
-performed in this case.
-
-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.
-
---
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-Edward Lewis +1-703-227-9854
-ARIN Research Engineer
-
+++ /dev/null
-Internet Engineering Task Force Ed Lewis
-Internet-Draft NAI Labs
-July 9, 2001 Expires: January 9, 2002
-
- DNS KEY Resource Record Generic Protocol Value
- <draft-lewis-dnsext-key-genprot-00.txt>
-
-Status of this Memo
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other
-groups may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference
-material or to cite them other than as "work in progress."
-
-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 draft expires on January 9, 2002.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (2001). All rights reserved.
-
-Abstract
-
-A new protocol value is defined for the KEY Resource Record which
-identifies the intended protocol as that identified in the SRV-like
-encoding of the KEY RR's owner name.
-
-1.0 Introduction
-
-Starting with discussions concerning the mixing of zone keys and
-application keys at a zone apex, with the implication that the signing
-of the apex set makes the parent responsible for signing data
-inherently specific to the child zone, various proposals have been
-made to eliminate that issue. One such proposal is to separate keys
-by using the owner name, a la the SRV record. E.g., for a host named
-"host.myzone.test." a key used for SSH might be found at
-"_ssh._tcp.host.myzone.test." [RFC 2782]
-
-Other motivations for this proposal and approach to naming key is to
-address issues including: concerns over size of the apex key set and
-the extensive use of sub-typing KEY records. Since it is desirable
-to send the apex key set as additional data, it would be good to
-limit its size (by not having to include non-zone keys). Subtyping
-refers to making a resolver filter a returned RR set to extract
-the subset of records that meets the query's intent.
-
-This draft is not intended to document the SRV naming proposal, nor
-are any of the examples represented here suggestions for naming
-conventions. The intent of the draft is to define a catch-all protocol
-value which informs a resolver that the intended protocol for this key
-is encoded in the ownership name.
-
-If this (or a) generic protocol proposal is not adopted, yet a naming
-convention is used, the impact is that for each new protocol a new
-IANA-defined value is needed for the protocol octet in addition to a
-new specific naming convention. This proposal is just a means to ease
-the burden on IANA.
-
-2.0 KEY RR Protocol Value
-
-The unsigned integer value of <foobar> is reserved to mean that the
-owner name indicates the intended protocol of the KEY RR.
-
-3.0 Acknowledgements
-
-This proposal has been made in conversation with Jakob Schylter and
-Ilja Hallberg at a DNS meeting in Malmo Sweden.
-
-4.0 IANA Considerations
-
-A protocol number assignment for the DNS Key Resource Record is
-requested. The specific value is not considered important.
-
-A suggestion to IANA is made regarding the KEY RR protocol values.
-One suggested assignment algorithm (perhaps this needs a different
-draft) is to assign the protocol number according to the reserved port
-number. This may help in uniqueness.
-
-5.0 Security Considerations
-
-This draft introduces no new security issues.
-
-6.0 References
-
-The text of any RFC may be retrieved by a web browser by requesting
-the URL: ftp://ftp.isi.edu/in-notes/rfc<wxyz>.txt, where "wxyz" is the
-number of the RFC.
-
-[RFC 2026] "The Internet Standards Process -- Revision 3", Bradner
-[RFC 2535] "Domain Name System Security Extensions", Eastlake
-[RFC 2782] "A DNS RR for specifying the location of services (DNS SRV)",
- Gulbrandsen, Vixie, Esibov
-
-7.0 Editor's Address
-
-Edward Lewis
-<lewis@tislabs.com>
-3060 Washington Rd (Rte 97)
-Glenwood, MD 21738
-+1(443)259-2352
-
-8.0 Full Copyright Statement
-
-Copyright (C) The Internet Society 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 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.
-
-
+++ /dev/null
-Network Working Group B. Woodcock
-Request for Comments: nnnn Zocalo
-Category: Experimental B. Manning
- ISI
- August 2000
-
-
- Multicast Discovery of DNS Services
- draft-manning-multicast-dns-02.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance
- with all provisions of Section 10 of RFC2026 except that the right
- to produce derivative works is not granted. Internet-Drafts are
- working documents of the Internet Engineering Task Force (IETF),
- its areas, and its working groups. Note that other groups may also
- distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-
- Drafts as reference material or to cite them other than as
- "work in progress."
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
- This memo defines an Experimental Protocol for the Internet
- community. This memo does not specify an Internet standard of any
- kind. Discussion and suggestions for improvement are requested.
- Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-1. Introduction
-
- This document describes a minimal extension to the method of a DNS
- query which allows unconfigured hosts to locate a local DNS server,
- or in the absence of a DNS server to nonetheless identify some
- local network services.
-
-2. Acknowledgments
-
- Vital contributions to this document were made by Paul Vixie, Dave
- Meyer, Stuart Cheshire, Richard Ford, Tony McGregor, Erik Guttman,
- Benard Aboba, and Peter Ford. Thanks also to Alex Hoppman for
- discussion of text-encoding methods.
-
-3. Overview and rationale
-
- This experimental extension to DNS is intended to provide a bootstrap
- mechanism whereby unconfigured devices may find a local DNS server
- and begin using it to perform the usual name resolution and service
- lookup functions. This need is particularly acute in the absence of
- a DHCP server.
-
- Secondarily, it is anticipated that device vendors may implement the
- server (query-receiving) portion of this extension, in order to
- render unconfigured devices which may lack an out-of-band
- configuration interface such as a screen or keyboard discoverable on
- the local network. For example, if a newly-purchased laser printer
- or router were connected to a network, this extension would allow a
- system administrator to use the DNS to discover the IP address which
- the device had selected or been DHCP-assigned, and begin
- communicating with it through the network.
-
- A tertiary objective of this extension is to make possible the
- deprecation of the AppleTalk protocol, which has been prolonged as a
- means of providing support for "network browsing."
-
-4. Discussion
-
- This extension to the DNS protocol consists of a single change to the
- method of use, and no change whatsoever to the current format of DNS
- packets. Specifically, this extension allows UDP DNS queries, as
- documented in RFC 1035, sections 4.1.1, 4.1.2 and 4.2.1, to be
- addressed to port 53 of statically-assigned relative offset -2 within
- the range of multicast addresses defined as "administratively scoped"
- by RFC 2365, section 9. Within the full /8 of administratively
- scoped addresses, this corresponds to the destination address
- 239.255.255.253. Until MZAP or a similar protocol is implemented to
- allow hosts to discover the extent of the local multicast scopes
- which enclose them, it is anticipated that implementations will
- simply utilize the destination address 239.255.255.253.
-
- In order to receive multicasted queries, DNS server implementations
- MUST listen on the -2 offset to their local scope (as above, in the
- absence of a method of determining the scope, this will be assumed to
- be relative to the full /8 allocated for administratively-scoped
- multicast use, or 239.255.255.253), and respond via ordinary unicast
- UDP to ONLY those queries for which they have or can find a positive
- non-null answer. Multicast-enabled DNS servers MUST answer
- multicasted queries non-authoritatively. That is, when responding to
- a query which was received via multicast, they MAY NOT include an NS
- record which contains data which resolves back to their own IP
- address.
-
- Resolvers SHOULD be liberal in their acceptance of wildcard queries.
- That is, resolvers should anticipate receiving queries which will
- contain the asterisk character in any position within the query's
- data field. For example, a query for SRV RRs with data
- "afp.tcp.*.domain.com." would match "afp.tcp.server.domain.com." but
- not match "afp.tcp.". A query for "afp.tcp.*" would match both,
- since the asterisk should be interpreted as matching zero or more
- characters within the RR data.
-
- Resolvers MUST anticipate receiving no replies to some multicasted
- queries, in the event that no multicast-enabled DNS server
- implementations are active within the local scope, or in the event
- that no positive non-null responses exist to the transmitted query.
- That is, a query for the MX record for host.domain.com would go
- unanswered if no local server was able to resolve that request, if no
- MX record exists for host.domain.com, or if no local servers were
- capable of receiving multicast queries. The resolver which initiated
- the query MUST treat such non-response as a non-cacheable negative
- response. Since this multicast transmission does not provide
- reliable delivery, resolvers MAY repeat the transmission of a query
- in order to assure themselves that is has been reveived by any hosts
- capable of answering, however any resolvers which repeat a query MUST
- increase the interval between such repetitions exponentially over
- time.
-
- Resolvers MUST also anticipate receiving multiple replies to the same
- multicasted query, in the event that several multicast-enabled DNS
- servers receive the query and respond with valid answers. When this
- occurs, the responses MAY first be concatenated, and then treated in
- the same manner that multiple RRs received from the same server
- would, ordinarily.
-
-
-5. Implementation Notes Appendix
-
- It is anticipated that a major use of this extension to DNS will be
- for the replacement of the AppleTalk Name Binding Protocol (NBP)
- "distributed database," and the implementation of a similar service
- within other operating systems and on other platforms. Such use
- implies the existence of "stub DNS servers" on each participating
- host, each containing only local information in its served zones, but
- not to the exclusion of data which other servers may assert within
- the same zones.
-
- The following rather complex example shows the format by which an
- implementor could assert the local information possessed by any
- Macintosh in zones served by a stub DNS server on that host:
-
- $ORIGIN .
- @ SOA . . 1998082701 0 0 0 0
- 0 IN NS dns.udp.
- Jasons-Mac 0 IN A 169.254.101.218
- 0 IN HINFO Macintosh-G3-400 MacOS-8.6
- 0 IN LOC 37 52 N 122 20 W
- 0 IN RP . owner-name.Jasons-Mac.
- Jasons-Hard-Disk 0 IN A 169.254.101.218
- 0 IN TXT "UTF8-encoded service-name"
- Print-Spooler 0 IN A 169.254.101.218
- 0 IN TXT "UTF8-encoded service-name"
- dns.udp 0 IN SRV 0 0 53 Jasons-Mac.
- afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk.
- lpr.tcp 0 IN SRV 0 0 515 Print-Spooler.
- http.tcp 0 IN SRV 0 0 80 www.jasonco.com.
- https.tcp 0 IN SRV 0 0 443 secure.jasonco.com.
-
- $ORIGIN jasonco.com.
- www 0 IN A 169.254.101.218
- 0 IN TXT "UTF8-encoded service-name"
- secure 0 IN A 169.254.101.218
- 0 IN TXT "UTF8-encoded service-name"
-
- $ORIGIN Jasons-Mac.
- dns.udp 0 IN SRV 0 0 53 Jasons-Mac.
- owner-name 0 IN TXT "Jason A. Luser"
- * 0 IN PTR afp.tcp.Jasons-Mac.
- 0 IN PTR lpr.tcp.Jasons-Mac.
- 0 IN PTR http.tcp.Jasons-Mac.
- afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk.
- lpr.tcp 0 IN SRV 0 0 515 Print-Spooler.
- http.tcp 0 IN SRV 0 0 80 www.jasonco.com.
-
- $ORIGIN 101.254.169.in-addr.arpa.
- 218 0 IN PTR Jasons-Mac.
-
- Windows and Unix hosts are possessed of many of the same, or
- analogous, types of local information, and similar examples could be
- constructed around hypothetical hosts of those types. A much
- simpler example featuring a laser printer follows, in section 6 of
- this document.
-
- Note that in translating service and device names from high-bit-depth
- character sets such as Unicode to DNS-compliant hostnames, a
- character-mapping must occur, whereby spaces are mapped to hyphens,
- punctuation other than periods is removed, and plain characters are
- substituted for their accented equivalents. Implementors MUST perform
- a uniqueness check, in order to guarantee that no other device within
- the local multicast scope has already asserted a claim to the DNS
- name which their device wishes to employ. Uniqueness checks at
- service-registration time must be somewhat more strict than their
- historical AppleTalk equivalents, comparing names which have already
- been converted to their DNS-compliant state (containing only a-z,
- A-Z, 0-9, and the hyphen character, and starting with a letter rather
- than a hyphen or number), and must treat upper and lower-case as
- equivalent. Note that periods in device and service names shall be
- preserved and used to establish subdomains within the stub DNS
- server's dataset. The high-bit-depth names are made available to
- queriants in the form of UTF8-encoded RDATA in TXT RRs included as
- Additional Information (as described in RFC 1035, sections 4.1
- through 4.1.3) appended to any A RR response.
-
- Implementors of multicast-enabled resolvers may expect the following
- results of the following query-types:
-
- Data Type Result
-
- *.in-addr.arpa PTR All hostnames in the local scope
- *.host.domain.com SRV All services on host.domain.com
- lpr.tcp. SRV All printers/spoolers in the local scope
-
- Duplicate identical records received in different responses to a
- query may be treated as a single record in the concatenation of
- responses. It is beyond the scope of this document to suggest
- disposition of different responses which contain disagreeing pairs of
- name NAME and RDATA.
-
- Implementors should note that "virtual hosts" (that is, the support
- of multiple IP addresses on a single host, and the binding of
- different services to different addresses) are easily supported in
- responses to multicast queries, but should also note that one of the
- benefits afforded by the use of SRV RR-types is a reduction in the
- need for virtual hosts, since multiple named services may be bound to
- different (non-well-known) ports of the same IP address, and still be
- individually identified and differentiated. For example, a single
- host might support one HTTP server on port 80, a second on port 8001,
- and an HTTPS server on port 443, and each could be reached via
- different name.
-
- Another major use of this extension to DNS is to allow bootstrapping
- machines to find local DNS servers. It is anticipated that larger
- enterprises may in the future possess one or more fully-featured DNS
- servers which are also multicast-enabled. Once a bootstrapping host
- has located such a server, that host need no longer use multicast at
- all. That host may instead employ ordinary unicast DNS exactly as
- any other host would, to query those DNS servers. The servers, in
- turn, might well employ multicast queries to glean information about
- the services contained within their local scope, which information
- they might then use to respond to unicast queries (proxying, in
- effect), and cache against future need. Note also that the ability
- to answer multicast queries would prove particularly useful to a DNS
- server which was resident on the same host as a NAT at the border of
- an enterprise which employed 10.0.0.0/8 or 169.254.0.0/16 unicast
- addresses internally.
-
- Implementors MAY choose to employ an optimization whereby the
- deleterious impact of large numbers of unconfigured hosts
- simultaneously attempting to locate DNS servers during the bootstrap
- process might be mitigated, and the process be made more efficient.
- Specifically, high- and low-water marks are defined for frequency of
- multicasted lookups for SRV RRs of "dns.udp.". When a
- multicast-enabled DNS server observes the frequency of such lookups
- exceeding a high-water mark (five queries per minute, perhaps), the
- server MAY begin interspersing responses transmitted via multicast,
- rather than unicast, until such time as the frequency of such lookups
- falls below a low-water mark (one query per five minutes, perhaps).
- In order for this to work, multicast-enabled resolvers would also
- need to listen on the multicast address for responses, and cache them
- briefly. Both the server and resolver portions of this optimized
- behavior are optional, and it should be stressed that this
- optimization need not be considered by implementors of stub servers
- in devices such as printers, which do not provide generalized DNS
- services. If DNS server implementors choose to employ multicast
- responses, they MUST interleave multicast responses with unicast
- responses in such a way that the multicast responses decrease over
- time, rather than flooding the network, in order that servers not be
- used to propagate denial-of-service attacks. In other words, a
- reasonable approach might be while above the high-water mark to make
- the first, second, fourth, eighth, sixteenth et cetera responses for
- each RR multicast, while all inbetween would be unicast. Note that
- this not only protects against multicast "storms," it also protects
- against the mis-match condition which occurs in the case that a
- non-optimized resolver is the presence only of optimized servers, all
- of which are temporarily in multicast-response mode.
-
- Implementors SHOULD also employ DNS Sec, or its equivalent, as soon
- as such technology is standardized, in order to minimize the
- possiblity of "spoofing" of information by nodes responding to
- multicast queries.
-
-
-6. Use & Administration Notes Appendix
-
- Administrators of networks employing this protocol are advised to
- employ fully-qualified domain names (FQDNs) as their host names where
- possible, such that the dots separating portions of the name shall be
- interpreted by the stub-server implementations as subdomain
- delimiters, and shall thus serve to remove the host from the local
- view of the root domain to its correct and appropriate
- globally-unique subdomain.
-
- Administrators of service-providing devices, such as already-deployed
- printers, which are not capable of receiving multicast DNS queries,
- may wish to inject DNS records into a local multicast-enabled DNS
- server on behalf of those devices. For example, an administrator
- might wish to create records of the following nature in order to make
- a non-multicast-capable laser printer visible to both multicast and
- unicast queriants:
-
- $ORIGIN .
- lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com.
-
- $ORIGIN sales.domain.com.
- laser2 0 IN A 169.254.5.28
- 0 IN TXT "Old Sales Dep't Laser Printer"
-
- $ORIGIN laser2.sales.domain.com.
- * 0 IN PTR lpr.tcp.laser2.sales.domain.com.
- lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com.
-
- $ORIGIN 5.254.169.in-addr.arpa.
- 28 0 IN PTR laser2.sales.domain.com.
-
- Administrators of networks which contain either multicast-capable
- resolvers or multicast-capable DNS servers MUST employ filters
- defining a contiguous border around their enterprises and prohibiting
- passage of data to and from the 239.0.0.0/8 address space, as well as
- routing information relating to the 239.0.0.0/8 prefix or any subnet
- of it. This is the mechanism by which RFC 2365 administrative
- scoping is enacted. The sole exception to this rule would be any
- explicitly-configured interconnections with other specific
- enterprises between which all involved administrators wish to share a
- single browsable network space. This is anticipated to be a very
- infrequent occurrence within the current regime of network security
- policies.
-
-References
-
- RFC 1035: Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November, 1987.
-
- RFC 2052: Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the
- location of services (DNS SRV)", RFC 2052, October, 1996.
-
- RFC 2365: Meyer, D., "Administratively Scoped IP Multicast",
- RFC 2365, July, 1998.
-
- Handley, M., Thaler, D., "Multicast-Scope Zone Announcement
- Protocol (MZAP)", MBoneD Internet Draft, October, 1998.
-
- Sidhu, G.S., Andrews, R.F., and Oppenheimer, A., "Inside AppleTalk,
- Second Edition", Addison-Wesley, 1990.
-
-Security Considerations
-
- While this extension to DNS introduces no new security problems to
- DNS or Multicast, it should be emphasized that distributed
- directories, common to other networking protocols, have not hitherto
- been widely used in the IP networking community. Distributed
- directories do require that users and system administrators assume
- some conscious balance between the level of trust which they accord
- to the responding entities on their network, and the degree of
- credence which they pay to the responses they receive. The level of
- trust traditionally assumed in distributed directory environments
- does not necessarily mix well with clear-text password transmission
- such as is still found on some IP networks, for example.
-
-
-Authors' Addresses
-
- Bill Woodcock
- Zocalo
- 2355 Virginia Street
- Berkeley, CA 94709-1315
- USA
-
- Phone: +1 510 540 8000
- EMail: woody@zocalo.net
-
-
- Bill Manning
- USC/ISI
- 4676 Admiralty Way, #1001
- Marina del Rey, CA. 90292
- USA
-
- Phone: +1 310 822 1511
- EMail: bmanning@isi.edu
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). 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
-
-......
-
---------------1F985EC911030AB70E0CD7B9--
-
-
-
---
---bill
+++ /dev/null
-
-
-DNSEXT (Independent submission) O. Kolkman
-Internet-Draft RIPE NCC
-Expires: March 2, 2003 J. Ihren
- Autonomica
- R. Arends
- A.R.E.N.D.S.
- September 2002
-
-
- DNSSEC Wildcard Optimization
- draft-olaf-dnsext-dnssec-wildcard-optimization-01.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 2, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- Secure denial of the existence of wildcards may lead to a large
- number of NXT RRs and associated SIG RRs in DNS responses, even in
- the common case when wildcards are not present in the zone. This
- optimization uses one bit from the NXT type array to signal that
- there is no closer wildcard in the zone for a given query name. This
- reduces the packet size and the need for executing slow, and
- complicated, code paths in common queries. In cases where there are
- no wildcard RRs in the zone (i.e. the root zone) only one NXT RR and
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 1]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
- corresponding SIG is needed for denial of existence of the wildcard.
-
- 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.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 RFC2535 Wildcard Processing . . . . . . . . . . . . . . . . 3
- 1.2 Signalling the Existence of a Wildcard . . . . . . . . . . . 3
- 2. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . 4
- 2.1 Server Side . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1.1 Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1.2 Server Responses . . . . . . . . . . . . . . . . . . . . . . 4
- 2.1.3 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.2 Resolver Side . . . . . . . . . . . . . . . . . . . . . . . 5
- 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
- 4. Security Considerations . . . . . . . . . . . . . . . . . . 6
- 5. Internationalization Considerations . . . . . . . . . . . . 6
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
- 7. Document Changes . . . . . . . . . . . . . . . . . . . . . . 6
- 7.1 draft 00->01 . . . . . . . . . . . . . . . . . . . . . . . . 6
- Normative References . . . . . . . . . . . . . . . . . . . . 7
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7
- A. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- A.1 Zone without wildcards . . . . . . . . . . . . . . . . . . . 8
- A.1.1 Optimized proof . . . . . . . . . . . . . . . . . . . . . . 8
- A.1.2 RFC2535 proof . . . . . . . . . . . . . . . . . . . . . . . 8
- A.2 Zone with wildcards . . . . . . . . . . . . . . . . . . . . 9
- A.2.1 Optimized proof . . . . . . . . . . . . . . . . . . . . . . 10
- A.2.2 NXDOMAIN with additional proof for no wildcard . . . . . . . 10
- A.2.3 Another Optimized Proof . . . . . . . . . . . . . . . . . . 11
- A.2.4 Denial of Existence of Closer Match . . . . . . . . . . . . 11
- A.2.5 The NXT 'next name' Proving Existence of a Wildcard . . . . 12
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 2]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
-1. Introduction
-
- Wildcards make authenticated denial of existence complex. Many zones
- do not contain wildcards but still incur a penalty. If the NXT RR
- contains an indication that a wildcard match can not exist then less
- DNSSEC related RRs and less computation are needed to authoritatively
- deny the existence of a name in the zone.
-
-1.1 RFC2535 Wildcard Processing
-
- RFC2535 [1] specifies that the non-existence of a match against a
- wildcard is proven by a set of relevant NXT records. In practice
- this will result to at least 2 NXT RRs and corresponding SIGs being
- returned. There are cases where the denial of the existence of
- wildcards will need many more than 2 NXT RRs. Even in zones that do
- not use wildcards this will lead to complex answers for which the
- resolvers will need to follow NXT chains and which are hard to
- troubleshoot by operators.
-
-1.2 Signalling the Existence of a Wildcard
-
- The NXT RR, used to the prove the non-existence of data, uses a type
- bit-map to track which types are available for a given name. We
- propose to use one bit (see section Section 3) in the type bitmap to
- signal if a wildcard is available in a zone. We refer to this bit as
- the "NOWILD-bit".
-
- If the NOWILD-bit is set to 1 then the NXT RR signals that there is
- no wildcard match possible against the query name, only if the bit is
- set to 0 further processing needs to be done. For zones without
- wildcards the NOWILD-bit MAY always be set to 1.
-
- The following optimizations are realized:
-
- o Servers and resolvers will only have to execute a slow and
- somewhat complicated code paths if wildcard are present in the
- zone.
-
- o Packet size of answers reduce in most common cases; for the root
- zone the authority section only contains one NXT RR with
- associated SIGs instead of two NXT RRs with associated SIGs.
-
- o In case of absence of wildcards-matches answers will be easier to
- interpret by human operators troubleshooting responses;
-
-
-
-
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 3]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
-2. DNSSEC Protocol Changes
-
- This is an update to the RFC2535 protocol. Resolvers MUST implement
- these changes. Servers MAY implement these changes.
-
-2.1 Server Side
-
-2.1.1 Zone Signing
-
- Servers that implement the optimization MAY perform the following
- actions at zone signing time.
-
- At zone signing time, when the NXT RRs are generated, the NOWILD-bit
- MUST be set to 0 if for an ownername 'label(j).label(j-1).label(j-2)
- ... label(0).' there is no wildcard name '*.label(i).label(i-1) ...
- label(0).' in the zone for all i < j. In other words the label is
- set to 0 if there exists a wildcard that would match QNAME=ownername
- while ignoring the possible existence of a domain name between the
- ownername and the wildcard domain. For all other ownernames the bit
- MUST be set to 1.
-
- If, because of implementation or policy issues, the algorithm in the
- previous paragraph is not applied then the bit MUST be set to 0 for
- all NXT RRs in the zone. Servers that do do not implement the
- optimization have already set their NOWILD bit to 0 by virtue of the
- requirements of RFC2535 section 5.2.
-
- When the algorithm is applied a NXT RR that proves the non-existence
- of a full match of the QNAME will also prove, when it's NOWILD-bit is
- set to 1, that there is no match of the QNAME to any wildcard that
- may exist in the zone
-
-2.1.2 Server Responses
-
- When queried for a name for which there is no match, i.e. no full
- and no wildcard match, in the zone:
-
- o Servers MUST return the NXT RR that proves the non-existence of
- the query name in the NXDOMAIN response. If there is no match for
- a wildcard and the NOWILD-bit is set to 1 at signing time and the
- one NXT RR is sufficient. If the NOWILD-bit for the NXT RR that
- proves non-existence of the query name is set to 0 then NXT RRs
- that prove the non-existence of possible wildcard matches MUST be
- returned as well.
-
- When queried for a name for which there is a match in the zone:
-
- o If the match is an exact match than no NXT RRs are returned in the
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 4]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
- additional section.
-
- o Servers for zones that contain one or more wildcards MUST return
- the NXT RRs that prove the non-existence of the exact match. They
- must also provide proof that there is no closer match for the
- QNAME than the match returned in the answer section.
-
- The proof algorithm for non-existence of wildcards, an exact match or
- closer matches conforms to RFC2535.
-
-2.1.3 Dynamic DNS
-
- When dynamically adding or removing a name that does not contains
- wildcards, the 'next name' for the name immediately above the
- inserted, or deleted name needs to be updated. The NOWILD bit of the
- inserted name is to be set according to the procedure as described in
- Section 2.1.1. Except for setting the NOWILD bit this is similar to
- the RFC2535 procedure.
-
- If a name containing a wildcard is deleted from a zone one has to
- verify if, for all names in the zone with the bit set to 0, the
- NOWILD bit can be toggled. If a name containing a wildcard is added
- one has to verify if, for all the names in the zone, the bit needs to
- be set to 0.
-
- The NOWILD bit is not to be modified during an update of a name that
- already exists in the zone.
-
- Dynamic updates of names that contain wildcards may lead to
- performance penalties for large dynamic zones and one MAY therefore
- choose not to perform the NOWILD optimization for dynamic zones.
-
-2.2 Resolver Side
-
- When receiving an answer to a query a resolver MUST assess if the
- answer is a result of a wildcard match. If the result is an exact
- match then there will be no NXT RRs in the authority section.
-
- If the answer is a wildcard match then the resolver will need to
- verify that the exact name does not exist. The NXT RRs in the
- additional section, which per definition have their NOWILD-bit set to
- 0, will need to prove that there is no closer match. ( conforming to
- RFC2535).
-
- If the response is NXDOMAIN (i.e. no match at all) then the resolver
- MUST verify if the NXT RR proves the non-existence of the exact match
- in the zone. No further NXT RRs are needed if the NXT RR has it's
- NOWILD-bit set to 1. A DNS packet containing an NXDOMAIN response
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 5]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
- accompanied by a NXT RR that has it's NOWILD-bit set to 0 will need
- to contain proof that there are no wildcard matches against the QNAME
- (conforming to RFC2535 ).
-
- The NXT data and the NOWILD-bit together supply the proof on the non-
- existence of a wildcard. There is one situation where the NOWILD-bit
- is set to 1 but the NXT's 'next name' proves that there is a
- wildcard. This is when the 'next name' itself contains a wildcard.
- Resolvers that verify NXDOMAIN replies MUST verify the NXT 'next
- name' first before the NOWILD-bit. Also see example Appendix A.2.5.
-
- The fact that resolvers that obtain an answer with a NXT RR's NOWILD
- set to 1 do not receive additional proof for the non-existence of
- wildcards is incompatible with RFC2535.
-
-3. IANA Considerations
-
- Although there is no RR record associated the NOWILD-bit. The value
- of the bit must be registered as a DNS RR-type. To not cause the NXT
- type bitmap to grow beyond 4 octets unnecessary we propose to reuse
- type code 31 (the EID type code is undocumented).
-
-4. Security Considerations
-
- The draft provides an optimization for wildcard handling. Resolvers
- MUST verify for the denial of existence of matches or the denial of
- existence of closer matches when an answer is returned and the
- NOWILD-bit is set to 0.
-
-5. Internationalization Considerations
-
- There are no internationalization considerations.
-
-6. Acknowledgements
-
- Olafur Gudmundsson, Daniel Karrenberg and Ed Lewis for providing
- critique and input on earlier versions of this document.
-
-7. Document Changes
-
-7.1 draft 00->01
-
- Reordered and reworded the 'protocol changes' section. We tried
- to make the fact that resolvers must and servers may implement
- this optimization more explicit.
-
- Change from using the SIG bit to another bit in the NXT type-
- bitmap, changed the name of the bit and added IANA considerations.
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 6]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
- Note that the meaning of the bit being set and unset are changed
- because of the default setting. Because of the fact that we want
- to maintain backward compatibility with servers that do not
- implement this bit and the bit in the typemap is currently set to
- 0 the default behaviour should be follow old-style NXT proof.
-
- Corrected mistakes in the examples.
-
- Various style and spelling corrections.
-
-Normative References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
-
-Authors' Addresses
-
- Olaf M. Kolkman
- RIPE NCC
- Singel 256
- 1016 AB Amsterdam
- NL
-
- Phone: +31 20 535 4444
- EMail: olaf@ripe.net
- URI: http://www.ripe.net/
-
-
- Johan Ihren
- Autonomica
- Bellmansgatan 30
- SE-118 47 Stockholm
- SE
-
- EMail: johani@autonomica.se
-
-
- Roy Arends
- A.R.E.N.D.S.
- Bankastraat 41-e
- 1094 EB Amsterdam
- NL
-
- Phone: +31206931681
- EMail: Roy@logmess.com
-
-
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 7]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
-Appendix A. Examples
-
-A.1 Zone without wildcards
-
- In the following example zone file there are no wildcards. All
- NOWILD bits are set to 1. The actual SIG RRs and the KEY RRs are
- left out from the zone data and type bitmaps for clarity only.
-
- $ORIGIN example.
- @ IN SOA
- @ NXT a SOA NXT NOWILD ; NOWILD-bit set to 1
- a A 10.0.0.1
- a NXT a.b A NXT NOWILD ; NOWILD-bit set to 1
- a.b A 10.0.0.2
- a.b NXT a.c A NXT NOWILD ; NOWILD-bit set to 1
- a.c A 10.0.0.4
- a.c NXT a.b.c A NXT NOWILD ; NOWILD-bit set to 1
- a.b.c A 10.0.0.5
- a.b.c NXT f A NXT NOWILD ; NOWILD-bit set to 1
- f A 10.0.0.6
- f NXT @ A NXT NOWILD ; NOWILD-bit set to 1
-
-
-A.1.1 Optimized proof
-
- A query for any existing name will return a signed answer without NXT
- RRs in the authority section. A query for any non existing name will
- only return 1 NXT RR proving the non-existence of the QNAME in the
- zone and, by virtue of the NOWILD-bit being 1, this is sufficient
- proof there is no wildcard.
-
- QNAME= d.b.c.example. QTYPE=A
-
- RCODE=NXDOMAIN
- ;; Authority
- example. SOA
- SIG SOA
- a.b.c.example. NXT f.example. A NXT NOWILD
- SIG NXT
- ;; Additional
- (... skipped ... )
-
-
-A.1.2 RFC2535 proof
-
- For comparison we supply the same answer without the optimization
- applied i.e. NOWILD set to 0 for all NXT RRs in the zone. The
- answer needs to contain prove that *.b.c.example, *.c.example and
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 8]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
- *.example do not exist, unless a name that exists in the zone
- terminates the possible match of those wildcards against the QNAME.
-
- QNAME= d.b.c.example. QTYPE=A
-
- RCODE=NXDOMAIN
- ;; Authority
- example. SOA
- SIG SOA
- a.b.c.example. NXT f.example. A NXT
- SIG NXT
- ; proofs non-existence of exact match.
-
- a.c.example. NXT a.b.c.example. A NXT
- SIG NXT
- ; proofs non-existence of *.b.c.example.
-
-
- ;; Additional
- (... skipped ... )
-
- Note that the existence of 'a.b.c.example NXT' RR terminates a
- wildcard match of QNAME against *.c.example. and *.example. So the
- answer packet does not need to contain further proof for the non-
- existence of those wildcards. However, a resolver will have to
- execute logic to verify that the existence of 'a.b.c.example.'
- terminates the possible match of the QNAME against the possible
- wildcards and that the answer is therefore complete.
-
-A.2 Zone with wildcards
-
- In the following example zone file there is a wildcard. Some NOWILD
- bits are set to 1, others for which there is no wildcard in the zone
- if the leftmost labels are chopped off, have there NOWILD-bit set to
- 0. The actual SIG RRs and the KEY RRs at the apex are left out for
- clarity. The queries for which a wildcard match is returned will
- have the NOWILD-bit set to 0, there proof for the non-existing closer
- match is to be supplied and checked by the resolver.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 9]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
- $ORIGIN example.
- @ IN SOA
- @ NXT a SOA NXT NOWILD ; NOWILD-bit set to 1
- a A 10.0.0.1
- a NXT a.b A NXT NOWILD ; NOWILD-bit set to 1
- a.b A 10.0.0.2
- a.b NXT *.c A NXT NOWILD ; NOWILD-bit set to 1
- *.c A 10.0.0.3
- *.c NXT a.c A NXT SIG ; NOWILD-bit set to 0
- a.c A 10.0.0.4
- a.c NXT a.b.c A NXT SIG ; NOWILD-bit set to 0
- a.b.c A 10.0.0.5
- a.b.c NXT f A NXT SIG ; NOWILD-bit set to 0
- f A 10.0.0.6
- f NXT @ A NXT NOWILD ; NOWILD-bit set to 1
-
-
-A.2.1 Optimized proof
-
- QNAME= c.a.a.example. QTYPE=A
-
- RCODE=NXDOMAIN
- ;; Authority
- example. SOA
- SIG SOA
- a.example. NXT a.b.example. A NXT SIG NOWILD
- ; NOWILD-bit set to 1 proves no full
- ; match and no wildcards that match
- ; QNAME
- SIG NXT
-
-
- ;; Additional
- (... skipped ... )
-
-
-A.2.2 NXDOMAIN with additional proof for no wildcard
-
- The following example contains a NXDOMAIN answer and the proof that
- there is no wildcard match.
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 10]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
- QNAME= e.example. QTYPE=A
-
- RCODE=NXDOMAIN
- ;; Authority
- example.example SOA
- SIG SOA
- a.b.c.example. NXT f.example. A NXT SIG ; NOWILD-bit set to 0,
- ; proves no full match
- SIG NXT
- example. NXT a.example A NXT SIG NOWILD ; NOWILD-bit set to 1,
- ; proves no *.example.
-
-
- ;; Additional
- (... skipped ... )
-
-
-A.2.3 Another Optimized Proof
-
- The following example contains a NXDOMAIN answer and the proof that
- there is no wildcard match. In this particular case the proof is
- optimized because of the NOWILD-bit on the f NXT RR being set to
- zero.
-
- QNAME= g.example. QTYPE=A
-
- RCODE=NXDOMAIN
- ;; Authority
- example.example SOA
- SIG SOA
- f.example. NXT example. A NXT NOWILD ; NOWILD-bit set to 1
- ; proves no full match
-
- ;; Additional
- (... skipped ... )
-
-
-A.2.4 Denial of Existence of Closer Match
-
- The following example contains an answer with wildcard expansion and
- the proof that there is no closer match. This is similar to a
- RFC2535 proof of non-existence.
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 11]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
- QNAME= d.b.c.example. QTYPE=A
-
- RCODE=ANSWER
- ;; Answer
- d.b.c.example. A 10.0.0.3 ; expansion of *.c
- SIG A (labelcount=2) ; labelcount proofs wildcard
- ; example
- ;; Authority
- example.example. SOA
- SIG SOA
- a.b.c.example. NXT f.example. A NXT SIG ; NOWILD-bit set to 0,
- ; proves no exact match,
- SIG NXT
- a.c.example. NXT a.b.c.example. A NXT SIG ; NOWILD-bit set to 0
- ; proves non-existence of
- ; *.b.c.example.
- ; No further proofs needed
-
- ;; Additional
- (... skipped ... )
-
-
-A.2.5 The NXT 'next name' Proving Existence of a Wildcard
-
- In the zone above the a.b NXT RR has it's NOWILD-bit set to 1. If
- one would query for '#.c' which canonically orders between a.b and
- *.c one would get back "a.b NXT *.c". A attacker can use the this
- NXT RR in a malformed NXDOMAIN response.
-
- QNAME= #.c.example. QTYPE=A
-
- RCODE=NXDOMAIN ; Black hat answer !!!!
- ;; Authority
- example.example SOA
- SIG SOA
- a.b.example. NXT *.c.example. A NXT NOWILD ; NOWILD-bit set to 1
- ; but *.c exists
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 12]
-\f
-Internet-Draft DNSSEC Wildcard Optimization September 2002
-
-
-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.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires March 2, 2003 [Page 13]
-\f
+++ /dev/null
-
-
-Independent submission M. Richardson
-Internet-Draft SSW
-Expires: August 24, 2003 February 23, 2003
-
-
- A method for storing IPsec keying material in DNS.
- draft-richardson-ipsec-rr-02.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 24, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document describes a new resource record for DNS. This record
- may be used to store public keys for use in IPsec systems.
-
- This record replaces the functionality of the sub-type #1 of the KEY
- Resource Record, which has been proposed to be obsoleted by [1].
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 1]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5
- 3.1 RDATA format - algo type . . . . . . . . . . . . . . . . . . . 5
- 3.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5
- 3.3 RDATA format - RSA public key . . . . . . . . . . . . . . . . 5
- 3.4 RDATA format - DSA public key . . . . . . . . . . . . . . . . 6
- 3.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6
- 4. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7
- 4.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
- Normative references . . . . . . . . . . . . . . . . . . . . . 10
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 2]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-1. Introduction
-
-1.1 Overview
-
- Overview.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 3]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-2. Storage formats
-
- The IPSECKEY resource record (RR) is used to publish a public key
- that is to be associated with a Domain Name System (DNS) name. It
- will be a public key as only public keys are stored in the DNS. This
- can be the public key of a host, network, or application (in the case
- of per-port keying).
-
- An IPSECKEY RR is, like any other RR, authenticated by a SIG RR.
-
- It is expected that there will often be multiple resource records of
- the IPSECKEY type. This will be due to the need to rollover keys,
- and due to the presence of multiple gateways.
-
- The type number for the IPSECKEY RR is 45 (IANA TBD).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 4]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-3. IPSECKEY RDATA format
-
- The RDATA for an IPSECKEY RR consists of a precedence value, a public
- key (and algorithm type), and an optional gateway address.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | RESV | algo | precedence | public key length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
- / public key
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- ~ gateway ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1 RDATA format - algo type
-
- The algorithm type ("algo") field indicates the type of key that is
- present in the public key field. Valid values are:
-
- 0 No key is present.
-
- 1 A RSA key is present, in the format defined in
-
- 2 A DSA key is present, in the format defined in
-
-
-3.2 RDATA format - precedence
-
- This is an 8-bit precedence for this record. This is interpreted in
- a similar way to the PREFERENCE field described in section 3.3.9 of
- [3].
-
-3.3 RDATA format - RSA public key
-
- If the algorithm type has the value 1, then public key portion
- contains an RSA public key, encoded as described in secion 2 of [8],
- and repeated here:
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | pub exp length| public key exponent /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
-
-
-
-Richardson Expires August 24, 2003 [Page 5]
-\f
-Internet-Draft ipsecrr February 2003
-
-
- +- modulus /
- | /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
-
- RFC2065 limited the exponent and modulus to 2552 bits in length, and
- RFC3110 to 4096 bits. No such limit is specified here for the
- purposes of encoding and decoding. The length in octets of the
- public exponent length is represented as one octet if it is in the
- range of 1 to 255 and by a zero octet followed by a two octet
- unsigned length if it is longer than 255 bytes. The public key
- modulus field is a multiprecision unsigned integer. The length of
- the modulus can be determined from the RDLENGTH and the preceding
- RDATA fields including the exponent.
-
- Leading zero bytes are prohibited in the exponent and modulus.
-
-3.4 RDATA format - DSA public key
-
- If the algorithm type has the value 2, then public key portion
- contains an DSA public key, encoded as described in [7].
-
-3.5 RDATA format - gateway
-
- The gateway field indicates a gateway to which an IPsec tunnel may be
- created in order to reach the entity holding this resource record.
- The length of this field is the size of the data portion minus the
- public key length, and the 4 bytes of header. The gateway field may
- be absent.
-
- The gateway field is a string. It is most commonly a simple fully
- qualified domain name (FQDN). IP version 4 and IP version 6
- addresses may be represented using names from in-addr.arpa. and
- ip6.arpa.
-
- The gateway field may also include a @-character in it. Either in
- the form @FQDN, or user@FQDN. In this context, it does not reference
- a single destination, but just an identifier that will be used when
- doing key negotiations. This may be used in the context where the
- gateway does not have a permanent IP address, but has permanent
- address space behind it, and will be initiating connections only.
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 6]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-4. Presentation formats
-
-4.1 Representation of IPSECKEY RRs
-
- IPSECKEY RRs may appear as lines in a zone data master file. The
- precedence field is mandatory. While both the gateway and public key
- fields are optional, it is illegal for neither to be present.
-
- As the IPv4, IPv6 and FQDN references to the gateway are mutually
- exclusive, they can share a position. If no gateway is to be
- indicated, then the special tokens of either "-" or "none" may be
- used.
-
- IPv4 addresses are to be represented as a dotted decimal quad, with
- no leading zeroes. IPv6 addresses are to be presented as specified
- in section 2.2 of [4].
-
-
- 38.46.139.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 192.139.46.38
- RSA: AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
- Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
- 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
- 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
- MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
- cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
- fejrfi1H )
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 7]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-5. IANA Considerations
-
- IANA is asked to assign resource record 45 to this resource record.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 8]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-6. Acknowledgments
-
- People who pushed me to write this.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 9]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-Normative references
-
- [1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record (RR)", RFC 3445, December 2002.
-
- [2] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [3] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [4] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 1884, December 1995.
-
- [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP
- version 6", RFC 1886, December 1995.
-
- [6] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
- (DNS)", RFC 2536, March 1999.
-
- [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
- System (DNS)", RFC 3110, May 2001.
-
-
-Author's Address
-
- Michael C. Richardson
- Sandelman Software Works
- 470 Dawson Avenue
- Ottawa, ON K1Z 5V7
- CA
-
- EMail: mcr@sandelman.ottawa.on.ca
- URI: http://www.sandelman.ottawa.on.ca/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 10]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 11]
-\f
+++ /dev/null
-Network Working Group J. Schlyter
-Internet-Draft Carlstedt Research &
-Expires: August 7, 2002 Technology
- February 6, 2002
-
-
- Storing application public keys in the DNS
- draft-schlyter-appkey-02.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 7, 2002.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This document specifies a new DNS RR type for applications to store
- public keys in. Experience with DNSSEC has indicated that mixing DNS
- keys and application keys is a bad idea in many regards. The new RR
- expands certain fields based on experience from early DNSSEC
- deployment.
-
-
-
-
-
-
-
-
-
-Schlyter Expires August 7, 2002 [Page 1]
-
-Internet-Draft Application public keys in DNS February 2002
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Comments on the KEY RR . . . . . . . . . . . . . . . . . . . . 3
- 2.1 The flag field . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2 The protocol field . . . . . . . . . . . . . . . . . . . . . . 3
- 3. The APPKEY resource record . . . . . . . . . . . . . . . . . . 3
- 3.1 The APPKEY RDATA format . . . . . . . . . . . . . . . . . . . 4
- 3.2 Algorithm number specification . . . . . . . . . . . . . . . . 4
- 3.3 Text representation of APPKEY RRs . . . . . . . . . . . . . . 4
- 3.4 Owner names for APPKEY RRs . . . . . . . . . . . . . . . . . . 4
- 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
- 5. Security considerations . . . . . . . . . . . . . . . . . . . 5
- 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5
- References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
- A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires August 7, 2002 [Page 2]
-
-Internet-Draft Application public keys in DNS February 2002
-
-
-1. Introduction
-
- The Domain Name System Security Extensions (DNSSEC) as described in
- RFC 2535 [3] specifies the KEY resource record (RR). The KEY RR is
- specified for use both for storing keys used by the DNSSEC
- infrastructure itself and for storing keys used by non-DNSSEC
- infrastructure applications (e.g. TLS [2], email and IPsec). The
- issues with combining these two uses in one RR are further discussed
- in a draft called "Limiting the Scope of the KEY Resource Record"
- [10].
-
- 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. Comments on the KEY RR
-
-2.1 The flag field
-
- The KEY RR includes a flag field that specifies key usage, what kind
- of entity the key is associated with and various other flags. As
- this kind of information often is application dependent and a common
- specification that covers all kinds of different flags that an
- application might need is hard to do, the usability of this field is
- questionable.
-
-2.2 The protocol field
-
- The protocol field in the KEY RR is only 8-bit and thus limited to
- 256 different protocols. As there is no way of separating different
- version of a specific protocol, incompatible versions of a single
- protocol requires multiple protocol values. A larger protocol field
- together with the possibility to specify a version of the protocol
- could solve this issue.
-
- A problem with multiple applications storing their public keys at a
- single owner name and thus creating a very large RR set has been
- identified. A possible solution for this could be to use a generic
- protocol value [9] indicating that the actual protocol used is
- indicated in the owner name using a SRV-like encoding. Although this
- would indeed solve the problem with large RR sets when querying for
- an application key, it could also make the protocol field lose its
- value in practice as new applications would not require a new
- protocol value.
-
-3. The APPKEY resource record
-
- The APPKEY resource record (RR) is used to store a application public
-
-
-
-Schlyter Expires August 7, 2002 [Page 3]
-
-Internet-Draft Application public keys in DNS February 2002
-
-
- key that is associated with a Domain Name System (DNS) name.
-
- The RR type code for the APPKEY RR is TBA.
-
- An APPKEY RR is, like any other RR, authenticated by a SIG RR.
-
-3.1 The APPKEY RDATA format
-
- The RDATA for an APPKEY RR consists of an algorithm number octet and
- the public key itself. The format is as follows:
-
- 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 | /
- +---------------+ public key /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
- The meaning of the APPKEY RR owner name and algorithm number octet
- are described in the sections below. The format of the public key is
- algorithm dependent.
-
- APPKEY RRs do not specify their validity period but their
- authenticating SIG RR(s) do as described in RFC 2535 [3].
-
-3.2 Algorithm number specification
-
- The algorithm number used is the same as defined for the KEY RR
- described in RFC 2535 [3].
-
-3.3 Text representation of APPKEY RRs
-
- The RDATA portion of an APPKEY RR has the algorithm number octet
- represented as unsigned integers.
-
- The public key fields is represented in base 64 [8] and may be
- divided up into any number of white space separated substrings, down
- to single base 64 digits, which are concatenated to obtain the full
- public key. These substrings can span lines using the standard
- parenthesis notation. Note that although the public key field may
- have internal sub-fields, these do not appear in the master file
- representation.
-
-3.4 Owner names for APPKEY RRs
-
- The owner name of the APPKEY RR is defined per application and SHOULD
- be defined in such a way that it is possible to query for a single
-
-
-
-Schlyter Expires August 7, 2002 [Page 4]
-
-Internet-Draft Application public keys in DNS February 2002
-
-
- application APPKEY. This can be, but is not limited to, the domain
- name of the host the application is running at (e.g.
- host.example.com) combined with a protocol identifier. A name
- matching the SRV RR [5] for the service (e.g.
- _service._protocol.host.example.com) could be a good starting point
- for this naming.
-
-4. Applicability Statement
-
- The APPKEY resource record (RR) are only intended for storage of
- public keys - private keys MUST NOT be stored in an APPKEY RR.
-
- The APPKEY RR is not intended for storage of certificates and a
- separate certificate RR, defined in RFC 2538 [4], has been developed
- for that purpose.
-
-5. Security considerations
-
- Public keys from an APPKEY RR, SHOULD NOT be trusted unless the
- APPKEY was authenticated by a trusted SIG RR. Applications that do
- not validate the signatures by themselves are advised to use TSIG [6]
- or SIG(0) [7] to protect the transport between themselves and the
- name server doing the signature validation.
-
-6. IANA considerations
-
- IANA needs to allocate a RR type code for APPKEY from the standard RR
- type space. No other IANA services are required by this document.
-
-References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
- P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
- 1999.
-
- [3] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [4] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
- Domain Name System (DNS)", RFC 2538, 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.
-
-
-
-
-Schlyter Expires August 7, 2002 [Page 5]
-
-Internet-Draft Application public keys in DNS February 2002
-
-
- [6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [7] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [8] Josefsson, S., "Base Encodings", work in progress draft-
- josefsson-base-encoding-03, November 2001.
-
- [9] Lewis, E., "DNS KEY Resource Record Generic Protocol Value",
- work in progress draft-lewis-dnsext-key-genprot-00, July 2001.
-
- [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record", work in progress draft-ietf-dnsext-restrict-key-for-
- dnssec-01, January 2002.
-
-
-Author's Address
-
- Jakob Schlyter
- Carlstedt Research & Technology
- Stora Badhusgatan 18-20
- Goteborg SE-411 21
- Sweden
-
- EMail: jakob@crt.se
- URI: http://www.crt.se/~jakob/
-
-Appendix A. Acknowledgements
-
- The author gratefully acknowledges, in no particular order, the
- contributions of the following persons:
-
- Olafur Gudmundsson
-
- Olaf Kolkman
-
- Edward Lewis
-
- Dan Massey
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires August 7, 2002 [Page 6]
-
-Internet-Draft Application public keys in DNS February 2002
-
-
-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.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires August 7, 2002 [Page 7]
-
-
+++ /dev/null
-PKIX Working Group J. Schlyter
-Internet-Draft Carlstedt Research &
-Expires: August 29, 2002 Technology
- L. Johansson
- Stockholm University
- February 28, 2002
-
-
- DNS as X.509 PKIX Certificate Storage
- draft-schlyter-pkix-dns-01
-
-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 29, 2002.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- A major problem facing PKIX deployment and implementation is the
- problem of constructing certificate paths for input to the path
- validation algorithm. This draft describes the use of the DNS as a
- certificate store and it's implication for path validation in PKIX.
-
-
-
-
-
-
-
-
-Schlyter & Johansson Expires August 29, 2002 [Page 1]
-
-Internet-Draft DNS PKIX storage February 2002
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Storing PKIX certificates in DNS . . . . . . . . . . . . . . . . 3
- 3. Certificate lookup algorithm . . . . . . . . . . . . . . . . . . 4
- 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
- References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
- A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Johansson Expires August 29, 2002 [Page 2]
-
-Internet-Draft DNS PKIX storage February 2002
-
-
-1. Introduction
-
- A major problem facing PKIX deployment and implementation is the
- problem of constructing certificate paths for input to the path
- validation algorithm described in RFC 2459 [2]. This problem can be
- solved by successively looking at the issuerAltName extension of each
- certificate and using the information found there together with a
- storage and transport protocol for certificates to find a set of
- candidate certificates associated with the issuerAltName.
-
- Using the CERT RR [5] a certificate can be published using DNS. This
- draft describes the use of DNS as a certificate store and it's
- implication for path validation in PKIX.
-
- 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. Storing PKIX certificates in DNS
-
- A PKIX certificate is published in DNS using the CERT RR [5] for a
- given domain name which SHOULD be equal to the dnsName component of
- the subjectAltName extension in the certificate. Multiple
- certificates may be present for each domain name and all SHOULD have
- the same subject DN. If the domain name does not match the dnsName
- component of the subjectAltName extension the client SHOULD notify
- the user of this and allow the user to decide weather to allow the
- use of the certificate or not.
-
- When constructing a certificate path for validation the client MAY
- use the AuthorityKeyIdentifier and SubjectKeyIdentifier extensions to
- select the (set of) certificates to use.
-
- There are a few important cases when multiple CA certificates are
- published in CERT RRs for given domain name:
-
- Multiple certificates each signed by another member of the same
- set. This situation occurs when a self-signed certificate issues
- a certificate under the same DN (for the purpose of adding policy
- for instance).
-
- Multiple certificates, either self-signed or issued by another CA,
- with different validity periods.
-
- Root key roll-over as described in section 2.4 of RFC 2510 [3]
- where exactly 4 certificates would be published using DNS.
-
-
-
-
-
-Schlyter & Johansson Expires August 29, 2002 [Page 3]
-
-Internet-Draft DNS PKIX storage February 2002
-
-
-3. Certificate lookup algorithm
-
- Given a certificate with a non-empty issuerAltName extension of type
- dnsName, perform a DNS lookup of the corresponding domain name with
- the class IN and type CERT. For each of the certificates returned
- that are of type PKIX, implementations SHOULD verify that the
- subjectAltName in the certificate contains a component of type
- dnsName with the same domain name as the one where the certificate
- was published using the DNS.
-
- If a certificate obtained by this algorithm is a self-signed
- certificate and was successfully verified by DNSSEC [4], the user
- SHOULD be given the opportunity to use this certificate as a trust
- anchor.
-
- The result of this algorithm is a set of of certificates suitable for
- input to the PKIX path validation algorithm.
-
-4. Security Considerations
-
- This document describes a mechanism for automated download of
- certificates from DNS with special provision for bridging trust
- between a PKIX PKI and DNSSEC. However, if only self-signed end-
- entity PKIX certificates are published using DNS the benefits of PKIX
- policy and key usage management is lost.
-
- The benefit of this mechanism is a potential for added protection of
- certificate trust anchors in common use on the Internet by leveraging
- DNSSEC infrastructure.
-
-References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
- Public Key Infrastructure Certificate and CRL Profile", RFC
- 2459, January 1999.
-
- [3] Adams, C. and S. Farrell, "Internet X.509 Public Key
- Infrastructure Certificate Management Protocols", RFC 2510,
- March 1999.
-
- [4] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
- Domain Name System (DNS)", RFC 2538, March 1999.
-
-
-
-Schlyter & Johansson Expires August 29, 2002 [Page 4]
-
-Internet-Draft DNS PKIX storage February 2002
-
-
-Authors' Addresses
-
- Jakob Schlyter
- Carlstedt Research & Technology
- Stora Badhusgatan 18-20
- Goteborg SE-411 21
- Sweden
-
- EMail: jakob@crt.se
- URI: http://www.crt.se/~jakob/
-
-
- Leif Johansson
- Stockholm University
- IT and Media Unit
- Frescati Hagvag 8
- Stockholm SE-106 91
- Sweden
-
- Phone: +46 8 16 45 41
- EMail: leifj@it.su.se
- URI: http://www.it.su.se
-
-Appendix A. Acknowledgements
-
- The author gratefully acknowledges, in no particular order, the
- contributions of the following persons:
-
- Martin Fredriksson
-
- Niklas Hallqvist
-
- Edward Lewis
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Johansson Expires August 29, 2002 [Page 5]
-
-Internet-Draft DNS PKIX storage February 2002
-
-
-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.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Johansson Expires August 29, 2002 [Page 6]
-
-
+++ /dev/null
-INTERNET-DRAFT Stuart Kwan
- James Gilroy
- Levon Esibov
- Microsoft Corp.
- May 2001
-<draft-skwan-utf8-dns-06.txt> Expires November 2001
-
-
- Using the UTF-8 Character Set in the Domain Name System
-
-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
-
-The Domain Names standard specifies that hostnames are represented
-using the ASCII character encoding. This document expands that
-specification to allow the use of the UTF-8 character encoding, a
-superset of ASCII and a translation of the UCS-2 character encoding.
-
-
-1. Introduction
-
-The Domain Names standard [RFC1123] specifies that hostnames are
-represented using the ASCII character encoding. This document expands
-that specification to allow the use of the UTF-8 character encoding
-[RFC2044], a superset of ASCII and a translation of the UCS-2
-character encoding.
-
-Interpreting names as ASCII-only limits the utility of DNS in an
-international setting. The UTF-8 character set includes characters
-from most of the world's written languages, allowing a far greater
-range of possible names and allowing names to use characters that are
-relevant to a particular locality. UTF-8 is the recommended character
-set for protocols that are evolving beyond ASCII [RFC2130].
-
-Expires November 2001 [Page 1]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-This document defines the technology for a richer character set in
-DNS. This document specifically does not define policy for the
-characters allowed in a name when used in a particular application.
-For example, some protocols place restrictions on the characters
-allowed in a name
-
-
-2. Protocol Description
-
-2.1 Components and roles
-
-Before the description of the protocol itself authors feel a need to
-clarify which components are involved in processing the hostnames and
-describe the usage of the hostnames by these components. The following
-list contains such information.
-
-User.
-User could be a human or application. Its role is to specify (also
-known as "write") and retrieve (also known as "read") the hostname to
-and from an application. The examples of such operations include
-typing the hostname, writing it on a touch sensitive screen, reading
-the name from the monitor, listening to a voicemail, etc...
-
-Application.
-Application's role is to
-- process the hostname specified by user or other local or remote
- application.
-- return to the user (for example display on a monitor screen) the
- hostname returned by DNS resolver.
-- call DNS name resolution APIs to request resolver to perform the
- name resolution
-
-Resolver.
-Resolver's role is to
-- process the name resolution requests from an application and submit
- appropriate DNS query to the DNS servers
-- process the response from a DNS server and pass the response to the
- Application.
-
-DNS server.
-The role of the DNS server is to store and maintain the DNS data,
-process the updates to its database, update the replica copies of the
-databases and perform the DNS name resolution through responding to
-the DNS queries.
-
-
-2.2 Protocol details
-
-This section describes the modifications (if any) to each of these
-components and interfaces between the communicating components.
-
-
-
-Expires November 2001 [Page 2]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-2.2.1 Users
-
-No modifications to the users are proposed in this document. At the
-same time support of this protocol by other components specified later
-in this section may enable users to start using in hostnames
-characters from wider set than one specified in [RFC1123].
-
-
-2.2.2 Interface between users and applications
-
-User may use any character set or multiple character sets supported by
-the particular application. Specification of the allowed character
-sets supported by an application is outside of the scope of this
-document. The decision on which characters sets can be used to allow
-user to input and retrieve the hostnames is left to the implementers
-of the particular applications unless a protocol underlying specific
-application specifies the supported characters set. Thus this protocol
-does not affect the interface between users and applications.
-
-
-2.2.3 Applications
-
-Storage format of the hostnames by the applications is outside of the
-scope of this protocol.
-
-
-2.2.4 Interface between applications and resolvers
-
-This protocol does not specify the APIs that applications should use
-to request the resolver to perform the DNS name resolution of the
-internationalized hostnames. Instead it only specifies the format of
-the hostnames specified in the input and output of such APIs.
-
-The applications supporting non-ASCII characters in hostnames MUST
-pass to the resolvers a hostname in ISO/IEC 10646 encoding. If the
-response returned by the resolver to the application contains the
-hostname, then the application should expect the hostname to be
-encoded using ISO/IEC 10646.
-
-
-2.2.5 Resolvers
-
-Before sending the hostname in the query packet, the resolver MUST
-prepare each name part as specified in [NAMEPREP]. After the name
-preparation the resolver MUST convert the hostname to be encoded using
-UTF-8 as specified in [RFC2044].
-Names encoded in UTF-8 must not exceed the size limits clarified in
-[RFC2181]. Character count is insufficient to determine size, since
-some UTF-8 characters exceed one octet in length.
-
-
-
-
-Expires November 2001 [Page 3]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-When resolver receives a response to the query from a DNS server, it
-MUST convert all of the hostnames from UTF-8 encoded format to the
-ISO/IEC 10646 encoding before passing these hostnames back to the
-application.
-
-
-2.2.6 DNS servers
-
-DNS servers authoritative for the records containing the hostnames
-containing the characters not allowed by [RFC1123] MUST allow use of
-the namepreped UTF-8 format to store and transmit those parts of the
-hostnames.
-
-According to existing standards, any binary string can be used in a
-DNS name [RFC2181], but names must be compared with case-insensitivity
-[RFC1035]. At the same time DNS protocol standard states that original
-case SHOULD be preserved when possible as data is entered into the DNS
-database. This requirement is modified as follows: a DNS server
-authoritative for the internationalized hostnames MUST nameprep and
-perform UTF-8 conversion on all names containing internationalized
-characters in both record names and record data before storing these
-hostnames and transmitting those names in any message. This new
-requirement guarantees case-insensitive comparison of the
-internationalized hostnames even by those DNS servers that do not
-support this protocol.
-
-DNS servers must compare names that contain UTF-8 characters
-byte-for-byte, as opposed to using Unicode equivalency rules.
-
-
-3. Interoperability Considerations
-
-If user continues using ASCII-only characters in the hostnames, then
-there is no need to upgrade any applications and/or resolvers.
-
-As pointed in the previous section, there is no need to upgrade DNS
-servers, except possibly those that are authoritative for the zones
-containing internationalized hostnames.
-
-The following interoperability issues should be taken into account
-
-- A legacy application may not be able to process the hostnames
-containing non-ASCII characters returned by DNS resolvers. Effect of
-failure to process a name containing 7-bit needs to be separately
-investigated.
-- If other protocols decide to use the nameprep-UTF-8-encoding to
-represent internationalized hostnames in their wire packets, then a
-legacy application supporting such protocol that receives UTF-8
-encoded hostname from another application (for example, such as mail
-server or client) may fail to process such hostname. Effect of failure
-to process a name containing 7-bit needs to be separately investigate.
-
-
-Expires November 2001 [Page 4]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-Thus hostnames that are intended to be globally usable [RFC1958] on
-legacy applications should still contain ASCII-only characters per
-[RFC1123].
-
-- If an updated application runs on legacy resolver that rejects name
-resolution of the names containing any character not allowed by
-[RFC1123], then such resolvers will require an upgrade to enable name
-resolution of the internationalized hostnames.
-
-- As specified above, DNS servers authoritative for the DNS records
-containing the internationalized hostnames must be able to save and
-load the hostnames containing napepreped-UTF-8-converted characters.
-If the DNS server doesn't satisfy this requirement, but needs to host
-such resource records, then it needs to be upgraded.
-
-- Any DNS server involved in a name resolution process of the DNS
-records containing an internationalized hostname must not reject name
-resolution only because the hostname contains characters not allowed
-by [RFC1123]. This requirement does not mean that every DNS server in
-the name resolution path between the client and authoritative server
-must be able to store and load the DNS records containing the
-internationalized hostnames, but only means that the DNS server
-performing recursive resolution needs to be able to query for and
-cache such records, and that the DNS servers authoritative for the DNS
-names higher in the DNS name hierarchy than the internationalized
-names in query, need to be able to respond to such queries.
-Overwhelming majority of the DNS servers currently deployed on the
-Internet already satisfy this requirement. Authors are not aware of
-any implementation of the DNS server widely deployed on the Internet
-that doesn't satisfy this requirement.
-
-Although most of the DNS servers may be capable of accepting a zone
-transfer of a zone containing UTF-8 encoded hostnames, some of them
-may not be able to store those names in a zone file or load those
-names from a zone file. Administrators should exercise caution when
-transferring a zone containing UTF-8 encoded hostnames to such DNS
-servers.
-
-
-
-4. Security Considerations
-
-Support for internationalized hostnames introduces a possibility of a
-new type of spoofing attacks that could be based on attacker's
-knowledge of misbehaving applications or resolvers that modifies the
-internationalized hostname that needs to be resolved. For example, if
-there is an application that modifies any character containing 7-bit
-in some predictable manner (for example by simply dropping the 7-bit),
-
-
-
-
-
-Expires November 2001 [Page 5]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-then an attacker may register a DNS record mapping the derivative
-(i.e. modified by the misbehaving application or resolver) name to the
-data desired by attacker. In this scenario any user using such
-misbehaving application may receive as a result of name resolution the
-data (for example an IP address in A resource record) specified by the
-attacker without noticing that they are subjected to an attack even if
-the DNSSEC is used to verify the authenticity of the response.
-
-Because this protocol depends on the procedures described in
-[NAMEPREP] and [RFC2044], the security issues identified in these
-document are also applicable to this protocol.
-
-
-5. Acknowledgements
-
-The authors of this document would like to thank the following people
-for their contribution to this specification: John McConnell,
-Cliff Van Dyke and Bjorn Rettig.
-
-
-6. References
-
-[RFC1035] P.V. Mockapetris, "Domain Names - Implementation and
- Specification," RFC 1035, ISI, Nov 1987.
-
-[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode
- and ISO 10646," RFC 2044, Alis Technologies, Oct 1996.
-
-[RFC1958] B. Carpenter, "Architectural Principles of the
- Internet," RFC 1958, IAB, June 1996.
-
-[RFC1123] R. Braden, "Requirements for Internet Hosts -
- Application and Support," STD 3, RFC 1123, January 1989.
-
-[RFC2130] C. Weider et. al., "The Report of the IAB Character
- Set Workshop held 29 July - 1 March 1996",
- RFC 2130, Apr 1997.
-
-[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS
- Specification," RFC 2181, University of Melbourne and
- RGnet Inc, July 1997.
-
-[UNICODE 2.0] The Unicode Consortium, "The Unicode Standard, Version
- 2.0," Addison-Wesley, 1996. ISBN 0-201-48345-9.
-
-[NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
- Internationalized Host Names",
- draft-ietf-idn-nameprep-*.txt.
-
-
-
-
-
-Expires November 2001 [Page 6]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-7. Author's Addresses
-
-Stuart Kwan James Gilroy
-Microsoft Corporation Microsoft Corporation
-One Microsoft Way One Microsoft Way
-Redmond, WA 98052 Redmond, WA 98052
-USA USA
-skwan@microsoft.com jamesg@microsoft.com
-
-Levon Esibov
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-USA
-levone@microsoft.com
-
-
-11. 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.
-
-
-12. Full Copyright Statement
-
-Copyright (C) The Internet Society (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 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
-
-Expires November 2001 [Page 7]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-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."
-
-Expires November 2001 [Page 8]
\ No newline at end of file
+++ /dev/null
-INTERNET DRAFT JUNHYUK SONG
-March 2002 SAMSUNG ELECTRONICS.
-
-
-
-
-
-
- MCI(Multicast Channel Identifier) DNS RR type
- for the support of SSM(Source Specific Multicast)
-
- draft-song-dnsext-mci-ssm-support-00.txt
-
-
-Status of This Memo
-
- Distribution of this memo is unlimited.
-
- 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 the use of the new DNS RR type MCI
- (Multicast Channel Identifier), as it is specifying SSM (Source
- Specific Multicast) multicast channel [SSM] as a DNS Resource
- Record. It shall allow the advance multicast session advertisement
- by providing the dynamic mapping between SSM multicast channel
- and MCI.
-
-
-
-
-
-
-
-
-
-
-Song Expires September 2002 [Page 1]
-\f
-
-Internet Draft 25 March 2002
-
-1. Introduction
-
- IP multicast is the efficient way of delivering IP packets from
- single source to multiple recipients or vice versa.
- It is especially beneficial for the limited bandwidth network such
- as Wireless network. However, one of the known challenge for
- the deployment of widely commercialized IP multicast is the address
- management. Unlike unicast IP address, Multicast IP addresses are
- not assigned to each of individual hosts. It rather statically or
- dynamically assigned to multicast group by service provider, and
- it often has its own address semantics. In order to expedite the
- the deployment of commercialized IP multicast service, the method of
- locating dynamically changed multicast group information may be
- beneficial.
-
- The purpose of this document is to propose the use of MCI (Multicast
- Channel Identifier) as a DNS RR so as to identify dynamically changed
- multicast source and SSM destination IP address for the SSM channel.
- The SSM (Source-Specific Multicast) is defined in [SSM] as below.
-
- "A datagram sent with source IP address S and destination IP address
- G in the SSM range is delivered to each host socket that has
- specifically requested delivery of datagrams sent by S to G, and
- only to those sockets."
-
- MCI shall provide the efficient way of identifying the SSM multicast
- group/channel information, that shall enable persistent mapping
- between multicast channel and dynamically changed Source IP address
- and SSM destination IP address.
-
-
-2. Applicability Statement
-
- One of the challenge of the wide deployment of the multicast service
- is the address management. SSM(Source Specific Multicast) is one of
- the proposed the solutions, the delivery semantics for host specific
- addressing.
-
- IP address in the 232/8 (232.0.0.0 to 232.255.255.255) range are
- currently designated as source specific multicast (SSM) destination
- addresses and are reserved for use by source-specific applications
- and protocols [IANA-ALLOCATION].
-
- The MCI RR defines the multicast channel. The channel is identified
- by (S,G), G for SSM address and S for source host address [SSM].
- MCI (Multicast Channel Identifier) RR provides persistent way to
- identify the multicast channel information.
-
-
-
-Song Expires September 2002 [Page 2]
-\f
-
-Internet Draft 25 March 2002
-
-
- There are two category of the multicast application that may
- make use of MCI, One-to-Many and Many-to-Many cases.[QA]
- One-to-Many case is a single source sending to one or more receivers
- The example of One-to-Many is Scheduled AV presentation, IP Push
- Service, File Distribution, White board, and etc.
-
- On the other hand, Many-to-Many case is multiple receivers also
- represent multiple senders. The example of Many-to-Many is multiple
- user network game, multi-user conference/chat and etc.
-
- In both cases, MCI can be beneficial because users can always locate
- the multicast group/channel by MCI, regardless of the dynamic
- allocation multicast IP address and source IP allocation.
- The multicast group subscribed user can access the service, since MCI
- shall always indicate unique SSM (S,G). Especially wireless mobile
- case, MS(Mobile Station) are more likely dynamically assigned to new
- Multicast IP address and source IP address.
-
- MS may be scattered over the visited networks, while having video
- conference. In that case, the potential members of the video
- conference group subscribe the group to the host of the the group by
- registering the home IP address or NAI [AM] by outband signaling.
- And then the host of the group can register MCI, assigned SSM
- destination IP address, source IP addresses or NAI of the members
- to DNS server. On scheduled time, the members of the group query
- the MCI to retrieve the SSM destination IP address, source IP
- addresses or NAI of other group members, and then send IGMPv3 report
- message [IGMPv3] to attached multicast router to join the conference
- call. With respect to session advertisement (Announcing information
- about the group), there are several approaches available, including
- WWW and SAP (Session Announcement Protocol) [QA]. However, it is
- outside the scope of this document.
-
-
-3. MCI Resource Record
-
- MCI name space is resemble to Domain Name Space, except that it is a
- sequence of one or more labels, made of the Multicast Channel
- Identifier and domain name. MCI records cause no additional section
- processing
-
- The MCI record has the DNS RR type of "?", hence has the same QTYPE
- number. Note: MCI RR requires IANA number assignment.
-
- The class of MCI RR is defined in the IN class only.
-
- TTL should be configured to minimize the time of the RR being cached
-
-
-Song Expires September 2002 [Page 3]
-\f
-
-Internet Draft 25 March 2002
-
-3.1 MCI RDATA 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | SSM Destination Multicast IP address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |IP Addr Count | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Source Address [1] |
- +- -+
- | Source Address [2] |
- +- . -+
- . . .
- . . .
- +- -+
- | Source Address [N] |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | NAI Count | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Network Access Identifier [1] |
- +- -+
- | Network Access Identifier [2] |
- +- . -+
- . . .
- . . .
- +- -+
- | Network Access Identifier [N] |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-where:
-
-SSM Destination Multicast IP address is the IP address in the 232/8
-(232.0.0.0 to 232.255.255.255) range. It also follows AS number scheme
-in RFC 1791 case 1 and RFC 3180(GLOP Addressing in 233/8)[ML], modified
-as follows: the high octet has the value of 232, identifying SSM scheme.
-There MUST be only one SSM Destination multicast IP address field.
-
-IP Addr Count is one octet long and indicating the number of Source IP
-addresses.
-
-Source address is the four octet long Source Host IP address,
-it always precede to NAI field.
-
-NAI Count is one octet long and indicating the number of NAI.
-
-Network Access Identifier is the four octet long Name Access Identifier
-and it always comes after Source address field.
-
-
-Song Expires September 2002 [Page 4]
-\f
-
-Internet Draft 25 March 2002
-
-
-4. Examples
-
- Multicast Router that support GLOP addressing [ML] and SSM mechanism
- shall have the 16 bits AS(Autonomous System) number [ML] while
- allowed to use the IP addresses in the 232/8 (232.0.0.0 to
- 232.255.255.255) range [SSM]. If the host attached to the
- multicast router with AS number 5662 shall allow to use the subnet
- of 232.22.30.0 as a multicast IP address. The AS number 5662 is
- written in hexadecimal format as 161E. Separating out the two octets
- 16 and 1E results in 22 and 30 in decimal format. These values result
- in a subnet of 232.22.30.0 that would be uniquely reserved for the use
- of SSM capable AS 5662 domain.
-
- Resource Record for SSM MCI for starcraft.xbs.samsung.co.kr with two
- source IP address and one NAI will be like below:
-
- starcraft.xbs.samsung.co.kr 1440 IN MCI 232.22.30.4
- 165.213.114.7
- 165.213.114.1
- santajun@lycos.co.kr
-
-
-5. IPv6 support
-
- For IPv6, the address prefixes FF3x:: and FF2x:: are proposed for Source-
- Specific Multicast [SSMIPv6]. It shall be covered by another document
-
-
-
-6. IANA Considerations
-
- It requires new RR type number from IANA.
-
-
-
-7. Acknowledgements
-
- Special thanks to Professor of Murali Venkatesh of Syracuse
- University
-
-
-
-
-
-
-
-
-
-
-Song Expires September 2002 [Page 5]
-\f
-
-Internet Draft 25 March 2002
-
-
-
-References
-
-[IANA] http://www.iana.org/numbers.html
-
-[AM] Bernard Aboba and Mark A. Beadles "The Network Access
- Identifier". RFC 2486. January 1999.
-
-[IGMPv3] B. Cain and S. Deering, I. Kouvelas and A. Thyagarajan.
- Internet Group Management Protocol, Version 3. Work in
- Progress.
-
-[IANA-ALLOCATION] Internet Assigned Numbers Authority,
- http://www.isi.edu/in-notes/iana/assignments/multicast-addresses.
-
-[ML] Meyer and Lothberg "GLOP Addressing in 233/8"
- RFC 3180 September 2001
-
-[RFC1797] IANA, "Class A Subnet Experiment", RFC 1797, April 1995.
-
-[SSM] Brad Cain, Hugh Holbrook "Source-Specific Multicast for IP"
- Work in Progress.
-
-[SSMIPv6] Haberman, B. and Thaler, D. "Unicast-Prefix-based IPv6
- Multicast Addresses." Work in Progress.
-
-[QA] Bob Quinn and Kevin Almeroth "IP Multicast Applications: Challenge
- and Solutions" RFC3170 September 2001
-
-
-
-
-
-Author's Address
-
-Questions about this memo can be directed to the author:
- JUNHYUK SONG
- SAMSUNG ELECTRONICS.
- Packet Technology System Lab.
- Mobile Development Team
- Phone: +82-31-279-3639
- Email: junhyuk@telecom.samsung.co.kr
- santajunman@yahoo.com
-
-
-
-
-
-
-Song Expires September 2002 [Page 6]
-\f
-
-Internet Draft 25 March 2002
-
-
-
-
-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 ore 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Song Expires September 2002 [Page 7]
-\f
+++ /dev/null
-INTERNET DRAFT JUNHYUK SONG
-March 2002 SAMSUNG ELECTRONICS
-
- DONGKIE LEE
- SK TELECOM
-
-
-
- DNS RR type for NAI
- draft-song-dnsext-nai-support-01.txt
-
-
-Status of This Memo
-
- Distribution of this memo is unlimited.
-
- 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 the use of the new DNS RR type "NAI"
- (Network Access Identifier) [RFC2486] to specify dynamically assigned
- IP address.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Song Expires September 2002 [Page 1]
-\f
-
-Internet Draft March 2002
-
-
-1. Introduction
-
- The use of the wireless mobile networking has been dramatically
- increased thanks to rapid development of wireless technology and
- commercial deployment of Mobile IP technology [RFC3220].
- The most recent release of Mobile IPv4 supports the dynamic Home
- Address assignment mechanism that allow MN (Mobile Node) being
- identified by NAI (Network Access Identifier) [RFC2486] rather than
- static Home IP address. NAI has a prominent role on the mobile
- network environment. This is not only because NAI significantly
- reduces the IPv4 address shortage problem and but also it provides
- the standardized method for identifying users in order to accomplish
- the interoperability for roaming over multiple ISPs (Internet Service
- Providers).
-
- The most of the Mobile IPv4 deployment including 3GPP2 CDMA2000
- wireless packet data system architecture [P.S0001-B] identify
- the Mobile Node by NAI. Therefore the need for standardized method
- of binding the ever changing home address of the MN over various ISPs
- to NAI is necessary.
-
- The DNS basically provides a mechanism to map between hostnames and
- IP address with support of many other RRs thorough hierarchically
- built domain names. The NAI is of the form user@realm [RFC2486].
- Adding NAI as a DNS RR shall enable tracking of the dynamically
- changed home IP address. This document specifies a new RR type for
- NAI, mapping host IP address and user identifier (NAI) [RFC2486].
-
-
-2. Applicability Statement
-
- Mobile IPv4 is designed to provide the IP mobility that provides
- reasonably seamless IP connectivity. Since the MN (Mobile Node) is
- no longer necessarily identified by the unique home IP address,
- the mechanism for the locating and updating newly assigned home IP
- address is required [UM].
-
- The NAI RR defines user identifier, NAI widely used for PPP dialup
- connection and Mobile IPv4. The basic idea is to let mobile Internet
- user to constantly update its IP address, while moving around
- multiple access provider network. It can enables correspondent user
- to always reach the specific user by querying NAI to name server,
- regardless of the connecting location.
-
- It is expected that NAI RR will be used in IRS(Internet Reachability
- Service) of 3GPP2 wireless IP network standard [P.S0001-B]
- (see Appendix A).
-
-
-Song Expires September 2002 [Page 2]
-\f
-
-Internet Draft March 2002
-
- The applications that running on the Dynamic Home Address Allocation
- enabled Mobile IPv4 MN (Mobile node) depends on the one to one
- mapping of NAI and newly assigned mobile host IP address in DNS name
- server for the connectivity with Correspondent nodes.
- Because it will be the only way the CN (Correspondent Node) can find
- the Mobile Node's newly assigned IP address. An example of
- application is including WWW server, IP push service, Instant
- Messaging, Multi-user Network games, Multi-chat, etc.
-
-
-
-3. NAI RR Type
-
- NAI name space is resemble to Domain Name Space, except that it is a
- sequence of one or more labels, made of the user identifier and
- domain name. The "@" sign before realm, shall be treated as a
- delimiter to flag user ID part. Every user Identifier
- shall end with "@" sign and placed before domain name. NAI records
- cause no additional section processing
-
- The NAI record has the DNS RR type of "?", hence has the same QTYPE
- number of "?". Note NAI RR requires IANA number assignment.
-
- The class of NAI RR is defined in the IN class only.
-
- TTL should be configured to minimize the time of the RR being cached
-
- The RDATA of NAI is same as A RDATA format, 32 bit Internet Address
-
-4. Examples
-
- Resource Record for NAI(junhyuk@xbs.samsung.co.kr) is like below:
-
- junhyuk@.xbs.samsung.co.kr. 1440 IN NAI 165.213.221.4
-
-
-5. IANA Considerations
-
- It requires new RR type number from IANA.
-
-
-6. Acknowledgements
-
- Special thanks to Professor Murali Venkatesh of Syracuse University
-
-
-
-
-
-
-Song Expires September 2002 [Page 3]
-\f
-
-Internet Draft March 2002
-
-
-
-Appendix A. IRS of 3GPP2 wireless IP Network standard
-
-
- In this example, I've omitted the detail operation of deleting
- DNS record in case of user disconnect. In IRS, it is assumed that
- MS desires to be reached by a fixed identifier such as an NAI-like
- hostname
-
-
-1. Simple IP operation
-
- Upon connecting to new access network MS(Mobile Station) shall
- generate CHAP authentication with NAI for user authentication.
- After successfully authenticate the user authentication request,
- AAAH shall send DNS A record update message to name server.
- (See figure 1)
-
- +--------------+ PPP CHAP (3) +--------------+
- | | Auth Req | AAAH |
- | AAAF |-------------->| |
- | |<--------------| |
- +--------------+ PPP CHAP(5) +--------------+
- ^ | Auth Ack |
- PPP CHAP | | User |
- Auth Req | | PPP CHAP Location |
- (2) | | Auth Ack Update(4)|
- | | (6) v
- | v +---------------+
-+------+ PPP CHAP +-----------+ | Name Server |
-| | Auth Req (1) | | +---------------+
-| |---------------------->| PDSN | ^
-| |<----------------------| | User |
-| MS | PPP CHAP | | Location |
-| | Auth Ack (7) | | Query |
-| |<--------------------->| | |
-| | IP data (8) | | +-------+
-+------+ | | <-----------| CH |
- +-----------+ IP data +-------+
-
-
-
- Figure 1: Simple IPv4 operation
-
-
-
-
-
-
-Song Expires September 2002 [Page 4]
-\f
-
-Internet Draft March 2002
-
-
-
-2. Mobile IP operation
-
- When the HA receives and successfully replies to an initial Mobile IP
- Registration Request, it performs the DNS update for the MS if it has
- previously received an indication from the home RADIUS server to do
- so, or has otherwise been provisioned to do so. The HA shall send a
- DNS Update message [RFC 2136] to the DNS server to add a Resource
- Record for the MS, if so required by the home RADIUS server [4].
- (See figure 2)
-
-
-
- +--------------+ +--------------+
- | |---------------->| |
- | AAAF | | AAAH |
- | |<----------------| |
- +--------------+ +--------------+
- ^ | ^
- Access | | Access |
- Request | v Accept v
-+------+ Agent +--------------+ +--------------+
-| |Advertisement | | | |
-| | with FAC | PDSN/FA | | Mobile IPv4 |
-| MS |<------------ | | | Home Agent |
-| |------------> | |---------------->| |
-| |Mobile IP RRQ | |Mobile IP RRQ | |
-| |with MN-AAA | | | |
-| |<-------------| |<----------------| |
-+------+Mobile IP RRP +--------------+Mobile IP RRP +--------------+
- |
- User |
- Location |
- Update |
- v
- +--------------+
- | Name Server |
- +--------------+
-
- Figure 2: Mobile IPv4 operation
-
-
-
-
-
-
-
-
-
-Song Expires September 2002 [Page 5]
-\f
-
-Internet Draft March 2002
-
-
-
-References
-
-
- [RFC3220] C. Perkins, Editor. "IP Mobility Support". RFC 3320.
- January 2002.
-
- [UM] J.H Song, DK Lee "draft-song-network-user-mobility-00.txt"
- Work in Progress
-
- [RFC2486] Bernard Aboba and Mark A. Beadles "The Network Access
- Identifier". RFC 2486. January 1999.
-
- [P.S0001-B] 3GPP2 P.S0001-B work in progress.
- ftp://ftp.3gpp2.org/TSGP/Standard/
-
-
-
-
-
-
-
-Addresses
-
-Questions about this memo can be directed to the authors:
-
- JUNHYUK SONG
- SAMSUNG ELECTRONICS.
- Packet Technology System Lab.
- Mobile Development Team
- Phone: +82-31-279-3639
- Email: junhyuk@telecom.samsung.co.kr
- santajunman@yahoo.com
-
-
- DONGKIE LEE
- SK TELECOM
- Core Network Development Team
- Network R&D Center
- Phone +82-2-829-4640
- Email: galahad@netsgo.com
- FAX:+82-2-829-4612
-
-
-
-
-
-
-
-Song Expires September 2002 [Page 6]
-\f
-
-Internet Draft March 2002
-
-
-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 ore 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Song Expires September 2002 [Page 7]
-\f
\ No newline at end of file
+++ /dev/null
-
-
-Network Working Group M. StJohns
-Internet-Draft Nominum, Inc.
-Expires: December 12, 2003 June 13, 2003
-
-
- Using DNSSEC-secured NOTIFY to Trigger Parent Zone Updating
- draft-stjohns-secure-notify-00
-
-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 December 12, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document describes an extension or revision to the DNS NOTIFY
- mechanism which would allow a child zone to securely notify a parent
- zone of the need to update records that appear in the parent zone,
- but are related to records in the child zone. At this time, the two
- resource record types are the NS or Name Server record, and the DS or
- Delegation Signer record.
-
-
-
-
-
-
-
-
-
-
-StJohns Expires December 12, 2003 [Page 1]
-\f
-Internet-Draft secured-notify June 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. General Mechanism . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Update Methods . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.1.1 Automatic Update . . . . . . . . . . . . . . . . . . . . . . 5
- 2.1.2 Manual Update . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.1.3 Parent Pull . . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.2 Update of Parent DS Records . . . . . . . . . . . . . . . . 6
- 2.3 Update of Parent NS Records . . . . . . . . . . . . . . . . 6
- 2.4 Uncommitted Updates . . . . . . . . . . . . . . . . . . . . 6
- 3. Parent Zone Secondary Server Update . . . . . . . . . . . . 6
- 4. Security Considerations . . . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . 8
- Normative References . . . . . . . . . . . . . . . . . . . . 7
- A. Discussion: NOTIFY vs UPDATE & Push vs Pull . . . . . . . . 8
- Intellectual Property and Copyright Statements . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires December 12, 2003 [Page 2]
-\f
-Internet-Draft secured-notify June 2003
-
-
-1. Introduction
-
- Author's note: "SEP" will be changed to whatever the final version of
- [SEPFLAG] ends up making it.
-
- Author's note: There may be too many options at places in this
- document. Prior to any submission for advancement to standard, the
- intent is reduce each set of choices down to either a single
- preferred approach, or a preferred choice plus one alternate.
-
- The orignal DNS NOTIFY RFC [RFC1996] specified a mechanism for a
- master server of a zone to tell its secondary servers that a zone had
- changed. The secondary server could then initiate a transfer from
- the master server to update its copy of that zone. RFC1996 only
- specified a notify of a change of an SOA record, and only a
- notification between primary and secondary servers.
-
- The original DNS Security (DNSSEC) RFC [RFC2535] specified various
- mechanisms for securing (i.e. authenticating) the data within the
- DNS. It also included mechanisms for signing transactions. [DSREC]
- specifies a change to RFC2535 which removes the glue KEY record from
- a parent domain, and replaces it with the Delegation Signer or DS
- record which points at a KEY record held by a child zone. The DS
- record is only present in the parent zone at a delegation point.
-
- This document specifies a mechanism for a child zone to notify a
- parent zone (more specifically, the master server of a parent zone)
- of changes in the child zone which might affect glue information held
- in the parent. The transaction signature mechanisms specified in
- RFC2535 and modified in RFC2931 [RFC2931] are used to provide
- authentication of the notification. A notify is triggered by a
- change to records in the child zone which have or should have related
- records in the parent. At this time, these are either the KSK KEY
- records (a subset of the KEY RRSet)which are represented in the
- parent by DS records, or records in the child's apex NS RRSet. Once
- notified, the parent MAY update its glue information.
-
- Note that while both parent and child zones may have RRSets of SIG
- and NXT with the same name, the content of those records in the
- parent zone is directly related to the content of the parent zone,
- and not to the child zone and vice versa.
-
- Glue "A" records could be updated using this mechanism, but may be
- problematic as not all "A" records covering the glue "NS" records
- will always reside within the child zone. Specifically, not all names
- contained in NS records for a zone will be names within the zone. In
- fact, best practice requires that a zone be served by at least one
- server that can be referenced by a name not within that zone.
-
-
-
-StJohns Expires December 12, 2003 [Page 3]
-\f
-Internet-Draft secured-notify June 2003
-
-
- 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. General Mechanism
-
- When the primary server of the child zone detects a change in either
- its set of secure-entry-point (SEP) KEY records or in its set of NS
- records, it MAY (configuration dependent) send a NOTIFY to the
- primary (or other designated server) of its parent zone. The NOTIFY
- includes the complete set of records which make up the changed RRSet.
- If more than one type of RRSet has changed, seperate NOTIFYs should
- be sent for each change, and per RFC1996, no more than one NOTIFY
- should be outstanding at any time.
-
- The NOTIFY is protected using a transaction signature SIG(0)RR
- [RFC2931]. The private key used to form the signature MUST be one of
- the ones currently used to sign the KEY RRSet in the child zone (e.g.
- there MUST be a SIG(KEY) record pointing at that key). If the SEP
- KEY record associated with this private key is not otherwise included
- in the NOTIFY message, it SHOULD be included in the additional
- information section of the NOTIFY message. If the KEY record is not
- included, there will be a delay in completing the NOTIFY transaction
- while the receiving parent server retrieves the KEY record from the
- child.
-
- If the SIG(0)is missing the server MUST return an error code of ??.
-
- The receiving server first checks to see if it holds a DS record that
- maps to the KEY associated with the SIG(0) on the NOTIFY. If the DS
- exists AND is signed, the signature over the NOTIFY is validated
- against the KEY record. If the DS does not exist, the server MUST
- return an error code of ??
-
- If the signature verifies, the NOTIFY message should be considered
- authentic, and the server then sends the NOTIFY response. If the
- signature does not verify, the server MUST return an error code of ??
-
- The sending server should continue to retry until it gets some
- response from the parent zone server, or until too many retries. See
- RFC1996 for details on general retransmission and retry procedures
- for NOTIFY. [Author's note: This may not be sufficient guidance to
- cover the case where the parent has to retrieve the KEY record from
- the child.]
-
- If the policy at the receiving server permits, the data included in
- the NOTIFY and secured under the signature MUST be considered
- authentic, and MUST be used as the source data to update the records
-
-
-
-StJohns Expires December 12, 2003 [Page 4]
-\f
-Internet-Draft secured-notify June 2003
-
-
- held by the parent zone. If policy does not permit acceptance of the
- data in the NOTIFY, or if data is missing (e.g. if the TC bit is
- set), the parent server MUST query the child zone to retrieve any
- missing data (e.g. KEY records, NS records, applicable SIG records).
- The retrieved data MUST be secured (e.g. the SIG records must verify,
- and the KEY used to sign the SIG MUST have a signed DS present in the
- parent zone.)
-
- At this point, the parent server has enough information to update the
- records it holds. How it does it is a matter of policy.
-
-2.1 Update Methods
-
- Author's note - I personally prefer Automatic or Manual - I think
- Parent Pull is the wrong model here.
-
-2.1.1 Automatic Update
-
- In the "Automatic Update" model, the parent server has immediate
- access to the private keys needed to sign the new records. Once the
- NOTIFY is verified, and the contents of the new records are checked
- or generated, the parent zone signs the new records and publishes
- them.
-
-2.1.2 Manual Update
-
- In the "Manual Update" model, private keys are either off-line, or
- require human action to sign the zone, or policy requires someone to
- check the data before its added to the zone (e.g. for child NS
- records). When an update becomes available (e.g. when the parent
- server verifies and accepts the NOTIFY), the server MUST notify an
- administrator by email or other appropriate method of the pending
- action. It must repeat that notification at a configurable interval
- (e.g. once a day) until the adminstrator takes action to approve or
- reject the change.
-
- Once the changes are approved and signed, the new records are
- published to the DNS.
-
-2.1.3 Parent Pull
-
- In the "Parent Pull" model, the child to parent NOTIFY acts like the
- master to secondary NOTIFY works currently. E.g. the parent takes the
- NOTIFY as a request to gather data to update its zone. The parent,
- on its own schedule, retrieves the NS or KEY records from the child
- and compares them to what it current has. If there are differences,
- the parent copies or generates replacement records (i.e. the DS
- records which map to the child KEY records), signs them, and
-
-
-
-StJohns Expires December 12, 2003 [Page 5]
-\f
-Internet-Draft secured-notify June 2003
-
-
- publishes them. As above, this can proceed either manually or
- automatically.
-
-2.2 Update of Parent DS Records
-
- The DS records held in the parent zone are derived from the KEY
- records originated by the child. They are also protected under a key
- held by the parent zone. Upon receipt of the NOTIFY indicating a
- child KEY change, and after any other queries required (e.g. to
- retrieve copies of the KEY or NS records from the child), the parent
- forms a new DS RRSet consisting only of DS's which point to the
- current set of child SEP KEY records. This new DS RRSet, after it is
- signed, replaces the current DS RRSet held by the parent server in
- its entirety.
-
-2.3 Update of Parent NS Records
-
- Since the parent zone's copies of the NS records for the child zone
- are not signed, it is a simple matter of policy as to whether the
- update of the NS records requires human intervention, or can be done
- automatically upon receipt of the NOTIFY. This should be a
- configurable item, and the action should default to automatic.
-
- The parent zone MUST verify the names pointed to by the NS are
- resolvable, that at least one name points to a server not named in
- the child zone, and that it has glue A records for any server named
- in the child zone. [Q: Does this make sense, or is it better to just
- trust the child?] If these conditions are not satisfied, the parent
- server MUST NOT install the new records, and MUST log the problem.
- It must also return an error code of ??
-
- The set of glue NS records held by the parent which point to the
- child MUST be replaced in their entirety by the new set of NS records
- provided either in the notify, or by retrieval by the parent server
- from the child.
-
-2.4 Uncommitted Updates
-
- If a parent zone has a uncommitted update of child information (e.g.
- because policy requires manual intervention to approve the update),
- it MUST discard that update upon validated receipt of a new NOTIFY
- covering the information to be updated. I.e., if the new NOTIFY
- covers NS records, discard any previous uncommitted updates to the NS
- RRSet.
-
-3. Parent Zone Secondary Server Update
-
- Once the adminstrator of the parent zone has accepted the changes
-
-
-
-StJohns Expires December 12, 2003 [Page 6]
-\f
-Internet-Draft secured-notify June 2003
-
-
- (either automatically, or by specific action), the parent zone
- records on the primary server MUST be updated, and, if policy allows,
- the primary SHOULD do a DNS NOTIFY to the secondary servers
- indicating the change to the NS or DS records.
-
-4. Security Considerations
-
- The security of this mechanism is directly related to the protection
- afforded the private keys of the parent and child zones. Compromise
- of the child zone keys can result in incorrect information being
- added to both the parent and child zones. It could also result in
- additional denial of service threats to the parent servers in that
- the servers could be tied up validating and processing bogus (but
- authenticated) update requests for the compromised child zone.
-
-Normative References
-
- [DSREC] Gudmundsson, O., "Delegation Signer Resource Record", ID
- draft-ietf-dnsext-delegation-signer-14.txt, May 2003,
- <http://www.ietf.org/internet-drafts/
- draft-ietf-dnsext-delegation-signer-14.txt>.
-
- [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
- Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [SEPFLAG] Kolkman, O., "KEY RR Secure Entry Point (SEP) Flag", ID
- draft-ietf-dnsext-keyrr-key-signing-flag-07.txt, January
- 2003, <http://www.ietf.org/internet-drafts/
- draft-ietf-dnsext-keyrr-key-signing-flag-07.txt>.
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires December 12, 2003 [Page 7]
-\f
-Internet-Draft secured-notify June 2003
-
-
-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
-
-Appendix A. Discussion: NOTIFY vs UPDATE & Push vs Pull
-
- During the pre-publication phase, the author solicited comments on
- this draft. One email made two suggestions. The first was to use
- UPDATE instead of NOTIFY, the second was if NOTIFY was used then to
- use the notify/pull model for update rather than the mode proposed
- here of pushing the data as part of the NOTIFY.
-
- On the subject of NOTIFY vs UPDATE, neither has exactly the model
- described here, but NOTIFY comes closer. UPDATE has semantics that
- says "please update your copy of something that I own with this
- information that I've provided." NOTIFY's semantics are "something's
- changed that you may care about." What we really want is
- "something's changed that I own, that may affect something that you
- own and here's the data that's changed." NOTIFY is probably the
- closest to this meaning.
-
- On the subject of push vs pull, either of these two models would
- work, and the pull model (ala the original NOTIFY RFC) should be the
- fall back if data isn't provided as part of the secured NOTIFY. If
- the data is provided and secured (i.e. signed) in the NOTIFY, the
- parent shouldn't actually have to retrieve data from the child zone
- (unless the NOTIFY is truncated). If the NOTIFY isn't signed, then
- the pull model is the only one that will work, but then there's no
- point in actually writing this document. In general, the author
- would like to minimize the work factor for the parent and keeping
- track of which child zones need to be polled could be expensive,
- especially in very large parent zones. Placing the burden on the
- child to push data to the parent seems a better choice.
-
-
-
-
-
-
-
-
-
-
-StJohns Expires December 12, 2003 [Page 8]
-\f
-Internet-Draft secured-notify June 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.
-
- The IETF has been notified of intellectual property rights claimed in
- regard to some or all of the specification contained in this
- document. For more information consult the online list of claimed
- rights.
-
-
-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.
-
-
-
-StJohns Expires December 12, 2003 [Page 9]
-\f
-Internet-Draft secured-notify June 2003
-
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns Expires December 12, 2003 [Page 10]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Sam Weiler
-Expires: August 2003 February 24, 2003
-
-
- Legacy Resolver Compatibility for Delegation Signer
- draft-weiler-dnsext-dnssec-2535-compat-00.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 have changed.
- Many deployed nameservers understand variants of these semantics.
- To avoid dangerous interactions when a resolver that understands an
- earlier version of these semantics queries an authoritative server
- that understands the new delegation signer semantics, this document
- proposes changing the type codes and mnemonics of the previous
- DNSSEC resource records (SIG, KEY, and NXT).
-
-1. Introduction
-
- The DNSSEC protocol has been through many iterations whose syntax
- and semantics are not completely compatible. In particular,
- delegation signer [DS] introduces new semantics for the NXT RR that
- are incompatible with the semantics in [RFC2535].
-
- In [RFC2535], NXT records were only returned as part of a
- non-existence proof. In [DS], an unsecure referral returns, in
- addition to the NS, an NXT and SIG(NXT) to prove the non-existence
- of a DS RR. [RFC2535] didn't specify resolver behavior in response
- to an answer with NOERROR or NODATA set and both an NS and an NXT
- in the authority section.
-
- Certain widely deployed 2535-aware resolvers interpret any answer
- with an NXT as a non-existence proof. This results in unsecure
- delegations being invisible to these versions of 2535-aware
- resolvers and violates the basic architectural principle that
- DNSSEC must do no harm -- DNSSEC must not prevent resolution of
- unsecured names. Since it's impractical to force all recursive
- resolvers to upgrade, zone owners who want their zones to be
- globally reachable will have a strong incentive to not sign their
- zones.
-
-2. Proposed Solution
-
- To avoid the problem described above, legacy resolvers (those that
- are 2535-aware) need to be kept from seeing unsecure referrals that
- include NXT records in the authority section. We propose doing
- this by changing the type codes for SIG, KEY, and NXT. To avoid
- operational confusion, it's also necessary to change the mnemonics
- for these RRs.
-
- The new types will have exactly the same syntax and semantics as
- specified for SIG, KEY, and NXT in [DNSSEC] and [DS], and they
- completely replace the old types -- a resolver, if it receives the
- old types, SHOULD treat them as unknown RRs, and SHOULD NOT assign
- any special semantic value to them. It SHOULD NOT use them for
- DNSSEC validations or other DNS operational decision making. An
- authoritative server SHOULD NOT serve the old RR types.
-
-3. Alternative Solutions
-
-3.1 Changing only NXT
-
- The observed problem with unsecure referrals could be addressed by
- changing only the NXT type code. It's quite possible, however,
- that additional incompatibilities exist between [DS] and earlier
- semantics. It's also possible that legacy code will be confused by
- seeing records it thinks it understands (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 code (resolvers and
- tools) completely blinded to DNSSEC -- it will see only unknown
- RRs.
-
-3.2 Replacing 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
- [RFC3225].
-
- 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.
-
-4. IANA Considerations
-
- This document updates the IANA registry for DNS Resource Record
- Types by assigning types X, Y, and Z to the X, Y, and Z, RRs,
- respectively.
-
-5. Security Considerations
-
- The change proposed here does not materially effect 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 results. Accordingly, zones SHOULD NOT contain both
- new and legacy types, and resolvers MUST NOT attempt to use both
- new and legacy types in making trust decisions.
-
- Changing type codes (or changing the EDNS0 flag) 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.
-
-6. References
-
- [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
- Extensions", RFC 2065, January 1997.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC3225] D. Conrad, "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
- [DS] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-12.txt, work in
- progress, December 2002.
-
- [DNSSEC] DNSSEC rewrite documents.
-
-7. Author's Address
-
- Sam Weiler
- Network Associates Laboratories
- 15204 Omega Dr., Suite 300
- Rockville, MD 20850
- USA
- weiler@tislabs.com
-
-
+++ /dev/null
-
-
-Network Working Group R. Bush
-Internet-Draft IIJ
-Expires: August 14, 2003 J. Damas
- February 13, 2003
-
-
- Delegation of 2.0.0.2.ip6.arpa
- draft-ymbk-6to4-arpa-delegation-00.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 14, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document discusses the need for delegation of the
- 2.0.0.2.ip6.arpa DNS zone in order to enable reverse lookups for 6to4
- addresses.
-
-1. 6to4 and DNS
-
- 6to4 [RFC3056] provides a mechanism for IPv6 native hosts to
- communicate over IPv4 clouds without explicit tunnel setup.
-
- 6to4 and DNS [I-D.moore-6to4-dns] describes methods to find the
- delegation path for reverse lookups of 6to4 addresses in the DNS.
- Section 3.1 of the I-D describes a simple method, using established
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 1]
-\f
-Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
-
-
- mechanisms at the RIRs, that would enable such a mechanism to be
- deployed using a minimum of additional setup.
-
- Under the described method, the holders of IPv4 address space can
- request the delegation of a sub-zone in the 2.0.0.2.ip6.arpa DNS tree
- from the party from which they obtained the corresponding IPv4
- in-addr.arpa delegation (or the holder of an even shorter IPv4 prefix
- if their immediate parent is not configured for ip6.arpa), following
- the mapping of IPv4 delegations. This sub-zone can then be populated
- by the entity deploying the 6to4 infrastructure.
-
-2. IANA Considerations
-
- This memo requests that the IANA delegate the 2.0.0.2.IP6.ARPA domain
- to the RIRs as will be described in instructions to be provided by
- the IAB. Names within this zone are to be further delegated within
- the regional IP registries and ISPs in accordance with the delegation
- of IPv4 address space.
-
-3. Security Considerations
-
- While DNS spoofing of address to name mapping has been exploited in
- IPv4, delegation of the 2.0.0.2.ip6.arpa zone creates no new threats
- to the security of the internet.
-
-Normative References
-
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
- via IPv4 Clouds", RFC 3056, February 2001.
-
-Informative References
-
- [I-D.moore-6to4-dns]
- Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
- in progress), October 2002.
-
-
-Authors' Addresses
-
- Randy Bush
- IIJ
- 5147 Crystal Springs
- Bainbrisge Island, WA 98110
- US
-
- Phone: +1 206 780 0431
- EMail: randy@psg.com
- URI: http://psg.com/~randy/
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 2]
-\f
-Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
-
-
- Joao Damas
- Amsterdam,
- The Netherlands
-
- Phone:
- EMail: joao@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 3]
-\f
-Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 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
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 4]
-\f
-Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 5]
-
--- /dev/null
+
+
+
+
+
+
+Network Working Group J. Klensin
+Request for Comments: 3071 February 2001
+Category: Informational
+
+
+ Reflections on the DNS, RFC 1591, and Categories of Domains
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ RFC 1591, "Domain Name System Structure and Delegation", laid out the
+ basic administrative design and principles for the allocation and
+ administration of domains, from the top level down. It was written
+ before the introduction of the world wide web (WWW) and rapid growth
+ of the Internet put significant market, social, and political
+ pressure on domain name allocations. In recent years, 1591 has been
+ cited by all sides in various debates, and attempts have been made by
+ various bodies to update it or adjust its provisions, sometimes under
+ pressures that have arguably produced policies that are less well
+ thought out than the original. Some of those efforts have begun from
+ misconceptions about the provisions of 1591 or the motivation for
+ those provisions. The current directions of the Internet Corporation
+ for Assigned Names and Numbers (ICANN) and other groups who now
+ determine the Domain Name System (DNS) policy directions appear to be
+ drifting away from the policies and philosophy of 1591. This
+ document is being published primarily for historical context and
+ comparative purposes, essentially to document some thoughts about how
+ 1591 might have been interpreted and adjusted by the Internet
+ Assigned Numbers Authority (IANA) and ICANN to better reflect today's
+ world while retaining characteristics and policies that have proven
+ to be effective in supporting Internet growth and stability. An
+ earlier variation of this memo was submitted to ICANN as a comment on
+ its evolving Top-level Domain (TLD) policies.
+
+
+
+
+
+
+
+
+
+Klensin Informational [Page 1]
+\f
+RFC 3071 Reflections on the DNS and RFC 1591 February 2001
+
+
+1. Introduction
+
+ RFC 1591 [1] has been heavily discussed and referenced in the last
+ year or two, especially in discussions within ICANN and its
+ predecessors about the creation, delegation, and management of top-
+ level domains. In particular, the ICANN Domain Name Supporting
+ Organization (DNSO), and especially its ccTLD constituency, have been
+ the home of many discussions in which 1591 and interpretations of it
+ have been cited in support of a variety of sometimes-contradictory
+ positions. During that period, other discussions have gone on to try
+ to reconstruct the thinking that went into RFC 1591. Those in turn
+ have led me and others to muse on how that original thinking might
+ relate to some of the issues being raised. 1591 is, I believe, one
+ of Jon Postel's masterpieces, drawing together very different
+ philosophies (e.g., his traditional view that people are basically
+ reasonable and will do the right thing if told what it is with some
+ stronger mechanisms when that model is not successful) into a single
+ whole.
+
+ RFC 1591 was written in the context of the assumption that what it
+ described as generic TLDs would be bound to policies and categories
+ of registration (see the "This domain is intended..." text in
+ section 2) while ccTLDs were expected to be used primarily to support
+ users and uses within and for a country and its residents. The
+ notion that different domains would be run in different ways --albeit
+ within the broad contexts of "public service on behalf of the
+ Internet community" and "trustee... for the global Internet
+ community"-- was considered a design feature and a safeguard against
+ a variety of potential abuses. Obviously the world has changed in
+ many ways in the seven or eight years since 1591 was written. In
+ particular, the Internet has become more heavily used and, because
+ the design of the world wide web has put domain names in front of
+ users, top-level domain names and registrations in them have been
+ heavily in demand: not only has the number of hosts increased
+ dramatically during that time, but the ratio between registered
+ domain names and physical hosts has increased very significantly.
+
+ The issues 1591 attempted to address when it was written and those we
+ face today have not changed significantly in principle. But one
+ alternative to present trends would be to take a step back to refine
+ it into a model that can function effectively today. Therefore, it
+ may be useful to try to reconstruct 1591's principles and think about
+ their applicability today as a model that could continue to be
+ applied: not because it is historically significant, but because many
+ of its elements have proven to work reasonably well, even in
+ difficult situations. In particular, for many domains (some in
+ 1591's "generic" list and others in its "country code" category) the
+ notion of "public service" --expected then to imply being carried out
+
+
+
+Klensin Informational [Page 2]
+\f
+RFC 3071 Reflections on the DNS and RFC 1591 February 2001
+
+
+ at no or minimal cost to the users, not merely on a non-profit
+ basis-- has yielded to profitability calculations. And, in most of
+ the rest, considerations of at least calculating and recovering costs
+ have crept in. While many of us feel some nostalgia for the old
+ system, it is clear that its days are waning if not gone: perhaps the
+ public service notions as understood when 1591 was written just don't
+ scale to rapid internet growth and very large numbers of
+ yregistrations.
+
+ In particular, some ccTLDs have advertised for registrations outside
+ the designated countries (or other entities), while others have made
+ clear decisions to allow registrations by non-nationals. These
+ decisions and others have produced protests from many sides,
+ suggesting, in turn, that a recategorization is in order. For
+ example, we have heard concerns by governments and managers of
+ traditional, "public service", in-country, ccTLDs about excessive
+ ICANN interference and fears of being forced to conform to
+ internationally-set policies for dispute resolution when their
+ domestic ones are considered more appropriate. We have also heard
+ concerns from registrars and operators of externally-marketed ccTLDs
+ about unreasonable government interference and from gTLD registrars
+ and registries about unreasonable competition from aggressively
+ marketed ccTLDs. The appropriate distinction is no longer between
+ what RFC 1591 described as "generic" TLDs (but which were really
+ intended to be "purpose-specific", a term I will use again below) and
+ ccTLDs but among:
+
+ (i) true "generic" TLDs, in which any registration is acceptable
+ and, ordinarily, registrations from all sources are actively
+ promoted. This list currently includes (the formerly purpose-
+ specific) COM, NET, and ORG, and some ccTLDs. There have been
+ proposals from time to time for additional TLDs of this variety in
+ which, as with COM (and, more recently, NET and ORG) anyone
+ (generally subject only to name conflicts and national law) could
+ register who could pay the fees.
+
+ (ii) purpose-specific TLDs, in which registration is accepted only
+ from organizations or individuals meeting particular
+ qualifications, but where those qualifications are not tied to
+ national boundaries. This list currently includes INT, EDU, the
+ infrastructure domain ARPA, and, arguably, the specialized US
+ Government TLDs MIL and GOV. There have been proposals from time
+ to time for other international TLDs of this variety, e.g., for
+ medical entities such as physicians and hospitals and for museums.
+ ICANN has recently approved several TLDs of this type and
+ describes them as "sponsored" TLDs.
+
+
+
+
+
+Klensin Informational [Page 3]
+\f
+RFC 3071 Reflections on the DNS and RFC 1591 February 2001
+
+
+ (iii) Country domains, operated according to the original
+ underlying assumptions of 1591, i.e., registrants are largely
+ expected to be people or other entities within the country. While
+ external registrations might be accepted by some of these, the
+ country does not aggressively advertise for such registrations,
+ nor does anyone expect to derive significant fee revenue from
+ them. All current domains in this category are ccTLDs, but not
+ all ccTLDs are in this category.
+
+ These categories are clearly orthogonal to the association between
+ the use of the IS 3166-1 registered code list [2] and two-letter
+ "country" domain names. If that relationship is to be maintained
+ (and I believe it is desirable), the only inherent requirement is
+ that no two-letter TLDs be created except from that list (in order to
+ avoid future conflicts). ICANN should control the allocation and
+ delegation of TLDs using these, and other, criteria, but only
+ registered 3166-1 two letter codes should be used as two-letter TLDs.
+
+2. Implications of the Categories
+
+ If we had adopted this type of three-way categorization and could
+ make it work, I believe it would have presented several opportunities
+ for ICANN and the community more generally to reduce controversies
+ and move forward. Of course, there will be cases where the
+ categorization of a particular domain and its operating style will
+ not be completely clear-cut (see section 3, below). But having ICANN
+ work out procedures for dealing with those (probably few) situations
+ appears preferable to strategies that would tend to propel ICANN into
+ areas that are beyond its competence or that might require
+ significant expansion of its mandate.
+
+ First, the internally-operated ccTLDs (category iii above) should not
+ be required to have much interaction with ICANN or vice versa. Once
+ a domain of this sort is established and delegated, and assuming that
+ the "admin contact in the country" rule is strictly observed, the
+ domain should be able to function effectively without ICANN
+ intervention or oversight. In particular, while a country might
+ choose to adopt the general ICANN policies about dispute resolution
+ or name management, issues that arise in these areas might equally
+ well be dealt with exclusively under applicable national laws. If a
+ domain chooses to use ICANN services that cost resources to provide,
+ it should contribute to ICANN's support, but, if it does not, ICANN
+ should not presume to charge it for other than a reasonable fraction
+ of the costs to ICANN of operating the root, root servers, and any
+ directory systems that are generally agreed upon to be necessary and
+ in which the domain participates.
+
+
+
+
+
+Klensin Informational [Page 4]
+\f
+RFC 3071 Reflections on the DNS and RFC 1591 February 2001
+
+
+ By contrast, ccTLDs operated as generic domains ought to be treated
+ as generic domains. ICANN dispute resolution and name management
+ policies and any special rules developed to protect the Internet
+ public in multiple registrar or registry situations should reasonably
+ apply.
+
+3. Telling TLD types apart
+
+ If appropriate policies are adopted, ccTLDs operated as generic
+ domains (category (i) above) and those operated as country domains
+ (category (iii) above) ought to be able to be self-identified. There
+ are several criteria that could be applied to make this
+ determination. For example, either a domain is aggressively seeking
+ outside registrations or it is not and either the vast majority of
+ registrants in a domain are in-country or they are not. One could
+ also think of this as the issue of having some tangible level of
+ presence in the jurisdiction - e.g., is the administrative contact
+ subject, in practical terms, to the in-country laws, or are the
+ registration rules such that it is reasonably likely that a court in
+ the jurisdiction of the country associated with the domain can
+ exercise jurisdiction and enforce a judgment against the registrant.
+
+ One (fairly non-intrusive) rule ICANN might well impose on all top-
+ level domains is that they identify and publish the policies they
+ intend to use. E.g., registrants in a domain that will use the laws
+ of one particular country to resolve disputes should have a
+ reasonable opportunity to understand those policies prior to
+ registration and to make other arrangements (e.g., to register
+ elsewhere) if that mechanism for dispute resolution is not
+ acceptable. Giving IANA (as the root registrar) incorrect
+ information about the purpose and use of a domain should be subject
+ to challenge, and should be grounds for reviewing the appropriateness
+ of the domain delegation, just as not acting consistently and
+ equitably provides such grounds under the original provisions of RFC
+ 1591.
+
+ In order to ensure the availability of accurate and up-to-date
+ registration information the criteria must be consistent, and
+ consistent with more traditional gTLDs, for all nominally country
+ code domains operating as generic TLDs.
+
+4. The role of ICANN in country domains
+
+ ICANN (and IANA) should, as described above, have as little
+ involvement as possible in the direction of true country [code]
+ domains (i.e., category (iii)). There is no particular reason why
+
+
+
+
+
+Klensin Informational [Page 5]
+\f
+RFC 3071 Reflections on the DNS and RFC 1591 February 2001
+
+
+ these domains should be subject to ICANN regulation beyond the basic
+ principles of 1591 and associated arrangements needed to ensure
+ Internet interoperability and stability.
+
+ ICANN's avoiding such involvement strengthens it: the desirability of
+ avoiding collisions with national sovereignty, determinations about
+ government legitimacy, and the authority of someone purportedly
+ writing on behalf of a government, is as important today as it was
+ when 1591 was written. The alternatives take us quickly from
+ "administration" into "internet governance" or, in the case of
+ determining which claimant is the legitimate government of a country,
+ "international relations", and the reasons for not moving in that
+ particular direction are legion.
+
+5. The role of governments
+
+ The history of IANA strategy in handling ccTLDs included three major
+ "things to avoid" considerations:
+
+ * Never get involved in determining which entities were countries
+ and which ones were not.
+
+ * Never get involved in determining who was, or was not, the
+ legitimate government of a country. And, more generally, avoid
+ deciding what entity --government, religion, commercial,
+ academic, etc.-- has what legitimacy or rights.
+
+ * If possible, never become involved in in-country disputes.
+ Instead, very strongly encourage internal parties to work
+ problems out among themselves. At most, adopt a role as
+ mediator and educator, rather than judge, unless abuses are very
+ clear and clearly will not be settled by any internal mechanism.
+
+ All three considerations were obviously intended to avoid IANA's
+ being dragged into a political morass in which it had (and, I
+ suggest, has) no competence to resolve the issues and could only get
+ bogged down. The first consideration was the most visible (and the
+ easiest) and was implemented by strict and careful adherence (see
+ below) to the ISO 3166 registered Country Code list. If an entity
+ had a code, it was eligible to be registered with a TLD (although
+ IANA was free to apply additional criteria-most of them stated in
+ 1591). If it did not, there were no exceptions: the applicant's only
+ recourse was a discussion with the 3166 Registration Authority (now
+ Maintenance Agency, often known just as "3166/MA") or the UN
+ Statistical Office (now Statistics Bureau), not with IANA.
+
+
+
+
+
+
+Klensin Informational [Page 6]
+\f
+RFC 3071 Reflections on the DNS and RFC 1591 February 2001
+
+
+ There are actually five ccTLD exceptions to the strict rules. One,
+ "UK", is historical: it predates the adoption of ISO 3166 for this
+ purpose. The others --Ascension Island, Guernsey, Isle of Man, and
+ Jersey --are arguably, at least in retrospect, just mistakes.
+ Regardless of the historical reasons (about which there has been much
+ speculation), it is almost certainly the case that the right way to
+ handle mistakes of this sort is to acknowledge them and move on,
+ rather than trying to use them as precedents to justify more
+ mistakes.
+
+ This, obviously, is also the argument against use of the "reserved"
+ list (technically internal to the 3166 maintenance activity, and not
+ part of the Standard): since IANA (or ICANN) can ask that a name be
+ placed on that list, there is no rule of an absolute determination by
+ an external organization. Purported countries can come to ICANN,
+ insist on having delegations made and persuade ICANN to ask that the
+ names be reserved. Then, since the reserved name would exist, they
+ could insist that the domain be delegated. Worse, someone could use
+ another organization to request reservation of the name by 3166/MA;
+ once it was reserved, ICANN might be hard-pressed not to do the
+ delegation. Of course, ICANN could (and probably would be forced to)
+ adopt additional criteria other than appearance on the "reserved
+ list" in order to delegate such domains. But those criteria would
+ almost certainly be nearly equivalent to determining which applicants
+ were legitimate and stable enough to be considered a country, the
+ exact decision process that 1591 strove to avoid.
+
+ The other two considerations were more subtle and not always
+ successful: from time to time, both before and after the formal
+ policy shifted toward "governments could have their way", IANA
+ received letters from people purporting to be competent government
+ authorities asking for changes. Some of them turned out later to not
+ have that authority or appropriate qualifications. The assumption of
+ 1591 itself was that, if the "administrative contact in country" rule
+ was strictly observed, as was the rule that delegation changes
+ requested by the administrative contact would be honored, then, if a
+ government _really_ wanted to assert itself, it could pressure the
+ administrative contact into requesting the changes it wanted, using
+ whatever would pass for due process in that country. And the ability
+ to apply that process and pressure would effectively determine who
+ was the government and who wasn't, and would do so far more
+ effectively than any IANA evaluation of, e.g., whether the letterhead
+ on a request looked authentic (and far more safely for ICANN than
+ asking the opinion of any particular other government or selection of
+ governments).
+
+
+
+
+
+
+Klensin Informational [Page 7]
+\f
+RFC 3071 Reflections on the DNS and RFC 1591 February 2001
+
+
+ Specific language in 1591 permitted IANA to adopt a "work it out
+ yourselves; if we have to decide, we will strive for a solution that
+ is not satisfactory to any party" stance. That approach was used
+ successfully, along with large doses of education, on many occasions
+ over the years, to avoid IANA's having to assume the role of judge
+ between conflicting parties.
+
+ Similar principles could be applied to the boundary between country-
+ code-based generic TLDs and country domains. Different countries,
+ under different circumstances, might prefer to operate the ccTLD
+ either as a national service or as a profit center where the
+ "customers" were largely external. Whatever decisions were made
+ historically, general Internet stability argues that changes should
+ not be made lightly. At the same time, if a government wishes to
+ make a change, the best mechanism for doing so is not to involve
+ ICANN in a potential determination of legitimacy (or even to have
+ ICANN's Government Advisory Committee (GAC) try to formally make that
+ decision for individual countries) but for the relevant government to
+ use its own procedures to persuade the administrative contact to
+ request the change and for IANA to promptly and efficiently carry out
+ requests made by administrative contacts.
+
+6. Implications for the current ICANN DNSO structure.
+
+ The arguments by some of the ccTLD administrators that they are
+ different from the rest of the ICANN and DNSO structures are (in this
+ model) correct: they are different. The ccTLDs that are operating as
+ generic TLDs should be separated from the ccTLD constituency and
+ joined to the gTLD constituency. The country ccTLDs should be
+ separated from ICANN's immediate Supporting Organization structure,
+ and operate in a parallel and advisory capacity to ICANN, similar to
+ the arrangements used with the GAC. The DNSO and country TLDs should
+ not be required to interact with each other except on a mutually
+ voluntary basis and, if ICANN needs interaction or advice from some
+ of all of those TLDs, it would be more appropriate to get it in the
+ form of an advisory body like the GAC rather than as DNSO
+ constituency.
+
+7. References
+
+ [1] Postel, J., "Domain Name System Structure and Delegation", RFC
+ 1591, March 1994.
+
+ [2] ISO 3166. ISO 3166-1. Codes for the representation of names of
+ countries and their subdivisions - Part 1: Country codes (1997).
+
+
+
+
+
+
+Klensin Informational [Page 8]
+\f
+RFC 3071 Reflections on the DNS and RFC 1591 February 2001
+
+
+8. Acknowledgements and disclaimer
+
+ These reflections have been prepared in my individual capacity and do
+ not necessarily reflect the views of my past or present employers.
+ Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
+ Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
+ suggestions or offered editorial comments about earlier versions of
+ this document. Cord Wischhoefer, of the ISO 3166/MA, was also kind
+ enough to look at the draft and supplied some useful details. Those
+ comments contributed significantly to whatever clarity the document
+ has, but the author bears responsibility for the selection of
+ comments which were ultimately incorporated and the way in which the
+ conclusions were presented.
+
+9. Security Considerations
+
+ This memo addresses the context for a set of administrative decisions
+ and procedures, and does not raise or address security issues.
+
+10. Author's Address
+
+ John C. Klensin
+ 1770 Massachusetts Ave, Suite 322
+ Cambridge, MA 02140, USA
+
+ EMail: klensin@jck.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin Informational [Page 9]
+\f
+RFC 3071 Reflections on the DNS and RFC 1591 February 2001
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society 2001. All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others provided that the above copyright notice and this paragraph
+ are included on all such copies. 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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin Informational [Page 10]
+\f
--- /dev/null
+
+
+
+
+
+
+Network Working Group J. Klensin
+Request for Comments: 3467 February 2003
+Category: Informational
+
+
+ Role of the Domain Name System (DNS)
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ This document reviews the original function and purpose of the domain
+ name system (DNS). It contrasts that history with some of the
+ purposes for which the DNS has recently been applied and some of the
+ newer demands being placed upon it or suggested for it. A framework
+ for an alternative to placing these additional stresses on the DNS is
+ then outlined. This document and that framework are not a proposed
+ solution, only a strong suggestion that the time has come to begin
+ thinking more broadly about the problems we are encountering and
+ possible approaches to solving them.
+
+Table of Contents
+
+ 1. Introduction and History ..................................... 2
+ 1.1 Context for DNS Development ............................... 3
+ 1.2 Review of the DNS and Its Role as Designed ................ 4
+ 1.3 The Web and User-visible Domain Names ..................... 6
+ 1.4 Internet Applications Protocols and Their Evolution ....... 7
+ 2. Signs of DNS Overloading ..................................... 8
+ 3. Searching, Directories, and the DNS .......................... 12
+ 3.1 Overview ................................................. 12
+ 3.2 Some Details and Comments ................................. 14
+ 4. Internationalization ......................................... 15
+ 4.1 ASCII Isn't Just Because of English ....................... 16
+ 4.2 The "ASCII Encoding" Approaches ........................... 17
+ 4.3 "Stringprep" and Its Complexities ......................... 17
+ 4.4 The Unicode Stability Problem ............................. 19
+ 4.5 Audiences, End Users, and the User Interface Problem ...... 20
+ 4.6 Business Cards and Other Natural Uses of Natural Languages. 22
+ 4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
+
+
+
+Klensin Informational [Page 1]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ 4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
+ 5. Search-based Systems: The Key Controversies .................. 23
+ 6. Security Considerations ...................................... 24
+ 7. References ................................................... 25
+ 7.1 Normative References ...................................... 25
+ 7.2 Explanatory and Informative References .................... 25
+ 8. Acknowledgements ............................................. 30
+ 9. Author's Address ............................................. 30
+ 10. Full Copyright Statement ..................................... 31
+
+1. Introduction and History
+
+ The DNS was designed as a replacement for the older "host table"
+ system. Both were intended to provide names for network resources at
+ a more abstract level than network (IP) addresses (see, e.g.,
+ [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]). In recent years,
+ the DNS has become a database of convenience for the Internet, with
+ many proposals to add new features. Only some of these proposals
+ have been successful. Often the main (or only) motivation for using
+ the DNS is because it exists and is widely deployed, not because its
+ existing structure, facilities, and content are appropriate for the
+ particular application of data involved. This document reviews the
+ history of the DNS, including examination of some of those newer
+ applications. It then argues that the overloading process is often
+ inappropriate. Instead, it suggests that the DNS should be
+ supplemented by systems better matched to the intended applications
+ and outlines a framework and rationale for one such system.
+
+ Several of the comments that follow are somewhat revisionist. Good
+ design and engineering often requires a level of intuition by the
+ designers about things that will be necessary in the future; the
+ reasons for some of these design decisions are not made explicit at
+ the time because no one is able to articulate them. The discussion
+ below reconstructs some of the decisions about the Internet's primary
+ namespace (the "Class=IN" DNS) in the light of subsequent development
+ and experience. In addition, the historical reasons for particular
+ decisions about the Internet were often severely underdocumented
+ contemporaneously and, not surprisingly, different participants have
+ different recollections about what happened and what was considered
+ important. Consequently, the quasi-historical story below is just
+ one story. There may be (indeed, almost certainly are) other stories
+ about how the DNS evolved to its present state, but those variants do
+ not invalidate the inferences and conclusions.
+
+ This document presumes a general understanding of the terminology of
+ RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
+
+
+
+
+
+Klensin Informational [Page 2]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+1.1 Context for DNS Development
+
+ During the entire post-startup-period life of the ARPANET and nearly
+ the first decade or so of operation of the Internet, the list of host
+ names and their mapping to and from addresses was maintained in a
+ frequently-updated "host table" [RFC625], [RFC811], [RFC952]. The
+ names themselves were restricted to a subset of ASCII [ASCII] chosen
+ to avoid ambiguities in printed form, to permit interoperation with
+ systems using other character codings (notably EBCDIC), and to avoid
+ the "national use" code positions of ISO 646 [IS646]. These
+ restrictions later became collectively known as the "LDH" rules for
+ "letter-digit-hyphen", the permitted characters. The table was just
+ a list with a common format that was eventually agreed upon; sites
+ were expected to frequently obtain copies of, and install, new
+ versions. The host tables themselves were introduced to:
+
+ o Eliminate the requirement for people to remember host numbers
+ (addresses). Despite apparent experience to the contrary in the
+ conventional telephone system, numeric numbering systems,
+ including the numeric host number strategy, did not (and do not)
+ work well for more than a (large) handful of hosts.
+
+ o Provide stability when addresses changed. Since addresses -- to
+ some degree in the ARPANET and more importantly in the
+ contemporary Internet -- are a function of network topology and
+ routing, they often had to be changed when connectivity or
+ topology changed. The names could be kept stable even as
+ addresses changed.
+
+ o Provide the capability to have multiple addresses associated with
+ a given host to reflect different types of connectivity and
+ topology. Use of names, rather than explicit addresses, avoided
+ the requirement that would otherwise exist for users and other
+ hosts to track these multiple host numbers and addresses and the
+ topological considerations for selecting one over others.
+
+ After several years of using the host table approach, the community
+ concluded that model did not scale adequately and that it would not
+ adequately support new service variations. A number of discussions
+ and meetings were held which drew several ideas and incomplete
+ proposals together. The DNS was the result of that effort. It
+ continued to evolve during the design and initial implementation
+ period, with a number of documents recording the changes (see
+ [RFC819], [RFC830], and [RFC1034]).
+
+
+
+
+
+
+
+Klensin Informational [Page 3]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ The goals for the DNS included:
+
+ o Preservation of the capabilities of the host table arrangements
+ (especially unique, unambiguous, host names),
+
+ o Provision for addition of additional services (e.g., the special
+ record types for electronic mail routing which quickly followed
+ introduction of the DNS), and
+
+ o Creation of a robust, hierarchical, distributed, name lookup
+ system to accomplish the other goals.
+
+ The DNS design also permitted distribution of name administration,
+ rather than requiring that each host be entered into a single,
+ central, table by a central administration.
+
+1.2 Review of the DNS and Its Role as Designed
+
+ The DNS was designed to identify network resources. Although there
+ was speculation about including, e.g., personal names and email
+ addresses, it was not designed primarily to identify people, brands,
+ etc. At the same time, the system was designed with the flexibility
+ to accommodate new data types and structures, both through the
+ addition of new record types to the initial "INternet" class, and,
+ potentially, through the introduction of new classes. Since the
+ appropriate identifiers and content of those future extensions could
+ not be anticipated, the design provided that these fields could
+ contain any (binary) information, not just the restricted text forms
+ of the host table.
+
+ However, the DNS, as it is actually used, is intimately tied to the
+ applications and application protocols that utilize it, often at a
+ fairly low level.
+
+ In particular, despite the ability of the protocols and data
+ structures themselves to accommodate any binary representation, DNS
+ names as used were historically not even unrestricted ASCII, but a
+ very restricted subset of it, a subset that derives from the original
+ host table naming rules. Selection of that subset was driven in part
+ by human factors considerations, including a desire to eliminate
+ possible ambiguities in an international context. Hence character
+ codes that had international variations in interpretation were
+ excluded, the underscore character and case distinctions were
+ eliminated as being confusing (in the underscore's case, with the
+ hyphen character) when written or read by people, and so on. These
+ considerations appear to be very similar to those that resulted in
+ similarly restricted character sets being used as protocol elements
+ in many ITU and ISO protocols (cf. [X29]).
+
+
+
+Klensin Informational [Page 4]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ Another assumption was that there would be a high ratio of physical
+ hosts to second level domains and, more generally, that the system
+ would be deeply hierarchical, with most systems (and names) at the
+ third level or below and a very large percentage of the total names
+ representing physical hosts. There are domains that follow this
+ model: many university and corporate domains use fairly deep
+ hierarchies, as do a few country-oriented top level domains
+ ("ccTLDs"). Historically, the "US." domain has been an excellent
+ example of the deeply hierarchical approach. However, by 1998,
+ comparison of several efforts to survey the DNS showed a count of SOA
+ records that approached (and may have passed) the number of distinct
+ hosts. Looked at differently, we appear to be moving toward a
+ situation in which the number of delegated domains on the Internet is
+ approaching or exceeding the number of hosts, or at least the number
+ of hosts able to provide services to others on the network. This
+ presumably results from synonyms or aliases that map a great many
+ names onto a smaller number of hosts. While experience up to this
+ time has shown that the DNS is robust enough -- given contemporary
+ machines as servers and current bandwidth norms -- to be able to
+ continue to operate reasonably well when those historical assumptions
+ are not met (e.g., with a flat, structure under ".COM" containing
+ well over ten million delegated subdomains [COMSIZE]), it is still
+ useful to remember that the system could have been designed to work
+ optimally with a flat structure (and very large zones) rather than a
+ deeply hierarchical one, and was not.
+
+ Similarly, despite some early speculation about entering people's
+ names and email addresses into the DNS directly (e.g., see
+ [RFC1034]), electronic mail addresses in the Internet have preserved
+ the original, pre-DNS, "user (or mailbox) at location" conceptual
+ format rather than a flatter or strictly dot-separated one.
+ Location, in that instance, is a reference to a host. The sole
+ exception, at least in the "IN" class, has been one field of the SOA
+ record.
+
+ Both the DNS architecture itself and the two-level (host name and
+ mailbox name) provisions for email and similar functions (e.g., see
+ the finger protocol [FINGER]), also anticipated a relatively high
+ ratio of users to actual hosts. Despite the observation in RFC 1034
+ that the DNS was expected to grow to be proportional to the number of
+ users (section 2.3), it has never been clear that the DNS was
+ seriously designed for, or could, scale to the order of magnitude of
+ number of users (or, more recently, products or document objects),
+ rather than that of physical hosts.
+
+ Just as was the case for the host table before it, the DNS provided
+ critical uniqueness for names, and universal accessibility to them,
+ as part of overall "single internet" and "end to end" models (cf.
+
+
+
+Klensin Informational [Page 5]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ [RFC2826]). However, there are many signs that, as new uses evolved
+ and original assumptions were abused (if not violated outright), the
+ system was being stretched to, or beyond, its practical limits.
+
+ The original design effort that led to the DNS included examination
+ of the directory technologies available at the time. The design
+ group concluded that the DNS design, with its simplifying assumptions
+ and restricted capabilities, would be feasible to deploy and make
+ adequately robust, which the more comprehensive directory approaches
+ were not. At the same time, some of the participants feared that the
+ limitations might cause future problems; this document essentially
+ takes the position that they were probably correct. On the other
+ hand, directory technology and implementations have evolved
+ significantly in the ensuing years: it may be time to revisit the
+ assumptions, either in the context of the two- (or more) level
+ mechanism contemplated by the rest of this document or, even more
+ radically, as a path toward a DNS replacement.
+
+1.3 The Web and User-visible Domain Names
+
+ From the standpoint of the integrity of the domain name system -- and
+ scaling of the Internet, including optimal accessibility to content
+ -- the web design decision to use "A record" domain names directly in
+ URLs, rather than some system of indirection, has proven to be a
+ serious mistake in several respects. Convenience of typing, and the
+ desire to make domain names out of easily-remembered product names,
+ has led to a flattening of the DNS, with many people now perceiving
+ that second-level names under COM (or in some countries, second- or
+ third-level names under the relevant ccTLD) are all that is
+ meaningful. This perception has been reinforced by some domain name
+ registrars [REGISTRAR] who have been anxious to "sell" additional
+ names. And, of course, the perception that one needed a second-level
+ (or even top-level) domain per product, rather than having names
+ associated with a (usually organizational) collection of network
+ resources, has led to a rapid acceleration in the number of names
+ being registered. That acceleration has, in turn, clearly benefited
+ registrars charging on a per-name basis, "cybersquatters", and others
+ in the business of "selling" names, but it has not obviously
+ benefited the Internet as a whole.
+
+ This emphasis on second-level domain names has also created a problem
+ for the trademark community. Since the Internet is international,
+ and names are being populated in a flat and unqualified space,
+ similarly-named entities are in conflict even if there would
+ ordinarily be no chance of confusing them in the marketplace. The
+ problem appears to be unsolvable except by a choice between draconian
+ measures. These might include significant changes to the legislation
+ and conventions that govern disputes over "names" and "marks". Or
+
+
+
+Klensin Informational [Page 6]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ they might result in a situation in which the "rights" to a name are
+ typically not settled using the subtle and traditional product (or
+ industry) type and geopolitical scope rules of the trademark system.
+ Instead they have depended largely on political or economic power,
+ e.g., the organization with the greatest resources to invest in
+ defending (or attacking) names will ultimately win out. The latter
+ raises not only important issues of equity, but also the risk of
+ backlash as the numerous small players are forced to relinquish names
+ they find attractive and to adopt less-desirable naming conventions.
+
+ Independent of these sociopolitical problems, content distribution
+ issues have made it clear that it should be possible for an
+ organization to have copies of data it wishes to make available
+ distributed around the network, with a user who asks for the
+ information by name getting the topologically-closest copy. This is
+ not possible with simple, as-designed, use of the DNS: DNS names
+ identify target resources or, in the case of email "MX" records, a
+ preferentially-ordered list of resources "closest" to a target (not
+ to the source/user). Several technologies (and, in some cases,
+ corresponding business models) have arisen to work around these
+ problems, including intercepting and altering DNS requests so as to
+ point to other locations.
+
+ Additional implications are still being discovered and evaluated.
+
+ Approaches that involve interception of DNS queries and rewriting of
+ DNS names (or otherwise altering the resolution process based on the
+ topological location of the user) seem, however, to risk disrupting
+ end-to-end applications in the general case and raise many of the
+ issues discussed by the IAB in [IAB-OPES]. These problems occur even
+ if the rewriting machinery is accompanied by additional workarounds
+ for particular applications. For example, security associations and
+ applications that need to identify "the same host" often run into
+ problems if DNS names or other references are changed in the network
+ without participation of the applications that are trying to invoke
+ the associated services.
+
+1.4 Internet Applications Protocols and Their Evolution
+
+ At the applications level, few of the protocols in active,
+ widespread, use on the Internet reflect either contemporary knowledge
+ in computer science or human factors or experience accumulated
+ through deployment and use. Instead, protocols tend to be deployed
+ at a just-past-prototype level, typically including the types of
+ expedient compromises typical with prototypes. If they prove useful,
+ the nature of the network permits very rapid dissemination (i.e.,
+ they fill a vacuum, even if a vacuum that no one previously knew
+ existed). But, once the vacuum is filled, the installed base
+
+
+
+Klensin Informational [Page 7]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ provides its own inertia: unless the design is so seriously faulty as
+ to prevent effective use (or there is a widely-perceived sense of
+ impending disaster unless the protocol is replaced), future
+ developments must maintain backward compatibility and workarounds for
+ problematic characteristics rather than benefiting from redesign in
+ the light of experience. Applications that are "almost good enough"
+ prevent development and deployment of high-quality replacements.
+
+ The DNS is both an illustration of, and an exception to, parts of
+ this pessimistic interpretation. It was a second-generation
+ development, with the host table system being seen as at the end of
+ its useful life. There was a serious attempt made to reflect the
+ computing state of the art at the time. However, deployment was much
+ slower than expected (and very painful for many sites) and some fixed
+ (although relaxed several times) deadlines from a central network
+ administration were necessary for deployment to occur at all.
+ Replacing it now, in order to add functionality, while it continues
+ to perform its core functions at least reasonably well, would
+ presumably be extremely difficult.
+
+ There are many, perhaps obvious, examples of this. Despite many
+ known deficiencies and weaknesses of definition, the "finger" and
+ "whois" [WHOIS] protocols have not been replaced (despite many
+ efforts to update or replace the latter [WHOIS-UPDATE]). The Telnet
+ protocol and its many options drove out the SUPDUP [RFC734] one,
+ which was arguably much better designed for a diverse collection of
+ network hosts. A number of efforts to replace the email or file
+ transfer protocols with models which their advocates considered much
+ better have failed. And, more recently and below the applications
+ level, there is some reason to believe that this resistance to change
+ has been one of the factors impeding IPv6 deployment.
+
+2. Signs of DNS Overloading
+
+ Parts of the historical discussion above identify areas in which the
+ DNS has become overloaded (semantically if not in the mechanical
+ ability to resolve names). Despite this overloading, it appears that
+ DNS performance and reliability are still within an acceptable range:
+ there is little evidence of serious performance degradation. Recent
+ proposals and mechanisms to better respond to overloading and scaling
+ issues have all focused on patching or working around limitations
+ that develop when the DNS is utilized for out-of-design functions,
+ rather than on dramatic rethinking of either DNS design or those
+ uses. The number of these issues that have arisen at much the same
+ time may argue for just that type of rethinking, and not just for
+ adding complexity and attempting to incrementally alter the design
+ (see, for example, the discussion of simplicity in section 2 of
+ [RFC3439]).
+
+
+
+Klensin Informational [Page 8]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ For example:
+
+ o While technical approaches such as larger and higher-powered
+ servers and more bandwidth, and legal/political mechanisms such as
+ dispute resolution policies, have arguably kept the problems from
+ becoming critical, the DNS has not proven adequately responsive to
+ business and individual needs to describe or identify things (such
+ as product names and names of individuals) other than strict
+ network resources.
+
+ o While stacks have been modified to better handle multiple
+ addresses on a physical interface and some protocols have been
+ extended to include DNS names for determining context, the DNS
+ does not deal especially well with many names associated with a
+ given host (e.g., web hosting facilities with multiple domains on
+ a server).
+
+ o Efforts to add names deriving from languages or character sets
+ based on other than simple ASCII and English-like names (see
+ below), or even to utilize complex company or product names
+ without the use of hierarchy, have created apparent requirements
+ for names (labels) that are over 63 octets long. This requirement
+ will undoubtedly increase over time; while there are workarounds
+ to accommodate longer names, they impose their own restrictions
+ and cause their own problems.
+
+ o Increasing commercialization of the Internet, and visibility of
+ domain names that are assumed to match names of companies or
+ products, has turned the DNS and DNS names into a trademark
+ battleground. The traditional trademark system in (at least) most
+ countries makes careful distinctions about fields of
+ applicability. When the space is flattened, without
+ differentiation by either geography or industry sector, not only
+ are there likely conflicts between "Joe's Pizza" (of Boston) and
+ "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
+ Repair" (of Los Angeles). All three would like to control
+ "Joes.com" (and would prefer, if it were permitted by DNS naming
+ rules, to also spell it as "Joe's.com" and have both resolve the
+ same way) and may claim trademark rights to do so, even though
+ conflict or confusion would not occur with traditional trademark
+ principles.
+
+ o Many organizations wish to have different web sites under the same
+ URL and domain name. Sometimes this is to create local variations
+ -- the Widget Company might want to present different material to
+ a UK user relative to a US one -- and sometimes it is to provide
+ higher performance by supplying information from the server
+ topologically closest to the user. If the name resolution
+
+
+
+Klensin Informational [Page 9]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ mechanism is expected to provide this functionality, there are
+ three possible models (which might be combined):
+
+ - supply information about multiple sites (or locations or
+ references). Those sites would, in turn, provide information
+ associated with the name and sufficient site-specific
+ attributes to permit the application to make a sensible choice
+ of destination, or
+
+ - accept client-site attributes and utilize them in the search
+ process, or
+
+ - return different answers based on the location or identity of
+ the requestor.
+
+ While there are some tricks that can provide partial simulations of
+ these types of function, DNS responses cannot be reliably conditioned
+ in this way.
+
+ These, and similar, issues of performance or content choices can, of
+ course, be thought of as not involving the DNS at all. For example,
+ the commonly-cited alternate approach of coupling these issues to
+ HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
+ connection first be opened to some "common" or "primary" host so that
+ preferences can be negotiated and then the client redirected or sent
+ alternate data. At least from the standpoint of improving
+ performance by accessing a "closer" location, both initially and
+ thereafter, this approach sacrifices the desired result before the
+ client initiates any action. It could even be argued that some of
+ the characteristics of common content negotiation approaches are
+ workarounds for the non-optimal use of the DNS in web URLs.
+
+ o Many existing and proposed systems for "finding things on the
+ Internet" require a true search capability in which near matches
+ can be reported to the user (or to some user agent with an
+ appropriate rule-set) and to which queries may be ambiguous or
+ fuzzy. The DNS, by contrast, can accommodate only one set of
+ (quite rigid) matching rules. Proposals to permit different rules
+ in different localities (e.g., matching rules that are TLD- or
+ zone-specific) help to identify the problem. But they cannot be
+ applied directly to the DNS without either abandoning the desired
+ level of flexibility or isolating different parts of the Internet
+ from each other (or both). Fuzzy or ambiguous searches are
+ desirable for resolution of names that might have spelling
+ variations and for names that can be resolved into different sets
+ of glyphs depending on context. Especially when
+ internationalization is considered, variant name problems go
+ beyond simple differences in representation of a character or
+
+
+
+Klensin Informational [Page 10]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ ordering of a string. Instead, avoiding user astonishment and
+ confusion requires consideration of relationships such as
+ languages that can be written with different alphabets, Kanji-
+ Hiragana relationships, Simplified and Traditional Chinese, etc.
+ See [Seng] for a discussion and suggestions for addressing a
+ subset of these issues in the context of characters based on
+ Chinese ones. But that document essentially illustrates the
+ difficulty of providing the type of flexible matching that would
+ be anticipated by users; instead, it tries to protect against the
+ worst types of confusion (and opportunities for fraud).
+
+ o The historical DNS, and applications that make assumptions about
+ how it works, impose significant risk (or forces technical kludges
+ and consequent odd restrictions), when one considers adding
+ mechanisms for use with various multi-character-set and
+ multilingual "internationalization" systems. See the IAB's
+ discussion of some of these issues [RFC2825] for more information.
+
+ o In order to provide proper functionality to the Internet, the DNS
+ must have a single unique root (the IAB provides more discussion
+ of this issue [RFC2826]). There are many desires for local
+ treatment of names or character sets that cannot be accommodated
+ without either multiple roots (e.g., a separate root for
+ multilingual names, proposed at various times by MINC [MINC] and
+ others), or mechanisms that would have similar effects in terms of
+ Internet fragmentation and isolation.
+
+ o For some purposes, it is desirable to be able to search not only
+ an index entry (labels or fully-qualified names in the DNS case),
+ but their values or targets (DNS data). One might, for example,
+ want to locate all of the host (and virtual host) names which
+ cause mail to be directed to a given server via MX records. The
+ DNS does not support this capability (see the discussion in
+ [IQUERY]) and it can be simulated only by extracting all of the
+ relevant records (perhaps by zone transfer if the source permits
+ doing so, but that permission is becoming less frequently
+ available) and then searching a file built from those records.
+
+ o Finally, as additional types of personal or identifying
+ information are added to the DNS, issues arise with protection of
+ that information. There are increasing calls to make different
+ information available based on the credentials and authorization
+ of the source of the inquiry. As with information keyed to site
+ locations or proximity (as discussed above), the DNS protocols
+ make providing these differentiated services quite difficult if
+ not impossible.
+
+
+
+
+
+Klensin Informational [Page 11]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ In each of these cases, it is, or might be, possible to devise ways
+ to trick the DNS system into supporting mechanisms that were not
+ designed into it. Several ingenious solutions have been proposed in
+ many of these areas already, and some have been deployed into the
+ marketplace with some success. But the price of each of these
+ changes is added complexity and, with it, added risk of unexpected
+ and destabilizing problems.
+
+ Several of the above problems are addressed well by a good directory
+ system (supported by the LDAP protocol or some protocol more
+ precisely suited to these specific applications) or searching
+ environment (such as common web search engines) although not by the
+ DNS. Given the difficulty of deploying new applications discussed
+ above, an important question is whether the tricks and kludges are
+ bad enough, or will become bad enough as usage grows, that new
+ solutions are needed and can be deployed.
+
+3. Searching, Directories, and the DNS
+
+3.1 Overview
+
+ The constraints of the DNS and the discussion above suggest the
+ introduction of an intermediate protocol mechanism, referred to below
+ as a "search layer" or "searchable system". The terms "directory"
+ and "directory system" are used interchangeably with "searchable
+ system" in this document, although the latter is far more precise.
+ Search layer proposals would use a two (or more) stage lookup, not
+ unlike several of the proposals for internationalized names in the
+ DNS (see section 4), but all operations but the final one would
+ involve searching other systems, rather than looking up identifiers
+ in the DNS itself. As explained below, this would permit relaxation
+ of several constraints, leading to a more capable and comprehensive
+ overall system.
+
+ Ultimately, many of the issues with domain names arise as the result
+ of efforts to use the DNS as a directory. While, at the time this
+ document was written, sufficient pressure or demand had not occurred
+ to justify a change, it was already quite clear that, as a directory
+ system, the DNS is a good deal less than ideal. This document
+ suggests that there actually is a requirement for a directory system,
+ and that the right solution to a searchable system requirement is a
+ searchable system, not a series of DNS patches, kludges, or
+ workarounds.
+
+
+
+
+
+
+
+
+Klensin Informational [Page 12]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ The following points illustrate particular aspects of this
+ conclusion.
+
+ o A directory system would not require imposition of particular
+ length limits on names.
+
+ o A directory system could permit explicit association of
+ attributes, e.g., language and country, with a name, without
+ having to utilize trick encodings to incorporate that information
+ in DNS labels (or creating artificial hierarchy for doing so).
+
+ o There is considerable experience (albeit not much of it very
+ successful) in doing fuzzy and "sonex" (similar-sounding) matching
+ in directory systems. Moreover, it is plausible to think about
+ different matching rules for different areas and sets of names so
+ that these can be adapted to local cultural requirements.
+ Specifically, it might be possible to have a single form of a name
+ in a directory, but to have great flexibility about what queries
+ matched that name (and even have different variations in different
+ areas). Of course, the more flexibility that a system provides,
+ the greater the possibility of real or imagined trademark
+ conflicts. But the opportunity would exist to design a directory
+ structure that dealt with those issues in an intelligent way,
+ while DNS constraints almost certainly make a general and
+ equitable DNS-only solution impossible.
+
+ o If a directory system is used to translate to DNS names, and then
+ DNS names are looked up in the normal fashion, it may be possible
+ to relax several of the constraints that have been traditional
+ (and perhaps necessary) with the DNS. For example, reverse-
+ mapping of addresses to directory names may not be a requirement
+ even if mapping of addresses to DNS names continues to be, since
+ the DNS name(s) would (continue to) uniquely identify the host.
+
+ o Solutions to multilingual transcription problems that are common
+ in "normal life" (e.g., two-sided business cards to be sure that
+ recipients trying to contact a person can access romanized
+ spellings and numbers if the original language is not
+ comprehensible to them) can be easily handled in a directory
+ system by inserting both sets of entries.
+
+ o A directory system could be designed that would return, not a
+ single name, but a set of names paired with network-locational
+ information or other context-establishing attributes. This type
+ of information might be of considerable use in resolving the
+ "nearest (or best) server for a particular named resource"
+
+
+
+
+
+Klensin Informational [Page 13]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ problems that are a significant concern for organizations hosting
+ web and other sites that are accessed from a wide range of
+ locations and subnets.
+
+ o Names bound to countries and languages might help to manage
+ trademark realities, while, as discussed in section 1.3 above, use
+ of the DNS in trademark-significant contexts tends to require
+ worldwide "flattening" of the trademark system.
+
+ Many of these issues are a consequence of another property of the
+ DNS: names must be unique across the Internet. The need to have a
+ system of unique identifiers is fairly obvious (see [RFC2826]).
+ However, if that requirement were to be eliminated in a search or
+ directory system that was visible to users instead of the DNS, many
+ difficult problems -- of both an engineering and a policy nature --
+ would be likely to vanish.
+
+3.2 Some Details and Comments
+
+ Almost any internationalization proposal for names that are in, or
+ map into, the DNS will require changing DNS resolver API calls
+ ("gethostbyname" or equivalent), or adding some pre-resolution
+ preparation mechanism, in almost all Internet applications -- whether
+ to cause the API to take a different character set (no matter how it
+ is then mapped into the bits used in the DNS or another system), to
+ accept or return more arguments with qualifying or identifying
+ information, or otherwise. Once applications must be opened to make
+ such changes, it is a relatively small matter to switch from calling
+ into the DNS to calling a directory service and then the DNS (in many
+ situations, both actions could be accomplished in a single API call).
+
+ A directory approach can be consistent both with "flat" models and
+ multi-attribute ones. The DNS requires strict hierarchies, limiting
+ its ability to differentiate among names by their properties. By
+ contrast, modern directories can utilize independently-searched
+ attributes and other structured schema to provide flexibilities not
+ present in a strictly hierarchical system.
+
+ There is a strong historical argument for a single directory
+ structure (implying a need for mechanisms for registration,
+ delegation, etc.). But a single structure is not a strict
+ requirement, especially if in-depth case analysis and design work
+ leads to the conclusion that reverse-mapping to directory names is
+ not a requirement (see section 5). If a single structure is not
+ needed, then, unlike the DNS, there would be no requirement for a
+ global organization to authorize or delegate operation of portions of
+ the structure.
+
+
+
+
+Klensin Informational [Page 14]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ The "no single structure" concept could be taken further by moving
+ away from simple "names" in favor of, e.g., multiattribute,
+ multihierarchical, faceted systems in which most of the facets use
+ restricted vocabularies. (These terms are fairly standard in the
+ information retrieval and classification system literature, see,
+ e.g., [IS5127].) Such systems could be designed to avoid the need
+ for procedures to ensure uniqueness across, or even within, providers
+ and databases of the faceted entities for which the search is to be
+ performed. (See [DNS-Search] for further discussion.)
+
+ While the discussion above includes very general comments about
+ attributes, it appears that only a very small number of attributes
+ would be needed. The list would almost certainly include country and
+ language for internationalization purposes. It might require
+ "charset" if we cannot agree on a character set and encoding,
+ although there are strong arguments for simply using ISO 10646 (also
+ known as Unicode or "UCS" (for Universal Character Set) [UNICODE],
+ [IS10646] coding in interchange. Trademark issues might motivate
+ "commercial" and "non-commercial" (or other) attributes if they would
+ be helpful in bypassing trademark problems. And applications to
+ resource location, such as those contemplated for Uniform Resource
+ Identifiers (URIs) [RFC2396, RFC3305] or the Service Location
+ Protocol [RFC2608], might argue for a few other attributes (as
+ outlined above).
+
+4. Internationalization
+
+ Much of the thinking underlying this document was driven by
+ considerations of internationalizing the DNS or, more specifically,
+ providing access to the functions of the DNS from languages and
+ naming systems that cannot be accurately expressed in the traditional
+ DNS subset of ASCII. Much of the relevant work was done in the
+ IETF's "Internationalized Domain Names" Working Group (IDN-WG),
+ although this document also draws on extensive parallel discussions
+ in other forums. This section contains an evaluation of what was
+ learned as an "internationalized DNS" or "multilingual DNS" was
+ explored and suggests future steps based on that evaluation.
+
+ When the IDN-WG was initiated, it was obvious to several of the
+ participants that its first important task was an undocumented one:
+ to increase the understanding of the complexities of the problem
+ sufficiently that naive solutions could be rejected and people could
+ go to work on the harder problems. The IDN-WG clearly accomplished
+ that task. The beliefs that the problems were simple, and in the
+ corresponding simplistic approaches and their promises of quick and
+ painless deployment, effectively disappeared as the WG's efforts
+ matured.
+
+
+
+
+Klensin Informational [Page 15]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ Some of the lessons learned from increased understanding and the
+ dissipation of naive beliefs should be taken as cautions by the wider
+ community: the problems are not simple. Specifically, extracting
+ small elements for solution rather than looking at whole systems, may
+ result in obscuring the problems but not solving any problem that is
+ worth the trouble.
+
+4.1 ASCII Isn't Just Because of English
+
+ The hostname rules chosen in the mid-70s weren't just "ASCII because
+ English uses ASCII", although that was a starting point. We have
+ discovered that almost every other script (and even ASCII if we
+ permit the rest of the characters specified in the ISO 646
+ International Reference Version) is more complex than hostname-
+ restricted-ASCII (the "LDH" form, see section 1.1). And ASCII isn't
+ sufficient to completely represent English -- there are several words
+ in the language that are correctly spelled only with characters or
+ diacritical marks that do not appear in ASCII. With a broader
+ selection of scripts, in some examples, case mapping works from one
+ case to the other but is not reversible. In others, there are
+ conventions about alternate ways to represent characters (in the
+ language, not [only] in character coding) that work most of the time,
+ but not always. And there are issues in coding, with Unicode/10646
+ providing different ways to represent the same character
+ ("character", rather than "glyph", is used deliberately here). And,
+ in still others, there are questions as to whether two glyphs
+ "match", which may be a distance-function question, not one with a
+ binary answer. The IETF approach to these problems is to require
+ pre-matching canonicalization (see the "stringprep" discussion
+ below).
+
+ The IETF has resisted the temptations to either try to specify an
+ entirely new coded character set, or to pick and choose Unicode/10646
+ characters on a per-character basis rather than by using well-defined
+ blocks. While it may appear that a character set designed to meet
+ Internet-specific needs would be very attractive, the IETF has never
+ had the expertise, resources, and representation from critically-
+ important communities to actually take on that job. Perhaps more
+ important, a new effort might have chosen to make some of the many
+ complex tradeoffs differently than the Unicode committee did,
+ producing a code with somewhat different characteristics. But there
+ is no evidence that doing so would produce a code with fewer problems
+ and side-effects. It is much more likely that making tradeoffs
+ differently would simply result in a different set of problems, which
+ would be equally or more difficult.
+
+
+
+
+
+
+Klensin Informational [Page 16]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+4.2 The "ASCII Encoding" Approaches
+
+ While the DNS can handle arbitrary binary strings without known
+ internal problems (see [RFC2181]), some restrictions are imposed by
+ the requirement that text be interpreted in a case-independent way
+ ([RFC1034], [RFC1035]). More important, most internet applications
+ assume the hostname-restricted "LDH" syntax that is specified in the
+ host table RFCs and as "prudent" in RFC 1035. If those assumptions
+ are not met, many conforming implementations of those applications
+ may exhibit behavior that would surprise implementors and users. To
+ avoid these potential problems, IETF internationalization work has
+ focused on "ASCII-Compatible Encodings" (ACE). These encodings
+ preserve the LDH conventions in the DNS itself. Implementations of
+ applications that have not been upgraded utilize the encoded forms,
+ while newer ones can be written to recognize the special codings and
+ map them into non-ASCII characters. These approaches are, however,
+ not problem-free even if human interface issues are ignored. Among
+ other issues, they rely on what is ultimately a heuristic to
+ determine whether a DNS label is to be considered as an
+ internationalized name (i.e., encoded Unicode) or interpreted as an
+ actual LDH name in its own right. And, while all determinations of
+ whether a particular query matches a stored object are traditionally
+ made by DNS servers, the ACE systems, when combined with the
+ complexities of international scripts and names, require that much of
+ the matching work be separated into a separate, client-side,
+ canonicalization or "preparation" process before the DNS matching
+ mechanisms are invoked [STRINGPREP].
+
+4.3 "Stringprep" and Its Complexities
+
+ As outlined above, the model for avoiding problems associated with
+ putting non-ASCII names in the DNS and elsewhere evolved into the
+ principle that strings are to be placed into the DNS only after being
+ passed through a string preparation function that eliminates or
+ rejects spurious character codes, maps some characters onto others,
+ performs some sequence canonicalization, and generally creates forms
+ that can be accurately compared. The impact of this process on
+ hostname-restricted ASCII (i.e., "LDH") strings is trivial and
+ essentially adds only overhead. For other scripts, the impact is, of
+ necessity, quite significant.
+
+ Although the general notion underlying stringprep is simple, the many
+ details are quite subtle and the associated tradeoffs are complex. A
+ design team worked on it for months, with considerable effort placed
+ into clarifying and fine-tuning the protocol and tables. Despite
+ general agreement that the IETF would avoid getting into the business
+ of defining character sets, character codings, and the associated
+ conventions, the group several times considered and rejected special
+
+
+
+Klensin Informational [Page 17]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ treatment of code positions to more nearly match the distinctions
+ made by Unicode with user perceptions about similarities and
+ differences between characters. But there were intense temptations
+ (and pressures) to incorporate language-specific or country-specific
+ rules. Those temptations, even when resisted, were indicative of
+ parts of the ongoing controversy or of the basic unsuitability of the
+ DNS for fully internationalized names that are visible,
+ comprehensible, and predictable for end users.
+
+ There have also been controversies about how far one should go in
+ these processes of preparation and transformation and, ultimately,
+ about the validity of various analogies. For example, each of the
+ following operations has been claimed to be similar to case-mapping
+ in ASCII:
+
+ o stripping of vowels in Arabic or Hebrew
+
+ o matching of "look-alike" characters such as upper-case Alpha in
+ Greek and upper-case A in Roman-based alphabets
+
+ o matching of Traditional and Simplified Chinese characters that
+ represent the same words,
+
+ o matching of Serbo-Croatian words whether written in Roman-derived
+ or Cyrillic characters
+
+ A decision to support any of these operations would have implications
+ for other scripts or languages and would increase the overall
+ complexity of the process. For example, unless language-specific
+ information is somehow available, performing matching between
+ Traditional and Simplified Chinese has impacts on Japanese and Korean
+ uses of the same "traditional" characters (e.g., it would not be
+ appropriate to map Kanji into Simplified Chinese).
+
+ Even were the IDN-WG's other work to have been abandoned completely
+ or if it were to fail in the marketplace, the stringprep and nameprep
+ work will continue to be extremely useful, both in identifying issues
+ and problem code points and in providing a reasonable set of basic
+ rules. Where problems remain, they are arguably not with nameprep,
+ but with the DNS-imposed requirement that its results, as with all
+ other parts of the matching and comparison process, yield a binary
+ "match or no match" answer, rather than, e.g., a value on a
+ similarity scale that can be evaluated by the user or by user-driven
+ heuristic functions.
+
+
+
+
+
+
+
+Klensin Informational [Page 18]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+4.4 The Unicode Stability Problem
+
+ ISO 10646 basically defines only code points, and not rules for using
+ or comparing the characters. This is part of a long-standing
+ tradition with the work of what is now ISO/IEC JTC1/SC2: they have
+ performed code point assignments and have typically treated the ways
+ in which characters are used as beyond their scope. Consequently,
+ they have not dealt effectively with the broader range of
+ internationalization issues. By contrast, the Unicode Technical
+ Committee (UTC) has defined, in annexes and technical reports (see,
+ e.g., [UTR15]), some additional rules for canonicalization and
+ comparison. Many of those rules and conventions have been factored
+ into the "stringprep" and "nameprep" work, but it is not
+ straightforward to make or define them in a fashion that is
+ sufficiently precise and permanent to be relied on by the DNS.
+
+ Perhaps more important, the discussions leading to nameprep also
+ identified several areas in which the UTC definitions are inadequate,
+ at least without additional information, to make matching precise and
+ unambiguous. In some of these cases, the Unicode Standard permits
+ several alternate approaches, none of which are an exact and obvious
+ match to DNS needs. That has left these sensitive choices up to
+ IETF, which lacks sufficient in-depth expertise, much less any
+ mechanism for deciding to optimize one language at the expense of
+ another.
+
+ For example, it is tempting to define some rules on the basis of
+ membership in particular scripts, or for punctuation characters, but
+ there is no precise definition of what characters belong to which
+ script or which ones are, or are not, punctuation. The existence of
+ these areas of vagueness raises two issues: whether trying to do
+ precise matching at the character set level is actually possible
+ (addressed below) and whether driving toward more precision could
+ create issues that cause instability in the implementation and
+ resolution models for the DNS.
+
+ The Unicode definition also evolves. Version 3.2 appeared shortly
+ after work on this document was initiated. It added some characters
+ and functionality and included a few minor incompatible code point
+ changes. IETF has secured an agreement about constraints on future
+ changes, but it remains to be seen how that agreement will work out
+ in practice. The prognosis actually appears poor at this stage,
+ since UTC chose to ballot a recent possible change which should have
+ been prohibited by the agreement (the outcome of the ballot is not
+ relevant, only that the ballot was issued rather than having the
+ result be a foregone conclusion). However, some members of the
+ community consider some of the changes between Unicode 3.0 and 3.1
+ and between 3.1 and 3.2, as well as this recent ballot, to be
+
+
+
+Klensin Informational [Page 19]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ evidence of instability and that these instabilities are better
+ handled in a system that can be more flexible about handling of
+ characters, scripts, and ancillary information than the DNS.
+
+ In addition, because the systems implications of internationalization
+ are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of
+ those issues to its SC22/WG20 (the Internationalization working group
+ within the subcommittee that deals with programming languages,
+ systems, and environments). WG20 has historically dealt with
+ internationalization issues thoughtfully and in depth, but its status
+ has several times been in doubt in recent years. However, assignment
+ of these matters to WG20 increases the risk of eventual ISO
+ internationalization standards that specify different behavior than
+ the UTC specifications.
+
+4.5 Audiences, End Users, and the User Interface Problem
+
+ Part of what has "caused" the DNS internationalization problem, as
+ well as the DNS trademark problem and several others, is that we have
+ stopped thinking about "identifiers for objects" -- which normal
+ people are not expected to see -- and started thinking about "names"
+ -- strings that are expected not only to be readable, but to have
+ linguistically-sensible and culturally-dependent meaning to non-
+ specialist users.
+
+ Within the IETF, the IDN-WG, and sometimes other groups, avoided
+ addressing the implications of that transition by taking "outside our
+ scope -- someone else's problem" approaches or by suggesting that
+ people will just become accustomed to whatever conventions are
+ adopted. The realities of user and vendor behavior suggest that
+ these approaches will not serve the Internet community well in the
+ long term:
+
+ o If we want to make it a problem in a different part of the user
+ interface structure, we need to figure out where it goes in order
+ to have proof of concept of our solution. Unlike vendors whose
+ sole [business] model is the selling or registering of names, the
+ IETF must produce solutions that actually work, in the
+ applications context as seen by the end user.
+
+ o The principle that "they will get used to our conventions and
+ adapt" is fine if we are writing rules for programming languages
+ or an API. But the conventions under discussion are not part of a
+ semi-mathematical system, they are deeply ingrained in culture.
+ No matter how often an English-speaking American is told that the
+ Internet requires that the correct spelling of "colour" be used,
+ he or she isn't going to be convinced. Getting a French-speaker in
+ Lyon to use exactly the same lexical conventions as a French-
+
+
+
+Klensin Informational [Page 20]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ speaker in Quebec in order to accommodate the decisions of the
+ IETF or of a registrar or registry is just not likely. "Montreal"
+ is either a misspelling or an anglicization of a similar word with
+ an acute accent mark over the "e" (i.e., using the Unicode
+ character U+00E9 or one of its equivalents). But global agreement
+ on a rule that will determine whether the two forms should match
+ -- and that won't astonish end users and speakers of one language
+ or the other -- is as unlikely as agreement on whether
+ "misspelling" or "anglicization" is the greater travesty.
+
+ More generally, it is not clear that the outcome of any conceivable
+ nameprep-like process is going to be good enough for practical,
+ user-level, use. In the use of human languages by humans, there are
+ many cases in which things that do not match are nonetheless
+ interpreted as matching. The Norwegian/Danish character that appears
+ in U+00F8 (visually, a lower case 'o' overstruck with a forward
+ slash) and the "o-umlaut" German character that appears in U+00F6
+ (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly
+ different and no matching program should yield an "equal" comparison.
+ But they are more similar to each other than either of them is to,
+ e.g., "e". Humans are able to mentally make the correction in
+ context, and do so easily, and they can be surprised if computers
+ cannot do so. Worse, there is a Swedish character whose appearance
+ is identical to the German o-umlaut, and which shares code point
+ U+00F6, but that, if the languages are known and the sounds of the
+ letters or meanings of words including the character are considered,
+ actually should match the Norwegian/Danish use of U+00F8.
+
+ This text uses examples in Roman scripts because it is being written
+ in English and those examples are relatively easy to render. But one
+ of the important lessons of the discussions about domain name
+ internationalization in recent years is that problems similar to
+ those described above exist in almost every language and script.
+ Each one has its idiosyncrasies, and each set of idiosyncracies is
+ tied to common usage and cultural issues that are very familiar in
+ the relevant group, and often deeply held as cultural values. As
+ long as a schoolchild in the US can get a bad grade on a spelling
+ test for using a perfectly valid British spelling, or one in France
+ or Germany can get a poor grade for leaving off a diacritical mark,
+ there are issues with the relevant language. Similarly, if children
+ in Egypt or Israel are taught that it is acceptable to write a word
+ with or without vowels or stress marks, but that, if those marks are
+ included, they must be the correct ones, or a user in Korea is
+ potentially offended or astonished by out-of-order sequences of Jamo,
+ systems based on character-at-a-time processing and simplistic
+ matching, with no contextual information, are not going to satisfy
+ user needs.
+
+
+
+
+Klensin Informational [Page 21]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ Users are demanding solutions that deal with language and culture.
+ Systems of identifier symbol-strings that serve specialists or
+ computers are, at best, a solution to a rather different (and, at the
+ time this document was written, somewhat ill-defined), problem. The
+ recent efforts have made it ever more clear that, if we ignore the
+ distinction between the user requirements and narrowly-defined
+ identifiers, we are solving an insufficient problem. And,
+ conversely, the approaches that have been proposed to approximate
+ solutions to the user requirement may be far more complex than simple
+ identifiers require.
+
+4.6 Business Cards and Other Natural Uses of Natural Languages
+
+ Over the last few centuries, local conventions have been established
+ in various parts of the world for dealing with multilingual
+ situations. It may be helpful to examine some of these. For
+ example, if one visits a country where the language is different from
+ ones own, business cards are often printed on two sides, one side in
+ each language. The conventions are not completely consistent and the
+ technique assumes that recipients will be tolerant. Translations of
+ names or places are attempted in some situations and transliterations
+ in others. Since it is widely understood that exact translations or
+ transliterations are often not possible, people typically smile at
+ errors, appreciate the effort, and move on.
+
+ The DNS situation differs from these practices in at least two ways.
+ Since a global solution is required, the business card would need a
+ number of sides approximating the number of languages in the world,
+ which is probably impossible without violating laws of physics. More
+ important, the opportunities for tolerance don't exist: the DNS
+ requires a exact match or the lookup fails.
+
+4.7 ASCII Encodings and the Roman Keyboard Assumption
+
+ Part of the argument for ACE-based solutions is that they provide an
+ escape for multilingual environments when applications have not been
+ upgraded. When an older application encounters an ACE-based name,
+ the assumption is that the (admittedly ugly) ASCII-coded string will
+ be displayed and can be typed in. This argument is reasonable from
+ the standpoint of mixtures of Roman-based alphabets, but may not be
+ relevant if user-level systems and devices are involved that do not
+ support the entry of Roman-based characters or which cannot
+ conveniently render such characters. Such systems are few in the
+ world today, but the number can reasonably be expected to rise as the
+ Internet is increasingly used by populations whose primary concern is
+ with local issues, local information, and local languages. It is,
+
+
+
+
+
+Klensin Informational [Page 22]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ for example, fairly easy to imagine populations who use Arabic or
+ Thai scripts and who do not have routine access to scripts or input
+ devices based on Roman-derived alphabets.
+
+4.8 Intra-DNS Approaches for "Multilingual Names"
+
+ It appears, from the cases above and others, that none of the intra-
+ DNS-based solutions for "multilingual names" are workable. They rest
+ on too many assumptions that do not appear to be feasible -- that
+ people will adapt deeply-entrenched language habits to conventions
+ laid down to make the lives of computers easy; that we can make
+ "freeze it now, no need for changes in these areas" decisions about
+ Unicode and nameprep; that ACE will smooth over applications
+ problems, even in environments without the ability to key or render
+ Roman-based glyphs (or where user experience is such that such glyphs
+ cannot easily be distinguished from each other); that the Unicode
+ Consortium will never decide to repair an error in a way that creates
+ a risk of DNS incompatibility; that we can either deploy EDNS
+ [RFC2671] or that long names are not really important; that Japanese
+ and Chinese computer users (and others) will either give up their
+ local or IS 2022-based character coding solutions (for which addition
+ of a large fraction of a million new code points to Unicode is almost
+ certainly a necessary, but probably not sufficient, condition) or
+ build leakproof and completely accurate boundary conversion
+ mechanisms; that out of band or contextual information will always be
+ sufficient for the "map glyph onto script" problem; and so on. In
+ each case, it is likely that about 80% or 90% of cases will work
+ satisfactorily, but it is unlikely that such partial solutions will
+ be good enough. For example, suppose someone can spell her name 90%
+ correctly, or a company name is matched correctly 80% of the time but
+ the other 20% of attempts identify a competitor: are either likely to
+ be considered adequate?
+
+5. Search-based Systems: The Key Controversies
+
+ For many years, a common response to requirements to locate people or
+ resources on the Internet has been to invoke the term "directory".
+ While an in-depth analysis of the reasons would require a separate
+ document, the history of failure of these invocations has given
+ "directory" efforts a bad reputation. The effort proposed here is
+ different from those predecessors for several reasons, perhaps the
+ most important of which is that it focuses on a fairly-well-
+ understood set of problems and needs, rather than on finding uses for
+ a particular technology.
+
+ As suggested in some of the text above, it is an open question as to
+ whether the needs of the community would be best served by a single
+ (even if functionally, and perhaps administratively, distributed)
+
+
+
+Klensin Informational [Page 23]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ directory with universal applicability, a single directory that
+ supports locally-tailored search (and, most important, matching)
+ functions, or multiple, locally-determined, directories. Each has
+ its attractions. Any but the first would essentially prevent
+ reverse-mapping (determination of the user-visible name of the host
+ or resource from target information such as an address or DNS name).
+ But reverse mapping has become less useful over the years --at least
+ to users -- as more and more names have been associated with many
+ host addresses and as CIDR [CIDR] has proven problematic for mapping
+ smaller address blocks to meaningful names.
+
+ Locally-tailored searches and mappings would permit national
+ variations on interpretation of which strings matched which other
+ ones, an arrangement that is especially important when different
+ localities apply different rules to, e.g., matching of characters
+ with and without diacriticals. But, of course, this implies that a
+ URL may evaluate properly or not depending on either settings on a
+ client machine or the network connectivity of the user. That is not,
+ in general, a desirable situation, since it implies that users could
+ not, in the general case, share URLs (or other host references) and
+ that a particular user might not be able to carry references from one
+ host or location to another.
+
+ And, of course, completely separate directories would permit
+ translation and transliteration functions to be embedded in the
+ directory, giving much of the Internet a different appearance
+ depending on which directory was chosen. The attractions of this are
+ obvious, but, unless things were very carefully designed to preserve
+ uniqueness and precise identities at the right points (which may or
+ may not be possible), such a system would have many of the
+ difficulties associated with multiple DNS roots.
+
+ Finally, a system of separate directories and databases, if coupled
+ with removal of the DNS-imposed requirement for unique names, would
+ largely eliminate the need for a single worldwide authority to manage
+ the top of the naming hierarchy.
+
+6. Security Considerations
+
+ The set of proposals implied by this document suggests an interesting
+ set of security issues (i.e., nothing important is ever easy). A
+ directory system used for locating network resources would presumably
+ need to be as carefully protected against unauthorized changes as the
+ DNS itself. There also might be new opportunities for problems in an
+ arrangement involving two or more (sub)layers, especially if such a
+ system were designed without central authority or uniqueness of
+ names. It is uncertain how much greater those risks would be as
+ compared to a DNS lookup sequence that involved looking up one name,
+
+
+
+Klensin Informational [Page 24]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ getting back information, and then doing additional lookups
+ potentially in different subtrees. That multistage lookup will often
+ be the case with, e.g., NAPTR records [RFC 2915] unless additional
+ restrictions are imposed. But additional steps, systems, and
+ databases almost certainly involve some additional risks of
+ compromise.
+
+7. References
+
+7.1 Normative References
+
+ None
+
+7.2 Explanatory and Informative References
+
+ [Albitz] Any of the editions of Albitz, P. and C. Liu, DNS and
+ BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
+
+ [ASCII] American National Standards Institute (formerly United
+ States of America Standards Institute), X3.4, 1968,
+ "USA Code for Information Interchange". ANSI X3.4-1968
+ has been replaced by newer versions with slight
+ modifications, but the 1968 version remains definitive
+ for the Internet. Some time after ASCII was first
+ formulated as a standard, ISO adopted international
+ standard 646, which uses ASCII as a base. IS 646
+ actually contained two code tables: an "International
+ Reference Version" (often referenced as ISO 646-IRV)
+ which was essentially identical to the ASCII of the
+ time, and a "Basic Version" (ISO 646-BV), which
+ designates a number of character positions for
+ national use.
+
+ [CIDR] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
+ Inter-Domain Routing (CIDR): an Address Assignment and
+ Aggregation Strategy", RFC 1519, September 1993.
+
+ Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
+ ADDR.ARPA delegation", RFC 2317, March 1998.
+
+ [COM-SIZE] Size information supplied by Verisign Global Registry
+ Services (the zone administrator, or "registry
+ operator", for COM, see [REGISTRAR], below) to ICANN,
+ third quarter 2002.
+
+ [DNS-Search] Klensin, J., "A Search-based access model for the
+ DNS", Work in Progress.
+
+
+
+
+Klensin Informational [Page 25]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ [FINGER] Zimmerman, D., "The Finger User Information Protocol",
+ RFC 1288, December 1991.
+
+ Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
+ December 1977.
+
+ [IAB-OPES] Floyd, S. and L. Daigle, "IAB Architectural and Policy
+ Considerations for Open Pluggable Edge Services", RFC
+ 3238, January 2002.
+
+ [IQUERY] Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+ 2002.
+
+ [IS646] ISO/IEC 646:1991 Information technology -- ISO 7-bit
+ coded character set for information interchange
+
+ [IS10646] ISO/IEC 10646-1:2000 Information technology --
+ Universal Multiple-Octet Coded Character Set (UCS) --
+ Part 1: Architecture and Basic Multilingual Plane and
+ ISO/IEC 10646-2:2001 Information technology --
+ Universal Multiple-Octet Coded Character Set (UCS) --
+ Part 2: Supplementary Planes
+
+ [MINC] The Multilingual Internet Names Consortium,
+ http://www.minc.org/ has been an early advocate for
+ the importance of expansion of DNS names to
+ accommodate non-ASCII characters. Some of their
+ specific proposals, while helping people to understand
+ the problems better, were not compatible with the
+ design of the DNS.
+
+ [NAPTR] Mealling, M. and R. Daniel, "The Naming Authority
+ Pointer (NAPTR) DNS Resource Record", RFC 2915,
+ September 2000.
+
+ Mealling, M., "Dynamic Delegation Discovery System
+ (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
+ October 2002.
+
+ Mealling, M., "Dynamic Delegation Discovery System
+ (DDDS) Part Two: The Algorithm", RFC 3402, October
+ 2002.
+
+ Mealling, M., "Dynamic Delegation Discovery System
+ (DDDS) Part Three: The Domain Name System (DNS)
+ Database", RFC 3403, October 2002.
+
+
+
+
+
+Klensin Informational [Page 26]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ [REGISTRAR] In an early stage of the process that created the
+ Internet Corporation for Assigned Names and Numbers
+ (ICANN), a "Green Paper" was released by the US
+ Government. That paper introduced new terminology
+ and some concepts not needed by traditional DNS
+ operations. The term "registry" was applied to the
+ actual operator and database holder of a domain
+ (typically at the top level, since the Green Paper was
+ little concerned with anything else), while
+ organizations that marketed names and made them
+ available to "registrants" were known as "registrars".
+ In the classic DNS model, the function of "zone
+ administrator" encompassed both registry and registrar
+ roles, although that model did not anticipate a
+ commercial market in names.
+
+ [RFC625] Kudlick, M. and E. Feinler, "On-line hostnames
+ service", RFC 625, March 1974.
+
+ [RFC734] Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
+
+ [RFC811] Harrenstien, K., White, V. and E. Feinler, "Hostnames
+ Server", RFC 811, March 1982.
+
+ [RFC819] Su, Z. and J. Postel, "Domain naming convention for
+ Internet user applications", RFC 819, August 1982.
+
+ [RFC830] Su, Z., "Distributed system for Internet name
+ service", RFC 830, October 1982.
+
+ [RFC882] Mockapetris, P., "Domain names: Concepts and
+ facilities", RFC 882, November 1983.
+
+ [RFC883] Mockapetris, P., "Domain names: Implementation
+ specification", RFC 883, November 1983.
+
+ [RFC952] Harrenstien, K, Stahl, M. and E. Feinler, "DoD
+ Internet host table specification", RFC 952, October
+ 1985.
+
+ [RFC953] Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
+ SERVER", RFC 953, October 1985.
+
+ [RFC1034] Mockapetris, P., "Domain names, Concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+
+
+
+
+
+Klensin Informational [Page 27]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [RFC1591] Postel, J., "Domain Name System Structure and
+ Delegation", RFC 1591, March 1994.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2295] Holtman, K. and A. Mutz, "Transparent Content
+ Negotiation in HTTP", RFC 2295, March 1998
+
+ [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter,
+ "Uniform Resource Identifiers (URI): Generic Syntax",
+ RFC 2396, August 1998.
+
+ [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day,
+ "Service Location Protocol, Version 2", RFC 2608, June
+ 1999.
+
+ [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+ 2671, August 1999.
+
+ [RFC2825] IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N,
+ Domain Names, and the Other Internet protocols", RFC
+ 2825, May 2000.
+
+ [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root",
+ RFC 2826, May 2000.
+
+ [RFC2972] Popp, N., Mealling, M., Masinter, L. and K. Sollins,
+ "Context and Goals for Common Name Resolution", RFC
+ 2972, October 2000.
+
+ [RFC3305] Mealling, M. and R. Denenberg, Eds., "Report from the
+ Joint W3C/IETF URI Planning Interest Group: Uniform
+ Resource Identifiers (URIs), URLs, and Uniform
+ Resource Names (URNs): Clarifications and
+ Recommendations", RFC 3305, August 2002.
+
+ [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
+ Guidelines and Philosophy", RFC 3439, December 2002.
+
+ [Seng] Seng, J., et al., Eds., "Internationalized Domain
+ Names: Registration and Administration Guideline for
+ Chinese, Japanese, and Korean", Work in Progress.
+
+
+
+
+
+Klensin Informational [Page 28]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings (stringprep)", RFC 3454,
+ December 2002.
+
+ The particular profile used for placing
+ internationalized strings in the DNS is called
+ "nameprep", described in Hoffman, P. and M. Blanchet,
+ "Nameprep: A Stringprep Profile for Internationalized
+ Domain Names", Work in Progress.
+
+ [TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
+ Specification", STD 8, RFC 854, May 1983.
+
+ Postel, J. and J. Reynolds, "Telnet Option
+ Specifications", STD 8, RFC 855, May 1983.
+
+ [UNICODE] The Unicode Consortium, The Unicode Standard, Version
+ 3.0, Addison-Wesley: Reading, MA, 2000. Update to
+ version 3.1, 2001. Update to version 3.2, 2002.
+
+ [UTR15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+ Unicode Normalization Forms", Unicode Consortium,
+ March 2002. An integral part of The Unicode Standard,
+ Version 3.1.1. Available at
+ (http://www.unicode.org/reports/tr15/tr15-21.html).
+
+ [WHOIS] Harrenstien, K, Stahl, M. and E. Feinler,
+ "NICNAME/WHOIS", RFC 954, October 1985.
+
+ [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
+ Information Lookup Service, Whois++", RFC 1834, August
+ 1995.
+
+ Weider, C., Fullton, J. and S. Spero, "Architecture of
+ the Whois++ Index Service", RFC 1913, February 1996.
+
+ Williamson, S., Kosters, M., Blacka, D., Singh, J. and
+ K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
+ RFC 2167, June 1997;
+
+ Daigle, L. and P. Faltstrom, "The
+ application/whoispp-query Content-Type", RFC 2957,
+ October 2000.
+
+ Daigle, L. and P. Falstrom, "The application/whoispp-
+ response Content-type", RFC 2958, October 2000.
+
+
+
+
+
+Klensin Informational [Page 29]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+ [X29] International Telecommuncations Union, "Recommendation
+ X.29: Procedures for the exchange of control
+ information and user data between a Packet
+ Assembly/Disassembly (PAD) facility and a packet mode
+ DTE or another PAD", December 1997.
+
+8. Acknowledgements
+
+ Many people have contributed to versions of this document or the
+ thinking that went into it. The author would particularly like to
+ thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt
+ Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie,
+ Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific
+ suggestions and/or challenging the assumptions and presentation of
+ earlier versions and suggesting ways to improve them.
+
+9. Author's Address
+
+ John C. Klensin
+ 1770 Massachusetts Ave, #322
+ Cambridge, MA 02140
+
+ EMail: klensin+srch@jck.com
+
+ A mailing list has been initiated for discussion of the topics
+ discussed in this document, and closely-related issues, at
+ ietf-irnss@lists.elistx.com. See http://lists.elistx.com/archives/
+ for subscription and archival information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin Informational [Page 30]
+\f
+RFC 3467 Role of the Domain Name System (DNS) February 2003
+
+
+10. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin Informational [Page 31]
+\f
projects / thirdparty / bind9.git / commitdiff
