aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDoug Barton <dougb@FreeBSD.org>2009-05-30 23:48:09 +0000
committerDoug Barton <dougb@FreeBSD.org>2009-05-30 23:48:09 +0000
commitde7e1db19da108c11098aad4d4237554b83e1c90 (patch)
treed52b2f78bc31caaa0b60dafa6a47a47014bcc0ff
parent6b52fc0a792f3f68a9bec5413913e371e9e6227f (diff)
downloadsrc-de7e1db19da108c11098aad4d4237554b83e1c90.tar.gz
src-de7e1db19da108c11098aad4d4237554b83e1c90.zip
In preparation for the BIND 9.6.1rc1 import, remove these two directories.
We do not install these files so there is little use to keeping them in the tree, and the drafts directory in particular is the source of a lot of churn for each new version.
Notes
Notes: svn path=/vendor/bind9/dist/; revision=193135
-rw-r--r--doc/draft/draft-baba-dnsext-acl-reqts-01.txt336
-rw-r--r--doc/draft/draft-daigle-napstr-04.txt1232
-rw-r--r--doc/draft/draft-danisch-dns-rr-smtp-03.txt1960
-rw-r--r--doc/draft/draft-dnsext-opcode-discover-02.txt241
-rw-r--r--doc/draft/draft-durand-dnsop-dynreverse-00.txt240
-rw-r--r--doc/draft/draft-ietf-dnsext-2929bis-01.txt928
-rw-r--r--doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt393
-rw-r--r--doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt674
-rw-r--r--doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt1397
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt442
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt616
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt784
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt616
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt896
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt392
-rw-r--r--doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt839
-rw-r--r--doc/draft/draft-ietf-dnsext-ds-sha256-05.txt504
-rw-r--r--doc/draft/draft-ietf-dnsext-ecc-key-07.txt928
-rw-r--r--doc/draft/draft-ietf-dnsext-interop3597-02.txt334
-rw-r--r--doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt560
-rw-r--r--doc/draft/draft-ietf-dnsext-mdns-43.txt1740
-rw-r--r--doc/draft/draft-ietf-dnsext-nsec3-04.txt2352
-rw-r--r--doc/draft/draft-ietf-dnsext-nsid-01.txt840
-rw-r--r--doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt464
-rw-r--r--doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt840
-rw-r--r--doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt580
-rw-r--r--doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt755
-rw-r--r--doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt1292
-rw-r--r--doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt1501
-rw-r--r--doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt730
-rw-r--r--doc/draft/draft-ietf-dnsext-tsig-sha-06.txt522
-rw-r--r--doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt1063
-rw-r--r--doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt1232
-rw-r--r--doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt2016
-rw-r--r--doc/draft/draft-ietf-dnsop-inaddr-required-07.txt396
-rw-r--r--doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt1848
-rw-r--r--doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt1682
-rw-r--r--doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt300
-rw-r--r--doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt389
-rw-r--r--doc/draft/draft-ietf-dnsop-respsize-02.txt480
-rw-r--r--doc/draft/draft-ietf-dnsop-serverid-06.txt618
-rw-r--r--doc/draft/draft-ietf-enum-e164-gstn-np-05.txt1588
-rw-r--r--doc/draft/draft-ietf-ipv6-node-requirements-08.txt1200
-rw-r--r--doc/draft/draft-ietf-secsh-dns-05.txt614
-rw-r--r--doc/draft/draft-ihren-dnsext-threshold-validation-00.txt519
-rw-r--r--doc/draft/draft-kato-dnsop-local-zones-00.txt295
-rw-r--r--doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt1830
-rw-r--r--doc/draft/update46
-rw-r--r--doc/rfc/index119
-rw-r--r--doc/rfc/rfc1032.txt781
-rw-r--r--doc/rfc/rfc1033.txt1229
-rw-r--r--doc/rfc/rfc1034.txt3077
-rw-r--r--doc/rfc/rfc1035.txt3077
-rw-r--r--doc/rfc/rfc1101.txt787
-rw-r--r--doc/rfc/rfc1122.txt6844
-rw-r--r--doc/rfc/rfc1123.txt5782
-rw-r--r--doc/rfc/rfc1183.txt619
-rw-r--r--doc/rfc/rfc1348.txt227
-rw-r--r--doc/rfc/rfc1535.txt283
-rw-r--r--doc/rfc/rfc1536.txt675
-rw-r--r--doc/rfc/rfc1537.txt507
-rw-r--r--doc/rfc/rfc1591.txt395
-rw-r--r--doc/rfc/rfc1611.txt1683
-rw-r--r--doc/rfc/rfc1612.txt1795
-rw-r--r--doc/rfc/rfc1706.txt563
-rw-r--r--doc/rfc/rfc1712.txt395
-rw-r--r--doc/rfc/rfc1750.txt1683
-rw-r--r--doc/rfc/rfc1876.txt1011
-rw-r--r--doc/rfc/rfc1886.txt268
-rw-r--r--doc/rfc/rfc1982.txt394
-rw-r--r--doc/rfc/rfc1995.txt451
-rw-r--r--doc/rfc/rfc1996.txt395
-rw-r--r--doc/rfc/rfc2052.txt563
-rw-r--r--doc/rfc/rfc2104.txt620
-rw-r--r--doc/rfc/rfc2119.txt171
-rw-r--r--doc/rfc/rfc2133.txt1795
-rw-r--r--doc/rfc/rfc2136.txt1460
-rw-r--r--doc/rfc/rfc2137.txt619
-rw-r--r--doc/rfc/rfc2163.txt1459
-rw-r--r--doc/rfc/rfc2168.txt1123
-rw-r--r--doc/rfc/rfc2181.txt842
-rw-r--r--doc/rfc/rfc2230.txt619
-rw-r--r--doc/rfc/rfc2308.txt1067
-rw-r--r--doc/rfc/rfc2317.txt563
-rw-r--r--doc/rfc/rfc2373.txt1459
-rw-r--r--doc/rfc/rfc2374.txt675
-rw-r--r--doc/rfc/rfc2375.txt451
-rw-r--r--doc/rfc/rfc2418.txt1459
-rw-r--r--doc/rfc/rfc2535.txt2635
-rw-r--r--doc/rfc/rfc2536.txt339
-rw-r--r--doc/rfc/rfc2537.txt339
-rw-r--r--doc/rfc/rfc2538.txt563
-rw-r--r--doc/rfc/rfc2539.txt395
-rw-r--r--doc/rfc/rfc2540.txt339
-rw-r--r--doc/rfc/rfc2541.txt395
-rw-r--r--doc/rfc/rfc2553.txt2299
-rw-r--r--doc/rfc/rfc2671.txt395
-rw-r--r--doc/rfc/rfc2672.txt507
-rw-r--r--doc/rfc/rfc2673.txt395
-rw-r--r--doc/rfc/rfc2782.txt675
-rw-r--r--doc/rfc/rfc2825.txt395
-rw-r--r--doc/rfc/rfc2826.txt339
-rw-r--r--doc/rfc/rfc2845.txt843
-rw-r--r--doc/rfc/rfc2874.txt1123
-rw-r--r--doc/rfc/rfc2915.txt1011
-rw-r--r--doc/rfc/rfc2929.txt675
-rw-r--r--doc/rfc/rfc2930.txt899
-rw-r--r--doc/rfc/rfc2931.txt563
-rw-r--r--doc/rfc/rfc3007.txt507
-rw-r--r--doc/rfc/rfc3008.txt395
-rw-r--r--doc/rfc/rfc3071.txt563
-rw-r--r--doc/rfc/rfc3090.txt619
-rw-r--r--doc/rfc/rfc3110.txt395
-rw-r--r--doc/rfc/rfc3123.txt451
-rw-r--r--doc/rfc/rfc3152.txt227
-rw-r--r--doc/rfc/rfc3197.txt283
-rw-r--r--doc/rfc/rfc3225.txt339
-rw-r--r--doc/rfc/rfc3226.txt339
-rw-r--r--doc/rfc/rfc3258.txt619
-rw-r--r--doc/rfc/rfc3363.txt339
-rw-r--r--doc/rfc/rfc3364.txt619
-rw-r--r--doc/rfc/rfc3425.txt283
-rw-r--r--doc/rfc/rfc3445.txt563
-rw-r--r--doc/rfc/rfc3467.txt1739
-rw-r--r--doc/rfc/rfc3490.txt1235
-rw-r--r--doc/rfc/rfc3491.txt395
-rw-r--r--doc/rfc/rfc3492.txt1963
-rw-r--r--doc/rfc/rfc3493.txt2187
-rw-r--r--doc/rfc/rfc3513.txt1459
-rw-r--r--doc/rfc/rfc3596.txt451
-rw-r--r--doc/rfc/rfc3597.txt451
-rw-r--r--doc/rfc/rfc3645.txt1459
-rw-r--r--doc/rfc/rfc3655.txt451
-rw-r--r--doc/rfc/rfc3658.txt1067
-rw-r--r--doc/rfc/rfc3757.txt451
-rw-r--r--doc/rfc/rfc3833.txt899
-rw-r--r--doc/rfc/rfc3845.txt395
-rw-r--r--doc/rfc/rfc3901.txt283
-rw-r--r--doc/rfc/rfc4025.txt675
-rw-r--r--doc/rfc/rfc4033.txt1179
-rw-r--r--doc/rfc/rfc4034.txt1627
-rw-r--r--doc/rfc/rfc4035.txt2971
-rw-r--r--doc/rfc/rfc4074.txt339
-rw-r--r--doc/rfc/rfc4159.txt171
-rw-r--r--doc/rfc/rfc4193.txt899
-rw-r--r--doc/rfc/rfc4255.txt507
-rw-r--r--doc/rfc/rfc4343.txt563
-rw-r--r--doc/rfc/rfc4367.txt955
-rw-r--r--doc/rfc/rfc4398.txt955
-rw-r--r--doc/rfc/rfc4408.txt2691
-rw-r--r--doc/rfc/rfc4431.txt227
-rw-r--r--doc/rfc/rfc4470.txt451
-rw-r--r--doc/rfc/rfc4634.txt6051
-rw-r--r--doc/rfc/rfc4641.txt1963
-rw-r--r--doc/rfc/rfc4648.txt1011
-rw-r--r--doc/rfc/rfc4701.txt675
-rw-r--r--doc/rfc/rfc5155.txt2915
-rw-r--r--doc/rfc/rfc952.txt340
158 files changed, 0 insertions, 153744 deletions
diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
deleted file mode 100644
index 1030e5782ef9..000000000000
--- a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-
-Internet-Draft T. Baba
-Expires: March 11, 2004 NTT Data
- September 11, 2003
-
-
- Requirements for Access Control in Domain Name Systems
- draft-baba-dnsext-acl-reqts-01.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Distribution of this memo is unlimited.
-
- This Internet-Draft will expire on March 11, 2004.
-
-Abstract
-
- This document describes the requirements for access control
- mechanisms in the Domain Name System (DNS), which authenticate
- clients and then allow or deny access to resource records in the
- zone according to the access control list (ACL).
-
-1. Introduction
-
- The Domain Name System (DNS) is a hierarchical, distributed, highly
- available database used for bi-directional mapping between domain
- names and IP addresses, for email routing, and for other information
- [RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined
- to authenticate the data in DNS and provide key distribution services
- using SIG, KEY, and NXT resource records (RRs) [RFC2535].
-
-
-
-Baba Expires March 11, 2004 [Page 1]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
- At the 28th IETF Meeting in Houston in 1993, DNS security design team
- started a discussion about DNSSEC and agreed to accept the assumption
- that "DNS data is public". Accordingly, confidentiality for queries
- or responses is not provided by DNSSEC, nor are any sort of access
- control lists or other means to differentiate inquirers. However,
- about ten years has passed, access control in DNS has been more
- important than before. Currently, new RRs are proposed to add new
- functionality to DNS such as ENUM [RFC2916]. Such new RRs may
- contain private information. Thus, DNS access control will be
- needed.
-
- Furthermore, with DNS access control mechanism, access from
- unauthorized clients can be blocked when they perform DNS name
- resolution. Thus, for example, Denial of Service (DoS) attacks
- against a server used by a closed user group can be prevented using
- this mechanism if IP address of the server is not revealed by other
- sources.
-
- This document describes the requirements for access control
- mechanisms in DNS.
-
-2. Terminology
-
- AC-aware client
- This is the client that understands the DNS access control
- extensions. This client may be an end host which has a stub
- resolver, or a cashing/recursive name server which has a
- full-service resolver.
-
- AC-aware server
- This is the authoritative name server that understands the DNS
- access control extensions.
-
- ACE
- An Access Control Entry. This is the smallest unit of access
- control policy. It grants or denies a given set of access
- rights to a set of principals. An ACE is a component of an ACL,
- which is associated with a resource.
-
- ACL
- An Access Control List. This contains all of the access control
- policies which are directly associated with a particular
- resource. These policies are expressed as ACEs.
-
- Client
- A program or host which issues DNS requests and accepts its
- responses. A client may be an end host or a cashing/recursive name
- server.
-
-
-
-Baba Expires March 11, 2004 [Page 2]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
- RRset
- All resource records (RRs) having the same NAME, CLASS and TYPE
- are called a Resource Record Set (RRset).
-
-3. Requirements
-
- This section describes the requirements for access control in DNS.
-
-3.1 Authentication
-
-3.1.1 Client Authentication Mechanism
-
- The AC-aware server must identify AC-aware clients based on IP
- address and/or domain name (user ID or host name), and must
- authenticate them using strong authentication mechanism such as
- digital signature or message authentication code (MAC).
-
- SIG(0) RR [RFC2931] contains a domain name associated with sender's
- public key in its signer's name field, and TSIG RR [RFC2845] also
- contains a domain name associated with shared secret key in its key
- name field. Each of these domain names can be a host name or a user
- name, and can be used as a sender's identifier for access control.
- Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
- message authentication. These mechanisms can be used to authenticate
- AC-aware clients.
-
- Server authentication may be also provided.
-
-3.1.2 End-to-End Authentication
-
- In current DNS model, caching/recursive name servers are deployed
- between end hosts and authoritative name servers. Although
- authoritative servers can authenticate caching/recursive name servers
- using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
- For end-to-end authentication, the mechanism for an end host to
- discover the target authoritative name server and directly access to
- it bypassing caching/recursive name servers is needed. For example,
- an end host can get the IP addresses of the authoritative name
- servers by retrieving NS RRs for the zone via local caching/recursive
- name server.
-
- In many enterprise networks, however, there are firewalls that block
- all DNS packets other than those going to/from the particular
- caching/recursive servers. To deal with this problem, one can
- implement packet forwarding function on the caching/recursive servers
- and enable end-to-end authentication via the caching/recursive
- servers.
-
-
-
-
-Baba Expires March 11, 2004 [Page 3]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
-3.1.3 Authentication Key Retrieval
-
- Keys which are used to authenticate clients should be able to be
- automatically retrieved. The KEY RR is used to store a public key
- for a zone or a host that is associated with a domain name. SIG(0)
- RR uses a public key in KEY RR for verifying the signature. If
- DNSSEC is available, the KEY RR would be protected by the SIG RR.
- KEY RR or newly defined RR can be used to automatic key retrieval.
-
-3.2 Confidentiality
-
-3.2.1 Data Encryption
-
- To avoid disclosure to eavesdroppers, the response containing the
- RRsets which are restricted to access from particular users should be
- encrypted. Currently, no encryption mechanism is specified in DNS.
- Therefore, new RRs should be defined for DNS message encryption.
- Instead, IPsec [RFC2401] can be used to provide confidentiality if
- name server and resolver can set up security associations dynamically
- using IPsec API [IPSECAPI] when encryption is required.
-
- In case encryption is applied, entire DNS message including DNS
- header should be encrypted to hide information including error code.
-
- Query encryption may be also provided for hiding query information.
-
-3.2.2 Key Exchange
-
- If DNS message encryption is provided, automatic key exchange
- mechanism should be also provided. [RFC2930] specifies a TKEY RR
- that can be used to establish and delete shared secret keys used by
- TSIG between a client and a server. With minor extensions, TKEY can
- be used to establish shared secret keys used for message encryption.
-
-3.2.3 Caching
-
- The RRset that is restricted to access from particular users must not
- be cached. To avoid caching, the TTL of the RR that is restricted to
- access should be set to zero during transit.
-
-3.3 Access Control
-
-3.3.1 Granularity of Access Control
-
- Control of access on a per-user/per-host granularity must be
- supported. Control of access to individual RRset (not just the
- entire zone) must be also supported. However, SOA, NS, SIG, NXT,
- KEY, and DS RRs must be publicly accessible to avoid unexpected
- results.
-
-
-Baba Expires March 11, 2004 [Page 4]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
-3.3.2 ACL Representation
-
- Access Control List (ACL) format must be standardized so that both
- the primary and secondary AC-aware servers can recognize the same
- ACL. Although ACL may appear in or out of zone data, it must be
- transferred to the secondary AC-aware server with associated zone
- data. It is a good idea to contain ACL in zone data, because ACL can
- be transferred with zone data using existing zone transfer mechanisms
- automatically. However, ACL must not be published except for
- authorized secondary master servers.
-
- In zone data master files, ACL should be specified using TXT RRs or
- newly defined RRs. In each access control entry (ACE), authorized
- entities (host or user) must be described using domain name (host
- name, user name, or IP address in in-addr.arpa/ip6.arpa format).
- There may be other access control attributes such as access time.
-
- It must be possible to create publicly readable entries, which may be
- read even by unauthenticated clients.
-
-3.3.3 Zone/ACL Transfer
-
- As mentioned above, ACL should be transferred from a primary AC-aware
- server to a secondary AC-aware server with associated zone data.
- When an AC-aware server receives a zone/ACL transfer request, the
- server must authenticate the client, and should encrypt the zone
- data and associated ACL during transfer.
-
-3.4 Backward/co-existence Compatibility
-
- Any new protocols to be defined for access control in DNS must be
- backward compatible with existing DNS protocol. AC-aware servers
- must be able to process normal DNS query without authentication, and
- must respond if retrieving RRset is publicly accessible.
-
- Modifications to root/gTLD/ccTLD name servers are not allowed.
-
-4. Security Considerations
-
- This document discusses the requirements for access control
- mechanisms in DNS.
-
-5. Acknowledgements
-
- This work is funded by the Telecommunications Advancement
- Organization of Japan (TAO).
-
- The author would like to thank the members of the NTT DATA network
- security team for their important contribution to this work.
-
-
-Baba Expires March 11, 2004 [Page 5]
-
-Internet-Draft DNS Access Control Requirements September 2003
-
-
-6. References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
- September 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
- RFC 2930, September 2000.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
- [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
- draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
- Progress.
-
-
-Author's Address
-
- Tatsuya Baba
- NTT Data Corporation
- Research and Development Headquarters
- Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
- Tokyo 104-0033, Japan
-
- Tel: +81 3 3523 8081
- Fax: +81 3 3523 8090
- Email: babatt@nttdata.co.jp
-
-
-
-
-
-
-
-
-Baba Expires March 11, 2004 [Page 6]
diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt
deleted file mode 100644
index fffa8a5f20b3..000000000000
--- a/doc/draft/draft-daigle-napstr-04.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-Network Working Group L. Daigle
-Internet-Draft A. Newton
-Expires: August 15, 2004 VeriSign, Inc.
- February 15, 2004
-
-
- Domain-based Application Service Location Using SRV RRs and the
- Dynamic Delegation Discovery Service (DDDS)
- draft-daigle-napstr-04.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 15, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This memo defines a generalized mechanism for application service
- naming that allows service location without relying on rigid domain
- naming conventions (so-called name hacks). The proposal defines a
- Dynamic Delegation Discovery System (DDDS) Application to map domain
- name, application service name, and application protocol to target
- server and port, dynamically.
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 1]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . 4
- 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . . 5
- 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . . . . 5
- 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . . . . 5
- 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . . . . 5
- 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . . . . 6
- 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . . . . 6
- 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.1 Guidelines for Application Protocol Developers . . . . . . . 7
- 3.1.1 Registration of application service and protocol tags . . . 7
- 3.1.2 Definition of conditions for retry/failure . . . . . . . . . 8
- 3.1.3 Server identification and handshake . . . . . . . . . . . . 8
- 3.2 Guidelines for Domain Administrators . . . . . . . . . . . . 8
- 3.3 Guidelines for Client Software Writers . . . . . . . . . . . 9
- 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . 9
- 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 4.2 Service Discovery within a Domain . . . . . . . . . . . . . 10
- 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
- 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
- 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 12
- 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . . 12
- 5. Motivation and Discussion . . . . . . . . . . . . . . . . . 14
- 5.1 So, why not just SRV records? . . . . . . . . . . . . . . . 15
- 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . . 15
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 16
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
- References . . . . . . . . . . . . . . . . . . . . . . . . . 17
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
- A. Application Service Location Application of DDDS . . . . . . 18
- A.1 Application Unique String . . . . . . . . . . . . . . . . . 18
- A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 18
- A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 18
- A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
- A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
- A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
- A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 20
- A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 20
- A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 20
- B. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . 20
- B.1 Finding the first (best) target . . . . . . . . . . . . . . 20
- B.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 21
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 2]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-1. Introduction
-
- This memo defines a generalized mechanism for application service
- naming that allows service location without relying on rigid domain
- naming conventions (so-called name hacks). The proposal defines a
- Dynamic Delegation Discovery System (DDDS -- see [6]) Application to
- map domain name, application service name, and application protocol
- to target server and port, dynamically.
-
- As discussed in Section 5, existing approaches to using DNS records
- to dynamically determining the current host for a given application
- service are limited in terms of the use cases supported. To address
- some of the limitations, this document defines a DDDS Application to
- map service+protocol+domain to specific server addresses using both
- NAPTR [7] and SRV ([5]) DNS resource records. This can be viewed as
- a more general version of the use of SRV and/or a very restricted
- application of the use of NAPTR resource records.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC2119 ([2]).
-
-2. Straightforward-NAPTR (S-NAPTR) Specification
-
- The precise details of the specification of this DDDS application are
- given in Appendix A. This section defines the usage of the DDDS
- application.
-
-2.1 Key Terms
-
- An "application service" is a generic term for some type of
- application, indpendent of the protocol that may be used to offer it.
- Each application service will be associated with an IANA-registered
- tag. For example, instant messaging is a type of application
- service, which can be implemented by many different application-layer
- protocols, and the tag "IM" (used as an illustration here) could be
- registered for it.
-
- An "application protocol" is used to implement the application
- service. These are also associated with IANA-registered tags. In
- the case where multiple transports are available for the application,
- separate tags should be defined for each transport.
-
- The intention is that the combination of application service and
- protocol tags should be specific enough that finding a known pair
- (e.g., "IM:ProtC") is sufficient for a client to identify a server
- with which it can communicate.
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 3]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- Some protocols support multiple application services. For example,
- LDAP is an application protocol, and can be found supporting various
- services (e.g., "whitepages", "directory enabled networking", etc).
-
-2.2 S-NAPTR DDDS Application Usage
-
- As outlined in Appendix A, NAPTR records are used to store
- application service+protocol information for a given domain.
- Following the DDDS standard, these records are looked up, and the
- rewrite rules (contained in the NAPTR records) are used to determine
- the successive DNS lookups, until a desirable target is found.
-
- For the rest of this section, refer to the set of NAPTR resource
- records for example.com shown in the figure below.
-
- example.com.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "WP:whois++" "" bunyip.example.
- IN NAPTR 100 20 "s" "WP:ldap" "" _ldap._tcp.myldap.example.com.
- IN NAPTR 200 10 "" "IM:protA" "" someisp.example.
- IN NAPTR 200 30 "a" "IM:protB" "" myprotB.example.com.
-
-
-2.2.1 Ordering and Preference
-
- A client retrieves all of the NAPTR records associated with the
- target domain name (example.com, above). These are to be sorted in
- terms of increasing ORDER, and increasing PREF within each ORDER.
-
-2.2.2 Matching and non-Matching NAPTR Records
-
- Starting with the first sorted NAPTR record, the client examines the
- SERVICE field to find a match. In the case of the S-NAPTR DDDS
- application, that means a SERVICE field that includes the tags for
- the desired application service and a supported application protocol.
-
- If more than one NAPTR record matches, they are processed in
- increasing sort order.
-
-2.2.3 Terminal and Non-Terminal NAPTR Records
-
- A NAPTR record with an empty FLAG field is "non-terminal". That is,
- more NAPTR RR lookups are to be performed. Thus, to process a NAPTR
- record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
- used as the target of the next DNS lookup -- for NAPTR RRs.
-
- In S-NAPTR, the only terminal flags are "S" and "A". These are
- called "terminal" NAPTR lookups because they denote the end of the
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 4]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- DDDS/NAPTR processing rules. In the case of an "S" flag, the
- REPLACEMENT field is used as the target of a DNS query for SRV RRs,
- and normal SRV processing is applied. In the case of an "A" flag, an
- address record is sought for the REPLACEMENT field target (and the
- default protocol port is assumed).
-
-2.2.4 S-NAPTR and Successive Resolution
-
- As shown in the example NAPTR RR set above, it is possible to have
- multiple possible targets for a single application service+protocol
- pair. These are to be pursued in order until a server is
- successfully contacted or all possible matching NAPTR records have
- been successively pursued to terminal lookups and servers contacted.
- That is, a client must backtrack and attempt other resolution paths
- in the case of failure.
-
- "Failure" is declared, and backtracking must be used when
-
- o the designated remote server (host and port) fail to provide
- appropriate security credentials for the *originating* domain
-
- o connection to the designated remote server otherwise fails -- the
- specifics terms of which are defined when an application protocol
- is registered
-
- o the S-NAPTR-designated DNS lookup fails to yield expected results
- -- e.g., no A RR for an "A" target, no SRV record for an "S"
- target, or no NAPTR record with appropriate application service
- and protocol for a NAPTR lookup. Except in the case of the very
- first NAPTR lookup, this last is a configuration error: the fact
- that example.com has a NAPTR record pointing to "bunyip.example"
- for the "WP:Whois++" service and protocol means the administrator
- of example.com believes that service exists. If bunyip.example
- has no "WP:Whois++" NAPTR record, the application client MUST
- backtrack and try the next available "WP:Whois++" option from
- example.com. As there is none, the whole resolution fails.
-
- An application client first queries for the NAPTR RRs for the domain
- of a named application service. The application client MUST select
- one protocol to choose The PREF field of the NAPTR RRs may be used by
- the domain administrator to The first DNS query is for the NAPTR RRs
- in the original target domain (example.com, above).
-
-2.2.5 Clients Supporting Multiple Protocols
-
- In the case of an application client that supports more than one
- protocol for a given application service, it MUST pursue S-NAPTR
- resolution completely for one protocol before trying another.j It MAY
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 5]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- choose which protocol to try first based on its own preference, or
- from the PREF ranking in the first set of NAPTR records (i.e., those
- for the target named domain). However, the chosen protocol MUST be
- listed in that first NAPTR RR set.
-
- That is, what the client MUST NOT do is start looking for one
- protocol, observe that a successive NAPTR RR set supports another of
- its preferred protocols, and continue the S-NAPTR resolution based on
- that protocol. For example, even if someisp.example offers the "IM"
- service with protocol "ProtB", there is no reason to believe it does
- so on behalf of example.com (since there is no such pointer in
- example.com's NAPTR RR set).
-
-3. Guidelines
-
-3.1 Guidelines for Application Protocol Developers
-
- The purpose of S-NAPTR is to provide application standards developers
- with a more powerful framework (than SRV RRs alone) for naming
- service targets, without requiring each application protocol (or
- service) standard to define a separate DDDS application.
-
- Note that this approach is intended specifically for use when it
- makes sense to associate services with particular domain names (e.g.,
- e-mail addresses, SIP addresses, etc). A non-goal is having all
- manner of label mapped into domain names in order to use this.
-
- Specifically not addressed in this document is how to select the
- domain for which the service+protocol is being sought. It is up to
- other conventions to define how that might be used (e.g., instant
- messaging standards can define what domain to use from IM URIs, how
- to step down from foobar.example.com to example.com, and so on, if
- that is applicable).
-
- Although this document proposes a DDDS application that does not use
- all the features of NAPTR resource records, it does not mean to imply
- that DNS resolvers should fail to implement all aspects of the NAPTR
- RR standard. A DDDS application is a client use convention.
-
- The rest of this section outlines the specific elements that protocol
- developers must determine and document in order to make use of S-
- NAPTR.
-
-3.1.1 Registration of application service and protocol tags
-
- Application protocol developers that wish to make use of S-NAPTR must
- make provision to register any relevant application service and
- application protocol tags, as described in Section 6.
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 6]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-3.1.2 Definition of conditions for retry/failure
-
- One other important aspect that must be defined is the expected
- behaviour for interacting with the servers that are reached via S-
- NAPTR. Specifically, under what circumstances should the client
- retry a target that was found via S-NAPTR? What should it consider a
- failure that causes it to return to the S-NAPTR process to determine
- the next serviceable target (a less preferred target)?
-
- For example, if the client gets a "connection refused" from a server,
- should it retry for some (protocol-dependent) period of time? Or,
- should it try the next-preferred target in the S-NAPTR chain of
- resolution? Should it only try the next-preferred target if it
- receives a protocol-specific permanent error message?
-
- The most important thing is to select one expected behaviour and
- document it as part of the use of S-NAPTR.
-
- As noted earlier, failure to provide appropriate credentials to
- identify the server as being authoritative for the original taret
- domain is always considered a failure condition.
-
-3.1.3 Server identification and handshake
-
- As noted in Section 7, use of the DNS for server location increases
- the importance of using protocol-specific handshakes to determine and
- confirm the identity of the server that is eventually reached.
-
- Therefore, application protocol developers using S-NAPTR should
- identify the mechanics of the expected identification handshake when
- the client connects to a server found through S-NAPTR.
-
-3.2 Guidelines for Domain Administrators
-
- Although S-NAPTR aims to provide a "straightforward" application of
- DDDS and use of NAPTR records, it is still possible to create very
- complex chains and dependencies with the NAPTR and SRV records.
-
- Therefore, domain administrators are called upon to use S-NAPTR with
- as much restraint as possible, while still achieving their service
- design goals.
-
- The complete set of NAPTR, SRV and A RRs that are "reachable" through
- the S-NAPTR process for a particular application service can be
- thought of as a "tree". Each NAPTR RR retrieved points to more NAPTR
- or SRV records; each SRV record points to several A record lookups.
- Even though a particular client can "prune" the tree to use only
- those records referring to application protocols supported by the
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 7]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- client, the tree could be quite deep, and retracing the tree to retry
- other targets can become expensive if the tree has many branches.
-
- Therefore,
-
- o Fewer branches is better: for both NAPTR and SRV records, provide
- different targets with varying preferences where appropriate
- (e.g., to provide backup services, etc), but don't look for
- reasons to provide more.
-
- o Shallower is better: avoid using NAPTR records to "rename"
- services within a zone. Use NAPTR records to identify services
- hosted elsewhere (i.e., where you cannot reasonably provide the
- SRV records in your own zone).
-
-
-3.3 Guidelines for Client Software Writers
-
- To properly understand DDDS/NAPTR, an implementor must read [6].
- However, the most important aspect to keep in mind is that, if one
- target fails to work for the application, it is expected that the
- application will continue through the S-NAPTR tree to try the (less
- preferred) alternatives.
-
-4. Illustrations
-
-4.1 Use Cases
-
- The basic intended use cases for which S-NAPTR has been developed
- are:
-
- o Service discovery within a domain. For example, this can be used
- to find the "authoritative" server for some type of service within
- a domain (see the specific example in Section 4.2).
-
- o Multiple protocols. This is increasingly common as new
- application services are defined. This includes the case of
- instant messaging (a service) which can be offered with multiple
- protocols (see Section 4.3).
-
- o Remote hosting. Each of the above use cases applies within the
- administration of a single domain. However, one domain operator
- may elect to engage another organization to provide an application
- service. See Section 4.4 for an example that cannot be served by
- SRV records alone.
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 8]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-4.2 Service Discovery within a Domain
-
- There are occasions when it is useful to be able to determine the
- "authoritative" server for a given application service within a
- domain. This is "discovery", because there is no a priori knowledge
- as to whether or where the service is offered; it is therefore
- important to determine the location and characteristics of the
- offered service.
-
- For example, there is growing discussion of having a generic
- mechanism for locating the keys or certificates associated with
- particular application (servers) operated in (or for) a particular
- domain. Here's a hypothetical case for storing application key or
- certificate data for a given domain. The premise is that some
- credentials registry (CredReg) service has been defined to be a leaf
- node service holding the keys/certs for the servers operated by (or
- for) the domain. Furthermore, it is assumed that more than one
- protocol is available to provide the service for a particular domain.
- This DDDS-based approach is used to find the CredReg server that
- holds the information.
-
- Thus, the set of NAPTR records for thinkingcat.example might look
- like this:
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" theserver.thinkingcat.example.
-
- Note that another domain, offering the same application service,
- might offer it using a different set of application protocols:
-
- anotherdomain.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" foo.anotherdomain.example.
-
-
-4.3 Multiple Protocols
-
- As it stands, there are several different protocols proposed for
- offering "instant message" services. Assuming that "IM" was
- registered as an application service, this DDDS application could be
- used to determine the available services for delivering to a target.
-
- Two particular features of instant messaging should be noted:
-
- 1. gatewaying is expected to bridge communications across protocols
-
- 2. instant messaging servers are likely to be operated out of a
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 9]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- different domain than the instant messaging address, and servers
- of different protocols may be offered by independent
- organizations
-
- For example, "thinkingcat.example" may support its own servers for
- the "ProtA" instant messaging protocol, but rely on outsourcing from
- "example.com" for "ProtC" and "ProtB" servers.
-
- Using this DDDS-based approach, thinkingcat.example can indicate a
- preference ranking for the different types of servers for the instant
- messaging service, and yet the out-sourcer can independently rank the
- preference and ordering of servers. This independence is not
- achievable through the use of SRV records alone.
-
- Thus, to find the IM services for thinkingcat.example, the NAPTR
- records for thinkingcat.example are retrieved:
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
- IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com.
- IN NAPTR 100 30 "s" "IM:ProtC" "" _ProtC._tcp.example.com.
-
- and then the administrators at example.com can manage the preference
- rankings of the servers they use to support the ProtB service:
-
- _ProtB._tcp.example.com.
- ;; Pref Weight Port Target
- IN SRV 10 0 10001 bigiron.example.com
- IN SRV 20 0 10001 backup.im.example.com
- IN SRV 30 0 10001 nuclearfallout.australia-isp.example
-
-
-4.4 Remote Hosting
-
- In the Instant Message hosting example in Section 4.3, the service
- owner (thinkingcat.example) had to host pointers to the hosting
- service's SRV records in the thinkingcat.example domain.
-
- A better way to approach this is to have one NAPTR RR in the
- thinkingcat.example domain pointing to all the hosted services, and
- the hosting domain has NAPTR records for each service to map them to
- whatever local hosts it chooses (and may change from time to time).
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 10]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
- IN NAPTR 100 20 "" "IM:ProtB:ProtC" "" thinkingcat.example.com.
-
-
- and then the administrators at example.com can break out the
- individual application protocols and manage the preference rankings
- of the servers they use to support the ProtB service (as before):
-
- thinkingcat.example.com.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtC" "" _ProtC._tcp.example.com.
- IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com.
-
-
-
- _ProtC._tcp.example.com.
- ;; Pref Weight Port Target
- IN SRV 10 0 10001 bigiron.example.com
- IN SRV 20 0 10001 backup.im.example.com
- IN SRV 30 0 10001 nuclearfallout.australia-isp.example
-
-
-4.5 Sets of NAPTR RRs
-
- Note that the above sections assumed that there was one service
- available (via S-NAPTR) per domain. Often, that will not be the
- case. Assuming thinkingcat.example had the CredReg service set up as
- described in Section 4.2 and the instant messaging service set up as
- described in Section 4.4, then a client querying for the NAPTR RR set
- from thinkingcat.com would get the following answer:
-
- thinkingcat.example.
- ;; order pref flags service regexp replacement
- IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example.
- IN NAPTR 100 20 "" "IM:ProtB:ProtC:" "" thinkingcat.example.com.
- IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.
-
- Sorting them by increasing "ORDER", the client would look through the
- SERVICE strings to determine if there was a NAPTR RR that matched the
- application service it was looking for, with an application protocol
- it could use. The first (lowest PREF) record that so matched is the
- one the client would use to continue.
-
-4.6 Sample sequence diagram
-
- Consider the example in Section 4.3. Visually, the sequence of steps
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 11]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- required for the client to reach the final server for a "ProtB"
- service for IM for the thinkingcat.example domain is as follows:
-
-
- Client NS for NS for
- thinkingcat.example example.com backup.im.example.com
- | | |
- 1 -------->| | |
- 2 <--------| | |
- 3 ------------------------------>| |
- 4 <------------------------------| |
- 5 ------------------------------>| |
- 6 <------------------------------| |
- 7 ------------------------------>| |
- 8 <------------------------------| |
- 9 ------------------------------------------------->|
- 10 <-------------------------------------------------|
- 11 ------------------------------------------------->|
- 12 <-------------------------------------------------|
- (...)
-
-
-
- 1. the name server (NS) for thinkingcat.example is reached with a
- request for all NAPTR records
-
- 2. the server responds with the NAPTR records shown in Section 4.3.
-
- 3. the second NAPTR record matches the desired criteria; that has an
- "s" flag and a replacement fields of "_ProtB._tcp.example.com".
- So, the client looks up SRV records for that target, ultimately
- making the request of the NS for example.com.
-
- 4. the response includes the SRV records listed in Section 4.3.
-
- 5. the client attempts to reach the server with the lowest PREF in
- the SRV list -- looking up the A record for the SRV record's
- target (bigiron.example.com).
-
- 6. the example.com NS responds with an error message -- no such
- machine!
-
- 7. the client attempts to reach the second server in the SRV list,
- and looks up the A record for backup.im.example.com
-
- 8. the client gets the A record with the IP address for
- backup.im.example.com from example.com's NS.
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 12]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- 9. the client connects to that IP address, on port 10001 (from the
- SRV record), using ProtB over tcp.
-
- 10. the server responds with an "OK" message.
-
- 11. the client uses ProtB to challenge that this server has
- credentials to operate the service for the original domain
- (thinkingcat.example)
-
- 12. the server responds, and the rest is IM.
-
-
-5. Motivation and Discussion
-
- Increasingly, application protocol standards are using domain names
- to identify server targets, and stipulating that clients should look
- up SRV resource records to determine the host and port providing the
- server. This enables a distinction between naming an application
- service target and actually hosting the server. It also increases
- flexibility in hosting the target service:
-
- o the server may be operated by a completely different organization
- without having to list the details of that organization's DNS
- setup (SRVs)
-
- o multiple instances can be set up (e.g., for load balancing or
- secondaries)
-
- o it can be moved from time to time without disrupting clients'
- access, etc.
-
- This is quite useful, but Section 5.1 outlines some of the
- limitations inherent in the approach.
-
- That is, while SRV records can be used to map from a specific service
- name and protocol for a specific domain to a specific server, SRV
- records are limited to one layer of indirection, and are focused on
- server administration rather than on application naming. And, while
- the DDDS specification and use of NAPTR allows multiple levels of
- redirection before locating the target server machine with an SRV
- record, this proposal requires only a subset of NAPTR strictly bound
- to domain names, without making use of the REGEXP field of NAPTR.
- These restrictions make the client's resolution process much more
- predictable and efficient than with some potential uses of NAPTR
- records. This is dubbed "S-NAPTR" -- a "S"traightforward use of
- NAPTR records.
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 13]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-5.1 So, why not just SRV records?
-
- An expected question at this point is: this is so similar in
- structure to SRV records, why are we doing this with DDDS/NAPTR?
-
- Limitations of SRV include:
-
- o SRV provides a single layer of indirection -- the outcome of an
- SRV lookup is a new domain name for which the A RR is to be found.
-
- o the purpose of SRV is focused on individual server administration,
- not application naming: as stated in [5] "The SRV RR allows
- administrators to use several servers for a single domain, to move
- services from host to host with little fuss, and to designate some
- hosts as primary servers for a service and others as backups."
-
- o target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
- "tcp") in a given domain. The definition of these terms implies
- specific things (e.g., that protocol should be one of UDP or TCP)
- without being precise. Restriction to UDP and TCP is insufficient
- for the uses described here.
-
- The basic answer is that SRV records provide mappings from protocol
- names to host and port. The use cases described herein require an
- additional layer -- from some service label to servers that may in
- fact be hosted within different administrative domains. We could
- tweak SRV to say that the next lookup could be something other than
- an address record, but that is more complex than is necessary for
- most applications of SRV.
-
-5.2 So, why not just NAPTR records?
-
- That's a trick question. NAPTR records cannot appear in the wild --
- see [6]. They must be part of a DDDS application.
-
- The purpose here is to define a single, common mechanism (the DDDS
- application) to use NAPTR when all that is desired is simple DNS-
- based location of services. This should be easy for applications to
- use -- some simple IANA registrations and it's done.
-
- Also, NAPTR has very powerful tools for expressing "rewrite" rules.
- That power (==complexity) makes some protocol designers and service
- administrators nervous. The concern is that it can translate into
- unintelligible, noodle-like rule sets that are difficult to test and
- administer.
-
- This proposed DDDS application specifically uses a subset of NAPTR's
- abilities. Only "replacement" expressions are allowed, not "regular
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 14]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- expressions".
-
-6. IANA Considerations
-
- This document calls for 2 IANA registries: one for application
- service tags, and one for application protocol tags.
-
- Application service and protocol tags should be defined in an RFC
- (unless the "x-" experimental form is used, in which case they are
- unregistered). There are no restrictions placed on the tags other
- than that they must conform with the syntax defined below (Appendix
- A.5). The IANA registries should list the tags and the RFC that
- defines their use.
-
-7. Security Considerations
-
- The security of this approach to application service location is only
- as good as the security of the DNS servers along the way. If any of
- them is compromised, bogus NAPTR and SRV records could be inserted to
- redirect clients to unintended destinations. This problem is hardly
- unique to S-NAPTR (or NAPTR in general).
-
- To protect against DNS-vectored attacks, applications should define
- some form of end-to-end authentication to ensure that the correct
- destination has been reached. Many application protocols such as
- HTTPS, BEEP, IMAP, etc... define the necessary handshake mechansims
- to accomplish this task.
-
- The basic mechanism works in the following way:
-
- 1. During some portion of the protocol handshake, the client sends
- to the server the original name of the desired destination (i.e.
- no transformations that may have resulted from NAPTR
- replacements, SRV targets, or CNAME changes). In certain cases
- where the application protocol does not have such a feature but
- TLS may be used, it is possible to use the "server_name" TLS
- extension.
-
- 2. The server sends back to the client a credential with the
- appropriate name. For X.509 certificates, the name would either
- be in the subjectDN or subjectAltName fields. For Kerberos, the
- name would be a service principle name.
-
- 3. Using the matching semantics defined by the application protocol,
- the client compares the name in the credential with the name sent
- to the server.
-
- 4. If the names match, there is reasonable assurance that the
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 15]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- correct end point has been reached.
-
- It is important to note that this document does not define either the
- handshake mechanism, the specific credenential naming fields, nor the
- name matching semantics. Definitions of S-NAPTR for particular
- application protocols MUST define these.
-
-8. Acknowledgements
-
- Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
- discussion and input that has (hopefully!) provoked clarifying
- revisions of this document.
-
-References
-
- [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
- Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [4] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
- [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- One: The Comprehensive DDDS", RFC 3401, October 2002.
-
- [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- Three: The Domain Name System (DNS) Database", RFC 3403, October
- 2002.
-
- [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
- Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
- 2002.
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 16]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-Authors' Addresses
-
- Leslie Daigle
- VeriSign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
-
-
- Andrew Newton
- VeriSign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- EMail: anewton@verisignlabs.com
-
-Appendix A. Application Service Location Application of DDDS
-
- This section defines the DDDS application, as described in [6].
-
-A.1 Application Unique String
-
- The Application Unique String is domain label for which an
- authoritative server for a particular service is sought.
-
-A.2 First Well Known Rule
-
- The "First Well Known Rule" is identity -- that is, the output of the
- rule is the Application Unique String, the domain label for which the
- authoritative server for a particular service is sought.
-
-A.3 Expected Output
-
- The expected output of this Application is the information necessary
- to connect to authoritative server(s) (host, port, protocol) for an
- application service within a given a given domain.
-
-A.4 Flags
-
- This DDDS Application uses only 2 of the Flags defined for the
- URI/URN Resolution Application ([8]): "S" and "A". No other Flags
- are valid.
-
- Both are for terminal lookups. This means that the Rule is the last
- one and that the flag determines what the next stage should be. The
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 17]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- "S" flag means that the output of this Rule is a domain label for
- which one or more SRV [5] records exist. "A" means that the output
- of the Rule is a domain name and should be used to lookup address
- records for that domain.
-
- Consistent with the DDDS algorithm, if the Flag string is empty the
- next lookup is for another NAPTR record (for the replacement target).
-
-A.5 Service Parameters
-
- Service Parameters for this Application take the form of a string of
- characters that follow this ABNF ([3]):
-
- service-parms = [ [app-service] *(":" app-protocol)]
- app-service = experimental-service / iana-registered-service
- app-protocol = experimental-protocol / iana-registered-protocol
- experimental-service = "x-" 1*30ALPHANUMSYM
- experimental-protocol = "x-" 1*30ALPHANUMSYM
- iana-registered-service = ALPHA *31ALPHANUMSYM
- iana-registered-protocol = ALPHA *31ALPHANUM
- ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
- DIGIT = %x30-39 ; 0-9
- SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
- ALPHANUMSYM = ALPHA / DIGIT / SYM
- ; The app-service and app-protocol tags are limited to 32
- ; characters and must start with an alphabetic character.
- ; The service-parms are considered case-insensitive.
-
- Thus, the Service Parameters may consist of an empty string, just an
- app-service, or an app-service with one or more app-protocol
- specifications separated by the ":" symbol.
-
- Note that this is similar to, but not the same as the syntax used in
- the URI DDDS application ([8]). The DDDS DNS database requires each
- DDDS application to define the syntax of allowable service strings.
- The syntax here is expanded to allow the characters that are valid in
- any URI scheme name (see [1]). Since "+" (the separator used in the
- RFC3404 service parameter string) is an allowed character for URI
- scheme names, ":" is chosen as the separator here.
-
-A.5.1 Application Services
-
- The "app-service" must be a registered service [this will be an IANA
- registry; this is not the IANA port registry, because we want to
- define services for which there is no single protocol, and we don't
- want to use up port space for nothing].
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 18]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-A.5.2 Application Protocols
-
- The protocol identifiers that are valid for the "app-protocol"
- production are any standard, registered protocols [IANA registry
- again -- is this the list of well known/registered ports?].
-
-A.6 Valid Rules
-
- Only substitution Rules are permitted for this application. That is,
- no regular expressions are allowed.
-
-A.7 Valid Databases
-
- At present only one DDDS Database is specified for this Application.
- [7] specifies a DDDS Database that uses the NAPTR DNS resource record
- to contain the rewrite rules. The Keys for this database are encoded
- as domain-names.
-
- The First Well Known Rule produces a domain name, and this is the Key
- that is used for the first lookup -- the NAPTR records for that
- domain are requested.
-
- DNS servers MAY interpret Flag values and use that information to
- include appropriate NAPTR, SRV or A records in the Additional
- Information portion of the DNS packet. Clients are encouraged to
- check for additional information but are not required to do so. See
- the Additional Information Processing section of [7] for more
- information on NAPTR records and the Additional Information section
- of a DNS response packet.
-
-Appendix B. Pseudo pseudocode for S-NAPTR
-
-B.1 Finding the first (best) target
-
- Assuming the client supports 1 protocol for a particular application
- service, the following pseudocode outlines the expected process to
- find the first (best) target for the client, using S-NAPTR.
-
-
- target = [initial domain]
- naptr-done = false
-
- while (not naptr-done)
- {
- NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
- [sort NAPTR-RRset by ORDER, and PREF within each ORDER]
- rr-done = false
- cur-rr = [first NAPTR RR]
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 19]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- while (not rr-done)
- if ([SERVICE field of cur-rr contains desired application
- service and application protocol])
- rr-done = true
- target= [REPLACEMENT target of NAPTR RR]
- else
- cur-rr = [next rr in list]
-
- if (not empty [FLAG in cur-rr])
- naptr-done = true
- }
-
- port = -1
-
- if ([FLAG in cur-rr is "S"])
- {
- SRV-RRset = [DNSlookup of SRV RRs for target]
- [sort SRV-RRset based on PREF]
- target = [target of first RR of SRV-RRset]
- port = [port in first RR of SRV-RRset]
- }
-
- ; now, whether it was an "S" or an "A" in the NAPTR, we
- ; have the target for an A record lookup
-
- host = [DNSlookup of target]
-
- return (host, port)
-
-
-
-B.2 Finding subsequent targets
-
- The pseudocode in Appendix B is crafted to find the first, most
- preferred, host-port pair for a particular application service an
- protocol. If, for any reason, that host-port pair did not work
- (connection refused, application-level error), the client is expected
- to try the next host-port in the S-NAPTR tree.
-
- The pseudocode above does not permit retries -- once complete, it
- sheds all context of where in the S-NAPTR tree it finished.
- Therefore, client software writers could
-
- o entwine the application-specific protocol with the DNS lookup and
- RRset processing described in the pseudocode and continue the S-
- NAPTR processing if the application code fails to connect to a
- located host-port pair;
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 20]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
- o use callbacks for the S-NAPTR processing;
-
- o use an S-NAPTR resolution routine that finds *all* valid servers
- for the required application service and protocol from the
- originating domain, and provides them in sorted order for the
- application to try in order.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 21]
-
-Internet-Draft draft-daigle-napstr-04 February 2004
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton Expires August 15, 2004 [Page 22]
-
diff --git a/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/doc/draft/draft-danisch-dns-rr-smtp-03.txt
deleted file mode 100644
index 4a01d91b9a8b..000000000000
--- a/doc/draft/draft-danisch-dns-rr-smtp-03.txt
+++ /dev/null
@@ -1,1960 +0,0 @@
-
-
-
-INTERNET-DRAFT Hadmut Danisch
-Category: Experimental Oct 2003
-Expires: Apr 1, 2004
-
- The RMX DNS RR and method for lightweight SMTP sender authorization
- draft-danisch-dns-rr-smtp-03.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-Abstract
-
- This memo introduces a new authorization scheme for SMTP e-mail
- transport. It is designed to be a simple and robust protection
- against e-mail fraud, spam and worms. It is based solely on
- organisational security mechanisms and does not require but still
- allow use of cryptography. This memo also focuses on security and
- privacy problems and requirements in context of spam defense. In
- contrast to prior versions of the draft a new RR type is not
- required anymore.
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 1]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- Table of Contents
-
-
-1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
-2. Problem and threat description . . . . . . . . . . . . . . . . . 4
- 2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4
- 2.1.1 Definition of sender forgery . . . . . . . . . . . 4
- 2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5
- 2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5
- 2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5
- 2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6
- 2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6
- 2.4. Shortcomings of cryptographical approaches . . . . . . . . 7
-3. A DNS based sender address verification . . . . . . . . . . . . 7
- 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.2. Envelope vs. header sender address . . . . . . . . . . . . 9
- 3.3. Domain part vs. full sender address . . . . . . . . . . . 9
-4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10
- 4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10
- 4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11
- 4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11
-5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11
- 5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11
- 5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12
- 5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13
- 5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13
- 5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14
- 5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14
- 5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15
- 5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15
- 5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16
-6. Optional and experimental entry types . . . . . . . . . . . . . 16
- 6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16
- 6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16
- 6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16
- 6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17
- 6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17
-7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 7.1. Alternative encoding as TXT records . . . . . . . . . . . 17
- 7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17
- 7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18
- 7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18
- 7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18
- 7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18
- 7.2.5 Encoding of unused and full query . . . . . . . . . 19
- 7.2.6 Additional Records . . . . . . . . . . . . . . . . 19
-8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19
-
-
-
-Hadmut Danisch Experimental [Page 2]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20
-10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20
- 10.1. Problem description . . . . . . . . . . . . . . . . . . . 20
- 10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21
- 10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21
-11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
- 11.1. Draft specific considerations . . . . . . . . . . . . . . 22
- 11.1.1 Authentication strength . . . . . . . . . . . . . 22
- 11.1.2 Where Authentication and Authorization end . . . . 22
- 11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23
- 11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25
- 11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25
- 11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25
- 11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26
- 11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26
- 11.2. General Considerations about spam defense . . . . . . . . 27
- 11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27
- 11.2.2 Content based Denial of Service attacks . . . . . 27
-12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28
- 12.1. Draft specific considerations . . . . . . . . . . . . . . 28
- 12.1.1 No content leaking . . . . . . . . . . . . . . . . 28
- 12.1.2 Message reception and sender domain . . . . . . . 28
- 12.1.3 Network structure . . . . . . . . . . . . . . . . 29
- 12.1.4 Owner information distribution . . . . . . . . . . 29
- 12.2. General Considerations about spam defense . . . . . . . . 29
- 12.2.1 Content leaking of content filters . . . . . . . . 29
- 12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30
-13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30
- 13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30
- 13.1.1 Compatibility with old mail receivers . . . . . . 30
- 13.1.2 Compatibility with old mail senders . . . . . . . 30
- 13.1.3 Compatibility with old DNS clients . . . . . . . . 30
- 13.1.4 Compatibility with old DNS servers . . . . . . . . 30
- 13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31
-14. General considerations about fighting spam . . . . . . . . . . 31
- 14.1. The economical problem . . . . . . . . . . . . . . . . . 31
- 14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32
- 14.3. The network structure problem . . . . . . . . . . . . . . 33
- 14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33
- 14.5. The identity problem . . . . . . . . . . . . . . . . . . 33
- 14.6. The multi-legislation problem . . . . . . . . . . . . . . 34
-Implementation and further Information . . . . . . . . . . . . . . . 34
-References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
-Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
-Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 3]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-1. General Issues
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
- this document are to be interpreted as described in RFC 2119 [1].
-
-2. Problem and threat description
-
-2.1. Mail sender forgery
-
- The amount of e-mails with forged sender addresses has dramatically
- increased. As a consequence, damages and annoyances caused by such
- e-mails increased as well. In the majority of examined e-mails the
- domain name of the envelope sender address was forged, and the e-
- mail was sent from an IP address which does not belong to a network
- used by the actual owner of the domain.
-
-2.1.1. Definition of sender forgery
-
- As discussions, comments to prior versions of this draft, and
- different approaches to stop forgery showed, different perceptions
- of "mail forgery" exist. For example, there are mechanisms to
- verify e-mail addresses for mailing lists, web servers, or to stop
- spam, which do send a message with a random number to the given
- address and expect the user to send a reply. Here, someone is
- considered to be allowed to use a particular e-mail address, if and
- only if he is able to receive informations sent to this address,
- and is able to reply to such a message. While this definition
- appears to be quite plausible and natural, it can't be used for a
- simple technical solution. Sending back a challenge and expecting a
- reply is simply too much overhead and time delay, and not every
- authorized sender is able or willing to reply (e.g. because he went
- offline or is not a human).
-
- Within the scope of this memo, sender forgery means that the
- initiator of an e-mail transfer (which is the original sender in
- contrast to relays) uses a sender address which he was not
- authorized to use. Being authorized to use an address means that
- the owner (administrator) of the internet domain has given
- permission, i.e. agrees with the use of the address by that
- particular sender. This memo will cover both the permission of the
- full e-mail address and the domain part only for simplicity.
-
- Within context of Internet and SMTP, the sender address usually
- occurs twice, once as the envelope sender address in SMTP, and once
- as the address given in the RFC822 mail header. While the following
- considerations apply to both addresses in principle, it is
- important to stress that both addresses have distinct semantics and
-
-
-
-Hadmut Danisch Experimental [Page 4]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- are not neccessarily the same. The envelope address identifies the
- initiator of the transport, while the header identifies the author
- of the message content. Since this memo deals with the message
- transport only and completely ignores the message content, the
- method should naturally be applied to the envelope sender address.
-
-2.1.2. Spam
-
- A common and well known problem is the dramatic increase of
- unsolicited e-mail, commonly called "spam". Again, the majority of
- examined e-mails had forged sender addresses. The abused domains
- were mainly those of common webmailers as hotmail or yahoo, or
- well-known companies.
-
- Unfortunately, there is no accurate definition of spam availabe
- yet, and neither are the concise technical criterions to filter or
- block spam with technical mechanisms. There are efforts to design
- content based filters, but these filters are expensive in
- calculation time (and sometimes money), and they do not reliably
- provide predictable results. Usually they give false positives
- and/or require user interaction. Content filters in general suffer
- from a design problem described later in this memo. Therefore,
- this proposal does not use the content based approach to block
- spam.
-
- As analysis of spam messages showed, most of spam messages were
- sent with forged envelope sender addresses. This has mainly three
- reasons. The first reason is, that spam senders usually do not
- want to be contacted by e-mail. The second reason is, that they do
- not want to be blacklisted easily. The third reason is, that spam
- is or is going to be unlawful in many countries, and the sender
- does not want to reveal his identity. Therefore, spam is considered
- to be a special case of sender forgery.
-
-2.1.3. E-Mail Worms
-
- Another example of sender forgery is the reproduction of e-mail
- worms. Most worms do choose random sender addresses, e.g. using
- the addresses found in mailboxes on the infected system. In most
- cases analyzed by the author, the e-mails sent by the reproduction
- process can also be categorized as forged, since the infected
- system would under normal circumstances not be authorized to send
- e-mails with such e-mail addresses. So forgery does not require a
- malicious human to be directly involved. This memo covers any kind
- of e-mail sender address forgery, included those generated by
- malicious software.
-
-2.1.4. E-Mail spoofing and fraud
-
-
-
-Hadmut Danisch Experimental [Page 5]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- Forging e-mail sender addresses for fraud or other kinds of
- deception ("human engineering") has also dramatically increased.
- There are many known cases where single or mass e-mails were sent
- with wrong sender addresses, pretending to come from service
- provider, software manufacturers etc., and asking the receiver to
- install any software or patches, or to reply with any confidential
- information. The Internet is becoming more and more a scene of
- crime, and so are it's services, including e-mail. It is obvious
- that crime based on e-mail is eased by the fact that SMTP allows
- arbitrary sender address spoofing.
-
-2.2. Indirect damage caused by forgery
-
- As observed by the author, mass mails and worms with forged sender
- addresses can cause a severe damage for the real owner of the
- abused sender addresses. If a sender A is sending an e-mail to the
- receiver B, pretending to be C by using a sender address of C's
- domain, then C has currently no chance to prevent this, since C's
- machines and software are not involved in any way in the delivery
- process between A and B. B will nevertheless send any error
- messages (virus/spam alert, "no such user", etc.) to C, erroneously
- assuming that the message was sent by C. The author found several
- cases where this flood of error messages caused a severe denial of
- service or a dramatic increase of costs, e.g. when C was
- downloading the e-mail through expensive or low bandwidth
- connections (e.g. modem or mobile phones), or where disk space was
- limited. The author examined mass mailings, where several tens or
- hundreds of thousands of messages were sent to several addresses
- around the world, where these messages caused only annoyance. But
- since several thousands of these addresses were invalid or didn't
- accept the message, the owner of the DNS domain which was abused by
- the spammer to forge sender addresses was flooded for several
- months with thousands of error messages, jamming the e-mail system
- and causing severe costs and damages.
-
- As a consequence, when A sends a message to B, pretending to be C,
- there must be any mechanism to allow C to inform B about the fact,
- that A is not authorized to use C as a sender address. This is what
- this memo is about.
-
-2.3. Technical problem analysis
-
- Why does e-mail forgery actually exist? Because of the lack of the
- Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
- authentication, authorisation, or verification. This protocol was
- designed at a time where security was not an issue. Efforts have
- been made to block forged e-mails by requiring the sender address
- domain part to be resolvable. This method provides protection from
-
-
-
-Hadmut Danisch Experimental [Page 6]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- e-mails with non-existing sender domains, and indeed, for some time
- it blocked most spam e-mails. However, since attackers and spam
- senders began to abuse existing domain names, this method was
- rendered ineffective.
-
-2.4. Shortcomings of cryptographical approaches
-
- At a first glance, the problem of sender address forgery might
- appear to be solvable with cryptographic methods such as challenge
- response authentications or digital signatures. A deeper analysis
- shows that only a small, closed user group could be covered with
- cryptographical methods. Any method used to stop spam forgery must
- be suitable to detect forgery not only for a small number of
- particular addresses, but for all addresses on the world. An
- attacker does not need to know the secrets belonging to a
- particular address. It is sufficient to be able to forge any
- address and thus to know any secret key. Since there are several
- hundreds of millions of users, there will always be a large amount
- of compromised keys, thus spoiling any common cryptographic method.
- Furthermore, cryptography has proven to be far too complicated and
- error prone to be commonly administered and reliably implemented.
- Many e-mail and DNS administrators do not have the knowledge
- required to deal with cryptographic mechanisms. Many legislations
- do not allow the general deployment of cryptography and a directory
- service with public keys. For these reasons, cryptography is
- applicable only to a small and closed group of users, but not to
- all participants of the e-mail service.
-
-3. A DNS based sender address verification
-
-3.1. Overview
-
- To gain improvement in e-mail authenticity while keeping as much
- SMTP compatibility as possible, a method is suggested which doesn't
- change SMTP at all.
-
- The idea is to store informations about how to verify who is
- authorized to transmit e-mails through SMTP with a particular
- sender address (either full address or - for simplicity - only the
- domain part of the address) in a directory service, which is
- currently the DNS. To be precise, the verification consists of two
- steps, the classical pair of authentication and authorization:
-
- The first step is the authentication. While several methods are
- possible to perform authentication (see below), the most important
- and robust method is the verification of the sender's IP address.
- This is done implicitely by TCP/IP and the TCP sequence number. The
- authenticated identity is the IP address. It has to be stressed
-
-
-
-Hadmut Danisch Experimental [Page 7]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- that this TCP/IP "authentication" is a weak authentication and
- vulnerable to several attacks. It is nevertheless sufficient for
- this purpose, especially for blocking spam. It doesn't take any
- implementation and it doesn't cost: It is already there, it is a
- functionality of TCP/IP. An incoming SMTP connection based on
- TCP/IP already carries the sender's IP address without any
- modification of SMTP. See below (section Entry types) for more
- details about authentication methods.
-
- The second step is the authorization. It is based on the identity
- given by the previous authentication step, e.g. the IP address of
- the originator of the incoming SMTP connection, and on the
- envelope sender address. The mechanism proposed in this memo
- answers the question "Is that particular sender (IP address,...)
- allowed to send with that sender address" by querying and
- processing informations stored in a directory service, which is
- DNS.
-
- When the sender has issued the "MAIL FROM:" SMTP command, the
- receiving mail transfer agent (MTA) can - and modern MTAs do -
- perform some authorization checks, e.g. run a local rule database
- or check whether the sender domain is resolvable.
-
- The suggested method is to let the DNS server for the sender domain
- provide informations about who - this means for example which IP
- address - is authorized to use an address or a domain as a part of
- it. After receiving the "MAIL FROM:" SMTP command, the receiving
- MTA can verify, whether e. g. the IP address of the sending MTA is
- authorized to send mails with this domain name. Therefore, a list
- of entries with authorized IP addresses or other informations is
- provided by the authoritative DNS server of that domain. The entry
- types are described in the subsequent chapters. Some of these
- methods are
-
- - An IPv4 or IPv6 network address and mask
- - A fully qualified domain name referring to an A record
- - A fully qualified domain name referring to an APL record
-
- RMX records of these types would look like this:
-
- somedomain.de. IN RMX ipv4:10.0.0.0/8
- rmxtest.de. IN RMX host:relay.provider.com
- danisch.de. IN RMX apl:relays.rackland.de
- relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
-
- where the machine with the example address 213.133.101.23 and the
- machines in the example subnet 1.2.3.0/24 are the only machines
- allowed to send e-mails with an envelope sender address of domain
-
-
-
-Hadmut Danisch Experimental [Page 8]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- danisch.de. Since the APL records do not necessarily belong to the
- same domain or zone table as the RMX records, this easily allows to
- refer to APL records defined by someone else, e.g. the internet
- access or server hosting provider, thus reducing administrative
- overhead to a minimum. In the example given above, the domain
- danisch.de and several other domains are hosted by the service
- provider Rackland. So if the relay structure of Rackland is
- modified, only the zone of rackland.de needs to be modified. The
- domain owners don't need to care about such details.
-
-3.2. Envelope vs. header sender address
-
- Questions were raised why the proposed mechanism is based on the
- envelope sender address, and not on the sender address given in the
- message header. Technically, both can be used. Actually, it makes
- sense to use the envelope address.
-
- In common, the header sender address identifies the author of the
- content, while the envelope sender tells who caused the
- transmission. The approach proposed in this memo is transmission
- based, not content based. We can not authorize the author of a
- message if we don't have contact with him, if the message does not
- already contain a signature. In contrast, the sending MTA is linked
- to an IP address which can be used for authentication. This
- mechanism might not be very strong, but it is available and
- sufficient to solve today's e-mail security problems.
-
- Some people argued that it is the header address and not the sender
- address, which is displayed in common mail readers (MUAs), and
- where the receiver believes the mail comes from. That's true, but
- it doesn't help. There are many cases where the header sender
- differs from the envelope sender for good reasons (see below in the
- consequences chapter for the discussion about relaying). Relaying,
- mailing lists etc. require to replace the sender address used for
- RMX. If this were the header address, the message header would have
- to be modified. This is undesirable.
-
-3.3. Domain part vs. full sender address
-
- Former versions of this draft were limited to the domain part of
- the sender address. The first reason is that it is common and MX-
- like, to lookup only the domain part of an e-mail address in DNS.
- The second reason is, that it was left to the private business of
- the domain administration to handle details of user verification.
- The idea was that the domain administration takes care to verify
- the left part of an e-mail address with an arbitrary method of
- their individual taste. RMX was originally designed to ignore the
- left part of the address and to expect the domain administration to
-
-
-
-Hadmut Danisch Experimental [Page 9]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- take over responsibility for enforcing their policy. If, e.g., a
- spam message arrived and passed the RMX mechanism, it is known to
- be authorized by the domain administration and they can be blamed,
- no matter what is on the left side of the sender address - it's
- their private problem what happens on the left side of the @. By
- far the most of the comments to prior versions of this draft agreed
- with that. A few comments asked for a finer granularity.
-
- And indeed, there is no technical reason against a finer
- granularity. All it takes is a mapping from a given envelope
- sender address to a DNS name, and the RMX lookup for that
- particular e-mail address could be done instead of a lookup for the
- domain part only. However, to my knowledge, most domain
- administrators would not like to provide an RMX entry for every
- single e-mail address. In many cases, this would also overload DNS
- servers.
-
- It is to be discussed how to cover both views. One method could be
- to query the full address, and if no RMX records were found to
- query the domain part only. A different approach would be to query
- the domain part only, and if it's RMX record contain a special
- entry, then a new query for the full address is triggered. A third
- way would be to always query the full address and to leave the
- problem to the wildcard mechanism of DNS. This still has to be
- discussed and will be described in future versions of this draft.
-
-
-
-
-
-
-
-
-
-
-
-4. Mapping of E-Mail addresses to DNS names
-
- To perform the RMX query, a mapping is needed from E-Mail addresses
- to DNS fully qualified domain names.
-
- This chapter is under development and just a first approach.
-
-4.1. Domain part only
-
- Mapping of the domain part is trivial, since the domain part of an
- e-mail address itself is a valid DNS name and does not need
- translation. It might be nevertheless desirable to distinguish the
-
-
-
-Hadmut Danisch Experimental [Page 10]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- RMX entries from other entries, depending of the encoding of the
- records. If the RMX entries are encoded in TXT record types, they
- might collide with other uses of TXT records. It might be
- necessary to prepend the domain part with a special prefix, e.g.
- _rmx. So the e-mail address some.user@example.com could be mapped
- to example.com or _rmx.example.com.
-
-4.2. Full address
-
- Mapping a full address is slightly more difficult. The @ sign must
- be unambiguously translated, and therefore can not be simply
- translated into a dot. The e-mail addresses some.user@example.com
- and some@user.example.com must have different mappings. Therefore,
- the @ sign could be translated into _rmx, implicitely assuming that
- this is not an allowed domain name component of normal domain
- names. Then the rightmost _rmx in the mapped DNS name always
- corresponds to the @ sign. some.user@example.com would e translated
- into some.user._rmx.example.com and can be covered by a wildcard
- entry like *._rmx.example.com.
-
- Character encoding and character sets are still to be discussed.
-
-4.3. Empty address
-
- Unfortunately, SMTP allows empty envelope sender addresses to be
- used for error messages. Empty sender addresses can therefore not
- be prohibited. As observed, a significant amount of spam was sent
- with such an empty sender address. To solve this problem, the host
- name given in the HELO or EHLO command is taken to lookup the RMX
- records instead. This makes sense, since such messages were
- generated by the machine, not a human.
-
-
-
-
-5. Mandatory entry types and their syntax
-
- The entry types described in this section MUST be supported by any
- implementation of this draft.
-
-5.1. Overall structure
-
- Similar to APL, an RMX record is just a concatenation of zero or
- more RMX entries. The entries within one record form an ordered
- rule base as commonly usual in packet filtes and firewall rulesets,
- i. e. they are processed one ofter another until the first entry
- matches. This entry determines the result of the query. Once a
- matching entry is found, the RMX processing is finished.
-
-
-
-Hadmut Danisch Experimental [Page 11]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- For any domain name there should not exist more than a single RMX
- record. Due to the structure of DNS, it is nevertheless possible to
- have more than a single RMX record. Multiple RMX records are
- treated as a single record consisting of the concatenation of all
- records. While the entries in a record are ordered, the records are
- not ordered and may be processed in arbitrary order. If the order
- of the entries matters, it is the zone maintainer's responsibility
- to keep those entries in a single record. For example, there are
- negative entries, which exclude IP addresses from authorization.
- It is important that these entries are processed before positive
- entries giving permission to a wider address range. Since order is
- guaranteed only within a record, corresponding negative and
- positive entries must be put in the same record.
-
- An RMX record may consist of one or more entries, where the entries
- are separated by whitespace. An entry must not contain white space.
- Each entry consists of an optional exclamation sign, a tag, a
- colon, and the entry data:
-
- [!] TAG : ENTRY-SPECIFIC-DATA
-
- If the entry starts with an exclamation sign, the entry is negated.
- See the entry type description below for details.
-
- The TAG is the mnemonic type identifier or the decimal number of
- the entry. The TAG is case-insensitive. It is immediately followed
- by a colon.
-
- The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
- entry type. See description below.
-
- Example:
-
- danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
- ipv4:1.2.3.0/24
-
-5.2. Unused
-
- This is a primitive entry which just says that this sender address
- will never be used as a sender address under any circumstances.
- Example:
-
- testdomain.danisch.de IN RMX unused:
-
-5.3. IPv4 and IPv6 address ranges
-
- These entry types contain a bit sequence representing a CIDR
- address part. If that bit sequence matches the given IP address,
-
-
-
-Hadmut Danisch Experimental [Page 12]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- authorization is granted or denied, depending on the negation flag.
-
- The entry is prepended with the tag "IPv4" or "IPv6". The colon is
- followed with an IPv4 or IPv6 address in standard notation,
- optionally followed by a slash and a mask length. If the negation
- flag is set, then the given address range is excluded. Examples:
-
- danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0
- IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16
- IN RMX !ipv4:1.2.3.4
-
- (Please note that it does not make much sense to use
- RFC1918-Addresses in RMX records, this is just to give a syntax
- example.)
-
-
-5.4. DNS Hostname
-
- This entry type simply contains a regular DNS name, which is to be
- resolved as a host name (fetch the A record or IPv6 equivalent). If
- the given IP address matches the result, authorization is granted
- or denied, depending on the negation flag. It is still to be
- defined how to treat unresolvable entries.
-
- The entry is prepended with the tag "host", followed by a colon and
- the hostname. Examples:
-
- danisch.de IN RMX host:relay.provider.de
- IN RMX !host:badmachine.domain.de apl:relays.domain.de
-
-5.4.1. Road warriors and DynDNS entries
-
- Several people argued against RMX that it would break their
- existing installation which delivers e-mail from dynamically
- assigned IP addresses, because their IP providers didn't assign a
- static address, or because they are a road warrior, plugging their
- notebook in any hotel room on the world.
-
- RMX provides a simple solution. If such a machine has a dynamically
- updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
- the hostname type pointing to this dynamic DNS entry.
-
- The cleaner solution would be to deliver mail the same way as it is
- received: If downloaded by POP from a central relay with a static
- address, where the MX points to, then it would be a good idea to
- deliver e-mail the same way in reverse direction. Unfortunately,
- plain POP does not support uploading yet.
-
-
-
-
-Hadmut Danisch Experimental [Page 13]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-5.5. APL Reference
-
- This entry type simply contains a regular DNS name, which is to be
- resolved as an APL record index (fetch the APL record). If the
- given IP address positively matches the APL, authorization is
- granted. Details of the semantic (espially when the negation bit is
- set) are still to be defined. It is still to be defined how to
- treat unresolvable entries.
-
- The entry is prepended with the tag "host", followed by a colon and
- the hostname. Example:
-
- danisch.de IN RMX apl:relays.rackland.de
-
-5.6. Domain Member
-
- In many cases it is desirable to cover all hosts of a given domain
- with an RMX record without the need to duplicate the list of these
- hosts. This entry type does it (thanks to Eric A. Hall for pointing
- out this entry type). It contains a regular DNS name.
-
- If this entry type is given, a reverse DNS query for the IP address
- of the sending MTA is performed to find its official fully
- qualified domain name. To prevent spoofing, this domain name is
- accepted only if a subsequent address query to the given domain
- name points to exactly the IP address of the sending MTA (the usual
- procedure to verify PTR records).
-
- The entry matches if the fully qualified domain name of the sending
- MTA ends in the given domain. The negation flag works as usual.
-
- The tag for this entry type is "domain". After the colon the domain
- name is given, but might be empty, thus pointing to itself.
- Example:
-
- somedomain.org IN RMX domain:somedomain.org domain:provider.com
-
- would authorize all machines which's hostname can be verified
- through an PTR and A query, and which ends in "somedomain.org" or
- "provider.com".
-
- With such an entry, large companies with different networks can
- easily be covered with just a single and simple RMX entry.
- Obviously, it requires proper PTR records.
-
- As a special shortcut, the DNS name may be empty. In this case the
- domain name of the zone itself is taken. Thus, with a very simple
- entry of the type
-
-
-
-Hadmut Danisch Experimental [Page 14]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- somecompany.com IN RMX domain:
-
- a company could authorize all machines which's IP addresses map to
- DNS names end in somecompany.com, which applies in the majority of
- companies.
-
-
-
-
-5.7. Full Address Query
-
- As described above, RMX records will in most cases apply to the
- domain part of the sender address. In special cases it might be
- desirable to query the RMX record for a particular address. An RMX
- entry of the Full Address Query type may occur in a domain RMX
- record only. It signals that the RMX record for the full address is
- to be fetched and processed.
-
- This entry type does not take arguments. The negation flag is not
- supported. The tag is "full".
-
- If such a full address query is to be performed, the mail address
- must be mapped to a valid and non-ambiguos DNS name. This mapping
- is still to be defined. It is not sufficient to simply replace the
- @ with a dot, because of case sensitivity, character sets, etc. The
- e-mail addresses
-
- john.doe@example.org
- John.Doe@example.org
- john@doe.example.org
-
- must all be mapped to different DNS entries. This entry type might
- vanish in future versions of the draft, depending on the discussion
- about whether to query the domain name part only or the full
- address.
-
-5.8. DNS mapped authorization
-
- As I learned from comments to prior versions of the draft and from
- alternative proposals, many users wish to have a DNS mapped
- authorization table, i. e. the client queries a DNS entry of the
- form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
- Since people wish to have this, RMX will now include such a mapping
- entry. The entry has a parameter giving the DNS domain name where
- to look at. If the parameter is empty, then the same domain is
- taken as for the RMX lookup.
-
- As this is currently under construction and discussion in an IETF
-
-
-
-Hadmut Danisch Experimental [Page 15]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- group, details will be published in future versions of this draft.
-
-5.9. RMX reference
-
- This entry type has no parameters. It means that all those machines
- are authorized, which are pointed to by an MX record.
-
-6. Optional and experimental entry types
-
- The following subsections roughly describe further entry types
- which might not be supported by all implementations and might not
- be allowed in all legislations. These methods might vanish in
- future versions of the draft and are just considerations about what
- to include in RMX and what to not include. The main purpose of this
- section is to start discussion about such entry types.
-
- The disadvantage of the following methods is that they violate the
- basic idea of RMX, i. e. to be simple, robust, easy to implement
- and easy to administer. I personally do not believe that it is a
- good idea or even feasible to implement cryptography for a world
- wide e-mail transfer network. Keep in mind that cryptographic keys
- can be copied. If only <0.1% of cryptographic keys were revealed,
- this completely compromises and spoils RMX. Cryptography is simply
- the wrong tool for the problem RMX is intended to solve. I
- nevertheless like to discuss these methods.
-
-6.1. TLS fingerprint
-
- The sender is considered to be authorized if the message was
- transmitted through SMTP and TLS, and the sender used a certificate
- matching the fingerprint given in the RMX record.
-
-6.2. TLS and LDAP
-
- This means that the receiver should perform an LDAP query for the
- sender address (through the LDAP SRV record or given in the RMX
- record), fetch the X.509 certificate for the sender. The sender is
- considered to be authorized when the message was transmitted
- through SMTP and TLS using this certificate.
-
-6.3. PGP or S/MIME signature
-
- It would be possible to accept a message only if it was signed with
- PGP or S/MIME with a key which's fingerprint is given in the RMX
- record or to be fetched from LDAP or any PGP database. This is
- just for discussion, since it violates the idea of RMX to focus on
- the transport, not on the content. It would also allow replay
- attacks and not cover the envelope sender address or message
-
-
-
-Hadmut Danisch Experimental [Page 16]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- header.
-
-6.4. Transparent Challenge/Response
-
- It would also be possible to implement a challenge-response
- mechanism without modifying the syntax of SMTP. For example, the
- receiving MTA could issue a challenge with it's very first greeting
- message, the sending MTA could hide the response in the HELO
- parameter and when the receiving MTA later learns the sender
- envelope address, it could verify the response based on
- informations in the RMX record.
-
-6.5. SASL Challenge/Response
-
- Modern SMTP implementations already include a SASL mechanisms,
- which easily allows to plugin new authentication mechanisms. While
- common SASL mechanisms require to use a previously shared password,
- a new mechanism could perform a challenge response authentication
- as a SASL method.
-
-
-
-
-
-
-7. Encoding
-
-7.1. Alternative encoding as TXT records
-
- The main objection against the prior versions of this draft was
- that it requires a new RR entry type and upgrading all DNS servers.
-
- Therefore and alternative encoding is proposed. Instead of using a
- new RR type, the TXT record type is used to contain the RMX record.
- The records would simply look as described in the entry type
- chapters above, e.g.
-
- _rmx.danisch.de. IN TXT "apl:relays.rackland.de"
-
- To allow smooth introduction of RMX without the need to immediately
- upgrade all DNS servers, all clients (which have to be newly
- installed anyway) MUST support both the TXT and the RMX records. A
- client has to perform an ANY or a TXT and a RMX query. Servers/zone
- tables may currently use TXT entries but SHOULD use RMX entries in
- future.
-
-7.2. RMX Records
-
-
-
-
-Hadmut Danisch Experimental [Page 17]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-7.2.1. Overall structure
-
- Each entry starts with an octet containting the entry type and the
- negation flag:
-
- +---+---+---+---+---+---+---+---+------
- | N | Entry Type Code | Parameters...
- +---+---+---+---+---+---+---+---+------
-
- N If this bit (MSB) is set, an IP address
- matching this entry is not authorized,
- but explicitely rejected. See entry
- type descriptions for details.
-
- Entry Type A 7bit number simply determining the entry
- type.
-
-
- Currently, entries do not have an explicit length field, the entry
- length is determined implicitely by the entry type. Applications
- are required to abort if an unknown entry type is found, instead of
- skipping unknown entries.
-
-7.2.2. Record encoding
-
- A RMX record is simply a concatenation of RMX entries.
-
-7.2.3. Encoding of IPv4 and IPv6 address ranges
-
- After the entry type tag as described above, one octet follows
- giving the length L of the bit sequence. Then a sequence of exactly
- as many octets follows as needed to carry L bits of information (=
- trunc((L+7)/8) ).
-
- +---+---+---+---+---+---+---+---+
- | N | Entry Type Code (1 or 2) |
- +---+---+---+---+---+---+---+---+
- | Length Field L |
- +---+---+---+---+---+---+---+---+
- | Bit Field |
- / ((L+7)/8) Octets /
- +---+---+---+---+---+---+---+---+
-
-
-7.2.4. Encoding of DNS
-
- After the entry type tag immediately follows a DNS encoded and
- compressed [3] domain name.
-
-
-
-Hadmut Danisch Experimental [Page 18]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- +---+---+---+---+---+---+---+---+
- | N | Entry Type Code (3..5) |
- +---+---+---+---+---+---+---+---+
- | Length Field L |
- +---+---+---+---+---+---+---+---+
- | Encoded DNS |
- / Name as described in RFC1035 /
- +---+---+---+---+---+---+---+---+
-
- In contrast to earlier versions of this draft, the DNS name cannot
- be compressed, since this would cause decompression errors when a
- DNS server is part of the query chain which does not know this
- particular RR type.
-
-7.2.5. Encoding of unused and full query
-
- These entries do not contain parameters and does not allow the
- negation flag. So the encoding is quite simple:
-
- +---+---+---+---+---+---+---+---+
- | 0 | Entry Type Code (6 or 7)|
- +---+---+---+---+---+---+---+---+
-
-
-
-7.2.6. Additional Records
-
- In order to avoid the need of a second query to resolve the given
- host name, a DNS server should enclose the A record for that domain
- name in the additional section of the additional section of the DNS
- reply, if the server happens to be authoritative.
-
- In order to avoid the need of a second query to resolve the given
- host name, a DNS server should enclose the APL record for that
- domain name in the additional section of the additional section of
- the DNS reply, if the server happens to be authoritative.
-
-
-
-8. Message Headers
-
- An RMX query must be followed by any kind of action depending on
- the RMX result. One action might be to reject the message. Another
- action might be to add a header line to the message body, thus
- allowing MUAs and delivery programs to filter or sort messages.
-
- In future, the RMX result might be melted into the Received: header
- line.
-
-
-
-Hadmut Danisch Experimental [Page 19]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- The details of such entries are to be discussed. As a proposal the
- following form is suggested:
-
- X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
-
- where
-
- RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
- "TempFail", "BadData", "Trusted".
-
- ADDRESS is the IP address of the sending machine
-
- HOST is the name of the machine performing the RMX query.
-
- DATE is the date of the query.
-
- MECHANISM is the RMX method used to authorize the sender.
-
-
-
-9. SMTP error messages
-
- If a message is rejected because of RMX records, an error message
- should be issued which explains the details. It is to be discussed
- whether new SMTP error codes are to be defined.
-
-
-10. Message relaying and forwarding
-
-10.1. Problem description
-
- Message forwarding and relaying means that an MTA which received an
- e-mail by SMTP does not deliver it locally, but resends the message
- - usually unchanged except for an additional Received header line
- and maybe the recipient's address rewritten - to the next SMTP MTA.
- Message forwarding is an essential functionality of e-mail
- transport services, for example:
-
- - Message transport from outer MX relay to the intranet
- - Message forwarding and Cc-ing by .forward or .procmail-alike
- mechanisms
- - Mailing list processing
- - Message reception by mail relays with low MX priority,
- usually provided by third parties as a stand-by service
- in case of relay failure or maintenance
- - "Forwarding" and "Bouncing" as a MUA functionality
-
- In all these cases a message is sent by SMTP from a host which is
-
-
-
-Hadmut Danisch Experimental [Page 20]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- not covered by the original sender domain's RMX records. While the
- RMX records would forbid accepting this message, it still must be
- accepted. The following subsections explain how to cope with
- relaying.
-
-10.2. Trusted relaying/forwarding
-
- In some cases the receiving MTA trusts the sending MTA to not fake
- messages and to already have checked the RMX records at message
- reception. As a typical example, a company might have an outer mail
- relay which receives messages from the Internet and checks the RMX
- records. This relay then forwards the messages to the different
- department's mail servers. It does not make sense for these
- department mail servers to check the RMX record, since the RMX
- records have already been checked and - since the message was
- relayed by the outer relay - always would deny the message. In this
- case there is a trust relationship between the department relays
- and the outer relay. So RMX checking is turned off for trusted
- relays. In this example, the department relays would not check
- messages from the outer relay (but for intranet security, they
- could still check RMX records of the other departments sub-domains
- to avoid internal forgery between departments).
-
- Another common example are the low-priority MX relays, which
- receive and cache e-mails when the high-priority relays are down.
- In this case, the high-priority relay would trust the low-priority
- relay to have verified the sender authorization and would not
- perform another RMX verification (which would obviously fail).
-
- When a relay forwards a message to a trusting machine, the envelope
- sender address should remain unchanged.
-
-10.3. Untrusted relaying/forwarding
-
- If the receiving MTA does not trust the forwarding MTA, then there
- is no chance to leave the sender envelope address unchanged. At a
- first glance this might appear impracticable, but this is
- absolutely necessary. If an untrusted MTA could claim to have
- forwarded a message from a foreign sender address, it could have
- forged the message as well. Spammers and forgers would just have to
- act as such a relay.
-
- Therefore, it is required that, when performing untrusted
- forwarding, the envelope sender address has to be replaced by the
- sender address of someone responsible for the relaying mechanism,
- e.g. the owner of the mailing list or the mail address of the user
- who's .forward caused the transmission. It is important to stress
- that untrusted relaying/forwarding means taking over responsibility
-
-
-
-Hadmut Danisch Experimental [Page 21]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- for the message. It is the idea of RMX records to tie
- responsibility to message transmission. Untrusted relaying without
- replacing the sender address would mean to transmit without taking
- responsibility.
-
- The disadvantage is that the original sender address is lost.
- Therefore, whenever a sender address replacement happens, the
- Received-Line must contain the old address. Many of today's MTAs
- already insert the envelope recipient address, but not the sender
- address into the Received header line. It seems reasonable to
- require every Received line to include both the sender and
- recipient address of the incoming SMTP connection.
-
-
-11. Security Considerations
-
-11.1. Draft specific considerations
-
-11.1.1. Authentication strength
-
- It is important to stress, that the suggested method does not
- provide high level security and does not completely prevent forged
- e-mails or spam under any circumstances. It is a robust, but not
- highly reliable and completely secure security mechanism. Keep in
- mind that it is based on DNS, and DNS is not secure today.
- Authorization is based on the IP address. The very same machine
- with the very same IP address could be authorized to send e-mail
- with a given sender address and sending spam at the same time.
- Maybe because several users are logged in. Or because several
- customers use the same relay of the same ISP, where one customer
- could use the sender address of a different customer. It is up to
- the ISP to prevent this or not. Machines can still be hijacked.
- Spammers are also domain owners. They can simply use their own
- domain and authorize themselves. You will always find people on the
- world who do not care about security and open their relays and RMX
- records for others to abuse them. RMX is to be considered as a
- very cheap and simple light weight mechanism, which can
- nevertheless provide a significant improvement in mail security
- against a certain class of attacks, until a successor of SMTP has
- been defined and commonly accepted.
-
-11.1.2. Where Authentication and Authorization end
-
- Previous versions of RMX records did not cover the local part of
- the e-mail address, i.e. what's on the left side of the @ sign.
- This is still to be discussed. Authentication and authorization are
- limited to the sending MTA's IP address. The authentication is
- limited to the TCP functionality, which is sufficient for light
-
-
-
-Hadmut Danisch Experimental [Page 22]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- weight authentication. The RMX records authorize the IP address of
- the sending host only, not the particular sender of the message. So
- if a machine is authorized to use sender addresses of more than a
- single domain, the authentication scheme does not prevent that any
- user on this machine can send with any of these domains. RMX is not
- a substitute for the host security of the involved machines.
-
- The proposed authentication scheme can be seen as a "half way
- authentication": It does not track back an e-mail to the effective
- sender. It tracks only half of the way, i. e. it tracks back to the
- domain and it's DNS administrators who authorized that particular
- sender IP address to use it for sending e-mail. How the party
- responsible for that domain performs user authentication, whom it
- grants access to, how it helds people responsible for abuse, is
- completely left as the private business of those who are in charge
- of that domain. So this draft does not interfere with the domain's
- individual security policy or any legislation about such policies.
- On the other hand, the proposed authentication scheme does not give
- any statement about the nature and quality of the domain's security
- policy. This is an essential feature of the proposal: E-mail
- authentication must be deployed world wide, otherwise it won't do
- the job. Any security scheme interfering with the local
- legislations or the domain's security policy will not be accepted
- and can't effectively deployed. Therefore, the security policy must
- remain the domain's private business, no matter how lousy the
- policy might be.
-
- In order to achieve this and to make use of the only existing world
- wide Internet directory scheme (DNS), the approach of this proposal
- is to just ignore the local part of the sender address (i.e. what's
- left of the @ part) and limit view to the domain part. After all,
- that's what we do anyway when delivering to a given address with
- SMTP.
-
-11.1.3. Vulnerability of DNS
-
- DNS is an essential part of the proposed authentication scheme,
- since it requires any directory service, and DNS is currently the
- only one available. Unfortunately, DNS is vulnerable and can be
- spoofed and poisoned. This flaw is commonly known and weakens many
- network services, but for reasons beyond that draft DNS has not
- been significantly improved yet. After the first version of this
- draft, I received several comments who asked me not to use DNS
- because of its lack of security. I took this into consideration,
- but came to the conclusion that this is unfeasible: Any
- authentication scheme linked to some kind of symbolic identity (in
- this case the domain name) needs some kind of infrastructure and
- trusted assignment. There are basically two ways to do it: Do it
-
-
-
-Hadmut Danisch Experimental [Page 23]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- yourself and trust nobody else, or let someone else do it. There
- are methods to do it the former way, e.g. to give someone some kind
- of authentication information after a first successful e-mail
- exchange, e.g. some kind of cookie or special e-mail address. This
- is certainly interesting and powerful, but it does not solve the
- problem on a world wide scale and is far to complicated and error
- prone for the average user, i. e. 99% of the users.
-
- The latter method to let someone else do the symbolic name
- assignment and create the authentication framework is well known.
- It context of public key cryptography, this is called a Public Key
- Infrastructure (PKI). On of the best known facts about PKIs is
- that, until now, we don't have any covering a significant part of
- the Internet. And we won't have any in near future. The complexity
- is far too high, it is too expensive, and it involves cooperation
- of every single user, which is simply unrealistic and extremely
- error prone. So what do we have we can use? All we have is the DNS
- and the Whois database. And we have countries who don't allow
- cryptography. So the proposal was designed to use DNS without
- cryptography. It does not avoid DNS because of its vulnerability,
- it asks for a better DNS, but accepts the DNS as it is for the
- moment. Currently there are two main threats caused by the DNS
- weakness:
-
- - A spammer/forger could spoof DNS in order to gain false
- authorization to send fake e-mails.
-
- - An attacker could spoof DNS in order to block delivery from
- authorized machines, i. e. perform a Denial of Service attack.
-
- The first one is rather unrealistic, because it would require an
- average spammer to poison a significant part of the DNS servers of
- its victims. A spammer sending messages to one million receipients
- would need to poison at least 1-10% which is 10,000 to 100,000
- receipient's DNS servers. This should be unfeasible in most cases.
-
- In contrast, the second threat is a severe one. If an attacker
- wanted to block messages from one company to another, he just needs
- to poison the recipients DNS server with a wrong RMX record in
- order to make the recipient's SMTP machine reject all messages. And
- this is feasible since the attacker needs to poison only a single
- DNS server. But does this make SMTP more vulnerable? No. Because
- the attacker can already do even more without RMX. By poisoning the
- sender's DNS server with wrong MX records, the attacker can also
- block message delivery or even redirect the messages to the
- attacker's machine, thus preventing any delivery error messages and
- furthermore getting access to the messages.
-
-
-
-
-Hadmut Danisch Experimental [Page 24]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- As a consequence, e-mail delivery by SMTP requires a better DNS
- anyway. The requirements are not significantly expanded by RMX.
-
-11.1.4. Sneaking RMX attack?
-
- While writing a test implementation, a certain kind of attack came
- into my mind. I'm still not sure, whether this attack is possible
- on any DNS server, but I believe it should be mentioned:
-
- Imagine an unauthorized sender is sending a forged mail (e.g.
- spam). At connection time, before querying the RMX record, the
- receiving MTA usually performs a PTR query for the IP address of
- the sending MTA. If the sender has control over the authoritative
- name server for that particular IP address, the sender could give a
- normal PTR answer, but could append a wrong RMX, APL, or A record
- in the additional section of the query. A subsequent RMX query
- could receive wrong DNS data if the DNS server used by the
- receiving MTA accepted those forged records.
-
-11.1.5. Open SMTP relays
-
- Open SMTP relays (i.e. machines who accept any e-mail message from
- anyone and deliver to the world) abused by spammers are a one of
- the main problems of spam defense and sender backtracking. In most
- cases this problem just vanishes because foreign open relay
- machines will not be covered by the RMX records of the forged
- sender address. But there are two special cases:
-
- If the spammer knows about a domain which authorizes this
- particular machine, that domain can be used for forgery. But in
- this case, the IP address of the relay machine and the RMX records
- of the domain track back to the persons responsible. Both can be
- demanded to fix the relay or remove the RMX record for this
- machine. An open relay is a security flaw like leaving the machine
- open for everybody to login and send random mails from inside. Once
- the administrative persons refuse to solve the problem, they can be
- identified as spammers and held responsible.
-
- The second special case is when a domain authorizes all IP
- addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
- this case, open relays don't make things worse. It's up to the
- recipient's MTA to reject mails from domains with loose security
- policies.
-
-11.1.6. Unforged Spam
-
- This proposal does not prevent spam (which is, by the way, not yet
- exactly defined), it prevents forgery. Since spam is against law
-
-
-
-Hadmut Danisch Experimental [Page 25]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- and violates the recipients rights, spam depends on untracability
- of the sender. In practice the sender forges the sender address
- (other cases see below). This proposal is designed to detect such
- forgeries.
-
- However, the RMX approach is rendered ineffective, if the sender
- doesn't forge. If the sender uses just a normal address of it's own
- domain, this is just a plain, normal e-mail, which needs to be let
- through. Since it is up to the human's taste whether this is spam
- or not, there's no technical way to reliably identify this as spam.
- But since the sender domain is known, this domain can be
- blacklisted or legal steps can be gone into.
-
-11.1.7. Reliability of Whois Entries
-
- Once the RMX infrastructure gets deployed, what's the security
- gain? It allows to determine the domain which's DNS zone
- authorized the sending machine. What's that good for? There are
- some immediate uses of the domain name, e.g. in black- and
- whitelisting. But in most cases this is just the starting point of
- further investigations, either performed automatically before
- message acceptance, or manually after spam has been received and
- complainted about.
-
- The next step after determining the domain is determining the
- people responsible for this domain. This can sometimes be achieved
- by querying the Whois databases. Unfortunately, many whois entries
- are useless because they are incomplete, wrong, obsolete, or in
- uncommon languages. Furthermore, there are several formats of
- address informations which make it difficult to automatically
- extract the address. Sometimes the whois entry identifies the
- provider and not the owner of the domain. Whois servers are not
- built for high availability and sometimes unreachable.
-
- Therefore, a mandatory standard is required about the contents and
- the format of whois entries, and the availability of the servers.
- After receiving the MAIL FROM SMTP command with the sender envelope
- address, the receiving MTA could check the RMX record and Whois
- entry. If it doesn't point to a real human, the message could be
- rejected and an error message like "Ask your provider to fix your
- Whois entry" could be issued. Obviously, domain providers must be
- held responsible for wrong entries. It might still be acceptable to
- allow anonymous domains, i. e. domains which don't point to a
- responsible human. But it is the receivers choice to accept e-mails
- from such domains or not.
-
-11.1.8. Hazards for Freedom of Speech
-
-
-
-
-Hadmut Danisch Experimental [Page 26]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- Currently, some governments try to enforce limitations of internet
- traffic in order to cut unwanted content providers from the
- network. Some of these governments try to hide a whole country
- behind firewalls, others try to force Internet providers to poison
- DNS servers with wrong A records for web servers, e.g. one county
- administration in Germany tries to do so. If message reception
- depends on DNS entries, the same governments will try to block not
- only HTTP, but SMTP also.
-
- However, since most MTAs already reject messages from unresolvable
- domain names this is not a new threat.
-
-11.2. General Considerations about spam defense
-
- After discussing security requirements of the proposal, now the
- security advantages of the RMX approach over content based filters
- will be explained. Basically, there are three kinds of content
- filters:
-
- - Those who upload the message or some digest to an external
- third party and ask "Is this spam"?
-
- - Those who download a set of patterns and rules from a third
- party and apply this set to incoming messages in order to
- determine whether it is spam.
-
- - Those who are independent and don't contact any third party,
- but try to learn themselves what is spam and what isn't.
-
-
- The message filters provided by some e-mail service providers are
- usually not a kind of their own, but a combination of the first two
- kinds.
-
-11.2.1. Action vs. reaction
-
- Content filters suffer from a fundamental design problem: They are
- late. They need to see some content of the same kind before in
- order to learn and to block further distribution.
-
- This works for viruses and worms, which redistribute. This doesn't
- work for spam, since spam is usually not redistributed after the
- first delivery. When the filters have learned or downloaded new
- pattern sets, it's too late.
-
- This proposal does not have this problem.
-
-11.2.2. Content based Denial of Service attacks
-
-
-
-Hadmut Danisch Experimental [Page 27]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- All three kinds of content filters, but especially the second and
- the third kind are vulnerable to content based Denial of Service
- attacks.
-
- If some kind of third party (e.g. non-democratic government,
- intellectual property warriors, religious groups, military, secret
- services, patriots, public relation agents, etc.) wants certain
- contents not to be distributed, they could either poison the
- pattern/rule databases or feed wrong sets to particular receivers.
-
- Such pattern/rule sets are the perfect tool for censoring e-mail
- traffic and denial of service attacks by governments and other
- parties, and a similar threat are virus filters. E. g. the content
- industry could demand to teach all virus and spam filters to delete
- all e-mails containing the URL of an MP3 web server outside the
- legislations. Software manufacturers could try to block all e-mails
- containing software license keys, thus trying to make unallowed
- distribution more difficult. Governments could try to block
- distribution of unwanted informations.
-
- This proposal does not have this problem.
-
-
-12. Privacy Considerations
-
- (It was proposed on the 56th IETF meeting to have a privacy section
- in drafts and RFCs.)
-
-12.1. Draft specific considerations
-
-12.1.1. No content leaking
-
- Since the RMX approach doesn't touch the contents of a message in
- any way, there is obviously no way of leaking out any information
- about the content of the message. RMX is based solely on the
- envelope recipient address. However, methods to fix problems not
- covered by RMX might allow content leaking, e.g. if the acceptance
- of a message with an empty sender address requires the reference to
- the message id of an e-mail recently sent, this allows an attacker
- to verify whether a certain message was delivered from there.
-
-12.1.2. Message reception and sender domain
-
- Message delivery triggers RMX and APL requests by the recipient.
- Thus, the admin of the DNS server or an eavesdropper could learn
- that the given machine has just received a message with a sender
- from this address, even if the SMTP traffic itself had been
- encrypted.
-
-
-
-Hadmut Danisch Experimental [Page 28]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- However, most of today's MTAs do query the MX and A records of the
- domain after the MAIL FROM command, so this is not a real new
- threat.
-
-12.1.3. Network structure
-
- Since RMX and its associated APL records provide a complete list of
- all IP addresses of hosts authorized to send messages from this
- address, they do reveal informations about the network structure
- and maybe the lifestyle of the domain owner, since a growing number
- of domains are owned by single persons or families. E.g. the RMX
- records could reveal where someone has his job or spends his time
- at weekends.
-
- If such informations are to be kept secret, it is the user's job to
- not sent e-mails from there and to relay them from non-compromising
- IP addresses.
-
-12.1.4. Owner information distribution
-
- As described above, RMX depends partly on the reliability of the
- whois database entries. It does not make anonymous domains
- impossible, but it requires to keep the database entries "true", i.
- e. if a whois entry does not contain informations about the
- responsible person, this must be unambigously labeled as anonymous.
- It must not contain fake names and addresses to pretend a non-
- existing person. However, since most Internet users on the world
- feel extremely annoyed by spam, they will urge their MTA admin to
- reject messages from anonymous domains. The domain owner will have
- the choice to either remain anonymous but be not able to send e-
- mail to everyone in the world, or to be able but to reveal his
- identity to everyone on the world.
-
- It would be possible to provide whois-like services only to
- recipients of recent messages, but this would make things too
- complicated to be commonly adopted.
-
-12.2. General Considerations about spam defense
-
-12.2.1. Content leaking of content filters
-
- As described above in the Security chapter, there are spam filters
- which inherently allow leakage of the message body. Those filters
- upload either the message body, or in most cases just some kind of
- checksum to a third party, which replies whether this is to be seen
- as spam or not. The idea is to keep a databases of all digests of
- all messages. If a message is sent more often than some threshold,
- it is to be considered as a mass mail and therefore tagged as spam.
-
-
-
-Hadmut Danisch Experimental [Page 29]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- While the digest itself does not reveal the content of the message,
- it perfectly reveals where a particular message has been delivered
- to. If a government finds just a single unwanted message, if a
- software manufacturer finds a single message with a stolen product
- license key, if someone finds a message with unpatriotic content,
- it takes just a single database lookup to get a list of all people
- who received this particular message. Content filters with digest
- upload are the perfect "Big Brother".
-
-12.2.2. Black- and Whitelists
-
- Some proposals against spam are based on a central database of
- white- or blacklisted IP addresses, Sender names, Message IDs or
- whatever. Again, there is a central database which learns who has
- received which e-mail or from which sender with every query. This
- allows tracking relations between persons, which is also a breach
- of privacy.
-
-
-
-13. Deployment Considerations
-
-13.1. Compatibility
-
-13.1.1. Compatibility with old mail receivers
-
- Since the suggested extension doesn't change the SMTP protocol at
- all, it is fully compatible with old mail receivers. They simply
- don't ask for the RMX records and don't perform the check.
-
-13.1.2. Compatibility with old mail senders
-
- Since the SMTP protocol is unchanged and the SMTP sender is not
- involved in the check, the method is fully compatible with old mail
- senders.
-
-13.1.3. Compatibility with old DNS clients
-
- Since the RMX is a new RR, the existing DNS protocol and zone
- informations remain completely untouched.
-
- If RMX is provided as a TXT record instead, it must be ensured that
- no other software is misinterpreting this entry.
-
-13.1.4. Compatibility with old DNS servers
-
- Full compatibility: If the server does not support RMX records, RMX
- in TXT records can be used.
-
-
-
-Hadmut Danisch Experimental [Page 30]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-13.2. Enforcement policy
-
- Obviously, for reasons of backward compatibility and smooth
- introduction of this scheme, RMX records can't be required
- immediately. Domains without RMX records must temporarily be
- treated the same way as they are treated right now, i.e. e-mail
- must be accepted from anywhere. But once the scheme becomes
- sufficiently widespread, mail relays can start to refuse e-mails
- with sender addresses from domains without RMX records, thus
- forcing the owner of the domain to include a statement of
- authorization into the domain's zone table. Domain owners will
- still be free to have an RMX record with a network and mask
- 0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
- On the other hand, mail receivers will be free to refuse mails from
- domains without RMX records or RMX records which are too loose.
- Advanced MTAs might have a configuration option to set the maximum
- number of IP addresses authorized to use a domain. E-mails from a
- domain, which's RMX records exceed this limit, would be rejected.
- For example, a relay could reject e-mails from domains which
- authorize more than 8 IP addresses. That allows to accept e-mails
- only from domains with a reasonable security policy.
-
-
-
-14. General considerations about fighting spam
-
- Is there a concise technical solution against spam? Yes.
-
- Will it be deployed? Certainly not.
-
- Why not? Because of the strong non-technical interests of several
- parties against a solution to the problem, as described below.
- Since these are non-technical reasons, they might be beyond the
- scope of such a draft. But since they are the main problems that
- prevent fighting spam, it is unavoidable to address them. This
- chapter exists temporarily only and should support the discussion
- of solutions. It is not supposed to be included in a later RFC.
-
-14.1. The economical problem
-
- As has been recently illustrated in the initial session of the
- IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
- sending spam is a business with significant revenues.
-
- But a much bigger business is selling Anti-Spam software. This is a
- billion dollar market, and it is rapidly growing. Any simple and
- effective solution against spam would defeat revenues and drive
- several companies into bankrupt, would make consultants jobless.
-
-
-
-Hadmut Danisch Experimental [Page 31]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- Therefore, spam is essential for the Anti-Spam business. If there
- is no spam, then no Anti-Spam software can be sold, similar to the
- Anti-Virus business. There are extremely strong efforts to keep
- this market growing. Viruses, Worms, and now spam are just perfect
- to keep this market alive: It is not sufficient to just buy a
- software. Databases need to be updated continuously, thus making
- the cash flow continuously. Have a single, simple, and permanent
- solution to the problem and - boom - this billion dollar market is
- dead.
-
- That's one of the reasons why people are expected to live with
- spam. They have to live with it to make them buy Anti-Spam
- software. Content filters are perfect products to keep this market
- alive.
-
-14.2. The POP problem
-
- Another problem is the history of mail delivery. Once upon a time,
- there used to be very few SMTP relays which handled the e-mail
- traffic of all the world, and everybody was happy with that. Then
- odd things like Personal Computers, which are sometimes switched
- off, portable computers, dynamicly assigned IP addresses, IP access
- from hotel rooms, etc. was invented, and people became unhappy,
- because SMTP does not support delivery to such machines. To make
- them happy again, the Post Office Protocol[4] was invented, which
- turned the last part of message delivery from SMTP's push style
- into a pull style, thus making virtually every computer on the
- world with any random IP address a potential receiver of mails for
- random domains. Unfortunately, only receiving e-mail was covered,
- but sending e-mail was left to SMTP.
-
- The result is that today we have only very few SMTP relays pointed
- to by MX records, but an extreme number of hosts sending e-mail
- with SMTP from any IP address with sender addresses from any
- domain. Mail delivery has become very asymmetric. Insecurity,
- especially forgeability, has become an essential part of mail
- transport.
-
- That problem could easily be fixed: Use protocols which allow
- uploading of messages to be delivered. If a host doesn't receive
- messages by SMTP, it shouldn't deliver by SMTP. Mail delivery
- should go the same way back that incoming mail went in. This is
- not a limitation to those people on the road who plug their
- portable computer in any hotel room's phone plug and use any
- provider. If there is a POP server granting download access from
- anywhere, then the same server should be ready to accept uploading
- of outgoing messages.
-
-
-
-
-Hadmut Danisch Experimental [Page 32]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- But as I saw from the comments on the first version of this draft,
- people religiously insist on sending e-mail with their domain from
- any computer with any IP address in the world, e.g. when visiting a
- friend using her computer. It appears to be impossible to convince
- people that stopping mail forgery requires every one of them to
- give up forging.
-
-14.3. The network structure problem
-
- A subsequent problem is that many organisations failed to implement
- a proper mail delivery structure and heavily based their network on
- this asymmetry. I received harsh comments from Universities who
- were unable to give their network a good structure. While they do
- have a central mail relay for incoming mail to the universities
- domain, they developed a structure where every member of the
- University randomly sends e-mails with that University's domain as
- a sender address from home or everywhere in the world with any
- dynamically assigned IP address from any provider. So this domain
- is to be used from every possible IP address on earth, and they are
- unable to operate any authentication scheme. Furthermore, they were
- unable to understand that such a policy heavily supports spam and
- that they have to expect that people don't accept such e-mails
- anymore once they become blacklisted.
-
- As long as organisations insist on having such policies, spammers
- will have a perfect playground.
-
-14.4. The mentality problem
-
- Another problem is the mentality of many internet users of certain
- countries. I received harsh comments from people who strongly
- insisted on the freedom to send any e-mail with any sender address
- from anywhere, and who heavily refused any kind of authentication
- step or any limitation, because they claimed that this would
- infringe their constitutional "Freedom of speech". They are
- undeviatingly convinced that "Freedom of speech" guarantees their
- right to talk to everybody with any sender address, and that is has
- to be kept the recipient's own problem to sort out what he doesn't
- want to read - on the recipient's expense.
-
- It requires a clear statement that the constitutional "Freedom of
- Speech" does not cover molesting people with unsolicited e-mail
- with forged sender address.
-
-14.5. The identity problem
-
- How does one fight against mail forgery? With authentication. What
- is authentication? In simple words: Making sure that the sender's
-
-
-
-Hadmut Danisch Experimental [Page 33]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
- real identity meets the recipients idea of who is the sender, based
- on the sender address which came with the message.
-
- What is identity? It is the main problem. Several countries have
- different ideas of "identity", which turn out to be somehow
- incompatible. In some countries people have identity cards and
- never change their name and birthday. Identities are created by
- human birth, not by identity changes. Other countries do not have
- such a tight idea about identity. People's temporary identity is
- based on nothing more than a driving license and a social security
- number. With this background, it is virtually impossible to create
- a trustworthy PKI covering all Internet users. I learned that it is
- extremely difficult to convince some people to give up random e-
- mail sending.
-
-14.6. The multi-legislation problem
-
- Many proposals about fighting spam are feasible under certain
- legislations only, and are inacceptable under some of the
- legislations. But a world wide applicable method is required.
- That's why the approach to ask everone on the world to sign
- messages with cryptographic keys is not feasible.
-
-
-Implementation and further Information
-
- Further informations and a test implementation are available at
-
- http://www.danisch.de/work/security/antispam.html
- http://www.danisch.de/software/rmx/
-
-
- Additional informations and a technology overview are also
- available at
-
- http://www.mikerubel.org/computers/rmx_records/
-
-
-References
-
-
-
-1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
- els," RFC 2119 (March 1997).
-
-2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
-
-
-
-
-
-Hadmut Danisch Experimental [Page 34]
-
-INTERNET-DRAFT DNS RMX RR Oct 2003
-
-
-3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
- RFC 1035 (November 1987).
-
-4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
- (May 1996).
-
-
-Draft History
-
- 00 Dec 2002
- 01 Apr 2003
- 02 Jun 2003
- 03 Oct 2003
-
-Author's Address
-
- Hadmut Danisch
-
- Tennesseeallee 58
- 76149 Karlsruhe
- Germany
-
- Phone: ++49-721-843004 or ++49-351-4850477
- E-Mail: rfc@danisch.de
-
-Comments
-
- Please send comments to rfc@danisch.de.
-
-Expiry
-
- This drafts expires on Apr 1, 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch Experimental [Page 35]
-
diff --git a/doc/draft/draft-dnsext-opcode-discover-02.txt b/doc/draft/draft-dnsext-opcode-discover-02.txt
deleted file mode 100644
index 7b5e8cc4455b..000000000000
--- a/doc/draft/draft-dnsext-opcode-discover-02.txt
+++ /dev/null
@@ -1,241 +0,0 @@
-
-IETF DNSEXT WG Bill Manning
-draft-dnsext-opcode-discover-02.txt ep.net
- Paul Vixie
- ISC
- 13 Oct 2003
-
-
- The DISCOVER opcode
-
-This document is an Internet-Draft and is subject to all provisions of
-Section 10 of RFC2026.
-
-Comments may be submitted to the group mailing list at "mdns@zocalo.net"
-or the authors.
-
-Distribution of this memo is unlimited.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months and
-may be updated, replaced, or obsoleted by other documents at any time. It
-is inappropriate to use Internet-Drafts as reference material or to cite
-them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-The capitalized keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-document are to be interpreted as described in RFC 2119
-
-0. Abstract:
-
- The QUERY opcode in the DNS is designed for unicast. With the
- development of multicast capabilities in the DNS, it is desireable
- to have a more robust opcode for server interactions since a single
- request may generate replies from multiple responders. So DISCOVER
- is defined to deal with replies from multiple responders.
-
- As such, this document extends the core DNS specifications to allow
- clients to have a method for coping with replies from multiple
- responders. Use of this new opcode may facilitate DNS operations in
- modern networking topologies. A prototype of the DISCOVER opcode
- was developed during the TBDS project (1999-2000), funded under DARPA
- grant F30602-99-1-0523.
-
-1. Introduction:
-
- This document describes an experimental extension to the DNS to receive
- multiple responses which is the likely result when using DNS that has
- enabled multicast queries. This approach was developed as part of the
- TBDS research project, funded under DARPA grant F30602-99-1-0523. The
- full processing rules used by TBDS are documented here for possible
- incorporation in a future revision of the DNS specification."
-
-2. Method:
-
- DISCOVER works like QUERY except:
-
- 1. it can be sent to a broadcast or multicast destination. QUERY
- isn't defined for non-unicast, and arguably shouldn't be.
-
- 2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
- tuples. TBDS tried to augment this structure as follows:
- <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
- TBDS, it is cleaner to place the SRV question in a separate pass.
-
- 3. if QDCOUNT equals 0 then only servers willing to do recursion should
- answer. Other servers must silently discard the DISCOVER request.
-
- 4. if QDCOUNT is not equal to 0 then only servers who are authoritative
- for the zones named by some QNAME should answer.
-
- 5. responses may echo the request's Question section or leave it blank,
- just like QUERY.
-
- 6. responses have standard Answer, Authority, and Additional sections.
- e.g. the response is the same as that to a QUERY. It is desireable
- that zero content answers not be sent to avoid badly formed or
- unfulfilled requests. Responses should be sent to the unicast
- address of the requester and the source address should reflect
- the unicast address of the responder.
-
- Example usage for gethostby{name,addr}-style requestors:
-
- Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
- ip6.arpa domain.
-
- DISCOVER whether anyone in-scope is authoritative for this zone.
-
- If so, query these authoritative servers for local
- in-addr/ip6 names.
-
- If not, DISCOVER whether there are recursive servers available.
-
- If so, query these recursive servers for local
- in-addr/ip6 names.
-
- So, a node will issue a multicast request with the DISCOVER opcode at
- some particular multicast scope. Then determine, from the replies,
- whether there are any DNS servers which are authoritative (or support
- recursion) for the zone. Replies to DISCOVER requests MUST set the
- Recursion Available (RA) flag in the DNS message header.
-
- It is important to recognize that a requester must be prepared to
- receive multiple replies from multiple responders. We expect that
- there will be a single response per responder.
-
- Once one learns a host's FQDN by the above means, repeat the process
- for discovering the closest enclosing authoritative server of such
- local name.
-
- Cache all NS and A data learned in this process, respecting TTL's.
-
- TBDS usage for SRV requestors:
-
- Do the gethostbyaddr() and gethostbyname() on one's own link-local
- address, using the above process.
-
- Assume that the closest enclosing zone for which an authority server
- answers an in-scope DISCOVER packet is "this host's parent domain".
-
- Compute the SRV name as _service._transport.*.parentdomain.
-
- This is a change to the definition as defined in RFC 1034.
- A wildcard label ("*") in the QNAME used in a DNS message with
- opcode DISCOVER SHOULD be evaluated with special rules. The
- wildcard matches any label for which the DNS server data is
- authoritative. For example 'x.*.example.com.' would match
- 'x.y.example.com.' and 'x.yy.example.com.' provided that the
- server was authoritative for 'example.com.' In this particular
- case, we suggest the follwing considerations be made:
-
- getservbyname() can be satisfied by issuing a request with
- this computed SRV name. This structure can be
- populated by values returned from a request as follows:
-
- s_name The name of the service, "_service" without the
- preceding underscore.
- s_aliases The names returned in the SRV RRs in replies
- to the query.
- s_port The port number in the SRV RRs replies to the
- query. If these port numbers disagree - one
- of the port numbers is chosen, and only those
- names which correspond are returned.
- s_proto The transport protocol from named by the
- "_transport" label, without the preceding
- underscore.
-
- Send SRV query for this name to discovered local authoritative servers.
-
- Usage for disconnected networks with no authoritative servers:
-
- Hosts should run a "stub server" which acts as though its FQDN is a
- zone name. Computed SOA gives the host's FQDN as MNAME, "." as the
- ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
- and the other timers. Compute NS as the host's FQDN. Compute the
- glue as the host's link-local address. Or Hosts may run a
- "DNS stub server" which acts as though its FQDN is a zone name. The
- rules governing the behavior of this stub server are given elsewhere
- [1] [2].
-
- Such stub servers should answer DISCOVER packets for its zone, and
- will be found by the iterative "discover closest enclosing authority
- server" by DISCOVER clients, either in the gethostbyname() or SRV
- cases described above. Note that stub servers only answer with
- zone names which exactly match QNAME's, not with zone names which
- are owned by QNAME's.
-
- The main deviation from the DNS[3][4] model is that a host (like, say, a
- printer offering LPD services) has a DNS server which answers authoritatively
- for something which hasn't been delegated to it. However, the only way that
- such DNS servers can be discovered is with a new opcode, DISCOVER, which
- is explicitly defined to discover undelegated zones for tightly scoped
- purposes. Therefore this isn't officially a violation of DNS's coherency
- principles. In some cases a responder to DISCOVER may not be traditional
- DNS software, it could be special purpose software.
-
-3. IANA Considerations
-
- As a new opcode, the IANA will need to assign a numeric value
- for the memnonic. The last OPCODE assigned was "5", for UPDATE.
- Test implementations have used OPCODE "6".
-
-4. Security Considerations
-
- No new security considerations are known to be introduced with any new
- opcode, however using multicast for service discovery has the potential
- for denial of service, primarly from flooding attacks. It may also be
- possible to enable deliberate misconfiguration of clients simply by
- running a malicious DNS resolver that claims to be authoritative for
- things that it is not. One possible way to mitigate this effect is by
- use of credentials, such as CERT resource records within an RR set.
- The TBDS project took this approach.
-
-5. Attribution:
-
- This material was generated in discussions on the mdns mailing list
-hosted by Zocalo in March 2000. Updated by discussion in September/October
-2003. David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
-Erik Guttman, Bill Manning and Paul Vixie were active contributors.
-
-6. Author's Address
-
- Bill Manning
- PO 12317
- Marina del Rey, CA. 90295
- +1.310.322.8102
- bmanning@karoshi.com
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 779 7001
- <vixie@isc.org>
-
-7. References
-
-Informational References:
-
-[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
- draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
-
-[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
- draft-manning-dnsext-mdns-00.txt, August 2000. Expired.
-
-Normative References:
-[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- RFC 1034, November 1987.
-[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
- RFC 1035, November 1987
-
- ----------------------------EOL-----------------------
-
diff --git a/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/doc/draft/draft-durand-dnsop-dynreverse-00.txt
deleted file mode 100644
index 224e7ad1697e..000000000000
--- a/doc/draft/draft-durand-dnsop-dynreverse-00.txt
+++ /dev/null
@@ -1,240 +0,0 @@
-Internet Engineering Task Force Alain Durand
-INTERNET-DRAFT SUN Microsystems
-Feb 21, 2003
-Expires Aug 2, 2003
-
-
-
- Dynamic reverse DNS for IPv6
- <draft-durand-dnsop-dynreverse-00.txt>
-
-
-
-Status of this memo
-
-
- This memo provides information to the Internet community. It does
- not specify an Internet standard of any kind. This memo is in full
- conformance with all provisions of Section 10 of RFC2026 [RFC2026].
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
-
-Abstract
-
- This document describes a method to dynamically generate PTR records
- and corresponding A or AAAA records when the reverse path DNS tree is
- not populated.
-
- A special domain dynrev.arpa. is reserved for that purpose.
-
-
-1. Introduction
-
- In IPv4, the reverse path tree of the DNS under in-addr.arpa.
- although not perfectly maintained, is still mostly usable and its
- existence is important for a number of applications that relies on
- its existence and decent status. Some applications performs some
- (very) weak security checks based on it. Mail relays relies on it for
- some anti-spams checks an some FTP server will not let you in unless
- your IP address resolve properly with a PTR record.
-
- IPv6 addresses being much longer (and cumbersome) than IPv4
- addresses, it is to fear that the reverse path tree under ip6.arpa.
- would not be as well maintained. Also, tools like 6to4, Isatap and
- others have made creative use of the 128 bits of an IPv6 address to
- automatically embed an IPv4 address to enable seamless connection to
- the IPv6 Internet. However, no provision has been made to make sure
- the reverse path tree gets automatically updated as well for those
- new IPv6 addresses. One step furter, RFC3041 describes a mechanism
- to basically use random bits in the bottom part of an IPv6 address to
- preserver anonymity. If those addresses are to resolve in the reverse
- path tree, it obviously has to be with anonymous data as well.
- Another point to note is that home customer ISPs in IPv4 have a
- current practice to pre-populate the reverse path tree with names
- automatically derived from the IP addresses. This practice is no
- longer possible in IPv6, where IP address allocation is not dense as
- it is the case in IPv4. The mere size of typical customer allocation
- (2^48 according to the recommendation of RFC3177) makes it
- impossible.
-
- Applications that check the existence of PTR records usually follow
- this by checking if the name pointed by the PTR resolve in a A (or
- AAAA for IPv6) that match the original IP address. Thus the forward
- path tree must also include the corresponding data.
-
- One simple approach of this problem is to simply declare the usage of
- the reverse path DNS as described above obsolete. The author believe
- this is too strong an approach for now.
-
- Similarly, a completely different approach would be to deprecate the
- usage of DNS for the reverse tree altogether and replace it by
- something inspired from ICMP name-info messages. The author believes
- that this approached is an important departure from the current
- practise and thus not very realistic. Also, there are some concerns
- about the the security implications of this method as any node could
- easily impersonate any name. This approach would fundamentally change
- the underlying assumption of "I trust what has been put in the DNS by
- the local administrators" to "I trust what has been configured on
- each machine I query directly".
-
-
-
-2. Dynamic record generation
-
- If static pre-population of the tree is not possible anymore and data
- still need to be returned to applications using getnameinfo(), the
- alternative is dynamic record generation. This can be done is two
- places: in the DNS servers responsible for the allocated space (/64
- or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the
- sub resolver library or the recursive DNS server).
-
- 2.1. On the resolver side.
-
- The resolver, either in the recursive DNS server or in the stub
- library could theoretically generate this data.
-
- In case DNSsec is in place, the recursive DNS server would have to
- pretend these records are authentic.
-
- If the synthesis is done in the stub-resolver library, no record
- needs to be actually generated, only the right information needs to
- be passed to getnameinfo() and getaddrinfo(). If the synthesis is
- done in the recursive DNS server, no modification is required to
- existing stub resolvers.
-
-
-2.2. On the server side.
-
- PTR records could be generated automatically by the server
- responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
- prefixes or basically anything in between) when static data is not
- available.
-
- There could be impact on DNSsec as the zone or some parts of the zone
- may need to be resigned each time a DNS query is made for an
- unpopulated address. This can be seen as a DOS attack on a DNSsec
- zone, so server side synthesis is not recommended if DNSsec is
- deployed.
-
-
-
-3. Synthesis
-
- The algorithm is simple: Do the normal queries. If the query returns
- No such domain, replace this answer by the synthetized one if
- possible.
-
-3.1. PTR synthesis
-
- The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
- where [X] is any valid DNS name.
-
- The fact that the synthetized PTR points to the dynrev.arpa. domain
- is an indication to the applications that this record has been
- dynamically generated.
-
-
-3.2. A synthesis
-
- If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
- record for the string [X].dynrev.arpa. which value is d.c.b.a. with
- a,b,c & d being integer [0..255]
-
-
-3.3. AAAA synthesis
-
- If [X] is in the form
- a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
- addr.arpa, one can synthetized a AAAA record for the string
- [X].dynrev.arpa. which value is
- FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
- a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
-
-
-3.4. Server side synthesis
-
- If synthesis is done on the server side, PTR could be set not to use
- the dynrev.arpa domain but the local domain name instead. It culd be
- for instance dynrev.mydomain.com.
-
- Note also that server side synthesis is not incompatible with
- resolver side synthesis.
-
-
-
-4. IANA considerations
-
- The dynrev.arpa. domain is reserved for the purpose of this document.
-
-
-
-5. Security considerations
-
- Section 2. discusses the the interactions with DNSsec.
-
-
-
-6. Authors addresses
-
- Alain Durand
- SUN Microsystems, Inc
- 17, Network Circle
- UMPK17-202
- Menlo Park, CA 94025
- USA
- Mail: Alain.Durand@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt
deleted file mode 100644
index fa41e7635e2f..000000000000
--- a/doc/draft/draft-ietf-dnsext-2929bis-01.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories
-Expires: February 2006 August 2005
-
-
-
- Domain Name System (DNS) IANA Considerations
- ------ ---- ------ ----- ---- --------------
- <draft-ietf-dnsext-2929bis-01.txt>
-
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Distribution of this draft is unlimited. It is intended to become
- the new BCP 42 obsoleting RFC 2929. Comments should be sent to the
- DNS Working Group mailing list <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
- Internet Assigned Number Authority (IANA) parameter assignment
- considerations are given for the allocation of Domain Name System
- (DNS) classes, RR types, operation codes, error codes, RR header
- bits, and AFSDB subtypes.
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DNS Query/Response Headers..............................3
- 2.1 One Spare Bit?.........................................4
- 2.2 Opcode Assignment......................................4
- 2.3 RCODE Assignment.......................................5
- 3. DNS Resource Records....................................6
- 3.1 RR TYPE IANA Considerations............................7
- 3.1.1 DNS TYPE Allocation Policy...........................8
- 3.1.2 Special Note on the OPT RR...........................9
- 3.1.3 The AFSDB RR Subtype Field...........................9
- 3.2 RR CLASS IANA Considerations...........................9
- 3.3 RR NAME Considerations................................11
- 4. Security Considerations................................11
-
- Appendix: Changes from RFC 2929...........................12
-
- Copyright and Disclaimer..................................13
- Normative References......................................13
- Informative References....................................14
-
- Authors Addresses.........................................16
- Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-1. Introduction
-
- The Domain Name System (DNS) provides replicated distributed secure
- hierarchical databases which hierarchically store "resource records"
- (RRs) under domain names. DNS data is structured into CLASSes and
- zones which can be independently maintained. See [RFC 1034, 1035,
- 2136, 2181, 4033] familiarity with which is assumed.
-
- This document provides, either directly or by reference, general IANA
- parameter assignment considerations applying across DNS query and
- response headers and all RRs. There may be additional IANA
- considerations that apply to only a particular RR type or
- query/response opcode. See the specific RFC defining that RR type or
- query/response opcode for such considerations if they have been
- defined, except for AFSDB RR considerations [RFC 1183] which are
- included herein. This RFC obsoletes [RFC 2929].
-
- IANA currently maintains a web page of DNS parameters. See
- <http://www.iana.org/numbers.htm>.
-
- "IETF Standards Action", "IETF Consensus", "Specification Required",
- and "Private Use" are as defined in [RFC 2434].
-
-
-
-2. DNS Query/Response Headers
-
- The header for DNS queries and responses contains field/bits in the
- following diagram taken from [RFC 2136, 2929]:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT/ZOCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT/PRCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT/UPCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- The ID field identifies the query and is echoed in the response so
- they can be matched.
-
- The QR bit indicates whether the header is for a query or a response.
-
-
-D. Eastlake 3rd [Page 3]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
- only in queries or only in responses, depending on the bit. However,
- many DNS implementations copy the query header as the initial value
- of the response header without clearing bits. Thus any attempt to
- use a "query" bit with a different meaning in a response or to define
- a query meaning for a "response" bit is dangerous given existing
- implementation. Such meanings may only be assigned by an IETF
- Standards Action.
-
- The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
- authority count (NSCOUNT), and additional information count (ARCOUNT)
- express the number of records in each section for all opcodes except
- Update. These fields have the same structure and data type for
- Update but are instead the counts for the zone (ZOCOUNT),
- prerequisite (PRCOUNT), update (UPCOUNT), and additional information
- (ARCOUNT) sections.
-
-
-
-2.1 One Spare Bit?
-
- There have been ancient DNS implementations for which the Z bit being
- on in a query meant that only a response from the primary server for
- a zone is acceptable. It is believed that current DNS
- implementations ignore this bit.
-
- Assigning a meaning to the Z bit requires an IETF Standards Action.
-
-
-
-2.2 Opcode Assignment
-
- Currently DNS OpCodes are assigned as follows:
-
- OpCode Name Reference
-
- 0 Query [RFC 1035]
- 1 IQuery (Inverse Query, Obsolete) [RFC 3425]
- 2 Status [RFC 1035]
- 3 available for assignment
- 4 Notify [RFC 1996]
- 5 Update [RFC 2136]
- 6-15 available for assignment
-
- New OpCode assignments require an IETF Standards Action as modified
- by [RFC 4020].
-
-
-
-
-
-
-D. Eastlake 3rd [Page 4]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-2.3 RCODE Assignment
-
- It would appear from the DNS header above that only four bits of
- RCODE, or response/error code are available. However, RCODEs can
- appear not only at the top level of a DNS response but also inside
- OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
- The OPT RR provides an eight bit extension resulting in a 12 bit
- RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
-
- Error codes appearing in the DNS header and in these three RR types
- all refer to the same error code space with the single exception of
- error code 16 which has a different meaning in the OPT RR from its
- meaning in other contexts. See table below.
-
- RCODE Name Description Reference
- Decimal
- Hexadecimal
- 0 NoError No Error [RFC 1035]
- 1 FormErr Format Error [RFC 1035]
- 2 ServFail Server Failure [RFC 1035]
- 3 NXDomain Non-Existent Domain [RFC 1035]
- 4 NotImp Not Implemented [RFC 1035]
- 5 Refused Query Refused [RFC 1035]
- 6 YXDomain Name Exists when it should not [RFC 2136]
- 7 YXRRSet RR Set Exists when it should not [RFC 2136]
- 8 NXRRSet RR Set that should exist does not [RFC 2136]
- 9 NotAuth Server Not Authoritative for zone [RFC 2136]
- 10 NotZone Name not contained in zone [RFC 2136]
- 11 - 15 Available for assignment
- 16 BADVERS Bad OPT Version [RFC 2671]
- 16 BADSIG TSIG Signature Failure [RFC 2845]
- 17 BADKEY Key not recognized [RFC 2845]
- 18 BADTIME Signature out of time window [RFC 2845]
- 19 BADMODE Bad TKEY Mode [RPC 2930]
- 20 BADNAME Duplicate key name [RPF 2930]
- 21 BADALG Algorithm not supported [RPF 2930]
-
- 22 - 3,840
- 0x0016 - 0x0F00 Available for assignment
-
- 3,841 - 4,095
- 0x0F01 - 0x0FFF Private Use
-
- 4,096 - 65,534
- 0x1000 - 0xFFFE Available for assignment
-
- 65,535
- 0xFFFF Reserved, can only be allocated by an IETF
- Standards Action.
-
-
-
-D. Eastlake 3rd [Page 5]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- Since it is important that RCODEs be understood for interoperability,
- assignment of new RCODE listed above as "available for assignment"
- requires an IETF Consensus.
-
-
-
-3. DNS Resource Records
-
- All RRs have the same top level format shown in the figure below
- taken from [RFC 1035]:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / /
- / NAME /
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | CLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TTL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RDLENGTH |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
- / RDATA /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- NAME is an owner name, i.e., the name of the node to which this
- resource record pertains. NAMEs are specific to a CLASS as described
- in section 3.2. NAMEs consist of an ordered sequence of one or more
- labels each of which has a label type [RFC 1035, 2671].
-
- TYPE is a two octet unsigned integer containing one of the RR TYPE
- codes. See section 3.1.
-
- CLASS is a two octet unsigned integer containing one of the RR CLASS
- codes. See section 3.2.
-
- TTL is a four octet (32 bit) bit unsigned integer that specifies the
- number of seconds that the resource record may be cached before the
- source of the information should again be consulted. Zero is
- interpreted to mean that the RR can only be used for the transaction
- in progress.
-
- RDLENGTH is an unsigned 16 bit integer that specifies the length in
-
-
-D. Eastlake 3rd [Page 6]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- octets of the RDATA field.
-
- RDATA is a variable length string of octets that constitutes the
- resource. The format of this information varies according to the TYPE
- and in some cases the CLASS of the resource record.
-
-
-
-3.1 RR TYPE IANA Considerations
-
- There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
- and MetaTYPEs.
-
- Data TYPEs are the primary means of storing data. QTYPES can only be
- used in queries. Meta-TYPEs designate transient data associated with
- an particular DNS message and in some cases can also be used in
- queries. Thus far, data TYPEs have been assigned from 1 upwards plus
- the block from 100 through 103 while Q and Meta Types have been
- assigned from 255 downwards except for the OPT Meta-RR which is
- assigned TYPE 41. There have been DNS implementations which made
- caching decisions based on the top bit of the bottom byte of the RR
- TYPE.
-
- There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
- [RFC 2845], and TKEY [RFC 2930].
-
- There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
- AXFR, and IXFR.
-
- Considerations for the allocation of new RR TYPEs are as follows:
-
- Decimal
- Hexadecimal
-
- 0
- 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
- 2535] and in other circumstances and must never be allocated
- for ordinary use.
-
- 1 - 127
- 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
- TYPEs by the DNS TYPE Allocation Policy as specified in
- section 3.1.1.
-
- 128 - 255
- 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
- Meta TYPEs by the DNS TYPE Allocation Policy as specified in
- section 3.1.1.
-
-
-
-
-D. Eastlake 3rd [Page 7]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- 256 - 32,767
- 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
- TYPE Allocation Policy as specified in section 3.1.1.
-
- 32,768 - 65,279
- 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
- 65,280 - 65534
- 0xFF00 - 0xFFFE - Private Use.
-
- 65,535
- 0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-
-3.1.1 DNS TYPE Allocation Policy
-
- Parameter values specified above as assigned based on DNS TYPE
- Allocation Policy. That is, Expert Review with the additional
- requirement that the review be based on a complete template as
- specified below which has been posted for three weeks to the
- namedroppers@ops.ietf.org mailing list.
-
- Partial or draft templates may be posted with the intend of
- soliciting feedback.
-
-
- DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
-
- Date:
-
- Name and email of originator:
-
- Pointer to internet-draft or other document giving a detailed
- description of the protocol use of the new RR Type:
-
- What need is the new RR TYPE intended to fix?
-
- What existing RR TYPE(s) come closest to filling that need and why are
- they unsatisfactory?
-
- Does the proposed RR TYPR require special handling within the DNS
- different from an Unknown RR TYPE?
-
- Comments:
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-3.1.2 Special Note on the OPT RR
-
- The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its
- primary purpose is to extend the effective field size of various DNS
- fields including RCODE, label type, OpCode, flag bits, and RDATA
- size. In particular, for resolvers and servers that recognize it, it
- extends the RCODE field from 4 to 12 bits.
-
-
-
-3.1.3 The AFSDB RR Subtype Field
-
- The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
- RDATA field structure as the MX RR but the 16 bit unsigned integer
- field at the beginning of the RDATA is interpreted as a subtype as
- follows:
-
- Decimal
- Hexadecimal
-
- 0
- 0x0000 - Allocation requires IETF Standards Action.
-
- 1
- 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
-
- 2
- 0x0002 - DCE/NCA root cell directory node [RFC 1183].
-
- 3 - 65,279
- 0x0003 - 0xFEFF - Allocation by IETF Consensus.
-
- 65,280 - 65,534
- 0xFF00 - 0xFFFE - Private Use.
-
- 65,535
- 0xFFFF - Reserved, allocation requires IETF Standards Action.
-
-
-
-3.2 RR CLASS IANA Considerations
-
- DNS CLASSes have been little used but constitute another dimension of
- the DNS distributed database. In particular, there is no necessary
- relationship between the name space or root servers for one CLASS and
- those for another CLASS. The same name can have completely different
- meanings in different CLASSes; however, the label types are the same
- and the null label is usable only as root in every CLASS. However,
- as global networking and DNS have evolved, the IN, or Internet, CLASS
- has dominated DNS use.
-
-
-D. Eastlake 3rd [Page 9]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- There are two subcategories of DNS CLASSes: normal data containing
- classes and QCLASSes that are only meaningful in queries or updates.
-
- The current CLASS assignments and considerations for future
- assignments are as follows:
-
- Decimal
- Hexadecimal
-
- 0
- 0x0000 - Reserved, assignment requires an IETF Standards Action.
-
- 1
- 0x0001 - Internet (IN).
-
- 2
- 0x0002 - Available for assignment by IETF Consensus as a data CLASS.
-
- 3
- 0x0003 - Chaos (CH) [Moon 1981].
-
- 4
- 0x0004 - Hesiod (HS) [Dyer 1987].
-
- 5 - 127
- 0x0005 - 0x007F - available for assignment by IETF Consensus for data
- CLASSes only.
-
- 128 - 253
- 0x0080 - 0x00FD - available for assignment by IETF Consensus for
- QCLASSes only.
-
- 254
- 0x00FE - QCLASS None [RFC 2136].
-
- 255
- 0x00FF - QCLASS Any [RFC 1035].
-
- 256 - 32,767
- 0x0100 - 0x7FFF - Assigned by IETF Consensus.
-
- 32,768 - 65,279
- 0x8000 - 0xFEFF - Assigned based on Specification Required as defined
- in [RFC 2434].
-
- 65,280 - 65,534
- 0xFF00 - 0xFFFE - Private Use.
-
- 65,535
- 0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-D. Eastlake 3rd [Page 10]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-3.3 RR NAME Considerations
-
- DNS NAMEs are sequences of labels [RFC 1035]. The last label in each
- NAME is "ROOT" which is the zero length label. By definition, the
- null or ROOT label can not be used for any other NAME purpose.
-
- At the present time, there are two categories of label types, data
- labels and compression labels. Compression labels are pointers to
- data labels elsewhere within an RR or DNS message and are intended to
- shorten the wire encoding of NAMEs. The two existing data label
- types are sometimes referred to as Text and Binary. Text labels can,
- in fact, include any octet value including zero value octets but most
- current uses involve only [US-ASCII]. For retrieval, Text labels are
- defined to treat ASCII upper and lower case letter codes as matching
- [insensitive]. Binary labels are bit sequences [RFC 2673]. The
- Binary label type is Experimental [RFC 3363].
-
- IANA considerations for label types are given in [RFC 2671].
-
- NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon
- 1981] CLASSes are essentially for local use. The IN or Internet
- CLASS is thus the only DNS CLASS in global use on the Internet at
- this time.
-
- A somewhat out-of-date description of name allocation in the IN Class
- is given in [RFC 1591]. Some information on reserved top level
- domain names is in BCP 32 [RFC 2606].
-
-
-
-4. Security Considerations
-
- This document addresses IANA considerations in the allocation of
- general DNS parameters, not security. See [RFC 4033, 4034, 4035] for
- secure DNS considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 11]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-Appendix: Changes from RFC 2929
-
- RFC Editor: This Appendix should be deleted for publication.
-
- Changes from RFC 2929 to this draft:
-
- 1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
- Allocation Policy" and add the specification of that policy. Change
- some remaining "IETF Standards Action" allocation requirements to say
- "as modified by [RFC 4020]".
-
- 2. Updated various RFC references.
-
- 3. Mentioned that the Binary label type is now Experimental and
- IQuery is Obsolete.
-
- 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
- IETF Standards Action required.
-
- 5. Add an IANA allocation policy for the AFSDB RR Subtype field.
-
- 6. Addition of reference to case insensitive draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 12]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-Copyright and Disclaimer
-
- Copyright (C) The Internet Society (2005). This document is subject to
- the rights, licenses and restrictions contained in BCP 78, and except
- as set forth therein, the authors retain all their rights.
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Normative References
-
- [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
- Facilities", STD 13, RFC 1034, November 1987.
-
- [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
- Specifications", STD 13, RFC 1035, November 1987.
-
- [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
- Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
-
- [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
- Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
- [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
- April 1997.
-
- [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
- [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
- RFC 2673, August 1999.
-
- [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
- Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
-
-D. Eastlake 3rd [Page 13]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", September 2000.
-
- [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
- Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in
- the Domain Name System (DNS)", RFC 3363, August 2002.
-
- [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
- 2002.
-
- [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
- Standards Track Code Points", BCP 100, RFC 4020, February 2005.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements", RFC 4033, March
- 2005.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security Extensions", RFC
- 4035, March 2005.
-
- [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
- X3.4, American National Standards Institute: New York, 1968.
-
-
-
-Informative References
-
- [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
- Technical Plan - Name Service, April 1987,
-
- [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
- Institute of Technology Artificial Intelligence Laboratory, June
- 1981.
-
- [RFC 1591] - Postel, J., "Domain Name System Structure and
- Delegation", RFC 1591, March 1994.
-
- [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
- "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
- September 2000.
-
- [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
- Names", RFC 2606, June 1999.
-
- [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
-
-
-D. Eastlake 3rd [Page 14]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
- Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
- work in progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 15]
-
-
-INTERNET-DRAFT DNS IANA Considerations August 2005
-
-
-Authors Addresses
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-786-7554 (w)
- email: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires February 2006.
-
- Its file name is draft-ietf-dnsext-2929bis-01.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 16]
-
diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
deleted file mode 100644
index f0ce70ab1c99..000000000000
--- a/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-
-INTERNET-DRAFT Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-05.txt Nominum Inc.
- November 2002
-
-
- DNS Zone Transfer Protocol Clarifications
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
- In the Domain Name System, zone data is replicated among
- authoritative DNS servers by means of the "zone transfer" protocol,
- also known as the "AXFR" protocol. This memo clarifies, updates, and
- adds missing detail to the original AXFR protocol specification in
- RFC1034.
-
-1. Introduction
-
- The original definition of the DNS zone transfer protocol consists of
- a single paragraph in [RFC1034] section 4.3.5 and some additional
- notes in [RFC1035] section 6.3. It is not sufficiently detailed to
- serve as the sole basis for constructing interoperable
- implementations. This document is an attempt to provide a more
- complete definition of the protocol. Where the text in RFC1034
- conflicts with existing practice, the existing practice has been
- codified in the interest of interoperability.
-
-
-
-
-Expires May 2003 [Page 1]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-2. The zone transfer request
-
- To initiate a zone transfer, the slave server sends a zone transfer
- request to the master server over a reliable transport such as TCP.
- The form of this request is specified in sufficient detail in RFC1034
- and needs no further clarification.
-
- Implementers are advised that one server implementation in widespread
- use sends AXFR requests where the TCP message envelope size exceeds
- the DNS request message size by two octets.
-
-3. The zone transfer response
-
- If the master server is unable or unwilling to provide a zone
- transfer, it MUST respond with a single DNS message containing an
- appropriate RCODE other than NOERROR. If the master is not
- authoritative for the requested zone, the RCODE SHOULD be 9
- (NOTAUTH).
-
- Slave servers should note that some master server implementations
- will simply close the connection when denying the slave access to the
- zone. Therefore, slaves MAY interpret an immediate graceful close of
- the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
- If a zone transfer can be provided, the master server sends one or
- more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
- The zone data in a zone transfer response is a sequence of answer
- RRs. These RRs are transmitted in the answer section(s) of one or
- more DNS response messages.
-
- The AXFR protocol definition in RFC1034 does not make a clear
- distinction between response messages and answer RRs. Historically,
- DNS servers always transmitted a single answer RR per message. This
- encoding is wasteful due to the overhead of repeatedly sending DNS
- message headers and the loss of domain name compression
- opportunities. To improve efficiency, some newer servers support a
- mode where multiple RRs are transmitted in a single DNS response
- message.
-
- A master MAY transmit multiple answer RRs per response message up to
- the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires May 2003 [Page 2]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- DNS message size. In the case of a small zone, this can cause the
- entire transfer to be transmitted in a single response message.
-
- Slaves MUST accept messages containing any number of answer RRs. For
- compatibility with old slaves, masters that support sending multiple
- answers per message SHOULD be configurable to revert to the
- historical mode of one answer per message, and the configuration
- SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
- RFC1034 does not specify the contents of the DNS message header of
- the zone transfer response messages. The header of each message MUST
- be as follows:
-
- ID Copy from request
- QR 1
- OPCODE QUERY
- AA 1, but MAY be 0 when RCODE is not NOERROR
- TC 0
- RD Copy from request, or 0
- RA Set according to availability of recursion, or 0
- Z 0
- AD 0
- CD 0
- RCODE NOERROR on success, error code otherwise
-
- The slave MUST check the RCODE in each message and abort the transfer
- if it is not NOERROR. It SHOULD check the ID of the first message
- received and abort the transfer if it does not match the ID of the
- request. The ID SHOULD be ignored in subsequent messages, and fields
- other than RCODE and ID SHOULD be ignored in all messages, to ensure
- interoperability with certain older implementations which transmit
- incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
- Zone transfer responses are not subject to any kind of additional
- section processing or automatic inclusion of SIG records. SIG RRs in
- the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
- RFC1034 does not specify whether zone transfer response messages have
- a question section or not. The initial message of a zone transfer
- response SHOULD have a question section identical to that in the
- request. Subsequent messages SHOULD NOT have a question section,
- though the final message MAY. The receiving slave server MUST accept
-
-
-
-Expires May 2003 [Page 3]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- any combination of messages with and without a question section.
-
-3.5. The authority section
-
- The master server MUST transmit messages with an empty authority
- section. Slaves MUST ignore any authority section contents they may
- receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
- The additional section MAY contain additional RRs such as transaction
- signatures. The slave MUST ignore any unexpected RRs in the
- additional section. It MUST NOT treat additional section RRs as zone
- data.
-
-4. Zone data
-
- The purpose of the zone transfer mechanism is to exactly replicate at
- each slave the set of RRs associated with a particular zone at its
- primary master. An RR is associated with a zone by being loaded from
- the master file of that zone at the primary master server, or by some
- other, equivalent method for configuring zone data.
-
- This replication shall be complete and unaltered, regardless of how
- many and which intermediate masters/slaves are involved, and
- regardless of what other zones those intermediate masters/slaves do
- or do not serve, and regardless of what data may be cached in
- resolvers associated with the intermediate masters/slaves.
-
- Therefore, in a zone transfer the master MUST send exactly those
- records that are associated with the zone, whether or not their owner
- names would be considered to be "in" the zone for purposes of
- resolution, and whether or not they would be eligible for use as glue
- in responses. The transfer MUST NOT include any RRs that are not
- associated with the zone, such as RRs associated with zones other
- than the one being transferred or present in the cache of the local
- resolver, even if their owner names are in the zone being transferred
- or are pointed to by NS records in the zone being transferred.
-
- The slave MUST associate the RRs received in a zone transfer with the
- specific zone being transferred, and maintain that association for
- purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
- RFC1034 states that "The first and last messages must contain the
- data for the top authoritative node of the zone". This is not
- consistent with existing practice. All known master implementations
-
-
-
-Expires May 2003 [Page 4]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- send, and slave implementations expect to receive, the zone's SOA RR
- as the first and last record of the transfer.
-
- Therefore, the quoted sentence is hereby superseded by the sentence
- "The first and last RR transmitted must be the SOA record of the
- zone".
-
- The initial and final SOA record MUST be identical, with the possible
- exception of case and compression. In particular, they MUST have the
- same serial number. The slave MUST consider the transfer to be
- complete when, and only when, it has received the message containing
- the second SOA record.
-
- The transmission order of all other RRs in the zone is undefined.
- Each of them SHOULD be transmitted only once, and slaves MUST ignore
- any duplicate RRs received.
-
-6. Security Considerations
-
- The zone transfer protocol as defined in [RFC1034] and clarified by
- this memo does not have any built-in mechanisms for the slave to
- securely verify the identity of the master server and the integrity
- of the transferred zone data. The use of a cryptographic mechanism
- for ensuring authenticity and integrity, such as TSIG [RFC2845],
- IPSEC, or TLS, is RECOMMENDED.
-
- The zone transfer protocol allows read-only public access to the
- complete zone data. Since data in the DNS is public by definition,
- this is generally acceptable. Sites that wish to avoid disclosing
- their full zone data MAY restrict zone transfer access to authorized
- slaves.
-
- These clarifications are not believed to themselves introduce any new
- security problems, nor to solve any existing ones.
-
-Acknowledgements
-
- Many people have contributed input and commentary to earlier versions
- of this document, including but not limited to Bob Halley, Dan
- Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
- Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
- Trenholme, and Brian Wellington.
-
-References
-
- [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
- November 1987.
-
-
-
-
-Expires May 2003 [Page 5]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- [RFC1035] - Domain Names - Implementation and Specifications, P.
- Mockapetris, November 1987.
-
- [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
- S. Bradner, BCP 14, March 1997.
-
- [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
- Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
- Andreas Gustafsson
- Nominum Inc.
- 2385 Bay Rd
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6004
-
- Email: gson@nominum.com
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000 - 2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implmentation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-
-
-
-Expires May 2003 [Page 6]
-
-draft-ietf-dnsext-axfr-clarify-05.txt November 2002
-
-
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2003 [Page 7]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt b/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
deleted file mode 100644
index 07749d954947..000000000000
--- a/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
+++ /dev/null
@@ -1,674 +0,0 @@
-
-
-
-
-DNSEXT M. Stapp
-Internet-Draft Cisco Systems, Inc.
-Expires: September 1, 2006 T. Lemon
- Nominum, Inc.
- A. Gustafsson
- Araneus Information Systems Oy
- February 28, 2006
-
-
- A DNS RR for Encoding DHCP Information (DHCID RR)
- <draft-ietf-dnsext-dhcid-rr-12.txt>
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on September 1, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- It is possible for DHCP clients to attempt to update the same DNS
- FQDN or attempt to update a DNS FQDN that has been added to the DNS
- for another purpose as they obtain DHCP leases. Whether the DHCP
- server or the clients themselves perform the DNS updates, conflicts
- can arise. To resolve such conflicts, "Resolution of DNS Name
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 1]
-
-Internet-Draft The DHCID RR February 2006
-
-
- Conflicts" [1] proposes storing client identifiers in the DNS to
- unambiguously associate domain names with the DHCP clients to which
- they refer. This memo defines a distinct RR type for this purpose
- for use by DHCP clients and servers, the "DHCID" RR.
-
-
-Table of Contents
-
- 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1. DHCID RDATA format . . . . . . . . . . . . . . . . . . . . 3
- 3.2. DHCID Presentation Format . . . . . . . . . . . . . . . . 4
- 3.3. The DHCID RR Identifier Type Codes . . . . . . . . . . . . 4
- 3.4. The DHCID RR Digest Type Code . . . . . . . . . . . . . . 4
- 3.5. Computation of the RDATA . . . . . . . . . . . . . . . . . 5
- 3.5.1. Using the Client's DUID . . . . . . . . . . . . . . . 5
- 3.5.2. Using the Client Identifier Option . . . . . . . . . . 5
- 3.5.3. Using the Client's htype and chaddr . . . . . . . . . 6
- 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 6
- 3.6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 6
- 3.6.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 7
- 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . . 7
- 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
- Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 2]
-
-Internet-Draft The DHCID RR February 2006
-
-
-1. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [2].
-
-
-2. Introduction
-
- A set of procedures to allow DHCP [6] [10] clients and servers to
- automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed
- in "Resolution of DNS Name Conflicts" [1].
-
- Conflicts can arise if multiple DHCP clients wish to use the same DNS
- name or a DHCP client attempts to use a name added for another
- purpose. To resolve such conflicts, "Resolution of DNS Name
- Conflicts" [1] proposes storing client identifiers in the DNS to
- unambiguously associate domain names with the DHCP clients using
- them. In the interest of clarity, it is preferable for this DHCP
- information to use a distinct RR type. This memo defines a distinct
- RR for this purpose for use by DHCP clients or servers, the "DHCID"
- RR.
-
- In order to obscure potentially sensitive client identifying
- information, the data stored is the result of a one-way SHA-256 hash
- computation. The hash includes information from the DHCP client's
- message as well as the domain name itself, so that the data stored in
- the DHCID RR will be dependent on both the client identification used
- in the DHCP protocol interaction and the domain name. This means
- that the DHCID RDATA will vary if a single client is associated over
- time with more than one name. This makes it difficult to 'track' a
- client as it is associated with various domain names.
-
-
-3. The DHCID RR
-
- The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
- DHCID RR is only defined in the IN class. DHCID RRs cause no
- additional section processing. The DHCID RR is not a singleton type.
-
-3.1. DHCID RDATA format
-
- The RDATA section of a DHCID RR in transmission contains RDLENGTH
- octets of binary data. The format of this data and its
- interpretation by DHCP servers and clients are described below.
-
- DNS software should consider the RDATA section to be opaque. DHCP
- clients or servers use the DHCID RR to associate a DHCP client's
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 3]
-
-Internet-Draft The DHCID RR February 2006
-
-
- identity with a DNS name, so that multiple DHCP clients and servers
- may deterministically perform dynamic DNS updates to the same zone.
- From the updater's perspective, the DHCID resource record RDATA
- consists of a 2-octet identifier type, in network byte order,
- followed by a 1-octet digest type, followed by one or more octets
- representing the actual identifier:
-
- < 2 octets > Identifier type code
- < 1 octet > Digest type code
- < n octets > Digest (length depends on digest type)
-
-3.2. DHCID Presentation Format
-
- In DNS master files, the RDATA is represented as a single block in
- base 64 encoding identical to that used for representing binary data
- in RFC 3548 [7]. The data may be divided up into any number of white
- space separated substrings, down to single base 64 digits, which are
- concatenated to form the complete RDATA. These substrings can span
- lines using the standard parentheses.
-
-3.3. The DHCID RR Identifier Type Codes
-
- The DHCID RR Identifier Type Code specifies what data from the DHCP
- client's request was used as input into the hash function. The
- identifier type codes are defined in a registry maintained by IANA,
- as specified in Section 7. The initial list of assigned values for
- the identifier type code is:
-
- 0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
- 0x0001 = The data octets (i.e., the Type and Client-Identifier
- fields) from a DHCPv4 client's Client Identifier option [9].
- 0x0002 = The client's DUID (i.e., the data octets of a DHCPv6
- client's Client Identifier option [10] or the DUID field from a
- DHCPv4 client's Client Identifier option [12]).
-
- 0x0003 - 0xfffe = Available to be assigned by IANA.
-
- 0xffff = RESERVED
-
-3.4. The DHCID RR Digest Type Code
-
- The DHCID RR Digest Type Code is an identifier for the digest
- algorithm used. The digest is calculated over an identifier and the
- canonical FQDN as described in the next section.
-
- The digest type codes are defined in a registry maintained by IANA,
- as specified in Section 7. The initial list of assigned values for
- the digest type codes is: value 0 is reserved and value 1 is SHA-256.
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 4]
-
-Internet-Draft The DHCID RR February 2006
-
-
- Reserving other types requires IETF standards action. Defining new
- values will also require IETF standards action to document how DNS
- updaters are to deal with multiple digest types.
-
-3.5. Computation of the RDATA
-
- The DHCID RDATA is formed by concatenating the 2-octet identifier
- type code with variable-length data.
-
- The RDATA for all type codes other than 0xffff, which is reserved for
- future expansion, is formed by concatenating the 2-octet identifier
- type code, the 1-octet digest type code, and the digest value (32
- octets for SHA-256).
-
- < identifier-type > < digest-type > < digest >
-
- The input to the digest hash function is defined to be:
-
- digest = SHA-256(< identifier > < FQDN >)
-
- The FQDN is represented in the buffer in unambiguous canonical form
- as described in RFC 4034 [8], section 6.1. The identifier type code
- and the identifier are related as specified in Section 3.3: the
- identifier type code describes the source of the identifier.
-
- A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
- option is present in the DHCPv4 messages and it is encoded as
- specified in [12]. Otherwise, the updater uses 0x0001 if a Client
- Identifier option is present and 0x0000 if not.
-
- A DHCPv6 updater always uses the 0x0002 type code.
-
-3.5.1. Using the Client's DUID
-
- When the updater is using the Client's DUID (either from a DHCPv6
- Client Identifier option or from a portion of the DHCPv4 Client
- Identifier option encoded as specified in [12]), the first two octets
- of the DHCID RR MUST be 0x0002, in network byte order. The third
- octet is the digest type code (1 for SHA-256). The rest of the DHCID
- RR MUST contain the results of computing the SHA-256 hash across the
- octets of the DUID followed by the FQDN.
-
-3.5.2. Using the Client Identifier Option
-
- When the updater is using the DHCPv4 Client Identifier option sent by
- the client in its DHCPREQUEST message, the first two octets of the
- DHCID RR MUST be 0x0001, in network byte order. The third octet is
- the digest type code (1 for SHA-256). The rest of the DHCID RR MUST
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 5]
-
-Internet-Draft The DHCID RR February 2006
-
-
- contain the results of computing the SHA-256 hash across the data
- octets (i.e., the Type and Client-Identifier fields) of the option,
- followed by the FQDN.
-
-3.5.3. Using the Client's htype and chaddr
-
- When the updater is using the client's link-layer address as the
- identifier, the first two octets of the DHCID RDATA MUST be zero.
- The third octet is the digest type code (1 for SHA-256). To generate
- the rest of the resource record, the updater computes a one-way hash
- using the SHA-256 algorithm across a buffer containing the client's
- network hardware type, link-layer address, and the FQDN data.
- Specifically, the first octet of the buffer contains the network
- hardware type as it appeared in the DHCP 'htype' field of the
- client's DHCPREQUEST message. All of the significant octets of the
- 'chaddr' field in the client's DHCPREQUEST message follow, in the
- same order in which the octets appear in the DHCPREQUEST message.
- The number of significant octets in the 'chaddr' field is specified
- in the 'hlen' field of the DHCPREQUEST message. The FQDN data, as
- specified above, follows.
-
-3.6. Examples
-
-3.6.1. Example 1
-
- A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
- Ethernet MAC address 01:02:03:04:05:06 using domain name
- "client.example.com" uses the client's link-layer address to identify
- the client. The DHCID RDATA is composed by setting the two type
- octets to zero, the 1-octet digest type to 1 for SHA-256, and
- performing an SHA-256 hash computation across a buffer containing the
- Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
- domain name (represented as specified in Section 3.5).
-
- client.example.com. A 10.0.0.1
- client.example.com. DHCID ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
- ytcKD//7es/deY= )
-
- If the DHCID RR type is not supported, the RDATA would be encoded
- [13] as:
-
- \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
- fffedeb3f75e6 )
-
-3.6.2. Example 2
-
- A DHCP server allocates the IPv4 address 10.0.12.99 to a client which
- included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 6]
-
-Internet-Draft The DHCID RR February 2006
-
-
- in its DHCP request. The server updates the name "chi.example.com"
- on the client's behalf, and uses the DHCP client identifier option
- data as input in forming a DHCID RR. The DHCID RDATA is formed by
- setting the two type octets to the value 0x0001, the 1-octet digest
- type to 1 for SHA-256, and performing a SHA-256 hash computation
- across a buffer containing the seven octets from the client-id option
- and the FQDN (represented as specified in Section 3.5).
-
- chi.example.com. A 10.0.12.99
- chi.example.com. DHCID ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
- L3b/NaiUDlW2No= )
-
- If the DHCID RR type is not supported, the RDATA would be encoded
- [13] as:
-
- \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
- 6a2503956d8da )
-
-3.6.3. Example 3
-
- A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
- which included the DHCPv6 client-identifier option data 00:01:00:06:
- 41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request. The server
- updates the name "chi6.example.com" on the client's behalf, and uses
- the DHCP client identifier option data as input in forming a DHCID
- RR. The DHCID RDATA is formed by setting the two type octets to the
- value 0x0002, the 1-octet digest type to 1 for SHA-256, and
- performing a SHA-256 hash computation across a buffer containing the
- 14 octets from the client-id option and the FQDN (represented as
- specified in Section 3.5).
-
- chi6.example.com. AAAA 2000::1234:5678
- chi6.example.com. DHCID ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
- OjxfNuVAA2kjEA= )
-
- If the DHCID RR type is not supported, the RDATA would be encoded
- [13] as:
-
- \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
- b95000da48c40 )
-
-
-4. Use of the DHCID RR
-
- This RR MUST NOT be used for any purpose other than that detailed in
- "Resolution of DNS Name Conflicts" [1]. Although this RR contains
- data that is opaque to DNS servers, the data must be consistent
- across all entities that update and interpret this record.
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 7]
-
-Internet-Draft The DHCID RR February 2006
-
-
- Therefore, new data formats may only be defined through actions of
- the DHC Working Group, as a result of revising [1].
-
-
-5. Updater Behavior
-
- The data in the DHCID RR allows updaters to determine whether more
- than one DHCP client desires to use a particular FQDN. This allows
- site administrators to establish policy about DNS updates. The DHCID
- RR does not establish any policy itself.
-
- Updaters use data from a DHCP client's request and the domain name
- that the client desires to use to compute a client identity hash, and
- then compare that hash to the data in any DHCID RRs on the name that
- they wish to associate with the client's IP address. If an updater
- discovers DHCID RRs whose RDATA does not match the client identity
- that they have computed, the updater SHOULD conclude that a different
- client is currently associated with the name in question. The
- updater SHOULD then proceed according to the site's administrative
- policy. That policy might dictate that a different name be selected,
- or it might permit the updater to continue.
-
-
-6. Security Considerations
-
- The DHCID record as such does not introduce any new security problems
- into the DNS. In order to obscure the client's identity information,
- a one-way hash is used. And, in order to make it difficult to
- 'track' a client by examining the names associated with a particular
- hash value, the FQDN is included in the hash computation. Thus, the
- RDATA is dependent on both the DHCP client identification data and on
- each FQDN associated with the client.
-
- However, it should be noted that an attacker that has some knowledge,
- such as of MAC addresses commonly used in DHCP client identification
- data, may be able to discover the client's DHCP identify by using a
- brute-force attack. Even without any additional knowledge, the
- number of unknown bits used in computing the hash is typically only
- 48 to 80.
-
- Administrators should be wary of permitting unsecured DNS updates to
- zones, whether or not they are exposed to the global Internet. Both
- DHCP clients and servers SHOULD use some form of update
- authentication (e.g., TSIG [11]) when performing DNS updates.
-
-
-7. IANA Considerations
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 8]
-
-Internet-Draft The DHCID RR February 2006
-
-
- IANA is requested to allocate a DNS RR type number for the DHCID
- record type.
-
- This specification defines a new number-space for the 2-octet
- identifier type codes associated with the DHCID RR. IANA is
- requested to establish a registry of the values for this number-
- space. Three initial values are assigned in Section 3.3, and the
- value 0xFFFF is reserved for future use. New DHCID RR identifier
- type codes are assigned through Standards Action, as defined in RFC
- 2434 [5].
-
- This specification defines a new number-space for the 1-octet digest
- type codes associated with the DHCID RR. IANA is requested to
- establish a registry of the values for this number-space. Two
- initial values are assigned in Section 3.4. New DHCID RR digest type
- codes are assigned through Standards Action, as defined in RFC 2434
- [5].
-
-
-8. Acknowledgements
-
- Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
- Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
- Volz for their review and suggestions.
-
-
-9. References
-
-9.1. Normative References
-
- [1] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
- DHCP Clients (draft-ietf-dhc-dns-resolution-*)", February 2006.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [4] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-
-
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 9]
-
-Internet-Draft The DHCID RR February 2006
-
-
-9.2. Informative References
-
- [6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
- [7] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
- RFC 3548, July 2003.
-
- [8] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 2132, March 1997.
-
- [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
- Carney, "Dynamic Host Configuration Protocol for IPv6
- (DHCPv6)", RFC 3315, July 2003.
-
- [11] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [12] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
- for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
- RFC 4361, February 2006.
-
- [13] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 10]
-
-Internet-Draft The DHCID RR February 2006
-
-
-Authors' Addresses
-
- Mark Stapp
- Cisco Systems, Inc.
- 1414 Massachusetts Ave.
- Boxborough, MA 01719
- USA
-
- Phone: 978.936.1535
- Email: mjs@cisco.com
-
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- Email: mellon@nominum.com
-
-
- Andreas Gustafsson
- Araneus Information Systems Oy
- Ulappakatu 1
- 02320 Espoo
- Finland
-
- Email: gson@araneus.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 11]
-
-Internet-Draft The DHCID RR February 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Stapp, et al. Expires September 1, 2006 [Page 12]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
deleted file mode 100644
index 438e8008a4c7..000000000000
--- a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
+++ /dev/null
@@ -1,1397 +0,0 @@
-DNS Extensions Working Group G. Sisson
-Internet-Draft B. Laurie
-Expires: January 11, 2006 Nominet
- July 10, 2005
-
-
- Derivation of DNS Name Predecessor and Successor
- draft-ietf-dnsext-dns-name-p-s-00
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on January 11, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document describes two methods for deriving the canonically-
- ordered predecessor and successor of a DNS name. These methods may
- be used for dynamic NSEC resource record synthesis, enabling
- security-aware name servers to provide authenticated denial of
- existence without disclosing other owner names in a DNSSEC-secured
- zone.
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 1]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
- 3. Absolute Method . . . . . . . . . . . . . . . . . . . . . . . 4
- 3.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 4
- 3.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 4
- 4. Modified Method . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1. Derivation of DNS Name Predecessor . . . . . . . . . . . . 6
- 4.2. Derivation of DNS Name Successor . . . . . . . . . . . . . 6
- 5. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 5.1. Case Considerations . . . . . . . . . . . . . . . . . . . 7
- 5.2. Choice of Range . . . . . . . . . . . . . . . . . . . . . 7
- 5.3. Wild Card Considerations . . . . . . . . . . . . . . . . . 8
- 5.4. Possible Modifications . . . . . . . . . . . . . . . . . . 8
- 5.4.1. Restriction of Effective Maximum DNS Name Length . . . 8
- 5.4.2. Use of Modified Method With Zones Containing
- SRV RRs . . . . . . . . . . . . . . . . . . . . . . . 9
- 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 6.1. Examples of Immediate Predecessors Using Absolute
- Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 6.2. Examples of Immediate Successors Using Absolute Method . . 13
- 6.3. Examples of Predecessors Using Modified Method . . . . . . 19
- 6.4. Examples of Successors Using Modified Method . . . . . . . 20
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
- Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22
- A.1. Changes from sisson-02 to ietf-00 . . . . . . . . . . . . 22
- A.2. Changes from sisson-01 to sisson-02 . . . . . . . . . . . 23
- A.3. Changes from sisson-00 to sisson-01 . . . . . . . . . . . 23
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
- Intellectual Property and Copyright Statements . . . . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 2]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
-1. Introduction
-
- One of the proposals for avoiding the exposure of zone information
- during the deployment DNSSEC is dynamic NSEC resource record (RR)
- synthesis. This technique is described in [I-D.ietf-dnsext-dnssec-
- trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the
- generation of NSEC RRs that just span the query name for non-existent
- owner names. In order to do this, the DNS names which would occur
- just prior to and just following a given query name must be
- calculated in real time, as maintaining a list of all possible owner
- names that might occur in a zone would be impracticable.
-
- Section 6.1 of [RFC4034] defines canonical DNS name order. This
- document does not amend or modify this definition. However, the
- derivation of immediate predecessor and successor, while trivial, is
- non-obvious. Accordingly, several methods are described here as an
- aid to implementors and a reference to other interested parties.
-
- This document describes two methods:
-
- 1. An ``absolute method'', which returns the immediate predecessor
- or successor of a domain name such that no valid DNS name could
- exist between that DNS name and the predecessor or successor.
-
- 2. A ``modified method'', which returns a predecessor and successor
- which are more economical in size and computation. This method
- is restricted to use with zones consisting only of single-label
- owner names where a maximum-length owner name would not result in
- a DNS name exceeding the maximum DNS name length. This is,
- however, the type of zone for which the technique of online-
- signing is most likely to be used.
-
-
-2. Notational Conventions
-
- The following notational conventions are used in this document for
- economy of expression:
-
- N: An unspecified DNS name.
-
- P(N): Immediate predecessor to N (absolute method).
-
- S(N): Immediate successor to N (absolute method).
-
- P'(N): Predecessor to N (modified method).
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 3]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- S'(N): Successor to N (modified method).
-
-
-3. Absolute Method
-
- These derivations assume that all uppercase US-ASCII letters in N
- have already been replaced by their corresponding lowercase
- equivalents. Unless otherwise specified, processing stops after the
- first step in which a condition is met.
-
-3.1. Derivation of DNS Name Predecessor
-
- To derive P(N):
-
- 1. If N is the same as the owner name of the zone apex, prepend N
- repeatedly with labels of the maximum length possible consisting
- of octets of the maximum sort value (e.g. 0xff) until N is the
- maximum length possible; otherwise continue to the next step.
-
- 2. If the least significant (left-most) label of N consists of a
- single octet of the minimum sort value (e.g. 0x00), remove that
- label; otherwise continue to the next step.
-
- 3. If the least significant (right-most) octet in the least
- significant (left-most) label of N is the minimum sort value,
- remove the least significant octet and continue with step 5.
-
- 4. Decrement the value of the least significant (right-most) octet,
- skipping any values that correspond to uppercase US-ASCII
- letters, and then append the label with as many octets as
- possible of the maximum sort value. Continue to the next step.
-
- 5. Prepend N repeatedly with labels of as long a length as possible
- consisting of octets of the maximum sort value until N is the
- maximum length possible.
-
-3.2. Derivation of DNS Name Successor
-
- To derive S(N):
-
- 1. If N is two or more octets shorter than the maximum DNS name
- length, prepend N with a label containing a single octet of the
- minimum sort value (e.g. 0x00); otherwise continue to the next
- step.
-
- 2. If N is one or more octets shorter than the maximum DNS name
- length and the least significant (left-most) label is one or more
- octets shorter than the maximum label length, append an octet of
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 4]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- the minimum sort value to the least significant label; otherwise
- continue to the next step.
-
- 3. Increment the value of the least significant (right-most) octet
- in the least significant (left-most) label that is less than the
- maximum sort value (e.g. 0xff), skipping any values that
- correspond to uppercase US-ASCII letters, and then remove any
- octets to the right of that one. If all octets in the label are
- the maximum sort value, then continue to the next step.
-
- 4. Remove the least significant (left-most) label. If N is now the
- same as the owner name of the zone apex, do nothing. (This will
- occur only if N is the maximum possible name in canonical DNS
- name order, and thus has wrapped to the owner name of zone apex.)
- Otherwise repeat starting at step 2.
-
-
-4. Modified Method
-
- This method is for use with zones consisting only of single-label
- owner names where an owner name consisting of label of maximum length
- would not result in a DNS name which exceeded the maximum DNS name
- length. This method is computationally simpler and returns values
- which are more economical in size than the absolute method. It
- differs from the absolute method detailed above in the following
- ways:
-
- 1. Step 1 of the derivation P(N) has been omitted as the existence
- of the owner name of the zone apex never requires denial.
-
- 2. A new step 1 has been introduced which removes unnecessary
- labels.
-
- 3. Step 4 of the derivation P(N) has been omitted as it is only
- necessary for zones containing owner names consisting of more
- than one label. This omission generally results in a significant
- reduction of the length of derived predecessors.
-
- 4. Step 1 of the derivation S(N) had been omitted as it is only
- necessary for zones containing owner names consisting of more
- than one label. This omission results in a tiny reduction of the
- length of derived successors, and maintains consistency with the
- modification of step 4 of the derivation P(N) described above.
-
- 5. Steps 2 and 4 of the derivation S(N) have been modified to
- eliminate checks for maximum DNS name length, as it is an
- assumption of this method that no DNS name in the zone can exceed
- the maximum DNS name length.
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 5]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- These derivations assume that all uppercase US-ASCII letters in N
- have already been replaced by their corresponding lowercase
- equivalents. Unless otherwise specified, processing stops after the
- first step in which a condition is met.
-
-4.1. Derivation of DNS Name Predecessor
-
- To derive P'(N):
-
- 1. If N has more labels than the number of labels in the owner name
- of the apex + 1, repeatedly remove the least significant (left-
- most) label until N has no more labels than the number of labels
- in the owner name of the apex + 1; otherwise continue to next
- step.
-
- 2. If the least significant (left-most) label of N consists of a
- single octet of the minimum sort value (e.g. 0x00), remove that
- label; otherwise continue to the next step.
-
- 3. If the least significant (right-most) octet in the least
- significant (left-most) label of N is the minimum sort value,
- remove the least significant octet.
-
- 4. Decrement the value of the least significant (right-most) octet,
- skipping any values which correspond to uppercase US-ASCII
- letters, and then append the label with as many octets as
- possible of the maximum sort value.
-
-4.2. Derivation of DNS Name Successor
-
- To derive S'(N):
-
- 1. If N has more labels than the number of labels in the owner name
- of the apex + 1, repeatedly remove the least significant (left-
- most) label until N has no more labels than the number of labels
- in the owner name of the apex + 1. Continue to next step.
-
- 2. If the least significant (left-most) label of N is one or more
- octets shorter than the maximum label length, append an octet of
- the minimum sort value to the least significant label; otherwise
- continue to the next step.
-
- 3. Increment the value of the least significant (right-most) octet
- in the least significant (left-most) label that is less than the
- maximum sort value (e.g. 0xff), skipping any values which
- correspond to uppercase US-ASCII letters, and then remove any
- octets to the right of that one. If all octets in the label are
- the maximum sort value, then continue to the next step.
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 6]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- 4. Remove the least significant (left-most) label. (This will occur
- only if the least significant label is the maximum label length
- and consists entirely of octets of the maximum sort value, and
- thus has wrapped to the owner name of the zone apex.)
-
-
-5. Notes
-
-5.1. Case Considerations
-
- Section 3.5 of [RFC1034] specifies that "while upper and lower case
- letters are allowed in [DNS] names, no significance is attached to
- the case". Additionally, Section 6.1 of [RFC4034] states that when
- determining canonical DNS name order, "uppercase US-ASCII letters are
- treated as if they were lowercase US-ASCII letters". Consequently,
- values corresponding to US-ASCII uppercase letters must be skipped
- when decrementing and incrementing octets in the derivations
- described in Section 3.1 and Section 3.2.
-
- The following pseudo-code is illustrative:
-
- Decrement the value of an octet:
-
- if (octet == '[') // '[' is just after uppercase 'Z'
- octet = '@'; // '@' is just prior to uppercase 'A'
- else
- octet--;
-
- Increment the value of an octet:
-
- if (octet == '@') // '@' is just prior to uppercase 'A'
- octet = '['; // '[' is just after uppercase 'Z'
- else
- octet++;
-
-5.2. Choice of Range
-
- [RFC2181] makes the clarification that "any binary string whatever
- can be used as the label of any resource record". Consequently the
- minimum sort value may be set as 0x00 and the maximum sort value as
- 0xff, and the range of possible values will be any DNS name which
- contains octets of any value other than those corresponding to
- uppercase US-ASCII letters.
-
- However, if all owner names in a zone are in the letter-digit-hyphen,
- or LDH, format specified in [RFC1034], it may be desirable to
- restrict the range of possible values to DNS names containing only
- LDH values. This has the effect of:
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 7]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- 1. making the output of tools such as `dig' and `nslookup' less
- subject to confusion;
-
- 2. minimising the impact that NSEC RRs containing DNS names with
- non-LDH values (or non-printable values) might have on faulty DNS
- resolver implementations; and
-
- 3. preventing the possibility of results which are wildcard DNS
- names (see Section 5.3).
-
- This may be accomplished by using a minimum sort value of 0x1f (US-
- ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
- character lowercase `z'), and then skipping non-LDH, non-lowercase
- values when incrementing or decrementing octets.
-
-5.3. Wild Card Considerations
-
- Neither derivation avoids the possibility that the result may be a
- DNS name containing a wildcard label, i.e. a label containing a
- single octet with the value 0x2a (US-ASCII character `*'). With
- additional tests, wildcard DNS names may be explicitly avoided;
- alternatively, if the range of octet values can be restricted to
- those corresponding to letter-digit-hyphen, or LDH, characters (see
- Section 5.2), such DNS names will not occur.
-
- Note that it is improbable that a result which is a wildcard DNS name
- will occur unintentionally; even if one does occur either as the
- owner name of, or in the RDATA of an NSEC RR, it is treated as a
- literal DNS name with no special meaning.
-
-5.4. Possible Modifications
-
-5.4.1. Restriction of Effective Maximum DNS Name Length
-
- [RFC1034] specifies that "the total number of octets that represent a
- [DNS] name (i.e., the sum of all label octets and label lengths) is
- limited to 255", including the null (zero-length) label which
- represents the root. For the purpose of deriving predecessors and
- successors during NSEC RR synthesis, the maximum DNS name length may
- be effectively restricted to the length of the longest DNS name in
- the zone. This will minimise the size of responses containing
- synthesised NSEC RRs but, especially in the case of the modified
- method, may result in some additional computational complexity.
-
- Note that this modification will have the effect of revealing
- information about the longest name in the zone. Moreover, when the
- contents of the zone changes, e.g. during dynamic updates and zone
- transfers, care must be taken to ensure that the effective maximum
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 8]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- DNS name length agrees with the new contents.
-
-5.4.2. Use of Modified Method With Zones Containing SRV RRs
-
- Normally the modified method cannot be used in zones that contain
- SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple
- labels. However the use of SRV RRs can be accommodated by various
- techniques. There are at least four possible ways to do this:
-
- 1. Use conventional NSEC RRs for the region of the zone that
- contains first-level labels beginning with the underscore (`_')
- character. For the purposes of generating these NSEC RRs, the
- existence of (possibly fictional) ownernames `9{63}' and `a'
- could be assumed, providing a lower and upper bound for this
- region. Then all queries where the QNAME doesn't exist but
- contains a first-level label beginning with an underscore could
- be handled using the normal DNSSEC protocol.
-
- This approach would make it possible to enumerate all DNS names
- in the zone containing a first-level label beginning with
- underscore, including all SRV RRs, but this may be of less a
- concern to the zone administrator than incurring the overhead of
- the absolute method or of the following variants of the modified
- method.
-
- 2. The absolute method could be used for synthesising NSEC RRs for
- all queries where the QNAME contains a leading underscore.
- However this re-introduces the susceptibility of the absolute
- method to denial of service activity, as an attacker could send
- queries for an effectively inexhaustible supply of domain names
- beginning with a leading underscore.
-
- 3. A variant of the modified method could be used for synthesising
- NSEC RRs for all queries where the QNAME contains a leading
- underscore. This variant would assume that all predecessors and
- successors to queries where the QNAME contains a leading
- underscore may consist of two lablels rather than only one. This
- introduces a little additional complexity without incurring the
- full increase in response size and computational complexity as
- the absolute method.
-
- 4. Finally, a variant the modified method which assumes that all
- owner names in the zone consist of one or two labels could be
- used. However this negates much of the reduction in response
- size of the modified method and may be nearly as computationally
- complex as the absolute method.
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 9]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
-6. Examples
-
- In the following examples:
-
- the owner name of the zone apex is "example.com.";
-
- the range of octet values is 0x00 - 0xff excluding values
- corresponding to uppercase US-ASCII letters; and
-
- non-printable octet values are expressed as three-digit decimal
- numbers preceded by a backslash (as specified in Section 5.1 of
- [RFC1035]).
-
-6.1. Examples of Immediate Predecessors Using Absolute Method
-
- Example of typical case:
-
- P(foo.example.com.) =
-
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255.\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255.\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255.fon\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255.example.com.
-
- or, in alternate notation:
-
- \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
-
- where {n} represents the number of repetitions of an octet.
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 10]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where least significant (left-most) label of DNS name
- consists of a single octet of the minimum sort value:
-
- P(\000.foo.example.com.) = foo.example.com.
-
- Example where least significant (right-most) octet of least
- significant (left-most) label has the minimum sort value:
-
- P(foo\000.example.com.) =
-
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255.\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255.\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255.\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255.foo.example.com.
-
- or, in alternate notation:
-
- \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 11]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where DNS name contains an octet which must be decremented by
- skipping values corresponding to US-ASCII uppercase letters:
-
- P(fo\[.example.com.) =
-
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255.\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255.\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255.fo\@\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255.example.com.
-
- or, in alternate notation:
-
- \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
-
- where {n} represents the number of repetitions of an octet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 12]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where DNS name is the owner name of the zone apex, and
- consequently wraps to the DNS name with the maximum possible sort
- order in the zone:
-
- P(example.com.) =
-
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255.\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255.\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255.\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255.example.com.
-
- or, in alternate notation:
-
- \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
-6.2. Examples of Immediate Successors Using Absolute Method
-
- Example of typical case:
-
- S(foo.example.com.) = \000.foo.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 13]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where DNS name is one octet short of the maximum DNS name
- length:
-
- N = fooooooooooooooooooooooooooooooooooooooooooooooo
- .ooooooooooooooooooooooooooooooooooooooooooooooo
- oooooooooooooooo.ooooooooooooooooooooooooooooooo
- oooooooooooooooooooooooooooooooo.ooooooooooooooo
- oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
-
- or, in alternate notation:
-
- fo{47}.o{63}.o{63}.o{63}.example.com.
-
- S(N) =
-
- fooooooooooooooooooooooooooooooooooooooooooooooo
- \000.ooooooooooooooooooooooooooooooooooooooooooo
- oooooooooooooooooooo.ooooooooooooooooooooooooooo
- oooooooooooooooooooooooooooooooooooo.ooooooooooo
- oooooooooooooooooooooooooooooooooooooooooooooooo
- oooo.example.com.
-
- or, in alternate notation:
-
- fo{47}\000.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 14]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where DNS name is the maximum DNS name length:
-
- N = fooooooooooooooooooooooooooooooooooooooooooooooo
- o.oooooooooooooooooooooooooooooooooooooooooooooo
- ooooooooooooooooo.oooooooooooooooooooooooooooooo
- ooooooooooooooooooooooooooooooooo.oooooooooooooo
- oooooooooooooooooooooooooooooooooooooooooooooooo
- o.example.com.
-
- or, in alternate notation:
-
- fo{48}.o{63}.o{63}.o{63}.example.com.
-
- S(N) =
-
- fooooooooooooooooooooooooooooooooooooooooooooooo
- p.oooooooooooooooooooooooooooooooooooooooooooooo
- ooooooooooooooooo.oooooooooooooooooooooooooooooo
- ooooooooooooooooooooooooooooooooo.oooooooooooooo
- oooooooooooooooooooooooooooooooooooooooooooooooo
- o.example.com.
-
- or, in alternate notation:
-
- fo{47}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 15]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where DNS name is the maximum DNS name length and the least
- significant (left-most) label has the maximum sort value:
-
- N = \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255.ooooooooooooooooooooooooooooooooooooooooooo
- oooooooooooooooooooo.ooooooooooooooooooooooooooo
- oooooooooooooooooooooooooooooooooooo.ooooooooooo
- oooooooooooooooooooooooooooooooooooooooooooooooo
- oooo.example.com.
-
- or, in alternate notation:
-
- \255{49}.o{63}.o{63}.o{63}.example.com.
-
- S(N) =
-
- oooooooooooooooooooooooooooooooooooooooooooooooo
- oooooooooooooop.oooooooooooooooooooooooooooooooo
- ooooooooooooooooooooooooooooooo.oooooooooooooooo
- ooooooooooooooooooooooooooooooooooooooooooooooo.
- example.com.
-
- or, in alternate notation:
-
- o{62}p.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 16]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where DNS name is the maximum DNS name length and the eight
- least significant (right-most) octets of the least significant (left-
- most) label have the maximum sort value:
-
- N = foooooooooooooooooooooooooooooooooooooooo\255
- \255\255\255\255\255\255\255.ooooooooooooooooooo
- oooooooooooooooooooooooooooooooooooooooooooo.ooo
- oooooooooooooooooooooooooooooooooooooooooooooooo
- oooooooooooo.ooooooooooooooooooooooooooooooooooo
- oooooooooooooooooooooooooooo.example.com.
-
- or, in alternate notation:
-
- fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
-
- S(N) =
-
- fooooooooooooooooooooooooooooooooooooooop.oooooo
- oooooooooooooooooooooooooooooooooooooooooooooooo
- ooooooooo.oooooooooooooooooooooooooooooooooooooo
- ooooooooooooooooooooooooo.oooooooooooooooooooooo
- ooooooooooooooooooooooooooooooooooooooooo.example.com.
-
- or, in alternate notation:
-
- fo{39}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 17]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where DNS name is the maximum DNS name length and contains an
- octet which must be incremented by skipping values corresponding to
- US-ASCII uppercase letters:
-
- N = fooooooooooooooooooooooooooooooooooooooooooooooo
- \@.ooooooooooooooooooooooooooooooooooooooooooooo
- oooooooooooooooooo.ooooooooooooooooooooooooooooo
- oooooooooooooooooooooooooooooooooo.ooooooooooooo
- oooooooooooooooooooooooooooooooooooooooooooooooo
- oo.example.com.
-
- or, in alternate notation:
-
- fo{47}\@.o{63}.o{63}.o{63}.example.com.
-
- S(N) =
-
- fooooooooooooooooooooooooooooooooooooooooooooooo
- \[.ooooooooooooooooooooooooooooooooooooooooooooo
- oooooooooooooooooo.ooooooooooooooooooooooooooooo
- oooooooooooooooooooooooooooooooooo.ooooooooooooo
- oooooooooooooooooooooooooooooooooooooooooooooooo
- oo.example.com.
-
- or, in alternate notation:
-
- fo{47}\[.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 18]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where DNS name has the maximum possible sort order in the
- zone, and consequently wraps to the owner name of the zone apex:
-
- N = \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255.\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255.\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255.\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255.example.com.
-
- or, in alternate notation:
-
- \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
- S(N) = example.com.
-
-6.3. Examples of Predecessors Using Modified Method
-
- Example of typical case:
-
- P'(foo.example.com.) =
-
- fon\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255.example.com.
-
- or, in alternate notation:
-
- fon\255{60}.example.com.
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 19]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where DNS name contains more labels than DNS names in the
- zone:
-
- P'(bar.foo.example.com.) = foo.example.com.
-
- Example where least significant (right-most) octet of least
- significant (left-most) label has the minimum sort value:
-
- P'(foo\000.example.com.) = foo.example.com.
-
- Example where least significant (left-most) label has the minimum
- sort value:
-
- P'(\000.example.com.) = example.com.
-
- Example where DNS name is the owner name of the zone apex, and
- consequently wraps to the DNS name with the maximum possible sort
- order in the zone:
-
- P'(example.com.) =
-
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255.example.com.
-
- or, in alternate notation:
-
- \255{63}.example.com.
-
-6.4. Examples of Successors Using Modified Method
-
- Example of typical case:
-
- S'(foo.example.com.) = foo\000.example.com.
-
- Example where DNS name contains more labels than DNS names in the
- zone:
-
- S'(bar.foo.example.com.) = foo\000.example.com.
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 20]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
- Example where least significant (left-most) label has the maximum
- sort value, and consequently wraps to the owner name of the zone
- apex:
-
- N = \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255.example.com.
-
- or, in alternate notation:
-
- \255{63}.example.com.
-
- S'(N) = example.com.
-
-
-7. Security Considerations
-
- The derivation of some predecessors/successors requires the testing
- of more conditions than others. Consequently the effectiveness of a
- denial-of-service attack may be enhanced by sending queries that
- require more conditions to be tested. The modified method involves
- the testing of fewer conditions than the absolute method and
- consequently is somewhat less susceptible to this exposure.
-
-
-8. IANA Considerations
-
- This document has no IANA actions.
-
- Note to RFC Editor: This section is included to make it clear during
- pre-publication review that this document has no IANA actions. It
- may therefore be removed should it be published as an RFC.
-
-
-9. Acknowledgments
-
- The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and
- Niall O'Reilly for their review and input.
-
-
-10. References
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 21]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
-10.1 Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", RFC 2782,
- February 2000.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
-10.2 Informative References
-
- [I-D.ietf-dnsext-dnssec-online-signing]
- Ihren, J. and S. Weiler, "Minimally Covering NSEC Records
- and DNSSEC On-line Signing",
- draft-ietf-dnsext-dnssec-online-signing-00 (work in
- progress), May 2005.
-
- [I-D.ietf-dnsext-dnssec-trans]
- Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC
- Transition Mechanisms",
- draft-ietf-dnsext-dnssec-trans-02 (work in progress),
- February 2005.
-
-
-Appendix A. Change History
-
-A.1. Changes from sisson-02 to ietf-00
-
- o Added notes on use of SRV RRs with modified method.
-
- o Changed reference from weiler-dnssec-online-signing to ietf-
- dnsext-dnssec-online-signing.
-
- o Changed reference from ietf-dnsext-dnssec-records to RFC 4034.
-
- o Miscellaneous minor changes to text.
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 22]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
-A.2. Changes from sisson-01 to sisson-02
-
- o Added modified version of derivation (with supporting examples).
-
- o Introduced notational conventions N, P(N), S(N), P'(N) and S'(N).
-
- o Added clarification to derivations about when processing stops.
-
- o Miscellaneous minor changes to text.
-
-A.3. Changes from sisson-00 to sisson-01
-
- o Split step 3 of derivation of DNS name predecessor into two
- distinct steps for clarity.
-
- o Added clarifying text and examples related to the requirement to
- avoid uppercase characters when decrementing or incrementing
- octets.
-
- o Added optimisation using restriction of effective maximum DNS name
- length.
-
- o Changed examples to use decimal rather than octal notation as per
- [RFC1035].
-
- o Corrected DNS name length of some examples.
-
- o Added reference to weiler-dnssec-online-signing.
-
- o Miscellaneous minor changes to text.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 23]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
-Authors' Addresses
-
- Geoffrey Sisson
- Nominet
- Sandford Gate
- Sandy Lane West
- Oxford
- OX4 6LB
- GB
-
- Phone: +44 1865 332339
- Email: geoff@nominet.org.uk
-
-
- Ben Laurie
- Nominet
- 17 Perryn Road
- London
- W3 7LR
- GB
-
- Phone: +44 20 8735 0686
- Email: ben@algroup.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 24]
-
-Internet-Draft DNS Name Predecessor and Successor July 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Sisson & Laurie Expires January 11, 2006 [Page 25]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
deleted file mode 100644
index bcc2b4ec516e..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+++ /dev/null
@@ -1,442 +0,0 @@
-
-
-INTERNET-DRAFT Samuel Weiler
-Expires: June 2004 December 15, 2003
-Updates: RFC 2535, [DS]
-
- Legacy Resolver Compatibility for Delegation Signer
- draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other
- documents at any time. It is inappropriate to use Internet-Drafts
- as reference material or to cite them other than as "work in
- progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Comments should be sent to the author or to the DNSEXT WG mailing
- list: namedroppers@ops.ietf.org
-
-Abstract
-
- As the DNS Security (DNSSEC) specifications have evolved, the
- syntax and semantics of the DNSSEC resource records (RRs) have
- changed. Many deployed nameservers understand variants of these
- semantics. Dangerous interactions can occur when a resolver that
- understands an earlier version of these semantics queries an
- authoritative server that understands the new delegation signer
- semantics, including at least one failure scenario that will cause
- an unsecured zone to be unresolvable. This document changes the
- type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
- avoid those interactions.
-
-Changes between 05 and 06:
-
- Signifigantly reworked the IANA section -- went back to one
- algorithm registry.
-
- Removed Diffie-Hellman from the list of zone-signing algorithms
- (leaving only DSA, RSA/SHA-1, and private algorithms).
-
- Added a DNSKEY flags field registry.
-
-Changes between 04 and 05:
-
- IESG approved publication.
-
- Cleaned up an internal reference in the acknowledgements section.
-
- Retained KEY and SIG for TKEY, too. Added TKEY (2930) reference.
-
- Changed the names of both new registries. Added algorithm
- mnemonics to the new zone signing algorithm registry. Minor
- rewording in the IANA section for clarity.
-
- Cleaned up formatting of references. Replaced unknown-rr draft
- references with RFC3597. Bumped DS version number.
-
-Changes between 03 and 04:
-
- Clarified that RRSIG(0) may be defined by standards action.
-
- Created a new algorithm registry and renamed the old algorithm
- registry for SIG(0) only. Added references to the appropriate
- crypto algorithm and format specifications.
-
- Several minor rephrasings.
-
-Changes between 02 and 03:
-
- KEY (as well as SIG) retained for SIG(0) use only.
-
-Changes between 01 and 02:
-
- SIG(0) still uses SIG, not RRSIG. Added 2931 reference.
-
- Domain names embedded in NSECs and RRSIGs are not compressible and
- are not downcased. Added unknown-rrs reference (as informative).
-
- Simplified the last paragraph of section 3 (NSEC doesn't always
- signal a negative answer).
-
- Changed the suggested type code assignments.
-
- Added 2119 reference.
-
- Added definitions of "unsecure delegation" and "unsecure referral",
- since they're not clearly defined elsewhere.
-
- Moved 2065 to informative references, not normative.
-
-1. Introduction
-
- The DNSSEC protocol has been through many iterations whose syntax
- and semantics are not completely compatible. This has occurred as
- part of the ordinary process of proposing a protocol, implementing
- it, testing it in the increasingly complex and diverse environment
- of the Internet, and refining the definitions of the initial
- Proposed Standard. In the case of DNSSEC, the process has been
- complicated by DNS's criticality and wide deployment and the need
- to add security while minimizing daily operational complexity.
-
- A weak area for previous DNS specifications has been lack of detail
- in specifying resolver behavior, leaving implementors largely on
- their own to determine many details of resolver function. This,
- combined with the number of iterations the DNSSEC spec has been
- through, has resulted in fielded code with a wide variety of
- behaviors. This variety makes it difficult to predict how a
- protocol change will be handled by all deployed resolvers. The
- risk that a change will cause unacceptable or even catastrophic
- failures makes it difficult to design and deploy a protocol change.
- One strategy for managing that risk is to structure protocol
- changes so that existing resolvers can completely ignore input that
- might confuse them or trigger undesirable failure modes.
-
- This document addresses a specific problem caused by Delegation
- Signer's [DS] introduction of new semantics for the NXT RR that are
- incompatible with the semantics in RFC 2535 [RFC2535]. Answers
- provided by DS-aware servers can trigger an unacceptable failure
- mode in some resolvers that implement RFC 2535, which provides a
- great disincentive to sign zones with DS. The changes defined in
- this document allow for the incremental deployment of DS.
-
-1.1 Terminology
-
- In this document, the term "unsecure delegation" means any
- delegation for which no DS record appears at the parent. An
- "unsecure referral" is an answer from the parent containing an NS
- RRset and a proof that no DS record exists for that name.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-1.2 The Problem
-
- Delegation Signer introduces new semantics for the NXT RR that are
- incompatible with the semantics in RFC 2535. In RFC 2535, NXT
- records were only required to be returned as part of a
- non-existence proof. With DS, an unsecure referral returns, in
- addition to the NS, a proof of non-existence of a DS RR in the form
- of an NXT and SIG(NXT). RFC 2535 didn't specify how a resolver was
- to interpret a response with both an NS and an NXT in the authority
- section, RCODE=0, and AA=0. Some widely deployed 2535-aware
- resolvers interpret any answer with an NXT as a proof of
- non-existence of the requested record. This results in unsecure
- delegations being invisible to 2535-aware resolvers and violates
- the basic architectural principle that DNSSEC must do no harm --
- the signing of zones must not prevent the resolution of unsecured
- delegations.
-
-2. Possible Solutions
-
- This section presents several solutions that were considered.
- Section 3 describes the one selected.
-
-2.1. Change SIG, KEY, and NXT type codes
-
- To avoid the problem described above, legacy (RFC2535-aware)
- resolvers need to be kept from seeing unsecure referrals that
- include NXT records in the authority section. The simplest way to
- do that is to change the type codes for SIG, KEY, and NXT.
-
- The obvious drawback to this is that new resolvers will not be able
- to validate zones signed with the old RRs. This problem already
- exists, however, because of the changes made by DS, and resolvers
- that understand the old RRs (and have compatibility issues with DS)
- are far more prevalent than 2535-signed zones.
-
-2.2. Change a subset of type codes
-
- The observed problem with unsecure referrals could be addressed by
- changing only the NXT type code or another subset of the type codes
- that includes NXT. This has the virtue of apparent simplicity, but
- it risks introducing new problems or not going far enough. It's
- quite possible that more incompatibilities exist between DS and
- earlier semantics. Legacy resolvers may also be confused by seeing
- records they recognize (SIG and KEY) while being unable to find
- NXTs. Although it may seem unnecessary to fix that which is not
- obviously broken, it's far cleaner to change all of the type codes
- at once. This will leave legacy resolvers and tools completely
- blinded to DNSSEC -- they will see only unknown RRs.
-
-2.3. Replace the DO bit
-
- Another way to keep legacy resolvers from ever seeing DNSSEC
- records with DS semantics is to have authoritative servers only
- send that data to DS-aware resolvers. It's been proposed that
- assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
- called "DA"), and having authoritative servers send DNSSEC data
- only in response to queries with the DA bit set, would accomplish
- this. This bit would presumably supplant the DO bit described in
- RFC 3225.
-
- This solution is sufficient only if all 2535-aware resolvers zero
- out EDNS0 flags that they don't understand. If one passed through
- the DA bit unchanged, it would still see the new semantics, and it
- would probably fail to see unsecure delegations. Since it's
- impractical to know how every DNS implementation handles unknown
- EDNS0 flags, this is not a universal solution. It could, though,
- be considered in addition to changing the RR type codes.
-
-2.4. Increment the EDNS version
-
- Another possible solution is to increment the EDNS version number
- as defined in RFC 2671 [RFC2671], on the assumption that all
- existing implementations will reject higher versions than they
- support, and retain the DO bit as the signal for DNSSEC awareness.
- This approach has not been tested.
-
-2.5. Do nothing
-
- There is a large deployed base of DNS resolvers that understand
- DNSSEC as defined by the standards track RFC 2535 and RFC 2065
- and, due to under specification in those documents, interpret any
- answer with an NXT as a non-existence proof. So long as that is
- the case, zone owners will have a strong incentive to not sign any
- zones that contain unsecure delegations, lest those delegations be
- invisible to such a large installed base. This will dramatically
- slow DNSSEC adoption.
-
- Unfortunately, without signed zones there's no clear incentive for
- operators of resolvers to upgrade their software to support the new
- version of DNSSEC, as defined in [DS]. Historical data suggests
- that resolvers are rarely upgraded, and that old nameserver code
- never dies.
-
- Rather than wait years for resolvers to be upgraded through natural
- processes before signing zones with unsecure delegations,
- addressing this problem with a protocol change will immediately
- remove the disincentive for signing zones and allow widespread
- deployment of DNSSEC.
-
-3. Protocol changes
-
- This document changes the type codes of SIG, KEY, and NXT. This
- approach is the cleanest and safest of those discussed above,
- largely because the behavior of resolvers that receive unknown type
- codes is well understood. This approach has also received the most
- testing.
-
- To avoid operational confusion, it's also necessary to change the
- mnemonics for these RRs. DNSKEY will be the replacement for KEY,
- with the mnemonic indicating that these keys are not for
- application use, per [RFC3445]. RRSIG (Resource Record SIGnature)
- will replace SIG, and NSEC (Next SECure) will replace NXT. These
- new types completely replace the old types, except that SIG(0)
- [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
-
- The new types will have exactly the same syntax and semantics as
- specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
- the following:
-
- 1) Consistent with [RFC3597], domain names embedded in
- RRSIG and NSEC RRs MUST NOT be compressed,
-
- 2) Embedded domain names in RRSIG and NSEC RRs are not downcased
- for purposes of DNSSEC canonical form and ordering nor for
- equality comparison, and
-
- 3) An RRSIG with a type-covered field of zero has undefined
- semantics. The meaning of such a resource record may only be
- defined by IETF Standards Action.
-
- If a resolver receives the old types, it SHOULD treat them as
- unknown RRs and SHOULD NOT assign any special meaning to them or
- give them any special treatment. It MUST NOT use them for DNSSEC
- validations or other DNS operational decision making. For example,
- a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
- validate RRSIGs. If SIG, KEY, or NXT RRs are included in a zone,
- they MUST NOT receive special treatment. As an example, if a SIG
- is included in a signed zone, there MUST be an RRSIG for it.
- Authoritative servers may wish to give error messages when loading
- zones containing SIG or NXT records (KEY records may be included
- for SIG(0) or TKEY).
-
- As a clarification to previous documents, some positive responses,
- particularly wildcard proofs and unsecure referrals, will contain
- NSEC RRs. Resolvers MUST NOT treat answers with NSEC RRs as
- negative answers merely because they contain an NSEC.
-
-4. IANA Considerations
-
-4.1 DNS Resource Record Types
-
- This document updates the IANA registry for DNS Resource Record
- Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
- DNSKEY RRs, respectively.
-
- Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
- TKEY [RFC2930] use only.
-
- Type 30 (NXT) should be marked as Obsolete.
-
-4.2 DNS Security Algorithm Numbers
-
- To allow zone signing (DNSSEC) and transaction security mechanisms
- (SIG(0) and TKEY) to use different sets of algorithms, the existing
- "DNS Security Algorithm Numbers" registry is modified to include
- the applicability of each algorithm. Specifically, two new columns
- are added to the registry, showing whether each algorithm may be
- used for zone signing, transaction security mechanisms, or both.
- Only algorithms usable for zone signing may be used in DNSKEY,
- RRSIG, and DS RRs. Only algorithms usable for SIG(0) and/or TSIG
- may be used in SIG and KEY RRs.
-
- All currently defined algorithms remain usable for transaction
- security mechanisms. Only RSA/SHA-1, DSA/SHA-1, and private
- algorithms (types 253 and 254) may be used for zone signing. Note
- that the registry does not contain the requirement level of each
- algorithm, only whether or not an algorithm may be used for the
- given purposes. For example, RSA/MD5, while allowed for
- transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
-
- Additionally, the presentation format algorithm mnemonics from
- RFC2535 Section 7 are added to the registry. This document assigns
- RSA/SHA-1 the mnemonic RSASHA1.
-
- As before, assignment of new algorithms in this registry requires
- IETF Standards Action. Additionally, modification of algorithm
- mnemonics or applicability requires IETF Standards Action.
- Documents defining a new algorithm must address the applicability
- of the algorithm and should assign a presentation mnemonic to the
- algorithm.
-
-4.3 DNSKEY Flags
-
- Like the KEY resource record, DNSKEY contains a 16-bit flags field.
- This document creates a new registry for the DNSKEY flags field.
-
- Initially, this registry only contains an assignment for bit 7 (the
- ZONE bit). Bits 0-6 and 8-15 are available for assignment by IETF
- Standards Action.
-
-4.4 DNSKEY Protocol Octet
-
- Like the KEY resource record, DNSKEY contains an eight bit protocol
- field. The only defined value for this field is 3 (DNSSEC). No
- other values are allowed, hence no IANA registry is needed for this
- field.
-
-5. Security Considerations
-
- The changes introduced here do not materially affect security.
- The implications of trying to use both new and legacy types
- together are not well understood, and attempts to do so would
- probably lead to unintended and dangerous results.
-
- Changing type codes will leave code paths in legacy resolvers that
- are never exercised. Unexercised code paths are a frequent source
- of security holes, largely because those code paths do not get
- frequent scrutiny.
-
- Doing nothing, as described in section 2.5, will slow DNSSEC
- deployment. While this does not decrease security, it also fails
- to increase it.
-
-6. Normative references
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [DS] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-15.txt, work in
- progress, June 2003.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
- RR)", RFC 2930, September 2000.
-
- [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
- System (DNS)", RFC 2436, March 1999.
-
- [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
- Domain Name System (DNS)", RFC 2539, March 1999.
-
- [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
- Domain Name System (DNS)", RFC 3110, May 2001.
-
-7. Informative References
-
- [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
- Extensions", RFC 2065, January 1997.
-
- [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
- 3225, December 2001.
-
- [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
- "Domain Name System (DNS) IANA Considerations", BCP 42,
- RFC 2929, September 2000.
-
- [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
- Resource Record (RR)", RFC 3445, December 2002.
-
- [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
- Record (RR) Types", RFC 3597, September 2003.
-
-8. Acknowledgments
-
- The changes introduced here and the analysis of alternatives had
- many contributors. With apologies to anyone overlooked, those
- include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
- Lewis, Bill Manning, and Suzanne Woolf.
-
- Thanks to Jakob Schlyter and Mark Andrews for identifying the
- incompatibility described in section 1.2.
-
- In addition to the above, the author would like to thank Scott
- Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
- comments.
-
-9. Author's Address
-
- Samuel Weiler
- SPARTA, Inc.
- 7075 Samuel Morse Drive
- Columbia, MD 21046
- USA
- weiler@tislabs.com
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
deleted file mode 100644
index 3a800f98880d..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-Network Working Group S. Weiler
-Internet-Draft SPARTA, Inc
-Updates: 4034, 4035 (if approved) May 23, 2005
-Expires: November 24, 2005
-
-
- Clarifications and Implementation Notes for DNSSECbis
- draft-ietf-dnsext-dnssec-bis-updates-01
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on November 24, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document is a collection of minor technical clarifications to
- the DNSSECbis document set. It is meant to serve as a resource to
- implementors as well as an interim repository of possible DNSSECbis
- errata.
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 1]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-Proposed additions in future versions
-
- An index sorted by the section of DNSSECbis being clarified.
-
- A list of proposed protocol changes being made in other documents,
- such as NSEC3 and Epsilon. This document would not make those
- changes, merely provide an index into the documents that are making
- changes.
-
-Changes between -00 and -01
-
- Document significantly restructured.
-
- Added section on QTYPE=ANY.
-
-Changes between personal submission and first WG draft
-
- Added Section 2.1 based on namedroppers discussions from March 9-10,
- 2005.
-
- Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
-
- Added the DNSSECbis RFC numbers.
-
- Figured out the confusion in Section 4.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 2]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-Table of Contents
-
- 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
- 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4
- 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Significant Concerns . . . . . . . . . . . . . . . . . . . . . 4
- 2.1 Clarifications on Non-Existence Proofs . . . . . . . . . . 4
- 2.2 Empty Non-Terminal Proofs . . . . . . . . . . . . . . . . 5
- 2.3 Validating Responses to an ANY Query . . . . . . . . . . . 5
- 3. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
- 3.1 Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
- 3.2 Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
- 3.3 Caution About Local Policy and Multiple RRSIGs . . . . . . 6
- 3.4 Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
- 4. Minor Corrections and Clarifications . . . . . . . . . . . . . 7
- 4.1 Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 7
- 4.2 Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 7
- 4.3 Errors in Examples . . . . . . . . . . . . . . . . . . . . 8
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
- 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 7.1 Normative References . . . . . . . . . . . . . . . . . . . 8
- 7.2 Informative References . . . . . . . . . . . . . . . . . . 9
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
- A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
- Intellectual Property and Copyright Statements . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 3]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-1. Introduction and Terminology
-
- This document lists some minor clarifications and corrections to
- DNSSECbis, as described in [1], [2], and [3].
-
- It is intended to serve as a resource for implementors and as a
- repository of items that need to be addressed when advancing the
- DNSSECbis documents from Proposed Standard to Draft Standard.
-
- In this version (-01 of the WG document), feedback is particularly
- solicited on the structure of the document and whether the text in
- the recently added sections is correct and sufficient.
-
- Proposed substantive additions to this document should be sent to the
- namedroppers mailing list as well as to the editor of this document.
- The editor would greatly prefer text suitable for direct inclusion in
- this document.
-
-1.1 Structure of this Document
-
- The clarifications to DNSSECbis are sorted according to the editor's
- impression of their importance, starting with ones which could, if
- ignored, lead to security and stability problems and progressing down
- to clarifications that are likely to have little operational impact.
- Mere typos and awkward phrasings are not addressed unless they could
- lead to misinterpretation of the DNSSECbis documents.
-
-1.2 Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [4].
-
-2. Significant Concerns
-
- This section provides clarifications that, if overlooked, could lead
- to security issues or major interoperability problems.
-
-2.1 Clarifications on Non-Existence Proofs
-
- RFC4035 Section 5.4 slightly underspecifies the algorithm for
- checking non-existence proofs. In particular, the algorithm there
- might incorrectly allow the NSEC from the parent side of a zone cut
- to prove the non-existence of either other RRs at that name in the
- child zone or other names in the child zone. It might also allow a
- NSEC at the same name as a DNAME to prove the non-existence of names
- beneath that DNAME.
-
-
-
-
-Weiler Expires November 24, 2005 [Page 4]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- A parent-side delegation NSEC (one with the NS bit set, but no SOA
- bit set, and with a singer field that's shorter than the owner name)
- must not be used to assume non-existence of any RRs below that zone
- cut (both RRs at that ownername and at ownernames with more leading
- labels, no matter their content). Similarly, an NSEC with the DNAME
- bit set must not be used to assume the non-existence of any
- descendant of that NSEC's owner name.
-
-2.2 Empty Non-Terminal Proofs
-
- To be written, based on Roy Arends' May 11th message to namedroppers.
-
-2.3 Validating Responses to an ANY Query
-
- RFC4035 does not address now to validate responses when QTYPE=*. As
- described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
- may include a subset of the RRsets at a given name -- it is not
- necessary to include all RRsets at the QNAME in the response.
-
- When validating a response to QTYPE=*, validate all received RRsets
- that match QNAME and QCLASS. If any of those RRsets fail validation,
- treat the answer as Bogus. If there are no RRsets matching QNAME and
- QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
- clarified in this document). To be clear, a validator must not
- insist on receiving all records at the QNAME in response to QTYPE=*.
-
-3. Interoperability Concerns
-
-3.1 Unknown DS Message Digest Algorithms
-
- Section 5.2 of RFC4035 includes rules for how to handle delegations
- to zones that are signed with entirely unsupported algorithms, as
- indicated by the algorithms shown in those zone's DS RRsets. It does
- not explicitly address how to handle DS records that use unsupported
- message digest algorithms. In brief, DS records using unknown or
- unsupported message digest algorithms MUST be treated the same way as
- DS records referring to DNSKEY RRs of unknown or unsupported
- algorithms.
-
- The existing text says:
-
- If the validator does not support any of the algorithms listed
- in an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
-
-
-
-Weiler Expires November 24, 2005 [Page 5]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- To paraphrase the above, when determining the security status of a
- zone, a validator discards (for this purpose only) any DS records
- listing unknown or unsupported algorithms. If none are left, the
- zone is treated as if it were unsigned.
-
- Modified to consider DS message digest algorithms, a validator also
- discards any DS records using unknown or unsupported message digest
- algorithms.
-
-3.2 Private Algorithms
-
- As discussed above, section 5.2 of RFC4035 requires that validators
- make decisions about the security status of zones based on the public
- key algorithms shown in the DS records for those zones. In the case
- of private algorithms, as described in RFC4034 Appendix A.1.1, the
- eight-bit algorithm field in the DS RR is not conclusive about what
- algorithm(s) is actually in use.
-
- If no private algorithms appear in the DS set or if any supported
- algorithm appears in the DS set, no special processing will be
- needed. In the remaining cases, the security status of the zone
- depends on whether or not the resolver supports any of the private
- algorithms in use (provided that these DS records use supported hash
- functions, as discussed in Section 3.1). In these cases, the
- resolver MUST retrieve the corresponding DNSKEY for each private
- algorithm DS record and examine the public key field to determine the
- algorithm in use. The security-aware resolver MUST ensure that the
- hash of the DNSKEY RR's owner name and RDATA matches the digest in
- the DS RR. If they do not match, and no other DS establishes that
- the zone is secure, the referral should be considered BAD data, as
- discussed in RFC4035.
-
- This clarification facilitates the broader use of private algorithms,
- as suggested by [5].
-
-3.3 Caution About Local Policy and Multiple RRSIGs
-
- When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
- suggests that "the local resolver security policy determines whether
- the resolver also has to test these RRSIG RRs and how to resolve
- conflicts if these RRSIG RRs lead to differing results." In most
- cases, a resolver would be well advised to accept any valid RRSIG as
- sufficient. If the first RRSIG tested fails validation, a resolver
- would be well advised to try others, giving a successful validation
- result if any can be validated and giving a failure only if all
- RRSIGs fail validation.
-
- If a resolver adopts a more restrictive policy, there's a danger that
-
-
-
-Weiler Expires November 24, 2005 [Page 6]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- properly-signed data might unnecessarily fail validation, perhaps
- because of cache timing issues. Furthermore, certain zone management
- techniques, like the Double Signature Zone-signing Key Rollover
- method described in section 4.2.1.2 of [6] might not work reliably.
-
-3.4 Key Tag Calculation
-
- RFC4034 Appendix B.1 incorrectly defines the Key Tag field
- calculation for algorithm 1. It correctly says that the Key Tag is
- the most significant 16 of the least significant 24 bits of the
- public key modulus. However, RFC4034 then goes on to incorrectly say
- that this is 4th to last and 3rd to last octets of the public key
- modulus. It is, in fact, the 3rd to last and 2nd to last octets.
-
-4. Minor Corrections and Clarifications
-
-4.1 Finding Zone Cuts
-
- Appendix C.8 of RFC4035 discusses sending DS queries to the servers
- for a parent zone. To do that, a resolver may first need to apply
- special rules to discover what those servers are.
-
- As explained in Section 3.1.4.1 of RFC4035, security-aware name
- servers need to apply special processing rules to handle the DS RR,
- and in some situations the resolver may also need to apply special
- rules to locate the name servers for the parent zone if the resolver
- does not already have the parent's NS RRset. Section 4.2 of RFC4035
- specifies a mechanism for doing that.
-
-4.2 Clarifications on DNSKEY Usage
-
- Questions of the form "can I use a different DNSKEY for signing the
- X" have occasionally arisen.
-
- The short answer is "yes, absolutely". You can even use a different
- DNSKEY for each RRset in a zone, subject only to practical limits on
- the size of the DNSKEY RRset. However, be aware that there is no way
- to tell resolvers what a particularly DNSKEY is supposed to be used
- for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
- authenticate any RRset in the zone. For example, if a weaker or less
- trusted DNSKEY is being used to authenticate NSEC RRsets or all
- dynamically updated records, that same DNSKEY can also be used to
- sign any other RRsets from the zone.
-
- Furthermore, note that the SEP bit setting has no effect on how a
- DNSKEY may be used -- the validation process is specifically
- prohibited from using that bit by RFC4034 section 2.1.2. It possible
- to use a DNSKEY without the SEP bit set as the sole secure entry
-
-
-
-Weiler Expires November 24, 2005 [Page 7]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- point to the zone, yet use a DNSKEY with the SEP bit set to sign all
- RRsets in the zone (other than the DNSKEY RRset). It's also possible
- to use a single DNSKEY, with or without the SEP bit set, to sign the
- entire zone, including the DNSKEY RRset itself.
-
-4.3 Errors in Examples
-
- The text in RFC4035 Section C.1 refers to the examples in B.1 as
- "x.w.example.com" while B.1 uses "x.w.example". This is painfully
- obvious in the second paragraph where it states that the RRSIG labels
- field value of 3 indicates that the answer was not the result of
- wildcard expansion. This is true for "x.w.example" but not for
- "x.w.example.com", which of course has a label count of 4
- (antithetically, a label count of 3 would imply the answer was the
- result of a wildcard expansion).
-
- The first paragraph of RFC4035 Section C.6 also has a minor error:
- the reference to "a.z.w.w.example" should instead be "a.z.w.example",
- as in the previous line.
-
-5. IANA Considerations
-
- This document specifies no IANA Actions.
-
-6. Security Considerations
-
- This document does not make fundamental changes to the DNSSEC
- protocol, as it was generally understood when DNSSECbis was
- published. It does, however, address some ambiguities and omissions
- in those documents that, if not recognized and addressed in
- implementations, could lead to security failures. In particular, the
- validation algorithm clarifications in Section 2 are critical for
- preserving the security properties DNSSEC offers. Furthermore,
- failure to address some of the interoperability concerns in Section 3
- could limit the ability to later change or expand DNSSEC, including
- by adding new algorithms.
-
-7. References
-
-7.1 Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
-
-
-Weiler Expires November 24, 2005 [Page 8]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-7.2 Informative References
-
- [5] Blacka, D., "DNSSEC Experiments",
- draft-blacka-dnssec-experiments-00 (work in progress),
- December 2004.
-
- [6] Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
- draft-ietf-dnsop-dnssec-operational-practices-04 (work in
- progress), May 2005.
-
-
-Author's Address
-
- Samuel Weiler
- SPARTA, Inc
- 7075 Samuel Morse Drive
- Columbia, Maryland 21046
- US
-
- Email: weiler@tislabs.com
-
-Appendix A. Acknowledgments
-
- The editor is extremely grateful to those who, in addition to finding
- errors and omissions in the DNSSECbis document set, have provided
- text suitable for inclusion in this document.
-
- The lack of specificity about handling private algorithms, as
- described in Section 3.2, and the lack of specificity in handling ANY
- queries, as described in Section 2.3, were discovered by David
- Blacka.
-
- The error in algorithm 1 key tag calculation, as described in
- Section 3.4, was found by Abhijit Hayatnagarkar. Donald Eastlake
- contributed text for Section 3.4.
-
- The bug relating to delegation NSEC RR's in Section 2.1 was found by
- Roy Badami. Roy Arends found the related problem with DNAME.
-
- The errors in the RFC4035 examples were found by Roy Arends, who also
- contributed text for Section 4.3 of this document.
-
-
-
-Weiler Expires November 24, 2005 [Page 9]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
- The editor would like to thank Olafur Gudmundsson and Scott Rose for
- their substantive comments on the text of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler Expires November 24, 2005 [Page 10]
-
-Internet-Draft DNSSECbis Implementation Notes May 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Weiler Expires November 24, 2005 [Page 11]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
deleted file mode 100644
index ee03583a1306..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-DNSEXT D. Blacka
-Internet-Draft Verisign, Inc.
-Expires: January 19, 2006 July 18, 2005
-
-
- DNSSEC Experiments
- draft-ietf-dnsext-dnssec-experiments-01
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on January 19, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- In the long history of the development of the DNS security extensions
- [1] (DNSSEC), a number of alternate methodologies and modifications
- have been proposed and rejected for practical, rather than strictly
- technical, reasons. There is a desire to be able to experiment with
- these alternate methods in the public DNS. This document describes a
- methodology for deploying alternate, non-backwards-compatible, DNSSEC
- methodologies in an experimental fashion without disrupting the
- deployment of standard DNSSEC.
-
-
-
-
-Blacka Expires January 19, 2006 [Page 1]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8
- 6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9
- 7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10
- 8. Security Considerations . . . . . . . . . . . . . . . . . . 11
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 10.1 Normative References . . . . . . . . . . . . . . . . . . 13
- 10.2 Informative References . . . . . . . . . . . . . . . . . 13
- Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
- Intellectual Property and Copyright Statements . . . . . . . 14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 2]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system (RFC 1035
- [4]) and the DNS security extensions ([1], [2], and [3].
-
- The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 3]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-2. Overview
-
- Historically, experimentation with DNSSEC alternatives has been a
- problematic endeavor. There has typically been a desire to both
- introduce non-backwards-compatible changes to DNSSEC, and to try
- these changes on real zones in the public DNS. This creates a
- problem when the change to DNSSEC would make all or part of the zone
- using those changes appear bogus (bad) or otherwise broken to
- existing DNSSEC-aware resolvers.
-
- This document describes a standard methodology for setting up public
- DNSSEC experiments. This methodology addresses the issue of co-
- existence with standard DNSSEC and DNS by using unknown algorithm
- identifiers to hide the experimental DNSSEC protocol modifications
- from standard DNSSEC-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 4]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-3. Experiments
-
- When discussing DNSSEC experiments, it is necessary to classify these
- experiments into two broad categories:
-
- Backwards-Compatible: describes experimental changes that, while not
- strictly adhering to the DNSSEC standard, are nonetheless
- interoperable with clients and server that do implement the DNSSEC
- standard.
-
- Non-Backwards-Compatible: describes experiments that would cause a
- standard DNSSEC-aware resolver to (incorrectly) determine that all
- or part of a zone is bogus, or to otherwise not interoperable with
- standard DNSSEC clients and servers.
-
- Not included in these terms are experiments with the core DNS
- protocol itself.
-
- The methodology described in this document is not necessary for
- backwards-compatible experiments, although it certainly could be used
- if desired.
-
- Note that, in essence, this metholodolgy would also be used to
- introduce a new DNSSEC algorithm, independently from any DNSSEC
- experimental protocol change.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 5]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-4. Method
-
- The core of the methodology is the use of strictly "unknown"
- algorithms to sign the experimental zone, and more importantly,
- having only unknown algorithm DS records for the delegation to the
- zone at the parent.
-
- This technique works because of the way DNSSEC-compliant validators
- are expected to work in the presence of a DS set with only unknown
- algorithms. From [3], Section 5.2:
-
- If the validator does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
- And further:
-
- If the resolver does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver will not be able to
- verify the authentication path to the child zone. In this case,
- the resolver SHOULD treat the child zone as if it were unsigned.
-
- While this behavior isn't strictly mandatory (as marked by MUST), it
- is unlikely that a validator would not implement the behavior, or,
- more to the point, it will not violate this behavior in an unsafe way
- (see below (Section 6).)
-
- Because we are talking about experiments, it is RECOMMENDED that
- private algorithm numbers be used (see [2], appendix A.1.1. Note
- that secure handling of private algorithms requires special handing
- by the validator logic. See [6] for futher details.) Normally,
- instead of actually inventing new signing algorithms, the recommended
- path is to create alternate algorithm identifiers that are aliases
- for the existing, known algorithms. While, strictly speaking, it is
- only necessary to create an alternate identifier for the mandatory
- algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be
- aliased as well.
-
- It is RECOMMENDED that for a particular DNSSEC experiment, a
- particular domain name base is chosen for all new algorithms, then
- the algorithm number (or name) is prepended to it. For example, for
- experiment A, the base name of "dnssec-experiment-a.example.com" is
- chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
- defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-
- experiment-a.example.com". However, any unique identifier will
-
-
-
-Blacka Expires January 19, 2006 [Page 6]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
- suffice.
-
- Using this method, resolvers (or, more specificially, DNSSEC
- validators) essentially indicate their ability to understand the
- DNSSEC experiment's semantics by understanding what the new algorithm
- identifiers signify.
-
- This method creates two classes of DNSSEC-aware servers and
- resolvers: servers and resolvers that are aware of the experiment
- (and thus recognize the experiments algorithm identifiers and
- experimental semantics), and servers and resolvers that are unware of
- the experiment.
-
- This method also precludes any zone from being both in an experiment
- and in a classic DNSSEC island of security. That is, a zone is
- either in an experiment and only experimentally validatable, or it
- isn't.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 7]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-5. Defining an Experiment
-
- The DNSSEC experiment must define the particular set of (previously
- unknown) algorithms that identify the experiment, and define what
- each unknown algorithm identifier means. Typically, unless the
- experiment is actually experimenting with a new DNSSEC algorithm,
- this will be a mapping of private algorithm identifiers to existing,
- known algorithms.
-
- Normally the experiment will choose a DNS name as the algorithm
- identifier base. This DNS name SHOULD be under the control of the
- authors of the experiment. Then the experiment will define a mapping
- between known mandatory and optional algorithms into this private
- algorithm identifier space. Alternately, the experiment MAY use the
- OID private algorithm space instead (using algorithm number 254), or
- may choose non-private algorithm numbers, although this would require
- an IANA allocation (see below (Section 9).)
-
- For example, an experiment might specify in its description the DNS
- name "dnssec-experiment-a.example.com" as the base name, and provide
- the mapping of "3.dnssec-experiment-a.example.com" is an alias of
- DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
- an alias of DNSSEC algorithm 5 (RSASHA1).
-
- Resolvers MUST then only recognize the experiment's semantics when
- present in a zone signed by one or more of these private algorithms.
-
- In general, however, resolvers involved in the experiment are
- expected to understand both standard DNSSEC and the defined
- experimental DNSSEC protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 8]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-6. Considerations
-
- There are a number of considerations with using this methodology.
-
- 1. Under some circumstances, it may be that the experiment will not
- be sufficiently masked by this technique and may cause resolution
- problem for resolvers not aware of the experiment. For instance,
- the resolver may look at the not validatable response and
- conclude that the response is bogus, either due to local policy
- or implementation details. This is not expected to be the common
- case, however.
-
- 2. In general, it will not be possible for DNSSEC-aware resolvers
- not aware of the experiment to build a chain of trust through an
- experimental zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 9]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-7. Transitions
-
- If an experiment is successful, there may be a desire to move the
- experiment to a standards-track extension. One way to do so would be
- to move from private algorithm numbers to IANA allocated algorithm
- numbers, with otherwise the same meaning. This would still leave a
- divide between resolvers that understood the extension versus
- resolvers that did not. It would, in essence, create an additional
- version of DNSSEC.
-
- An alternate technique might be to do a typecode rollover, thus
- actually creating a definitive new version of DNSSEC. There may be
- other transition techniques available, as well.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 10]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-8. Security Considerations
-
- Zones using this methodology will be considered insecure by all
- resolvers except those aware of the experiment. It is not generally
- possible to create a secure delegation from an experimental zone that
- will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 11]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-9. IANA Considerations
-
- IANA may need to allocate new DNSSEC algorithm numbers if that
- transition approach is taken, or the experiment decides to use
- allocated numbers to begin with. No IANA action is required to
- deploy an experiment using private algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 12]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-10. References
-
-10.1 Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
-10.2 Informative References
-
- [4] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Weiler, S., "Clarifications and Implementation Notes for
- DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
- progress), March 2005.
-
-
-Author's Address
-
- David Blacka
- Verisign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- Email: davidb@verisign.com
- URI: http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-Blacka Expires January 19, 2006 [Page 13]
-
-Internet-Draft DNSSEC Experiments July 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Blacka Expires January 19, 2006 [Page 14]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
deleted file mode 100644
index 7503c66ab318..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-Network Working Group S. Weiler
-Internet-Draft SPARTA, Inc
-Updates: 4034, 4035 (if approved) J. Ihren
-Expires: July 24, 2006 Autonomica AB
- January 20, 2006
-
-
- Minimally Covering NSEC Records and DNSSEC On-line Signing
- draft-ietf-dnsext-dnssec-online-signing-02
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on July 24, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes how to construct DNSSEC NSEC resource records
- that cover a smaller range of names than called for by RFC4034. By
- generating and signing these records on demand, authoritative name
- servers can effectively stop the disclosure of zone contents
- otherwise made possible by walking the chain of NSEC records in a
- signed zone.
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 1]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
-Changes from ietf-01 to ietf-02
-
- Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
- and NSEC bits set, to be consistent with DNSSECbis -- previous text
- said SHOULD.
-
- Made the applicability statement a little less oppressive.
-
-Changes from ietf-00 to ietf-01
-
- Added an applicability statement, making reference to ongoing work on
- NSEC3.
-
- Added the phrase "epsilon functions", which has been commonly used to
- describe the technique and already appeared in the header of each
- page, in place of "increment and decrement functions". Also added an
- explanatory sentence.
-
- Corrected references from 4034 section 6.2 to section 6.1.
-
- Fixed an out-of-date reference to [-bis] and other typos.
-
- Replaced IANA Considerations text.
-
- Escaped close parentheses in examples.
-
- Added some more acknowledgements.
-
-Changes from weiler-01 to ietf-00
-
- Inserted RFC numbers for 4033, 4034, and 4035.
-
- Specified contents of bitmap field in synthesized NSEC RR's, pointing
- out that this relaxes a constraint in 4035. Added 4035 to the
- Updates header.
-
-Changes from weiler-00 to weiler-01
-
- Clarified that this updates RFC4034 by relaxing requirements on the
- next name field.
-
- Added examples covering wildcard names.
-
- In the 'better functions' section, reiterated that perfect functions
- aren't needed.
-
- Added a reference to RFC 2119.
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 2]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
-Table of Contents
-
- 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 4
- 2. Applicability of This Technique . . . . . . . . . . . . . . . 4
- 3. Minimally Covering NSEC Records . . . . . . . . . . . . . . . 5
- 4. Better Epsilon Functions . . . . . . . . . . . . . . . . . . . 6
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
- 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
- Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
- Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 3]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
-1. Introduction and Terminology
-
- With DNSSEC [1], an NSEC record lists the next instantiated name in
- its zone, proving that no names exist in the "span" between the
- NSEC's owner name and the name in the "next name" field. In this
- document, an NSEC record is said to "cover" the names between its
- owner name and next name.
-
- Through repeated queries that return NSEC records, it is possible to
- retrieve all of the names in the zone, a process commonly called
- "walking" the zone. Some zone owners have policies forbidding zone
- transfers by arbitrary clients; this side-effect of the NSEC
- architecture subverts those policies.
-
- This document presents a way to prevent zone walking by constructing
- NSEC records that cover fewer names. These records can make zone
- walking take approximately as many queries as simply asking for all
- possible names in a zone, making zone walking impractical. Some of
- these records must be created and signed on demand, which requires
- on-line private keys. Anyone contemplating use of this technique is
- strongly encouraged to review the discussion of the risks of on-line
- signing in Section 6.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [4].
-
-
-2. Applicability of This Technique
-
- The technique presented here may be useful to a zone owner that wants
- to use DNSSEC, is concerned about exposure of its zone contents via
- zone walking, and is willing to bear the costs of on-line signing.
-
- As discussed in Section 6, on-line signing has several security
- risks, including an increased likelihood of private keys being
- disclosed and an increased risk of denial of service attack. Anyone
- contemplating use of this technique is strongly encouraged to review
- the discussion of the risks of on-line signing in Section 6.
-
- Furthermore, at the time this document was published, the DNSEXT
- working group was actively working on a mechanism to prevent zone
- walking that does not require on-line signing (tentatively called
- NSEC3). The new mechanism is likely to expose slightly more
- information about the zone than this technique (e.g. the number of
- instantiated names), but it may be preferable to this technique.
-
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 4]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
-3. Minimally Covering NSEC Records
-
- This mechanism involves changes to NSEC records for instantiated
- names, which can still be generated and signed in advance, as well as
- the on-demand generation and signing of new NSEC records whenever a
- name must be proven not to exist.
-
- In the 'next name' field of instantiated names' NSEC records, rather
- than list the next instantiated name in the zone, list any name that
- falls lexically after the NSEC's owner name and before the next
- instantiated name in the zone, according to the ordering function in
- RFC4034 [2] section 6.1. This relaxes the requirement in section
- 4.1.1 of RFC4034 that the 'next name' field contains the next owner
- name in the zone. This change is expected to be fully compatible
- with all existing DNSSEC validators. These NSEC records are returned
- whenever proving something specifically about the owner name (e.g.
- that no resource records of a given type appear at that name).
-
- Whenever an NSEC record is needed to prove the non-existence of a
- name, a new NSEC record is dynamically produced and signed. The new
- NSEC record has an owner name lexically before the QNAME but
- lexically following any existing name and a 'next name' lexically
- following the QNAME but before any existing name.
-
- The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
- bits set and SHOULD NOT have any other bits set. This relaxes the
- requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
- names that did not exist before the zone was signed.
-
- The functions to generate the lexically following and proceeding
- names need not be perfect nor consistent, but the generated NSEC
- records must not cover any existing names. Furthermore, this
- technique works best when the generated NSEC records cover as few
- names as possible. In this document, the functions that generate the
- nearby names are called 'epsilon' functions, a reference to the
- mathematical convention of using the greek letter epsilon to
- represent small deviations.
-
- An NSEC record denying the existence of a wildcard may be generated
- in the same way. Since the NSEC record covering a non-existent
- wildcard is likely to be used in response to many queries,
- authoritative name servers using the techniques described here may
- want to pregenerate or cache that record and its corresponding RRSIG.
-
- For example, a query for an A record at the non-instantiated name
- example.com might produce the following two NSEC records, the first
- denying the existence of the name example.com and the second denying
- the existence of a wildcard:
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 5]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
- exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
-
- \).com 3600 IN NSEC +.com ( RRSIG NSEC )
-
- Before answering a query with these records, an authoritative server
- must test for the existence of names between these endpoints. If the
- generated NSEC would cover existing names (e.g. exampldd.com or
- *bizarre.example.com), a better epsilon function may be used or the
- covered name closest to the QNAME could be used as the NSEC owner
- name or next name, as appropriate. If an existing name is used as
- the NSEC owner name, that name's real NSEC record MUST be returned.
- Using the same example, assuming an exampldd.com delegation exists,
- this record might be returned from the parent:
-
- exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
-
- Like every authoritative record in the zone, each generated NSEC
- record MUST have corresponding RRSIGs generated using each algorithm
- (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
- described in RFC4035 [3] section 2.2. To minimize the number of
- signatures that must be generated, a zone may wish to limit the
- number of algorithms in its DNSKEY RRset.
-
-
-4. Better Epsilon Functions
-
- Section 6.1 of RFC4034 defines a strict ordering of DNS names.
- Working backwards from that definition, it should be possible to
- define epsilon functions that generate the immediately following and
- preceding names, respectively. This document does not define such
- functions. Instead, this section presents functions that come
- reasonably close to the perfect ones. As described above, an
- authoritative server should still ensure than no generated NSEC
- covers any existing name.
-
- To increment a name, add a leading label with a single null (zero-
- value) octet.
-
- To decrement a name, decrement the last character of the leftmost
- label, then fill that label to a length of 63 octets with octets of
- value 255. To decrement a null (zero-value) octet, remove the octet
- -- if an empty label is left, remove the label. Defining this
- function numerically: fill the left-most label to its maximum length
- with zeros (numeric, not ASCII zeros) and subtract one.
-
- In response to a query for the non-existent name foo.example.com,
- these functions produce NSEC records of:
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 6]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
- fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
-
- \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
- \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
-
- The first of these NSEC RRs proves that no exact match for
- foo.example.com exists, and the second proves that there is no
- wildcard in example.com.
-
- Both of these functions are imperfect: they don't take into account
- constraints on number of labels in a name nor total length of a name.
- As noted in the previous section, though, this technique does not
- depend on the use of perfect epsilon functions: it is sufficient to
- test whether any instantiated names fall into the span covered by the
- generated NSEC and, if so, substitute those instantiated owner names
- for the NSEC owner name or next name, as appropriate.
-
-
-5. IANA Considerations
-
- This document specifies no IANA Actions.
-
-
-6. Security Considerations
-
- This approach requires on-demand generation of RRSIG records. This
- creates several new vulnerabilities.
-
- First, on-demand signing requires that a zone's authoritative servers
- have access to its private keys. Storing private keys on well-known
- internet-accessible servers may make them more vulnerable to
- unintended disclosure.
-
- Second, since generation of digital signatures tends to be
- computationally demanding, the requirement for on-demand signing
- makes authoritative servers vulnerable to a denial of service attack.
-
- Lastly, if the epsilon functions are predictable, on-demand signing
- may enable a chosen-plaintext attack on a zone's private keys. Zones
- using this approach should attempt to use cryptographic algorithms
- that are resistant to chosen-plaintext attacks. It's worth noting
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 7]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
- that while DNSSEC has a "mandatory to implement" algorithm, that is a
- requirement on resolvers and validators -- there is no requirement
- that a zone be signed with any given algorithm.
-
- The success of using minimally covering NSEC record to prevent zone
- walking depends greatly on the quality of the epsilon functions
- chosen. An increment function that chooses a name obviously derived
- from the next instantiated name may be easily reverse engineered,
- destroying the value of this technique. An increment function that
- always returns a name close to the next instantiated name is likewise
- a poor choice. Good choices of epsilon functions are the ones that
- produce the immediately following and preceding names, respectively,
- though zone administrators may wish to use less perfect functions
- that return more human-friendly names than the functions described in
- Section 4 above.
-
- Another obvious but misguided concern is the danger from synthesized
- NSEC records being replayed. It's possible for an attacker to replay
- an old but still validly signed NSEC record after a new name has been
- added in the span covered by that NSEC, incorrectly proving that
- there is no record at that name. This danger exists with DNSSEC as
- defined in [3]. The techniques described here actually decrease the
- danger, since the span covered by any NSEC record is smaller than
- before. Choosing better epsilon functions will further reduce this
- danger.
-
-7. Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-
-Appendix A. Acknowledgments
-
- Many individuals contributed to this design. They include, in
- addition to the authors of this document, Olaf Kolkman, Ed Lewis,
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 8]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
- Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
- Jakob Schlyter, Bill Manning, and Joao Damas.
-
- In addition, the editors would like to thank Ed Lewis, Scott Rose,
- and David Blacka for their careful review of the document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 9]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
-Authors' Addresses
-
- Samuel Weiler
- SPARTA, Inc
- 7075 Samuel Morse Drive
- Columbia, Maryland 21046
- US
-
- Email: weiler@tislabs.com
-
-
- Johan Ihren
- Autonomica AB
- Bellmansgatan 30
- Stockholm SE-118 47
- Sweden
-
- Email: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 10]
-
-Internet-Draft NSEC Epsilon January 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Weiler & Ihren Expires July 24, 2006 [Page 11]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
deleted file mode 100644
index 17e28e8286e2..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-DNSEXT R. Arends
-Internet-Draft Telematica Instituut
-Expires: January 19, 2006 M. Kosters
- D. Blacka
- Verisign, Inc.
- July 18, 2005
-
-
- DNSSEC Opt-In
- draft-ietf-dnsext-dnssec-opt-in-07
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on January 19, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
- 4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
- cryptographically secured. Maintaining this cryptography is not
- practical or necessary. This document describes an experimental
- "Opt-In" model that allows administrators to omit this cryptography
- and manage the cost of adopting DNSSEC with large zones.
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 1]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Experimental Status . . . . . . . . . . . . . . . . . . . . . 4
- 4. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . 4
- 4.1 Server Considerations . . . . . . . . . . . . . . . . . . 5
- 4.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . 5
- 4.1.2 Insecure Delegation Responses . . . . . . . . . . . . 6
- 4.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . 6
- 4.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . 7
- 4.2 Client Considerations . . . . . . . . . . . . . . . . . . 7
- 4.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . 7
- 4.2.2 Validation Process Changes . . . . . . . . . . . . . . 7
- 4.2.3 NSEC Record Caching . . . . . . . . . . . . . . . . . 8
- 4.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . 8
- 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
- 7. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 10
- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 11.1 Normative References . . . . . . . . . . . . . . . . . . . 13
- 11.2 Informative References . . . . . . . . . . . . . . . . . . 13
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
- A. Implementing Opt-In using "Views" . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 2]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system (RFC 1035
- [1]), DNS security extensions ([3], [4], and [5], referred to in this
- document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
- [10]) is assumed.
-
- The following abbreviations and terms are used in this document:
-
- RR: is used to refer to a DNS resource record.
- RRset: refers to a Resource Record Set, as defined by [8]. In this
- document, the RRset is also defined to include the covering RRSIG
- records, if any exist.
- signed name: refers to a DNS name that has, at minimum, a (signed)
- NSEC record.
- unsigned name: refers to a DNS name that does not (at least) have a
- NSEC record.
- covering NSEC record/RRset: is the NSEC record used to prove
- (non)existence of a particular name or RRset. This means that for
- a RRset or name 'N', the covering NSEC record has the name 'N', or
- has an owner name less than 'N' and "next" name greater than 'N'.
- delegation: refers to a NS RRset with a name different from the
- current zone apex (non-zone-apex), signifying a delegation to a
- subzone.
- secure delegation: refers to a signed name containing a delegation
- (NS RRset), and a signed DS RRset, signifying a delegation to a
- signed subzone.
- insecure delegation: refers to a signed name containing a delegation
- (NS RRset), but lacking a DS RRset, signifying a delegation to an
- unsigned subzone.
- Opt-In insecure delegation: refers to an unsigned name containing
- only a delegation NS RRset. The covering NSEC record uses the
- Opt-In methodology described in this document.
-
- The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [7].
-
-2. Overview
-
- The cost to cryptographically secure delegations to unsigned zones is
- high for large delegation-centric zones and zones where insecure
- delegations will be updated rapidly. For these zones, the costs of
- maintaining the NSEC record chain may be extremely high relative to
- the gain of cryptographically authenticating existence of unsecured
- zones.
-
- This document describes an experimental method of eliminating the
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 3]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- superfluous cryptography present in secure delegations to unsigned
- zones. Using "Opt-In", a zone administrator can choose to remove
- insecure delegations from the NSEC chain. This is accomplished by
- extending the semantics of the NSEC record by using a redundant bit
- in the type map.
-
-3. Experimental Status
-
- This document describes an EXPERIMENTAL extension to DNSSEC. It
- interoperates with non-experimental DNSSEC using the technique
- described in [6]. This experiment is identified with the following
- private algorithms (using algorithm 253):
-
- "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
- and
- "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
- RSASHA1.
-
- Servers wishing to sign and serve zones that utilize Opt-In MUST sign
- the zone with only one or more of these private algorithms. This
- requires the signing tools and servers to support private algorithms,
- as well as Opt-In.
-
- Resolvers wishing to validate Opt-In zones MUST only do so when the
- zone is only signed using one or more of these private algorithms.
-
- The remainder of this document assumes that the servers and resolvers
- involved are aware of and are involved in this experiment.
-
-4. Protocol Additions
-
- In DNSSEC, delegation NS RRsets are not signed, but are instead
- accompanied by a NSEC RRset of the same name and (possibly) a DS
- record. The security status of the subzone is determined by the
- presence or absence of the DS RRset, cryptographically proven by the
- NSEC record. Opt-In expands this definition by allowing insecure
- delegations to exist within an otherwise signed zone without the
- corresponding NSEC record at the delegation's owner name. These
- insecure delegations are proven insecure by using a covering NSEC
- record.
-
- Since this represents a change of the interpretation of NSEC records,
- resolvers must be able to distinguish between RFC standard DNSSEC
- NSEC records and Opt-In NSEC records. This is accomplished by
- "tagging" the NSEC records that cover (or potentially cover) insecure
- delegation nodes. This tag is indicated by the absence of the NSEC
- bit in the type map. Since the NSEC bit in the type map merely
- indicates the existence of the record itself, this bit is redundant
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 4]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- and safe for use as a tag.
-
- An Opt-In tagged NSEC record does not assert the (non)existence of
- the delegations that it covers (except for a delegation with the same
- name). This allows for the addition or removal of these delegations
- without recalculating or resigning records in the NSEC chain.
- However, Opt-In tagged NSEC records do assert the (non)existence of
- other RRsets.
-
- An Opt-In NSEC record MAY have the same name as an insecure
- delegation. In this case, the delegation is proven insecure by the
- lack of a DS bit in type map and the signed NSEC record does assert
- the existence of the delegation.
-
- Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
- records and standard DNSSEC NSEC records. If a NSEC record is not
- Opt-In, there MUST NOT be any insecure delegations (or any other
- records) between it and the RRsets indicated by the 'next domain
- name' in the NSEC RDATA. If it is Opt-In, there MUST only be
- insecure delegations between it and the next node indicated by the
- 'next domain name' in the NSEC RDATA.
-
- In summary,
-
- o An Opt-In NSEC type is identified by a zero-valued (or not-
- specified) NSEC bit in the type bit map of the NSEC record.
- o A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
- the type bit map of the NSEC record.
-
- and,
-
- o An Opt-In NSEC record does not assert the non-existence of a name
- between its owner name and "next" name, although it does assert
- that any name in this span MUST be an insecure delegation.
- o An Opt-In NSEC record does assert the (non)existence of RRsets
- with the same owner name.
-
-4.1 Server Considerations
-
- Opt-In imposes some new requirements on authoritative DNS servers.
-
-4.1.1 Delegations Only
-
- This specification dictates that only insecure delegations may exist
- between the owner and "next" names of an Opt-In tagged NSEC record.
- Signing tools SHOULD NOT generate signed zones that violate this
- restriction. Servers SHOULD refuse to load and/or serve zones that
- violate this restriction. Servers also SHOULD reject AXFR or IXFR
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 5]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- responses that violate this restriction.
-
-4.1.2 Insecure Delegation Responses
-
- When returning an Opt-In insecure delegation, the server MUST return
- the covering NSEC RRset in the Authority section.
-
- In standard DNSSEC, NSEC records already must be returned along with
- the insecure delegation. The primary difference that this proposal
- introduces is that the Opt-In tagged NSEC record will have a
- different owner name from the delegation RRset. This may require
- implementations to search for the covering NSEC RRset.
-
-4.1.3 Wildcards and Opt-In
-
- Standard DNSSEC describes the practice of returning NSEC records to
- prove the non-existence of an applicable wildcard in non-existent
- name responses. This NSEC record can be described as a "negative
- wildcard proof". The use of Opt-In NSEC records changes the
- necessity for this practice. For non-existent name responses when
- the query name (qname) is covered by an Opt-In tagged NSEC record,
- servers MAY choose to omit the wildcard proof record, and clients
- MUST NOT treat the absence of this NSEC record as a validation error.
-
- The intent of the standard DNSSEC negative wildcard proof requirement
- is to prevent malicious users from undetectably removing valid
- wildcard responses. In order for this cryptographic proof to work,
- the resolver must be able to prove:
-
- 1. The exact qname does not exist. This is done by the "normal"
- NSEC record.
- 2. No applicable wildcard exists. This is done by returning a NSEC
- record proving that the wildcard does not exist (this is the
- negative wildcard proof).
-
- However, if the NSEC record covering the exact qname is an Opt-In
- NSEC record, the resolver will not be able to prove the first part of
- this equation, as the qname might exist as an insecure delegation.
- Thus, since the total proof cannot be completed, the negative
- wildcard proof NSEC record is not useful.
-
- The negative wildcard proof is also not useful when returned as part
- of an Opt-In insecure delegation response for a similar reason: the
- resolver cannot prove that the qname does or does not exist, and
- therefore cannot prove that a wildcard expansion is valid.
-
- The presence of an Opt-In tagged NSEC record does not change the
- practice of returning a NSEC along with a wildcard expansion. Even
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 6]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- though the Opt-In NSEC will not be able to prove that the wildcard
- expansion is valid, it will prove that the wildcard expansion is not
- masking any signed records.
-
-4.1.4 Dynamic Update
-
- Opt-In changes the semantics of Secure DNS Dynamic Update [9]. In
- particular, it introduces the need for rules that describe when to
- add or remove a delegation name from the NSEC chain. This document
- does not attempt to define these rules. Until these rules are
- defined, servers MUST NOT process DNS Dynamic Update requests against
- zones that use Opt-In NSEC records. Servers SHOULD return responses
- to update requests with RCODE=REFUSED.
-
-4.2 Client Considerations
-
- Opt-In imposes some new requirements on security-aware resolvers
- (caching or otherwise).
-
-4.2.1 Delegations Only
-
- As stated in the "Server Considerations" section above, this
- specification restricts the namespace covered by Opt-In tagged NSEC
- records to insecure delegations only. Thus, resolvers MUST reject as
- invalid any records that fall within an Opt-In NSEC record's span
- that are not NS records or corresponding glue records.
-
-4.2.2 Validation Process Changes
-
- This specification does not change the resolver's resolution
- algorithm. However, it does change the DNSSEC validation process.
- Resolvers MUST be able to use Opt-In tagged NSEC records to
- cryptographically prove the validity and security status (as
- insecure) of a referral. Resolvers determine the security status of
- the referred-to zone as follows:
-
- o In standard DNSSEC, the security status is proven by the existence
- or absence of a DS RRset at the same name as the delegation. The
- existence of the DS RRset indicates that the referred-to zone is
- signed. The absence of the DS RRset is proven using a verified
- NSEC record of the same name that does not have the DS bit set in
- the type map. This NSEC record MAY also be tagged as Opt-In.
- o Using Opt-In, the security status is proven by the existence of a
- DS record (for signed) or the presence of a verified Opt-In tagged
- NSEC record that covers the delegation name. That is, the NSEC
- record does not have the NSEC bit set in the type map, and the
- delegation name falls between the NSEC's owner and "next" name.
-
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 7]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- Using Opt-In does not substantially change the nature of following
- referrals within DNSSEC. At every delegation point, the resolver
- will have cryptographic proof that the referred-to subzone is signed
- or unsigned.
-
- When receiving either an Opt-In insecure delegation response or a
- non-existent name response where that name is covered by an Opt-In
- tagged NSEC record, the resolver MUST NOT require proof (in the form
- of a NSEC record) that a wildcard did not exist.
-
-4.2.3 NSEC Record Caching
-
- Caching resolvers MUST be able to retrieve the appropriate covering
- Opt-In NSEC record when returning referrals that need them. This
- requirement differs from standard DNSSEC in that the covering NSEC
- will not have the same owner name as the delegation. Some
- implementations may have to use new methods for finding these NSEC
- records.
-
-4.2.4 Use of the AD bit
-
- The AD bit, as defined by [2] and [5], MUST NOT be set when:
-
- o sending a Name Error (RCODE=3) response where the covering NSEC is
- tagged as Opt-In.
- o sending an Opt-In insecure delegation response, unless the
- covering (Opt-In) NSEC record's owner name equals the delegation
- name.
-
- This rule is based on what the Opt-In NSEC record actually proves:
- for names that exist between the Opt-In NSEC record's owner and
- "next" names, the Opt-In NSEC record cannot prove the non-existence
- or existence of the name. As such, not all data in the response has
- been cryptographically verified, so the AD bit cannot be set.
-
-5. Benefits
-
- Using Opt-In allows administrators of large and/or changing
- delegation-centric zones to minimize the overhead involved in
- maintaining the security of the zone.
-
- Opt-In accomplishes this by eliminating the need for NSEC records for
- insecure delegations. This, in a zone with a large number of
- delegations to unsigned subzones, can lead to substantial space
- savings (both in memory and on disk). Additionally, Opt-In allows
- for the addition or removal of insecure delegations without modifying
- the NSEC record chain. Zones that are frequently updating insecure
- delegations (e.g., TLDs) can avoid the substantial overhead of
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 8]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- modifying and resigning the affected NSEC records.
-
-6. Example
-
- Consider the zone EXAMPLE, shown below. This is a zone where all of
- the NSEC records are tagged as Opt-In.
-
- Example A: Fully Opt-In Zone.
-
- EXAMPLE. SOA ...
- EXAMPLE. RRSIG SOA ...
- EXAMPLE. NS FIRST-SECURE.EXAMPLE.
- EXAMPLE. RRSIG NS ...
- EXAMPLE. DNSKEY ...
- EXAMPLE. RRSIG DNSKEY ...
- EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (
- SOA NS RRSIG DNSKEY )
- EXAMPLE. RRSIG NSEC ...
-
- FIRST-SECURE.EXAMPLE. A ...
- FIRST-SECURE.EXAMPLE. RRSIG A ...
- FIRST-SECURE.EXAMPLE. NSEC NOT-SECURE-2.EXAMPLE. A RRSIG
- FIRST-SECURE.EXAMPLE. RRSIG NSEC ...
-
- NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
- NS.NOT-SECURE.EXAMPLE. A ...
-
- NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
- NOT-SECURE-2.EXAMPLE NSEC SECOND-SECURE.EXAMPLE NS RRSIG
- NOT-SECURE-2.EXAMPLE RRSIG NSEC ...
-
- SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE.
- SECOND-SECURE.EXAMPLE. DS ...
- SECOND-SECURE.EXAMPLE. RRSIG DS ...
- SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DNSKEY
- SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
-
- UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE.
- NS.UNSIGNED.EXAMPLE. A ...
-
-
- In this example, a query for a signed RRset (e.g., "FIRST-
- SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
- SECURE.EXAMPLE A") will result in a standard DNSSEC response.
-
- A query for a nonexistent RRset will result in a response that
- differs from standard DNSSEC by: the NSEC record will be tagged as
- Opt-In, there may be no NSEC record proving the non-existence of a
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 9]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- matching wildcard record, and the AD bit will not be set.
-
- A query for an insecure delegation RRset (or a referral) will return
- both the answer (in the Authority section) and the corresponding
- Opt-In NSEC record to prove that it is not secure.
-
- Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
-
-
- RCODE=NOERROR, AD=0
-
- Answer Section:
-
- Authority Section:
- UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE
- SECOND-SECURE.EXAMPLE. NSEC EXAMPLE. NS RRSIG DS
- SECOND-SECURE.EXAMPLE. RRSIG NSEC ...
-
- Additional Section:
- NS.UNSIGNED.EXAMPLE. A ...
-
- In the Example A.1 zone, the EXAMPLE. node MAY use either style of
- NSEC record, because there are no insecure delegations that occur
- between it and the next node, FIRST-SECURE.EXAMPLE. In other words,
- Example A would still be a valid zone if the NSEC record for EXAMPLE.
- was changed to the following RR:
-
- EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. (SOA NS
- RRSIG DNSKEY NSEC )
-
- However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
- SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are insecure
- delegations in the range they define. (NOT-SECURE.EXAMPLE. and
- UNSIGNED.EXAMPLE., respectively).
-
- NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
- part of the NSEC chain and also covered by an Opt-In tagged NSEC
- record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
- removed from the zone without modifying and resigning the prior NSEC
- record. Delegations with names that fall between NOT-SECURE-
- 2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
- resigning any NSEC records.
-
-7. Transition Issues
-
- Opt-In is not backwards compatible with standard DNSSEC and is
- considered experimental. Standard DNSSEC compliant implementations
- would not recognize Opt-In tagged NSEC records as different from
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 10]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- standard NSEC records. Because of this, standard DNSSEC
- implementations, if they were to validate Opt-In style responses,
- would reject all Opt-In insecure delegations within a zone as
- invalid. However, by only signing with private algorithms, standard
- DNSSEC implementations will treat Opt-In responses as unsigned.
-
- It should be noted that all elements in the resolution path between
- (and including) the validator and the authoritative name server must
- be aware of the Opt-In experiment and implement the Opt-In semantics
- for successful validation to be possible. In particular, this
- includes any caching middleboxes between the validator and
- authoritative name server.
-
-8. Security Considerations
-
- Opt-In allows for unsigned names, in the form of delegations to
- unsigned subzones, to exist within an otherwise signed zone. All
- unsigned names are, by definition, insecure, and their validity or
- existence cannot by cryptographically proven.
-
- In general:
-
- o Records with unsigned names (whether existing or not) suffer from
- the same vulnerabilities as records in an unsigned zone. These
- vulnerabilities are described in more detail in [12] (note in
- particular sections 2.3, "Name Games" and 2.6, "Authenticated
- Denial").
- o Records with signed names have the same security whether or not
- Opt-In is used.
-
- Note that with or without Opt-In, an insecure delegation may have its
- contents undetectably altered by an attacker. Because of this, the
- primary difference in security that Opt-In introduces is the loss of
- the ability to prove the existence or nonexistence of an insecure
- delegation within the span of an Opt-In NSEC record.
-
- In particular, this means that a malicious entity may be able to
- insert or delete records with unsigned names. These records are
- normally NS records, but this also includes signed wildcard
- expansions (while the wildcard record itself is signed, its expanded
- name is an unsigned name).
-
- For example, if a resolver received the following response from the
- example zone above:
-
-
-
-
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 11]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
-
- RCODE=NOERROR
-
- Answer Section:
-
- Authority Section:
- DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
- EXAMPLE. NSEC FIRST-SECURE.EXAMPLE. SOA NS \
- RRSIG DNSKEY
- EXAMPLE. RRSIG NSEC ...
-
- Additional Section:
-
-
- The resolver would have no choice but to believe that the referral to
- NS.FORGED. is valid. If a wildcard existed that would have been
- expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
- have undetectably removed it and replaced it with the forged
- delegation.
-
- Note that being able to add a delegation is functionally equivalent
- to being able to add any record type: an attacker merely has to forge
- a delegation to nameserver under his/her control and place whatever
- records needed at the subzone apex.
-
- While in particular cases, this issue may not present a significant
- security problem, in general it should not be lightly dismissed.
- Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
- In particular, zone signing tools SHOULD NOT default to Opt-In, and
- MAY choose to not support Opt-In at all.
-
-9. IANA Considerations
-
- None.
-
-10. Acknowledgments
-
- The contributions, suggestions and remarks of the following persons
- (in alphabetic order) to this draft are acknowledged:
-
- Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
- Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
- Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
- Wellington.
-
-11. References
-
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 12]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
-11.1 Normative References
-
- [1] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [2] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
- Authenticated Data (AD) bit", RFC 3655, November 2003.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [6] Blacka, D., "DNSSEC Experiments",
- draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
- July 2005.
-
-11.2 Informative References
-
- [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [8] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [9] Eastlake, D., "Secure Domain Name System Dynamic Update",
- RFC 2137, April 1997.
-
- [10] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [11] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
- December 2001.
-
- [12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 13]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- Email: roy.arends@telin.nl
-
-
- Mark Kosters
- Verisign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- Email: markk@verisign.com
- URI: http://www.verisignlabs.com
-
-
- David Blacka
- Verisign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- Email: davidb@verisign.com
- URI: http://www.verisignlabs.com
-
-Appendix A. Implementing Opt-In using "Views"
-
- In many cases, it may be convenient to implement an Opt-In zone by
- combining two separately maintained "views" of a zone at request
- time. In this context, "view" refers to a particular version of a
- zone, not to any specific DNS implementation feature.
-
- In this scenario, one view is the secure view, the other is the
- insecure (or legacy) view. The secure view consists of an entirely
- signed zone using Opt-In tagged NSEC records. The insecure view
- contains no DNSSEC information. It is helpful, although not
- necessary, for the secure view to be a subset (minus DNSSEC records)
- of the insecure view.
-
- In addition, the only RRsets that may solely exist in the insecure
- view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 14]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
- the zone apex NS RRset) MUST be signed and in the secure view.
-
- These two views may be combined at request time to provide a virtual,
- single Opt-In zone. The following algorithm is used when responding
- to each query:
- V_A is the secure view as described above.
- V_B is the insecure view as described above.
- R_A is a response generated from V_A, following RFC 2535bis.
- R_B is a response generated from V_B, following DNS resolution as
- per RFC 1035 [1].
- R_C is the response generated by combining R_A with R_B, as
- described below.
- A query is DNSSEC-aware if it either has the DO bit [11] turned
- on, or is for a DNSSEC-specific record type.
-
-
-
- 1. If V_A is a subset of V_B and the query is not DNSSEC-aware,
- generate and return R_B, otherwise
- 2. Generate R_A.
- 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise
- 4. Generate R_B and combine it with R_A to form R_C:
- For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
- records from R_A into R_B, EXCEPT the AUTHORITY section SOA
- record, if R_B's RCODE = NOERROR.
- 5. Return R_C.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 15]
-
-Internet-Draft DNSSEC Opt-In July 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Arends, et al. Expires January 19, 2006 [Page 16]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
deleted file mode 100644
index 390420abecd6..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-DNS Extensions working group J. Jansen
-Internet-Draft NLnet Labs
-Expires: July 5, 2006 January 2006
-
-
- Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
- draft-ietf-dnsext-dnssec-rsasha256-00
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on July 5, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
- resource records for use in the Domain Name System Security
- Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
-
-
-
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 1]
-
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
- 3. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . . . 3
- 4. Implementation Considerations . . . . . . . . . . . . . . . . . 4
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 5
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
- Intellectual Property and Copyright Statements . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 2]
-
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical distributed
- database for Internet Addressing. The DNS has been extended to use
- digital signatures and cryptographic keys for the verification of
- data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
- Security Extensions.
-
- RFC4034 describes how to store DNSKEY and RRSIG resource records, and
- specifies a list of cryptographic algorithms to use. This document
- extends that list with the algorithm RSA/SHA-256, and specifies how
- to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
- resource records.
-
- Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
- this document.
-
-
-2. RSA/SHA-256 DNSKEY Resource Records
-
- RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
- resource records (RRs) with the algorithm number [TBA].
-
- The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
- [6].
-
-
-3. RSA/SHA-256 RRSIG Resource Records
-
- RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
- records (RRs) with algorithm number [TBA].
-
- The value of the signature field in the RRSIG RR is calculated as
- follows. The values for the fields that precede the signature data
- are specified in RFC4034 [2].
-
- hash = SHA-256(data)
-
- signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
- Where SHA-256 is the message digest algorithm as specified in FIPS
- 180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
- corresponding hexadecimal value, "e" is the private exponent of the
- signing RSA key, and "n" is the public modulus of the signing key.
- The FF octet MUST be repeated the maximum number of times so that the
- total length of the signature equals the length of the modulus of the
- signer's public key ("n"). "data" is the data of the resource record
- set that is signed, as specified in RFC4034 [2].
-
-
-
-Jansen Expires July 5, 2006 [Page 3]
-
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
- The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
- specified in PKCS 2.1 [4]:
-
- hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
-
- This prefix should make the use of standard cryptographic libraries
- easier. These specifications are taken directly from PKCS #1 v2.1
- section 9.2 [4].
-
-
-4. Implementation Considerations
-
- DNSSEC aware implementations MUST be able to support RRSIG resource
- records with the RSA/SHA-256 algorithm.
-
- If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
- available for a certain rrset, with a secure path to their keys, the
- validator SHOULD ignore the SHA-1 signature. If the RSA/SHA-256
- signature does not verify the data, and the RSA/SHA-1 does, the
- validator SHOULD mark the data with the security status from the RSA/
- SHA-256 signature.
-
-
-5. IANA Considerations
-
- IANA has not yet assigned an algorithm number for RSA/SHA-256.
-
- The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
- following entry:
-
- Zone
- Value Algorithm [Mnemonic] Signing References Status
- ----- ----------- ----------- -------- ---------- ---------
- [tba] RSA/SHA-256 [RSASHA256] y [TBA] MANDATORY
-
-
-6. Security Considerations
-
- Recently, weaknesses have been discovered in the SHA-1 hashing
- algorithm. It is therefore strongly encouraged to deploy SHA-256
- where SHA-1 is used now, as soon as the DNS software supports it.
-
- SHA-256 is considered sufficiently strong for the immediate future,
- but predictions about future development in cryptography and
- cryptanalysis are beyond the scope of this document.
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 4]
-
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-7. Acknowledgments
-
- This document is a minor extension to RFC4034 [2]. Also, we try to
- follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
- [8] for consistency. The authors of and contributors to these
- documents are gratefully acknowledged for their hard work.
-
- The following people provided additional feedback and text: Jaap
- Akkerhuis, Miek Gieben and Wouter Wijngaards.
-
-
-8. References
-
-8.1. Normative References
-
- [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Resource Records for the DNS Security Extensions", RFC 4034,
- March 2005.
-
- [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
- (PKCS) #1: RSA Cryptography Specifications Version 2.1",
- RFC 3447, February 2003.
-
- [5] National Institute of Standards and Technology, "Secure Hash
- Standard", FIPS PUB 180-2, August 2002.
-
- [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
- System (DNS)", RFC 3110, May 2001.
-
-8.2. Informative References
-
- [7] Schneier, B., "Applied Cryptography Second Edition: protocols,
- algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
- 11709-9, 1996.
-
- [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
- Resource Records (RRs)", Work in Progress Feb 2006.
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 5]
-
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-Author's Address
-
- Jelte Jansen
- NLnet Labs
- Kruislaan 419
- Amsterdam 1098VA
- NL
-
- Email: jelte@NLnetLabs.nl
- URI: http://www.nlnetlabs.nl/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen Expires July 5, 2006 [Page 6]
-
-Internet-Draft RSA/SHA-256 DNSKEYs and RRSIGS January 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Jansen Expires July 5, 2006 [Page 7]
-
diff --git a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
deleted file mode 100644
index dd8cbf0682e0..000000000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
+++ /dev/null
@@ -1,839 +0,0 @@
-
-DNS Extensions Working Group R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 25, 2005 P. Koch
- DENIC eG
- J. Schlyter
- NIC-SE
- February 21, 2005
-
-
- Evaluating DNSSEC Transition Mechanisms
- draft-ietf-dnsext-dnssec-trans-02.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to all provisions
- of Section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 25, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This document collects and summarizes different proposals for
- alternative and additional strategies for authenticated denial in DNS
- responses, evaluates these proposals and gives a recommendation for a
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 1]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- way forward.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
- 2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4
- 2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
- 2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5
- 2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
- 2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6
- 2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
- 2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8
- 2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
- 2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9
- 2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
- 2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10
- 2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11
- 2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
- 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
- 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
- 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
- 5.2 Informative References . . . . . . . . . . . . . . . . . . 13
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
- Intellectual Property and Copyright Statements . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 2]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-1. Introduction
-
- This report shall document the process of dealing with the NSEC
- walking problem late in the Last Call for
- [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
- I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion
- that took place in the DNSEXT WG during the first half of June 2004
- as well as some additional ideas that came up subsequently.
-
- This is an edited excerpt of the chairs' mail to the WG:
- The working group consents on not including NSEC-alt in the
- DNSSEC-bis documents. The working group considers to take up
- "prevention of zone enumeration" as a work item.
- There may be multiple mechanisms to allow for co-existence with
- DNSSEC-bis. The chairs allow the working group a little over a
- week (up to June 12, 2004) to come to consensus on a possible
- modification to the document to enable gentle rollover. If that
- consensus cannot be reached the DNSSEC-bis documents will go out
- as-is.
-
- To ease the process of getting consensus, a summary of the proposed
- solutions and analysis of the pros and cons were written during the
- weekend.
-
- This summary includes:
-
- An inventory of the proposed mechanisms to make a transition to
- future work on authenticated denial of existence.
- List the known Pros and Cons, possibly provide new arguments, and
- possible security considerations of these mechanisms.
- Provide a recommendation on a way forward that is least disruptive
- to the DNSSEC-bis specifications as they stand and keep an open
- path to other methods for authenticated denial of existence.
-
- The descriptions of the proposals in this document are coarse and do
- not cover every detail necessary for implementation. In any case,
- documentation and further study is needed before implementaion and/or
- deployment, including those which seem to be solely operational in
- nature.
-
-2. Transition Mechanisms
-
- In the light of recent discussions and past proposals, we have found
- several ways to allow for transition to future expansion of
- authenticated denial. We tried to illuminate the paths and pitfalls
- in these ways forward. Some proposals lead to a versioning of
- DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
- proposals are 'clean' but may cause delay, while again others may be
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 3]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- plain hacks.
-
- Some paths do not introduce versioning, and might require the current
- DNSSEC-bis documents to be fully updated to allow for extensions to
- authenticated denial mechanisms. Other paths introduce versioning
- and do not (or minimally) require DNSSEC-bis documents to be updated,
- allowing DNSSEC-bis to be deployed, while future versions can be
- drafted independent from or partially depending on DNSSEC-bis.
-
-2.1 Mechanisms With Need of Updating DNSSEC-bis
-
- Mechanisms in this category demand updates to the DNSSEC-bis document
- set.
-
-2.1.1 Dynamic NSEC Synthesis
-
- This proposal assumes that NSEC RRs and the authenticating RRSIG will
- be generated dynamically to just cover the (non existent) query name.
- The owner name is (the) one preceding the name queried for, the Next
- Owner Name Field has the value of the Query Name Field + 1 (first
- successor in canonical ordering). A separate key (the normal ZSK or
- a separate ZSK per authoritative server) would be used for RRSIGs on
- NSEC RRs. This is a defense against enumeration, though it has the
- presumption of online signing.
-
-2.1.1.1 Coexistence and Migration
-
- There is no change in interpretation other then that the next owner
- name might or might not exist.
-
-2.1.1.2 Limitations
-
- This introduces an unbalanced cost between query and response
- generation due to dynamic generation of signatures.
-
-2.1.1.3 Amendments to DNSSEC-bis
-
- The current DNSSEC-bis documents might need to be updated to indicate
- that the next owner name might not be an existing name in the zone.
- This is not a real change to the spec since implementers have been
- warned not to synthesize with previously cached NSEC records. A
- specific bit to identify the dynamic signature generating key might
- be useful as well, to prevent it from being used to fake positive
- data.
-
-2.1.1.4 Cons
-
- Unbalanced cost is a ground for DDoS. Though this protects against
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 4]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- enumeration, it is not really a path for versioning.
-
-2.1.1.5 Pros
-
- Hardly any amendments to DNSSEC-bis.
-
-2.1.2 Add Versioning/Subtyping to Current NSEC
-
- This proposal introduces versioning for the NSEC RR type (a.k.a.
- subtyping) by adding a (one octet) version field to the NSEC RDATA.
- Version number 0 is assigned to the current (DNSSEC-bis) meaning,
- making this an 'Must Be Zero' (MBZ) for the to be published docset.
-
-2.1.2.1 Coexistence and Migration
-
- Since the versioning is done inside the NSEC RR, different versions
- may coexist. However, depending on future methods, that may or may
- not be useful inside a single zone. Resolvers cannot ask for
- specific NSEC versions but may be able to indicate version support by
- means of a to be defined EDNS option bit.
-
-2.1.2.2 Limitations
-
- There are no technical limitations, though it will cause delay to
- allow testing of the (currently unknown) new NSEC interpretation.
-
- Since the versioning and signaling is done inside the NSEC RR, future
- methods will likely be restricted to a single RR type authenticated
- denial (as opposed to e.g. NSEC-alt, which currently proposes three
- RR types).
-
-2.1.2.3 Amendments to DNSSEC-bis
-
- Full Update of the current DNSSEC-bis documents to provide for new
- fields in NSEC, while specifying behavior in case of unknown field
- values.
-
-2.1.2.4 Cons
-
- Though this is a clean and clear path without versioning DNSSEC, it
- takes some time to design, gain consensus, update the current
- dnssec-bis document, test and implement a new authenticated denial
- record.
-
-2.1.2.5 Pros
-
- Does not introduce an iteration to DNSSEC while providing a clear and
- clean migration strategy.
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 5]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.1.3 Type Bit Map NSEC Indicator
-
- Bits in the type-bit-map are reused or allocated to signify the
- interpretation of NSEC.
-
- This proposal assumes that future extensions make use of the existing
- NSEC RDATA syntax, while it may need to change the interpretation of
- the RDATA or introduce an alternative denial mechanism, invoked by
- the specific type-bit-map-bits.
-
-2.1.3.1 Coexistence and migration
-
- Old and new NSEC meaning could coexist, depending how the signaling
- would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR
- types are available as well as those covering meta/query types or
- types to be specifically allocated.
-
-2.1.3.2 Limitations
-
- This mechanism uses an NSEC field that was not designed for that
- purpose. Similar methods were discussed during the Opt-In discussion
- and the Silly-State discussion.
-
-2.1.3.3 Amendments to DNSSEC-bis
-
- The specific type-bit-map-bits must be allocated and they need to be
- specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
- interpretation. Also, behaviour of the resolver and validator must
- be documented in case unknown values are encountered for the MBZ
- field. Currently the protocol document specifies that the validator
- MUST ignore the setting of the NSEC and the RRSIG bits, while other
- bits are only used for the specific purpose of the type-bit-map field
-
-2.1.3.4 Cons
-
- The type-bit-map was not designed for this purpose. It is a
- straightforward hack. Text in protocol section 5.4 was put in
- specially to defend against this usage.
-
-2.1.3.5 Pros
-
- No change needed to the on-the-wire protocol as specified in the
- current docset.
-
-2.1.4 New Apex Type
-
- This introduces a new Apex type (parallel to the zone's SOA)
- indicating the DNSSEC version (or authenticated denial) used in or
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 6]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- for this zone.
-
-2.1.4.1 Coexistence and Migration
-
- Depending on the design of this new RR type multiple denial
- mechanisms may coexist in a zone. Old validators will not understand
- and thus ignore the new type, so interpretation of the new NSEC
- scheme may fail, negative responses may appear 'bogus'.
-
-2.1.4.2 Limitations
-
- A record of this kind is likely to carry additional
- feature/versioning indications unrelated to the current question of
- authenticated denial.
-
-2.1.4.3 Amendments to DNSSEC-bis
-
- The current DNSSEC-bis documents need to be updated to indicate that
- the absence of this type indicates dnssec-bis, and that the (mere)
- presence of this type indicated unknown versions.
-
-2.1.4.4 Cons
-
- The only other 'zone' or 'apex' record is the SOA record. Though
- this proposal is not new, it is yet unknown how it might fulfill
- authenticated denial extensions. This new RR type would only provide
- for a generalized signaling mechanism, not the new authenticated
- denial scheme. Since it is likely to be general in nature, due to
- this generality consensus is not to be reached soon.
-
-2.1.4.5 Pros
-
- This approach would allow for a lot of other per zone information to
- be transported or signaled to both (slave) servers and resolvers.
-
-2.1.5 NSEC White Lies
-
- This proposal disables one part of NSEC (the pointer part) by means
- of a special target (root, apex, owner, ...), leaving intact only the
- ability to authenticate denial of existence of RR sets, not denial of
- existence of domain names (NXDOMAIN). It may be necessary to have
- one working NSEC to prove the absence of a wildcard.
-
-2.1.5.1 Coexistence and Migration
-
- The NSEC target can be specified per RR, so standard NSEC and 'white
- lie' NSEC can coexist in a zone. There is no need for migration
- because no versioning is introduced or intended.
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 7]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.1.5.2 Limitations
-
- This proposal breaks the protocol and is applicable to certain types
- of zones only (no wildcard, no deep names, delegation only). Most of
- the burden is put on the resolver side and operational consequences
- are yet to be studied.
-
-2.1.5.3 Amendments to DNSSEC-bis
-
- The current DNSSEC-bis documents need to be updated to indicate that
- the NXDOMAIN responses may be insecure.
-
-2.1.5.4 Cons
-
- Strictly speaking this breaks the protocol and doesn't fully fulfill
- the requirements for authenticated denial of existence. Security
- implications need to be carefully documented: search path problems
- (forged denial of existence may lead to wrong expansion of non-FQDNs
- [RFC1535]) and replay attacks to deny existence of records.
-
-2.1.5.5 Pros
-
- Hardly any amendments to DNSSEC-bis. Operational "trick" that is
- available anyway.
-
-2.1.6 NSEC Optional via DNSSKEY Flag
-
- A new DNSKEY may be defined to declare NSEC optional per zone.
-
-2.1.6.1 Coexistence and Migration
-
- Current resolvers/validators will not understand the Flag bit and
- will have to treat negative responses as bogus. Otherwise, no
- migration path is needed since NSEC is simply turned off.
-
-2.1.6.2 Limitations
-
- NSEC can only be made completely optional at the cost of being unable
- to prove unsecure delegations (absence of a DS RR [RFC3658]). A next
- to this approach would just disable authenticated denial for
- non-existence of nodes.
-
-2.1.6.3 Amendments to DNSSEC-bis
-
- New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
- be specified in the light of absence of authenticated denial.
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 8]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.1.6.4 Cons
-
- Doesn't fully meet requirements. Operational consequences to be
- studied.
-
-2.1.6.5 Pros
-
- Official version of the "trick" presented in (8). Operational
- problems can be addressed during future work on validators.
-
-2.1.7 New Answer Pseudo RR Type
-
- A new pseudo RR type may be defined that will be dynamically created
- (and signed) by the responding authoritative server. The RR in the
- response will cover the QNAME, QCLASS and QTYPE and will authenticate
- both denial of existence of name (NXDOMAIN) or RRset.
-
-2.1.7.1 Coexistence and Migration
-
- Current resolvers/validators will not understand the pseudo RR and
- will thus not be able to process negative responses so testified. A
- signaling or solicitation method would have to be specified.
-
-2.1.7.2 Limitations
-
- This method can only be used with online keys and online signing
- capacity.
-
-2.1.7.3 Amendments to DNSSEC-bis
-
- Signaling method needs to be defined.
-
-2.1.7.4 Cons
-
- Keys have to be held and processed online with all security
- implications. An additional flag for those keys identifying them as
- online or negative answer only keys should be considered.
-
-2.1.7.5 Pros
-
- Expands DNSSEC authentication to the RCODE.
-
-2.1.8 SIG(0) Based Authenticated Denial
-
-
-2.1.8.1 Coexistence and Migration
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 9]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.1.8.2 Limitations
-
-
-2.1.8.3 Amendments to DNSSEC-bis
-
-
-2.1.8.4 Cons
-
-
-2.1.8.5 Pros
-
-
-2.2 Mechanisms Without Need of Updating DNSSEC-bis
-
-2.2.1 Partial Type-code and Signal Rollover
-
- Carefully crafted type code/signal rollover to define a new
- authenticated denial space that extends/replaces DNSSEC-bis
- authenticated denial space. This particular path is illuminated by
- Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
- posted to <namedroppers@ops.ietf.org> 2004-06-02.
-
-2.2.1.1 Coexistence and Migration
-
- To protect the current resolver for future versions, a new DNSSEC-OK
- bit must be allocated to make clear it does or does not understand
- the future version. Also, a new DS type needs to be allocated to
- allow differentiation between a current signed delegation and a
- 'future' signed delegation. Also, current NSEC needs to be rolled
- into a new authenticated denial type.
-
-2.2.1.2 Limitations
-
- None.
-
-2.2.1.3 Amendments to DNSSEC-bis
-
- None.
-
-2.2.1.4 Cons
-
- It is cumbersome to carefully craft an TCR that 'just fits'. The
- DNSSEC-bis protocol has many 'borderline' cases that needs special
- consideration. It might be easier to do a full TCR, since a few of
- the types and signals need upgrading anyway.
-
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 10]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-2.2.1.5 Pros
-
- Graceful adoption of future versions of NSEC, while there are no
- amendments to DNSSEC-bis.
-
-2.2.2 A Complete Type-code and Signal Rollover
-
- A new DNSSEC space is defined which can exist independent of current
- DNSSEC-bis space.
-
- This proposal assumes that all current DNSSEC type-codes
- (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
- future versions of DNSSEC. Any future version of DNSSEC has its own
- types to allow for keys, signatures, authenticated denial, etcetera.
-
-2.2.2.1 Coexistence and Migration
-
- Both spaces can co-exist. They can be made completely orthogonal.
-
-2.2.2.2 Limitations
-
- None.
-
-2.2.2.3 Amendments to DNSSEC-bis
-
- None.
-
-2.2.2.4 Cons
-
- With this path we abandon the current DNSSEC-bis. Though it is easy
- to role specific well-known and well-tested parts into the re-write,
- once deployment has started this path is very expensive for
- implementers, registries, registrars and registrants as well as
- resolvers/users. A TCR is not to be expected to occur frequently, so
- while a next generation authenticated denial may be enabled by a TCR,
- it is likely that that TCR will only be agreed upon if it serves a
- whole basket of changes or additions. A quick introduction of
- NSEC-ng should not be expected from this path.
-
-2.2.2.5 Pros
-
- No amendments/changes to current DNSSEC-bis docset needed. It is
- always there as last resort.
-
-2.2.3 Unknown Algorithm in RRSIG
-
- This proposal assumes that future extensions make use of the existing
- NSEC RDATA syntax, while it may need to change the interpretation of
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 11]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- the RDATA or introduce an alternative denial mechanism, invoked by
- the specific unknown signing algorithm. The different interpretation
- would be signaled by use of different signature algorithms in the
- RRSIG records covering the NSEC RRs.
-
- When an entire zone is signed with a single unknown algorithm, it
- will cause implementations that follow current dnssec-bis documents
- to treat individual RRsets as unsigned.
-
-2.2.3.1 Coexistence and migration
-
- Old and new NSEC RDATA interpretation or known and unknown Signatures
- can NOT coexist in a zone since signatures cover complete (NSEC)
- RRSets.
-
-2.2.3.2 Limitations
-
- Validating resolvers agnostic of new interpretation will treat the
- NSEC RRset as "not signed". This affects wildcard and non-existence
- proof, as well as proof for (un)secured delegations. Also, all
- positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
- insecure/bogus to an old validator.
-
- The algorithm version space is split for each future version of
- DNSSEC. Violation of the 'modular components' concept. We use the
- 'validator' to protect the 'resolver' from unknown interpretations.
-
-2.2.3.3 Amendments to DNSSEC-bis
-
- None.
-
-2.2.3.4 Cons
-
- The algorithm field was not designed for this purpose. This is a
- straightforward hack.
-
-2.2.3.5 Pros
-
- No amendments/changes to current DNSSEC-bis docset needed.
-
-3. Recommendation
-
- The authors recommend that the working group commits to and starts
- work on a partial TCR, allowing graceful transition towards a future
- version of NSEC. Meanwhile, to accomodate the need for an
- immediately, temporary, solution against zone-traversal, we recommend
- On-Demand NSEC synthesis.
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 12]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- This approach does not require any mandatory changes to DNSSEC-bis,
- does not violate the protocol and fulfills the requirements. As a
- side effect, it moves the cost of implementation and deployment to
- the users (zone owners) of this mechanism.
-
-4. Acknowledgements
-
- The authors would like to thank Sam Weiler and Mark Andrews for their
- input and constructive comments.
-
-5. References
-
-5.1 Normative References
-
- [I-D.ietf-dnsext-dnssec-intro]
- Arends, R., Austein, R., Massey, D., Larson, M. and S.
- Rose, "DNS Security Introduction and Requirements",
- Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
- 2004.
-
- [I-D.ietf-dnsext-dnssec-protocol]
- Arends, R., "Protocol Modifications for the DNS Security
- Extensions",
- Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
- October 2004.
-
- [I-D.ietf-dnsext-dnssec-records]
- Arends, R., "Resource Records for the DNS Security
- Extensions",
- Internet-Draft draft-ietf-dnsext-dnssec-records-11,
- October 2004.
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
-5.2 Informative References
-
- [RFC1535] Gavron, E., "A Security Problem and Proposed Correction
- With Widely Deployed DNS Software", RFC 1535, October
- 1993.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 13]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
- RFC 2535, March 1999.
-
- [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
- June 1999.
-
- [RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
- (RR)", RFC 3658, December 2003.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Brouwerijstraat 1
- Enschede 7523 XC
- The Netherlands
-
- Phone: +31 53 4850485
- Email: roy.arends@telin.nl
-
-
- Peter Koch
- DENIC eG
- Wiesenh"uttenplatz 26
- Frankfurt 60329
- Germany
-
- Phone: +49 69 27235 0
- Email: pk@DENIC.DE
-
-
- Jakob Schlyter
- NIC-SE
- Box 5774
- Stockholm SE-114 87
- Sweden
-
- Email: jakob@nic.se
- URI: http://www.nic.se/
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 14]
-
-Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Arends, et al. Expires August 25, 2005 [Page 15]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
deleted file mode 100644
index 2460cb619b67..000000000000
--- a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-Network Working Group W. Hardaker
-Internet-Draft Sparta
-Expires: August 25, 2006 February 21, 2006
-
-
- Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
- draft-ietf-dnsext-ds-sha256-05.txt
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 25, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document specifies how to use the SHA-256 digest type in DNS
- Delegation Signer (DS) Resource Records (RRs). DS records, when
- stored in a parent zone, point to key signing DNSKEY key(s) in a
- child zone.
-
-
-
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 1]
-
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Implementing the SHA-256 algorithm for DS record support . . . 3
- 2.1. DS record field values . . . . . . . . . . . . . . . . . . 3
- 2.2. DS Record with SHA-256 Wire Format . . . . . . . . . . . . 3
- 2.3. Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
- 3. Implementation Requirements . . . . . . . . . . . . . . . . . . 4
- 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
- 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
- 6.1. Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
- 6.2. SHA-1 vs SHA-256 Considerations for DS Records . . . . . . 6
- 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
- Intellectual Property and Copyright Statements . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 2]
-
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-1. Introduction
-
- The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
- zones to distribute a cryptographic digest of a child's Key Signing
- Key (KSK) DNSKEY RR. The DS RRset is signed by at least one of the
- parent zone's private zone data signing keys for each algorithm in
- use by the parent. Each signature is published in an RRSIG resource
- record, owned by the same domain as the DS RRset and with a type
- covered of DS.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-2. Implementing the SHA-256 algorithm for DS record support
-
- This document specifies that the digest type code [XXX: To be
- assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
- [SHA256CODE] for use within DS records. The results of the digest
- algorithm MUST NOT be truncated and the entire 32 byte digest result
- is to be published in the DS record.
-
-2.1. DS record field values
-
- Using the SHA-256 digest algorithm within a DS record will make use
- of the following DS-record fields:
-
- Digest type: [XXX: To be assigned by IANA; likely 2]
-
- Digest: A SHA-256 bit digest value calculated by using the following
- formula ("|" denotes concatenation). The resulting value is not
- truncated and the entire 32 byte result is to used in the
- resulting DS record and related calculations.
-
- digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
-
- where DNSKEY RDATA is defined by [RFC4034] as:
-
- DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
-
- The Key Tag field and Algorithm fields remain unchanged by this
- document and are specified in the [RFC4034] specification.
-
-2.2. DS Record with SHA-256 Wire Format
-
- The resulting on-the-wire format for the resulting DS record will be
- [XXX: IANA assignment should replace the 2 below]:
-
-
-
-Hardaker Expires August 25, 2006 [Page 3]
-
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Key Tag | Algorithm | DigestType=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / /
- / Digest (length for SHA-256 is 32 bytes) /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-2.3. Example DS Record Using SHA-256
-
- The following is an example DNSKEY and matching DS record. This
- DNSKEY record comes from the example DNSKEY/DS records found in
- section 5.4 of [RFC4034].
-
- The DNSKEY record:
-
- dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
- fwJr1AYtsmx3TGkJaNXVbfi/
- 2pHm822aJ5iI9BMzNXxeYCmZ
- DRD99WYwYqUSdjMmmAphXdvx
- egXd/M5+X7OrzKBaMbCVdFLU
- Uh6DhweJBjEVv5f2wwjM9Xzc
- nOf+EPbtG9DMBmADjFDc2w/r
- ljwvFw==
- ) ; key id = 60485
-
- The resulting DS record covering the above DNSKEY record using a SHA-
- 256 digest: [RFC Editor: please replace XXX with the assigned digest
- type (likely 2):]
-
- dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
- CEB1E3E0614B93C4F9E99B83
- 83F6A1E4469DA50A )
-
-
-3. Implementation Requirements
-
- Implementations MUST support the use of the SHA-256 algorithm in DS
- RRs. Validator implementations SHOULD ignore DS RRs containing SHA-1
- digests if DS RRs with SHA-256 digests are present in the DS RRset.
-
-
-4. Deployment Considerations
-
- If a validator does not support the SHA-256 digest type and no other
- DS RR exists in a zone's DS RRset with a supported digest type, then
-
-
-
-Hardaker Expires August 25, 2006 [Page 4]
-
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
- the validator has no supported authentication path leading from the
- parent to the child. The resolver should treat this case as it would
- the case of an authenticated NSEC RRset proving that no DS RRset
- exists, as described in [RFC4035], section 5.2.
-
- Because zone administrators can not control the deployment speed of
- support for SHA-256 in validators that may be referencing any of
- their zones, zone operators should consider deploying both SHA-1 and
- SHA-256 based DS records. This should be done for every DNSKEY for
- which DS records are being generated. Whether to make use of both
- digest types and for how long is a policy decision that extends
- beyond the scope of this document.
-
-
-5. IANA Considerations
-
- Only one IANA action is required by this document:
-
- The Digest Type to be used for supporting SHA-256 within DS records
- needs to be assigned by IANA. This document requests that the Digest
- Type value of 2 be assigned to the SHA-256 digest algorithm.
-
- At the time of this writing, the current digest types assigned for
- use in DS records are as follows:
-
- VALUE Digest Type Status
- 0 Reserved -
- 1 SHA-1 MANDATORY
- 2 SHA-256 MANDATORY
- 3-255 Unassigned -
-
-
-6. Security Considerations
-
-6.1. Potential Digest Type Downgrade Attacks
-
- A downgrade attack from a stronger digest type to a weaker one is
- possible if all of the following are true:
-
- o A zone includes multiple DS records for a given child's DNSKEY,
- each of which use a different digest type.
-
- o A validator accepts a weaker digest even if a stronger one is
- present but invalid.
-
- For example, if the following conditions are all true:
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 5]
-
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
- o Both SHA-1 and SHA-256 based digests are published in DS records
- within a parent zone for a given child zone's DNSKEY.
-
- o The DS record with the SHA-1 digest matches the digest computed
- using the child zone's DNSKEY.
-
- o The DS record with the SHA-256 digest fails to match the digest
- computed using the child zone's DNSKEY.
-
- Then if the validator accepts the above situation as secure then this
- can be used as a downgrade attack since the stronger SHA-256 digest
- is ignored.
-
-6.2. SHA-1 vs SHA-256 Considerations for DS Records
-
- Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
- implementations allow for it. SHA-256 is widely believed to be more
- resilient to attack than SHA-1, and confidence in SHA-1's strength is
- being eroded by recently-announced attacks. Regardless of whether or
- not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
- time of this writing) that SHA-256 is the better choice for use in DS
- records.
-
- At the time of this publication, the SHA-256 digest algorithm is
- considered sufficiently strong for the immediate future. It is also
- considered sufficient for use in DNSSEC DS RRs for the immediate
- future. However, future published attacks may weaken the usability
- of this algorithm within the DS RRs. It is beyond the scope of this
- document to speculate extensively on the cryptographic strength of
- the SHA-256 digest algorithm.
-
- Likewise, it is also beyond the scope of this document to specify
- whether or for how long SHA-1 based DS records should be
- simultaneously published alongside SHA-256 based DS records.
-
-
-7. Acknowledgments
-
- This document is a minor extension to the existing DNSSEC documents
- and those authors are gratefully appreciated for the hard work that
- went into the base documents.
-
- The following people contributed to portions of this document in some
- fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
- Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
- Weiler.
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 6]
-
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-8. References
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [SHA256] National Institute of Standards and Technology, "Secure
- Hash Algorithm. NIST FIPS 180-2", August 2002.
-
-8.2. Informative References
-
- [SHA256CODE]
- Eastlake, D., "US Secure Hash Algorithms (SHA)",
- June 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 7]
-
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-Author's Address
-
- Wes Hardaker
- Sparta
- P.O. Box 382
- Davis, CA 95617
- US
-
- Email: hardaker@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 8]
-
-Internet-Draft Use of SHA-256 in DNSSEC DS RRs February 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Hardaker Expires August 25, 2006 [Page 9]
-
diff --git a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
deleted file mode 100644
index 2cdcdb16c920..000000000000
--- a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT ECC Keys in the DNS
-Expires: January 2006 July 2005
-
-
-
- Elliptic Curve KEYs in the DNS
- -------- ----- ---- -- --- ---
- <draft-ietf-dnsext-ecc-key-07.txt>
-
- Richard C. Schroeppel
- Donald Eastlake 3rd
-
-
-Status of This Document
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNS mailing list <namedroppers@ops.ietf.org>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-Abstract
-
- The standard method for storing elliptic curve cryptographic keys and
- signatures in the Domain Name System is specified.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-
-
-R. Schroeppel, et al [Page 1]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-Acknowledgement
-
- The assistance of Hilarie K. Orman in the production of this document
- is greatfully acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
- Copyright Notice...........................................1
-
- Acknowledgement............................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. Elliptic Curve Data in Resource Records.................3
- 3. The Elliptic Curve Equation.............................9
- 4. How do I Compute Q, G, and Y?..........................10
- 5. Elliptic Curve SIG Resource Records....................11
- 6. Performance Considerations.............................13
- 7. Security Considerations................................13
- 8. IANA Considerations....................................13
- Copyright and Disclaimer..................................14
-
- Informational References..................................15
- Normative Refrences.......................................15
-
- Author's Addresses........................................16
- Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 2]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. The DNS has been extended to include digital
- signatures and cryptographic keys as described in [RFC 4033, 4034,
- 4035].
-
- This document describes how to store elliptic curve cryptographic
- (ECC) keys and signatures in the DNS so they can be used for a
- variety of security purposes. Familiarity with ECC cryptography is
- assumed [Menezes].
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC 2119].
-
-
-
-2. Elliptic Curve Data in Resource Records
-
- Elliptic curve public keys are stored in the DNS within the RDATA
- portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
- structure shown below.
-
- The research world continues to work on the issue of which is the
- best elliptic curve system, which finite field to use, and how to
- best represent elements in the field. So, representations are
- defined for every type of finite field, and every type of elliptic
- curve. The reader should be aware that there is a unique finite
- field with a particular number of elements, but many possible
- representations of that field and its elements. If two different
- representations of a field are given, they are interconvertible with
- a tedious but practical precomputation, followed by a fast
- computation for each field element to be converted. It is perfectly
- reasonable for an algorithm to work internally with one field
- representation, and convert to and from a different external
- representation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 3]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S M -FMT- A B Z|
- +-+-+-+-+-+-+-+-+
- | LP |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | P (length determined from LP) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LF |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | F (length determined from LF) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEG |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGI |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGJ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | TRDV |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | H (length determined from LH) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LK |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | K (length determined from LK) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LQ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Q (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | A (length determined from LA) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | ALTA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LB |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | B (length determined from LB) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LC |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | C (length determined from LC) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LG |
-
-
-R. Schroeppel, et al [Page 4]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | G (length determined from LG) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LY |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Y (length determined from LY) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- SMFMTABZ is a flags octet as follows:
-
- S = 1 indicates that the remaining 7 bits of the octet selects
- one of 128 predefined choices of finite field, element
- representation, elliptic curve, and signature parameters.
- MFMTABZ are omitted, as are all parameters from LP through G.
- LY and Y are retained.
-
- If S = 0, the remaining parameters are as in the picture and
- described below.
-
- M determines the type of field underlying the elliptic curve.
-
- M = 0 if the field is a GF[2^N] field;
-
- M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
-
- FMT is a three bit field describing the format of the field
- representation.
-
- FMT = 0 for a (mod P) field.
- > 0 for an extension field, either GF[2^D] or GF[P^D].
- The degree D of the extension, and the field polynomial
- must be specified. The field polynomial is always monic
- (leading coefficient 1.)
-
- FMT = 1 The field polynomial is given explicitly; D is implied.
-
- If FMT >=2, the degree D is given explicitly.
-
- = 2 The field polynomial is implicit.
- = 3 The field polynomial is a binomial. P>2.
- = 4 The field polynomial is a trinomial.
- = 5 The field polynomial is the quotient of a trinomial by a
- short polynomial. P=2.
- = 6 The field polynomial is a pentanomial. P=2.
-
- Flags A and B apply to the elliptic curve parameters.
-
-
-
-
-
-
-R. Schroeppel, et al [Page 5]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- A = 1 When P>=5, the curve parameter A is negated. If P=2, then
- A=1 indicates that the A parameter is special. See the
- ALTA parameter below, following A. The combination A=1,
- P=3 is forbidden.
-
- B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
- then B=1 indicates an alternate elliptic curve equation is
- used. When P=2 and B=1, an additional curve parameter C
- is present.
-
- The Z bit SHOULD be set to zero on creation of an RR and MUST be
- ignored when processing an RR (when S=0).
-
- Most of the remaining parameters are present in some formats and
- absent in others. The presence or absence of a parameter is
- determined entirely by the flags. When a parameter occurs, it is in
- the order defined by the picture.
-
- Of the remaining parameters, PFHKQABCGY are variable length. When
- present, each is preceded by a one-octet length field as shown in the
- diagram above. The length field does not include itself. The length
- field may have values from 0 through 110. The parameter length in
- octets is determined by a conditional formula: If LL<=64, the
- parameter length is LL. If LL>64, the parameter length is 16 times
- (LL-60). In some cases, a parameter value of 0 is sensible, and MAY
- be represented by an LL value of 0, with the data field omitted. A
- length value of 0 represents a parameter value of 0, not an absent
- parameter. (The data portion occupies 0 space.) There is no
- requirement that a parameter be represented in the minimum number of
- octets; high-order 0 octets are allowed at the front end. Parameters
- are always right adjusted, in a field of length defined by LL. The
- octet-order is always most-significant first, least-significant last.
- The parameters H and K may have an optional sign bit stored in the
- unused high-order bit of their length fields.
-
- LP defines the length of the prime P. P must be an odd prime. The
- parameters LP,P are present if and only if the flag M=1. If M=0, the
- prime is 2.
-
- LF,F define an explicit field polynomial. This parameter pair is
- present only when FMT = 1. The length of a polynomial coefficient is
- ceiling(log2 P) bits. Coefficients are in the numerical range
- [0,P-1]. The coefficients are packed into fixed-width fields, from
- higher order to lower order. All coefficients must be present,
- including any 0s and also the leading coefficient (which is required
- to be 1). The coefficients are right justified into the octet string
- of length specified by LF, with the low-order "constant" coefficient
- at the right end. As a concession to storage efficiency, the higher
- order bits of the leading coefficient may be elided, discarding high-
- order 0 octets and reducing LF. The degree is calculated by
-
-
-R. Schroeppel, et al [Page 6]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- determining the bit position of the left most 1-bit in the F data
- (counting the right most bit as position 0), and dividing by
- ceiling(log2 P). The division must be exact, with no remainder. In
- this format, all of the other degree and field parameters are
- omitted. The next parameters will be LQ,Q.
-
- If FMT>=2, the degree of the field extension is specified explicitly,
- usually along with other parameters to define the field polynomial.
-
- DEG is a two octet field that defines the degree of the field
- extension. The finite field will have P^DEG elements. DEG is
- present when FMT>=2.
-
- When FMT=2, the field polynomial is specified implicitly. No other
- parameters are required to define the field; the next parameters
- present will be the LQ,Q pair. The implicit field poynomial is the
- lexicographically smallest irreducible (mod P) polynomial of the
- correct degree. The ordering of polynomials is by highest-degree
- coefficients first -- the leading coefficient 1 is most important,
- and the constant term is least important. Coefficients are ordered
- by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
- degree D is X^D (which is not irreducible). The next is X^D+1, which
- is sometimes irreducible, followed by X^D-1, which isn't. Assuming
- odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
- X, X^D + X + 1, X^D + X - 1, etc.
-
- When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
- odd. The polynomial is determined by the degree and the low order
- term K. Of all the field parameters, only the LK,K parameters are
- present. The high-order bit of the LK octet stores on optional sign
- for K; if the sign bit is present, the field polynomial is X^DEG - K.
-
- When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
- K. When P=2, the H and K parameters are implicitly 1, and are
- omitted from the representation. Only DEG and DEGH are present; the
- next parameters are LQ,Q. When P>2, then LH,H and LK,K are
- specified. Either or both of LH, LK may contain a sign bit for its
- parameter.
-
- When FMT=5, then P=2 (only). The field polynomial is the exact
- quotient of a trinomial divided by a small polynomial, the trinomial
- divisor. The small polynomial is right-adjusted in the two octet
- field TRDV. DEG specifies the degree of the field. The degree of
- TRDV is calculated from the position of the high-order 1 bit. The
- trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
- DEGH is 0, the middle term is omitted from the trinomial. The
- quotient must be exact, with no remainder.
-
- When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
- with the degrees of the middle terms given by the three 2-octet
-
-
-R. Schroeppel, et al [Page 7]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
- X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
- > DEGJ > 0.
-
- DEGH, DEGI, DEGJ are two-octet fields that define the degree of
- a term in a field polynomial. DEGH is present when FMT = 4,
- 5, or 6. DEGI and DEGJ are present only when FMT = 6.
-
- TRDV is a two-octet right-adjusted binary polynomial of degree <
- 16. It is present only for FMT=5.
-
- LH and H define the H parameter, present only when FMT=4 and P
- is odd. The high bit of LH is an optional sign bit for H.
-
- LK and K define the K parameter, present when FMT = 3 or 4, and
- P is odd. The high bit of LK is an optional sign bit for K.
-
- The remaining parameters are concerned with the elliptic curve and
- the signature algorithm.
-
- LQ defines the length of the prime Q. Q is a prime > 2^159.
-
- In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
- member of the pair is an element from the finite field defined
- earlier. The length field defines a long octet string. Field
- elements are represented as (mod P) polynomials of degree < DEG, with
- DEG or fewer coefficients. The coefficients are stored from left to
- right, higher degree to lower, with the constant term last. The
- coefficients are represented as integers in the range [0,P-1]. Each
- coefficient is allocated an area of ceiling(log2 P) bits. The field
- representation is right-justified; the "constant term" of the field
- element ends at the right most bit. The coefficients are fitted
- adjacently without regard for octet boundaries. (Example: if P=5,
- three bits are used for each coefficient. If the field is GF[5^75],
- then 225 bits are required for the coefficients, and as many as 29
- octets may be needed in the data area. Fewer octets may be used if
- some high-order coefficients are 0.) If a flag requires a field
- element to be negated, each non-zero coefficient K is replaced with
- P-K. To save space, 0 bits may be removed from the left end of the
- element representation, and the length field reduced appropriately.
- This would normally only happen with A,B,C, because the designer
- chose curve parameters with some high-order 0 coefficients or bits.
-
- If the finite field is simply (mod P), then the field elements are
- simply numbers (mod P), in the usual right-justified notation. If
- the finite field is GF[2^D], the field elements are the usual right-
- justified polynomial basis representation.
-
-
-
-
-
-R. Schroeppel, et al [Page 8]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- LA,A is the first parameter of the elliptic curve equation.
- When P>=5, the flag A = 1 indicates A should be negated (mod
- P). When P=2 (indicated by the flag M=0), the flag A = 1
- indicates that the parameter pair LA,A is replaced by the two
- octet parameter ALTA. In this case, the parameter A in the
- curve equation is x^ALTA, where x is the field generator.
- Parameter A often has the value 0, which may be indicated by
- LA=0 (with no A data field), and sometimes A is 1, which may
- be represented with LA=1 and a data field of 1, or by setting
- the A flag and using an ALTA value of 0.
-
- LB,B is the second parameter of the elliptic curve equation.
- When P>=5, the flag B = 1 indicates B should be negated (mod
- P). When P=2 or 3, the flag B selects an alternate curve
- equation.
-
- LC,C is the third parameter of the elliptic curve equation,
- present only when P=2 (indicated by flag M=0) and flag B=1.
-
- LG,G defines a point on the curve, of order Q. The W-coordinate
- of the curve point is given explicitly; the Z-coordinate is
- implicit.
-
- LY,Y is the user's public signing key, another curve point of
- order Q. The W-coordinate is given explicitly; the Z-
- coordinate is implicit. The LY,Y parameter pair is always
- present.
-
-
-
-3. The Elliptic Curve Equation
-
- (The coordinates of an elliptic curve point are named W,Z instead of
- the more usual X,Y to avoid confusion with the Y parameter of the
- signing key.)
-
- The elliptic curve equation is determined by the flag octet, together
- with information about the prime P. The primes 2 and 3 are special;
- all other primes are treated identically.
-
- If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
- + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
- If A and/or B is negative (i.e., in the range from P/2 to P), and
- P>=5, space may be saved by putting the sign bit(s) in the A and B
- bits of the flags octet, and the magnitude(s) in the parameter
- fields.
-
- If M=1 and P=3, the B flag has a different meaning: it specifies an
- alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
- the right-hand-side is different. When P=3, this equation is more
-
-
-R. Schroeppel, et al [Page 9]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- commonly used.
-
- If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
- A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
- parameter can often be 0 or 1, or be chosen as a single-1-bit value.
- The flag B is used to select an alternate curve equation, Z^2 + C*Z =
- W^3 + A*W + B. This is the only time that the C parameter is used.
-
-
-
-4. How do I Compute Q, G, and Y?
-
- The number of points on the curve is the number of solutions to the
- curve equation, + 1 (for the "point at infinity"). The prime Q must
- divide the number of points. Usually the curve is chosen first, then
- the number of points is determined with Schoof's algorithm. This
- number is factored, and if it has a large prime divisor, that number
- is taken as Q.
-
- G must be a point of order Q on the curve, satisfying the equation
-
- Q * G = the point at infinity (on the elliptic curve)
-
- G may be chosen by selecting a random [RFC 1750] curve point, and
- multiplying it by (number-of-points-on-curve/Q). G must not itself
- be the "point at infinity"; in this astronomically unlikely event, a
- new random curve point is recalculated.
-
- G is specified by giving its W-coordinate. The Z-coordinate is
- calculated from the curve equation. In general, there will be two
- possible Z values. The rule is to choose the "positive" value.
-
- In the (mod P) case, the two possible Z values sum to P. The smaller
- value is less than P/2; it is used in subsequent calculations. In
- GF[P^D] fields, the highest-degree non-zero coefficient of the field
- element Z is used; it is chosen to be less than P/2.
-
- In the GF[2^N] case, the two possible Z values xor to W (or to the
- parameter C with the alternate curve equation). The numerically
- smaller Z value (the one which does not contain the highest-order 1
- bit of W (or C)) is used in subsequent calculations.
-
- Y is specified by giving the W-coordinate of the user's public
- signature key. The Z-coordinate value is determined from the curve
- equation. As with G, there are two possible Z values; the same rule
- is followed for choosing which Z to use.
-
-
-
-
-
-
-R. Schroeppel, et al [Page 10]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- During the key generation process, a random [RFC 1750] number X must
- be generated such that 1 <= X <= Q-1. X is the private key and is
- used in the final step of public key generation where Y is computed
- as
-
- Y = X * G (as points on the elliptic curve)
-
- If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
- in the (mod P) case, or the high-order non-zero coefficient of Z >
- P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
- GF[2^N] case), then X must be replaced with Q-X. This will
- correspond to the correct Z-coordinate.
-
-
-
-5. Elliptic Curve SIG Resource Records
-
- The signature portion of an RR RDATA area when using the EC
- algorithm, for example in the RRSIG and SIG [RFC records] RRs is
- shown below.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | R, (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | S, (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- R and S are integers (mod Q). Their length is specified by the LQ
- field of the corresponding KEY RR and can also be calculated from the
- SIG RR's RDLENGTH. They are right justified, high-order-octet first.
- The same conditional formula for calculating the length from LQ is
- used as for all the other length fields above.
-
- The data signed is determined as specified in [RFC 2535]. Then the
- following steps are taken where Q, P, G, and Y are as specified in
- the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate random [RFC 4086] K such that 0 < K < Q. (Never sign two
- different messages with the same K. K should be chosen from a
- very large space: If an opponent learns a K value for a single
- signature, the user's signing key is compromised, and a forger
- can sign arbitrary messages. There is no harm in signing the
- same message multiple times with the same key or different
- keys.)
-
- R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
-
-
-R. Schroeppel, et al [Page 11]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- as an integer, and reduced (mod Q). (R must not be 0. In
- this astronomically unlikely event, generate a new random K
- and recalculate R.)
-
- S = ( K^(-1) * (hash + X*R) ) mod Q.
-
- S must not be 0. In this astronomically unlikely event, generate a
- new random K and recalculate R and S.
-
- If S > Q/2, set S = Q - S.
-
- The pair (R,S) is the signature.
-
- Another party verifies the signature as follows:
-
- Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
- valid EC sigature.
-
- hash = SHA-1 ( data )
-
- Sinv = S^(-1) mod Q.
-
- U1 = (hash * Sinv) mod Q.
-
- U2 = (R * Sinv) mod Q.
-
- (U1 * G + U2 * Y) is computed on the elliptic curve.
-
- V = (the W-coordinate of this point) interpreted as an integer
- and reduced (mod Q).
-
- The signature is valid if V = R.
-
- The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
- (R,Q-S) would be valid signatures for the same data. Note that a
- signature that is valid for hash(data) is also valid for
- hash(data)+Q or hash(data)-Q, if these happen to fall in the range
- [0,2^160-1]. It's believed to be computationally infeasible to
- find data that hashes to an assigned value, so this is only a
- cosmetic blemish. The blemish can be eliminated by using Q >
- 2^160, at the cost of having slightly longer signatures, 42 octets
- instead of 40.
-
- We must specify how a field-element E ("the W-coordinate") is to be
- interpreted as an integer. The field-element E is regarded as a
- radix-P integer, with the digits being the coefficients in the
- polynomial basis representation of E. The digits are in the ragne
- [0,P-1]. In the two most common cases, this reduces to "the
- obvious thing". In the (mod P) case, E is simply a residue mod P,
- and is taken as an integer in the range [0,P-1]. In the GF[2^D]
-
-
-R. Schroeppel, et al [Page 12]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- case, E is in the D-bit polynomial basis representation, and is
- simply taken as an integer in the range [0,(2^D)-1]. For other
- fields GF[P^D], it's necessary to do some radix conversion
- arithmetic.
-
-
-
- 6. Performance Considerations
-
- Elliptic curve signatures use smaller moduli or field sizes than
- RSA and DSA. Creation of a curve is slow, but not done very often.
- Key generation is faster than RSA or DSA.
-
- DNS implementations have been optimized for small transfers,
- typically less than 512 octets including DNS overhead. Larger
- transfers will perform correctly and and extensions have been
- standardized to make larger transfers more efficient [RFC 2671].
- However, it is still advisable at this time to make reasonable
- efforts to minimize the size of RR sets stored within the DNS
- consistent with adequate security.
-
-
-
- 7. Security Considerations
-
- Keys retrieved from the DNS should not be trusted unless (1) they
- have been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- Some specific key generation considerations are given in the body
- of this document.
-
-
-
- 8. IANA Considerations
-
- The key and signature data structures defined herein correspond to
- the value 4 in the Algorithm number field of the IANA registry
-
- Assignment of meaning to the remaining ECC data flag bits or to
- values of ECC fields outside the ranges for which meaning in
- defined in this document requires an IETF consensus as defined in
- [RFC 2434].
-
-
-
-
-
-R. Schroeppel, et al [Page 13]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- Copyright and Disclaimer
-
- Copyright (C) The Internet Society 2005. This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
- This document and the information contained herein are provided on
- an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
- EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
- THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
- ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
- PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 14]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- Informational References
-
- [RFC 1034] - P. Mockapetris, "Domain names - concepts and
- facilities", 11/01/1987.
-
- [RFC 1035] - P. Mockapetris, "Domain names - implementation and
- specification", 11/01/1987.
-
- [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
- August 1999.
-
- [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
- S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
- March 2005.
-
- [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
- S. Rose, "Protocol Modifications for the DNS Security Extensions",
- RFC 4035, March 2005.
-
- [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086, June
- 2005.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C", 1996, John Wiley and Sons
-
- [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
- Cryptosystems", 1993 Kluwer.
-
- [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
- Curves", 1986, Springer Graduate Texts in mathematics #106.
-
-
-
- Normative Refrences
-
- [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", March 1997.
-
- [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", October 1998.
-
- [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
- S. Rose, "Resource Records for the DNS Security Extensions", RFC
- 4034, March 2005.
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 15]
-
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- Author's Addresses
-
- Rich Schroeppel
- 500 S. Maple Drive
- Woodland Hills, UT 84653 USA
-
- Telephone: +1-505-844-9079(w)
- Email: rschroe@sandia.gov
-
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-786-7554 (w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
- Expiration and File Name
-
- This draft expires in January 2006.
-
- Its file name is draft-ietf-dnsext-ecc-key-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 16]
-
diff --git a/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/doc/draft/draft-ietf-dnsext-interop3597-02.txt
deleted file mode 100644
index 160afc356a07..000000000000
--- a/doc/draft/draft-ietf-dnsext-interop3597-02.txt
+++ /dev/null
@@ -1,334 +0,0 @@
-DNS Extensions Working Group J. Schlyter
-Internet-Draft May 19, 2005
-Expires: November 20, 2005
-
-
- RFC 3597 Interoperability Report
- draft-ietf-dnsext-interop3597-02.txt
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on November 20, 2005.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2005).
-
-Abstract
-
- This memo documents the result from the RFC 3597 (Handling of Unknown
- DNS Resource Record Types) interoperability testing.
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires November 20, 2005 [Page 1]
-
-Internet-Draft RFC 3597 Interoperability Report May 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Implementations . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1 Authoritative Primary Name Server . . . . . . . . . . . . 3
- 3.2 Authoritative Secondary Name Server . . . . . . . . . . . 3
- 3.3 Full Recursive Resolver . . . . . . . . . . . . . . . . . 4
- 3.4 Stub Resolver . . . . . . . . . . . . . . . . . . . . . . 4
- 3.5 DNSSEC Signer . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Problems found . . . . . . . . . . . . . . . . . . . . . . . . 4
- 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 4
- A. Test zone data . . . . . . . . . . . . . . . . . . . . . . . . 5
- Intellectual Property and Copyright Statements . . . . . . . . 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires November 20, 2005 [Page 2]
-
-Internet-Draft RFC 3597 Interoperability Report May 2005
-
-
-1. Introduction
-
- This memo documents the result from the RFC 3597 (Handling of Unknown
- DNS Resource Record Types) interoperability testing. The test was
- performed during June and July 2004 by request of the IETF DNS
- Extensions Working Group.
-
-2. Implementations
-
- The following is a list, in alphabetic order, of implementations
- tested for compliance with RFC 3597:
-
- DNSJava 1.6.4
- ISC BIND 8.4.5
- ISC BIND 9.3.0
- NSD 2.1.1
- Net::DNS 0.47 patchlevel 1
- Nominum ANS 2.2.1.0.d
-
- These implementations covers the following functions (number of
- implementations tested for each function in paranthesis):
-
- Authoritative Name Servers (4)
- Full Recursive Resolver (2)
- Stub Resolver (4)
- DNSSEC Zone Signers (2)
-
- All listed implementations are genetically different.
-
-3. Tests
-
- The following tests was been performed to validate compliance with
- RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
- and 5 ("Text Representation").
-
-3.1 Authoritative Primary Name Server
-
- The test zone data (Appendix A) was loaded into the name server
- implementation and the server was queried for the loaded information.
-
-3.2 Authoritative Secondary Name Server
-
- The test zone data (Appendix A) was transferred using AXFR from
- another name server implementation and the server was queried for the
- transferred information.
-
-
-
-
-
-
-Schlyter Expires November 20, 2005 [Page 3]
-
-Internet-Draft RFC 3597 Interoperability Report May 2005
-
-
-3.3 Full Recursive Resolver
-
- A recursive resolver was queried for resource records from a domain
- with the test zone data (Appendix A).
-
-3.4 Stub Resolver
-
- A stub resolver was used to query resource records from a domain with
- the test zone data (Appendix A).
-
-3.5 DNSSEC Signer
-
- A DNSSEC signer was used to sign a zone with test zone data
- (Appendix A).
-
-4. Problems found
-
- Two implementations had problems with text presentation of zero
- length RDATA.
-
- One implementation had problems with text presentation of RR type
- code and classes >= 4096.
-
- Bug reports were filed for problems found.
-
-5. Summary
-
- Unknown type codes works in the tested authoritative servers,
- recursive resolvers and stub clients.
-
- No changes are needed to advance RFC 3597 to draft standard.
-
-6. Normative References
-
- [1] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
-
-Author's Address
-
- Jakob Schlyter
-
- Email: jakob@rfc.se
-
-
-
-
-
-
-
-
-Schlyter Expires November 20, 2005 [Page 4]
-
-Internet-Draft RFC 3597 Interoperability Report May 2005
-
-
-Appendix A. Test zone data
-
- ; A-record encoded as TYPE1
- a TYPE1 \# 4 7f000001
- a TYPE1 192.0.2.1
- a A \# 4 7f000002
-
- ; draft-ietf-secsh-dns-05.txt
- sshfp TYPE44 \# 22 01 01 c691e90714a1629d167de8e5ee0021f12a7eaa1e
-
- ; bogus test record (from RFC 3597)
- type731 TYPE731 \# 6 abcd (
- ef 01 23 45 )
-
- ; zero length RDATA (from RFC 3597)
- type62347 TYPE62347 \# 0
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires November 20, 2005 [Page 5]
-
-Internet-Draft RFC 3597 Interoperability Report May 2005
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Schlyter Expires November 20, 2005 [Page 6]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
deleted file mode 100644
index 6bffb70423f4..000000000000
--- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-DNS Extensions O. Kolkman
-Internet-Draft RIPE NCC
-Expires: June 17, 2004 J. Schlyter
-
- E. Lewis
- ARIN
- December 18, 2003
-
-
- DNSKEY RR Secure Entry Point Flag
- draft-ietf-dnsext-keyrr-key-signing-flag-12
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at http://
- www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on June 17, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- With the Delegation Signer (DS) resource record the concept of a
- public key acting as a secure entry point has been introduced. During
- exchanges of public keys with the parent there is a need to
- differentiate secure entry point keys from other public keys in the
- DNSKEY resource record (RR) set. A flag bit in the DNSKEY RR is
- defined to indicate that DNSKEY is to be used as a secure entry
- point. The flag bit is intended to assist in operational procedures
- to correctly generate DS resource records, or to indicate what
- DNSKEYs are intended for static configuration. The flag bit is not to
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 1]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- be used in the DNS verification protocol. This document updates RFC
- 2535 and RFC 3445.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The Secure Entry Point (SEP) Flag . . . . . . . . . . . . . . . 4
- 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . . 5
- 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
- 7. Internationalization Considerations . . . . . . . . . . . . . . 6
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
- Normative References . . . . . . . . . . . . . . . . . . . . . . 7
- Informative References . . . . . . . . . . . . . . . . . . . . . 7
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
- Intellectual Property and Copyright Statements . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 2]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
-1. Introduction
-
- "All keys are equal but some keys are more equal than others" [6]
-
- With the definition of the Delegation Signer Resource Record (DS RR)
- [5] it has become important to differentiate between the keys in the
- DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
- other keys in the DNSKEY RR set. We refer to these public keys as
- Secure Entry Point (SEP) keys. A SEP key either used to generate a
- DS RR or is distributed to resolvers that use the key as the root of
- a trusted subtree[3].
-
- In early deployment tests, the use of two (kinds of) key pairs for
- each zone has been prevalent. For one kind of key pair the private
- key is used to sign just the zone's DNSKEY resource record (RR) set.
- Its public key is intended to be referenced by a DS RR at the parent
- or configured statically in a resolver. The private key of the other
- kind of key pair is used to sign the rest of the zone's data sets.
- The former key pair is called a key-signing key (KSK) and the latter
- is called a zone-signing key (ZSK). In practice there have been
- usually one of each kind of key pair, but there will be multiples of
- each at times.
-
- It should be noted that division of keys pairs into KSK's and ZSK's
- is not mandatory in any definition of DNSSEC, not even with the
- introduction of the DS RR. But, in testing, this distinction has
- been helpful when designing key roll over (key super-cession)
- schemes. Given that the distinction has proven helpful, the labels
- KSK and ZSK have begun to stick.
-
- There is a need to differentiate the public keys for the key pairs
- that are used for key signing from keys that are not used key signing
- (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
- be sent for generating DS RRs, which DNSKEYs are to be distributed to
- resolvers, and which keys are fed to the signer application at the
- appropriate time.
-
- In other words, the SEP bit provides an in-band method to communicate
- a DNSKEY RR's intended use to third parties. As an example we present
- 3 use cases in which the bit is useful:
-
- The parent is a registry, the parent and the child use secured DNS
- queries and responses, with a preexisting trust-relation, or plain
- DNS over a secured channel to exchange the child's DNSKEY RR
- sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
- the SEP bit can be used to isolate the DNSKEYs for which a DS RR
- needs to be created.
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 3]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- An administrator has configured a DNSKEY as root for a trusted
- subtree into security aware resolver. Using a special purpose tool
- that queries for the KEY RRs from that domain's apex, the
- administrator will be able to notice the roll over of the trusted
- anchor by a change of the subset of KEY RRs with the DS flag set.
-
- A signer might use the SEP bit on the public key to determine
- which private key to use to exclusively sign the DNSKEY RRset and
- which private key to use to sign the other RRsets in the zone.
-
- As demonstrated in the above examples it is important to be able to
- differentiate the SEP keys from the other keys in a DNSKEY RR set in
- the flow between signer and (parental) key-collector and in the flow
- between the signer and the resolver configuration. The SEP flag is to
- be of no interest to the flow between the verifier and the
- authoritative data store.
-
- The reason for the term "SEP" is a result of the observation that the
- distinction between KSK and ZSK key pairs is made by the signer, a
- key pair could be used as both a KSK and a ZSK at the same time. To
- be clear, the term SEP was coined to lessen the confusion caused by
- the overlap. ( Once this label was applied, it had the side effect of
- removing the temptation to have both a KSK flag bit and a ZSK flag
- bit.)
-
- The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
- "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
- interpreted as described in RFC2119 [1].
-
-2. The Secure Entry Point (SEP) Flag
-
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | flags |S| protocol | algorithm |
- | |E| | |
- | |P| | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
- / public key /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- DNSKEY RR Format
-
-
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 4]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- This document assigns the 15'th bit in the flags field as the secure
- entry point (SEP) bit. If the the bit is set to 1 the key is
- intended to be used as secure entry point key. One SHOULD NOT assign
- special meaning to the key if the bit is set to 0. Operators can
- recognize the secure entry point key by the even or odd-ness of the
- decimal representation of the flag field.
-
-3. DNSSEC Protocol Changes
-
- The bit MUST NOT be used during the resolving and verification
- process. The SEP flag is only used to provide a hint about the
- different administrative properties of the key and therefore the use
- of the SEP flag does not change the DNS resolution protocol or the
- resolution process.
-
-4. Operational Guidelines
-
- The SEP bit is set by the key-pair-generator and MAY be used by the
- zone signer to decide whether the public part of the key pair is to
- be prepared for input to a DS RR generation function. The SEP bit is
- recommended to be set (to 1) whenever the public key of the key pair
- will be distributed to the parent zone to build the authentication
- chain or if the public key is to be distributed for static
- configuration in verifiers.
-
- When a key pair is created, the operator needs to indicate whether
- the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within
- the data that is used to compute the 'key tag field' in the SIG RR,
- changing the SEP bit will change the identity of the key within DNS.
- In other words, once a key is used to generate signatures, the
- setting of the SEP bit is to remain constant. If not, a verifier will
- not be able to find the relevant KEY RR.
-
- When signing a zone, it is intended that the key(s) with the SEP bit
- set (if such keys exist) are used to sign the KEY RR set of the zone.
- The same key can be used to sign the rest of the zone data too. It
- is conceivable that not all keys with a SEP bit set will sign the
- DNSKEY RR set, such keys might be pending retirement or not yet in
- use.
-
- When verifying a RR set, the SEP bit is not intended to play a role.
- How the key is used by the verifier is not intended to be a
- consideration at key creation time.
-
- Although the SEP flag provides a hint on which public key is to be
- used as trusted root, administrators can choose to ignore the fact
- that a DNSKEY has its SEP bit set or not when configuring a trusted
- root for their resolvers.
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 5]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- Using the SEP flag a key roll over can be automated. The parent can
- use an existing trust relation to verify DNSKEY RR sets in which a
- new DNSKEY RR with the SEP flag appears.
-
-5. Security Considerations
-
- As stated in Section 3 the flag is not to be used in the resolution
- protocol or to determine the security status of a key. The flag is to
- be used for administrative purposes only.
-
- No trust in a key should be inferred from this flag - trust MUST be
- inferred from an existing chain of trust or an out-of-band exchange.
-
- Since this flag might be used for automating public key exchanges, we
- think the following consideration is in place.
-
- Automated mechanisms for roll over of the DS RR might be vulnerable
- to a class of replay attacks. This might happen after a public key
- exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
- SEP flag set, is sent to the parent. The parent verifies the DNSKEY
- RR set with the existing trust relation and creates the new DS RR
- from the DNSKEY RR that the current DS RR is not pointing to. This
- key exchange might be replayed. Parents are encouraged to implement a
- replay defense. A simple defense can be based on a registry of keys
- that have been used to generate DS RRs during the most recent roll
- over. These same considerations apply to entities that configure keys
- in resolvers.
-
-6. IANA Considerations
-
- The flag bits in the DNSKEY RR are assigned by IETF consensus and
- registered in the DNSKEY Flags registry (created by [4]). This
- document assigns the 15th bit in the DNSKEY RR as the Secure Entry
- Point (SEP) bit.
-
-7. Internationalization Considerations
-
- Although SEP is a popular acronym in many different languages, there
- are no internationalization considerations.
-
-8. Acknowledgments
-
- The ideas documented in this document are inspired by communications
- we had with numerous people and ideas published by other folk. Among
- others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
- Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
- have contributed ideas and provided feedback.
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 6]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- This document saw the light during a workshop on DNSSEC operations
- hosted by USC/ISI in August 2002.
-
-Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [3] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [4] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
- in progress), October 2003.
-
-Informative References
-
- [5] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-15 (work in progress), June
- 2003.
-
- [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
- Story", ISBN 0151002177 (50th anniversary edition), April 1996.
-
-
-Authors' Addresses
-
- Olaf M. Kolkman
- RIPE NCC
- Singel 256
- Amsterdam 1016 AB
- NL
-
- Phone: +31 20 535 4444
- EMail: olaf@ripe.net
- URI: http://www.ripe.net/
-
-
- Jakob Schlyter
- Karl Gustavsgatan 15
- Goteborg SE-411 25
- Sweden
-
- EMail: jakob@schlyter.se
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 7]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- Edward P. Lewis
- ARIN
- 3635 Concorde Parkway Suite 200
- Chantilly, VA 20151
- US
-
- Phone: +1 703 227 9854
- EMail: edlewis@arin.net
- URI: http://www.arin.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 8]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 9]
-
-Internet-Draft DNSKEY RR Secure Entry Point Flag December 2003
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires June 17, 2004 [Page 10]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-mdns-43.txt b/doc/draft/draft-ietf-dnsext-mdns-43.txt
deleted file mode 100644
index 5de6e85ecf65..000000000000
--- a/doc/draft/draft-ietf-dnsext-mdns-43.txt
+++ /dev/null
@@ -1,1740 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group Bernard Aboba
-INTERNET-DRAFT Dave Thaler
-Category: Standards Track Levon Esibov
-<draft-ietf-dnsext-mdns-43.txt> Microsoft Corporation
-29 August 2005
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on March 15, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society 2005.
-
-Abstract
-
- The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable
- name resolution in scenarios in which conventional DNS name
- resolution is not possible. LLMNR supports all current and future
- DNS formats, types and classes, while operating on a separate port
- from DNS, and with a distinct resolver cache. Since LLMNR only
- operates on the local link, it cannot be considered a substitute for
- DNS.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name Resolution Using LLMNR ........................... 4
- 2.1 LLMNR Packet Format ............................. 6
- 2.2 Sender Behavior ................................. 9
- 2.3 Responder Behavior .............................. 10
- 2.4 Unicast Queries and Responses ................... 12
- 2.5 Off-link Detection .............................. 13
- 2.6 Responder Responsibilities ...................... 13
- 2.7 Retransmission and Jitter ....................... 14
- 2.8 DNS TTL ......................................... 15
- 2.9 Use of the Authority and Additional Sections .... 15
-3. Usage model ........................................... 16
- 3.1 LLMNR Configuration ............................. 17
-4. Conflict Resolution ................................... 18
- 4.1 Uniqueness Verification ......................... 19
- 4.2 Conflict Detection and Defense .................. 20
- 4.3 Considerations for Multiple Interfaces .......... 21
- 4.4 API issues ...................................... 22
-5. Security Considerations ............................... 22
- 5.1 Denial of Service ............................... 23
- 5.2 Spoofing ...............,........................ 23
- 5.3 Authentication .................................. 24
- 5.4 Cache and Port Separation ....................... 25
-6. IANA considerations ................................... 25
-7. Constants ............................................. 25
-8. References ............................................ 25
- 8.1 Normative References ............................ 25
- 8.2 Informative References .......................... 26
-Acknowledgments .............................................. 27
-Authors' Addresses ........................................... 28
-Intellectual Property Statement .............................. 28
-Disclaimer of Validity ....................................... 29
-Copyright Statement .......................................... 29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-1. Introduction
-
- This document discusses Link Local Multicast Name Resolution (LLMNR),
- which is based on the DNS packet format and supports all current and
- future DNS formats, types and classes. LLMNR operates on a separate
- port from the Domain Name System (DNS), with a distinct resolver
- cache.
-
- The goal of LLMNR is to enable name resolution in scenarios in which
- conventional DNS name resolution is not possible. Usage scenarios
- (discussed in more detail in Section 3.1) include situations in which
- hosts are not configured with the address of a DNS server; where the
- DNS server is unavailable or unreachable; where there is no DNS
- server authoritative for the name of a host, or where the
- authoritative DNS server does not have the desired RRs, as described
- in Section 2.
-
- Since LLMNR only operates on the local link, it cannot be considered
- a substitute for DNS. Link-scope multicast addresses are used to
- prevent propagation of LLMNR traffic across routers, potentially
- flooding the network. LLMNR queries can also be sent to a unicast
- address, as described in Section 2.4.
-
- Propagation of LLMNR packets on the local link is considered
- sufficient to enable name resolution in small networks. In such
- networks, if a network has a gateway, then typically the network is
- able to provide DNS server configuration. Configuration issues are
- discussed in Section 3.1.
-
- In the future, it may be desirable to consider use of multicast name
- resolution with multicast scopes beyond the link-scope. This could
- occur if LLMNR deployment is successful, the need arises for
- multicast name resolution beyond the link-scope, or multicast routing
- becomes ubiquitous. For example, expanded support for multicast name
- resolution might be required for mobile ad-hoc networks.
-
- Once we have experience in LLMNR deployment in terms of
- administrative issues, usability and impact on the network, it will
- be possible to reevaluate which multicast scopes are appropriate for
- use with multicast name resolution. IPv4 administratively scoped
- multicast usage is specified in "Administratively Scoped IP
- Multicast" [RFC2365].
-
- Service discovery in general, as well as discovery of DNS servers
- using LLMNR in particular, is outside of the scope of this document,
- as is name resolution over non-multicast capable media.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-1.1. Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
- and "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-1.2. Terminology
-
- This document assumes familiarity with DNS terminology defined in
- [RFC1035]. Other terminology used in this document includes:
-
-Positively Resolved
- Responses with RCODE set to zero are referred to in this document
- as "positively resolved".
-
-Routable Address
- An address other than a Link-Local address. This includes globally
- routable addresses, as well as private addresses.
-
-Reachable
- An LLMNR responder considers one of its addresses reachable over a
- link if it will respond to an ARP or Neighbor Discovery query for
- that address received on that link.
-
-Responder
- A host that listens to LLMNR queries, and responds to those for
- which it is authoritative.
-
-Sender
- A host that sends an LLMNR query.
-
-UNIQUE
- There are some scenarios when multiple responders may respond to
- the same query. There are other scenarios when only one responder
- may respond to a query. Names for which only a single responder is
- anticipated are referred to as UNIQUE. Name uniqueness is
- configured on the responder, and therefore uniqueness verification
- is the responder's responsibility.
-
-2. Name Resolution Using LLMNR
-
- LLMNR is a peer-to-peer name resolution protocol that is not intended
- as a replacement for DNS. LLMNR queries are sent to and received on
- port 5355. The IPv4 link-scope multicast address a given responder
- listens to, and to which a sender sends queries, is 224.0.0.252. The
- IPv6 link-scope multicast address a given responder listens to, and
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- to which a sender sends all queries, is FF02:0:0:0:0:0:1:3.
-
- Typically a host is configured as both an LLMNR sender and a
- responder. A host MAY be configured as a sender, but not a
- responder. However, a host configured as a responder MUST act as a
- sender, if only to verify the uniqueness of names as described in
- Section 4. This document does not specify how names are chosen or
- configured. This may occur via any mechanism, including DHCPv4
- [RFC2131] or DHCPv6 [RFC3315].
-
- LLMNR usage MAY be configured manually or automatically on a per
- interface basis. By default, LLMNR responders SHOULD be enabled on
- all interfaces, at all times. Enabling LLMNR for use in situations
- where a DNS server has been configured will result in a change in
- default behavior without a simultaneous update to configuration
- information. Where this is considered undesirable, LLMNR SHOULD NOT
- be enabled by default, so that hosts will neither listen on the link-
- scope multicast address, nor will they send queries to that address.
-
- By default, LLMNR queries MAY be sent only when one of the following
- conditions are met:
-
- [1] No manual or automatic DNS configuration has been performed.
- If DNS server address(es) have been configured, then LLMNR
- SHOULD NOT be used as the primary name resolution mechanism,
- although it MAY be used as a secondary name resolution
- mechanism. A dual stack host SHOULD attempt to reach DNS
- servers overall protocols on which DNS server address(es) are
- configured, prior to sending LLMNR queries. For dual stack
- hosts configured with DNS server address(es) for one protocol
- but not another, this inplies that DNS queries SHOULD be sent
- over the protocol configured with a DNS server, prior to
- sending LLMNR queries.
-
- [2] All attempts to resolve the name via DNS on all interfaces
- have failed after exhausting the searchlist. This can occur
- because DNS servers did not respond, or because they
- responded to DNS queries with RCODE=3 (Authoritative Name
- Error) or RCODE=0, and an empty answer section. Where a
- single resolver call generates DNS queries for A and AAAA RRs,
- an implementation MAY choose not to send LLMNR queries if any
- of the DNS queries is successful. An LLMNR query SHOULD only
- be sent for the originally requested name; a searchlist
- is not used to form additional LLMNR queries.
-
- While these conditions are necessary for sending an LLMNR query, they
- are not sufficient. While an LLMNR sender MAY send a query for any
- name, it also MAY impose additional conditions on sending LLMNR
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- queries. For example, a sender configured with a DNS server MAY send
- LLMNR queries only for unqualified names and for fully qualified
- domain names within configured zones.
-
- A typical sequence of events for LLMNR usage is as follows:
-
- [a] DNS servers are not configured or attempts to resolve the
- name via DNS have failed, after exhausting the searchlist.
- Also, the name to be queried satisfies the restrictions
- imposed by the implementation.
-
- [b] An LLMNR sender sends an LLMNR query to the link-scope
- multicast address(es), unless a unicast query is indicated,
- as specified in Section 2.4.
-
- [c] A responder responds to this query only if it is authoritative
- for the domain name in the query. A responder responds to a
- multicast query by sending a unicast UDP response to the sender.
- Unicast queries are responded to as indicated in Section 2.4.
-
- [d] Upon reception of the response, the sender processes it.
-
- The sections that follow provide further details on sender and
- responder behavior.
-
-2.1. LLMNR Packet Format
-
- LLMNR is based on the DNS packet format defined in [RFC1035] Section
- 4 for both queries and responses. LLMNR implementations SHOULD send
- UDP queries and responses only as large as are known to be
- permissible without causing fragmentation. When in doubt a maximum
- packet size of 512 octets SHOULD be used. LLMNR implementations MUST
- accept UDP queries and responses as large as the smaller of the link
- MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
- octets for the header, VLAN tag and CRC).
-
-2.1.1. LLMNR Header Format
-
- LLMNR queries and responses utilize the DNS header format defined in
- [RFC1035] with exceptions noted below:
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode | C|TC| T| Z| Z| Z| Z| RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- where:
-
-ID A 16 bit identifier assigned by the program that generates any kind
- of query. This identifier is copied from the query to the response
- and can be used by the sender to match responses to outstanding
- queries. The ID field in a query SHOULD be set to a pseudo-random
- value. For advice on generation of pseudo-random values, please
- consult [RFC1750].
-
-QR Query/Response. A one bit field, which if set indicates that the
- message is an LLMNR response; if clear then the message is an LLMNR
- query.
-
-OPCODE
- A four bit field that specifies the kind of query in this message.
- This value is set by the originator of a query and copied into the
- response. This specification defines the behavior of standard
- queries and responses (opcode value of zero). Future
- specifications may define the use of other opcodes with LLMNR.
- LLMNR senders and responders MUST support standard queries (opcode
- value of zero). LLMNR queries with unsupported OPCODE values MUST
- be silently discarded by responders.
-
-C Conflict. When set within a request, the 'C'onflict bit indicates
- that a sender has received multiple LLMNR responses to this query.
- In an LLMNR response, if the name is considered UNIQUE, then the
- 'C' bit is clear, otherwise it is set. LLMNR senders do not
- retransmit queries with the 'C' bit set. Responders MUST NOT
- respond to LLMNR queries with the 'C' bit set, but may start the
- uniqueness verification process, as described in Section 4.2.
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-TC TrunCation - specifies that this message was truncated due to
- length greater than that permitted on the transmission channel.
- The TC bit MUST NOT be set in an LLMNR query and if set is ignored
- by an LLMNR responder. If the TC bit is set in an LLMNR response,
- then the sender SHOULD discard the response and resend the LLMNR
- query over TCP using the unicast address of the responder as the
- destination address. See [RFC2181] and Section 2.4 of this
- specification for further discussion of the TC bit.
-
-T Tentative. The 'T'entative bit is set in a response if the
- responder is authoritative for the name, but has not yet verified
- the uniqueness of the name. A responder MUST ignore the 'T' bit in
- a query, if set. A response with the 'T' bit set is silently
- discarded by the sender, except if it is a uniqueness query, in
- which case a conflict has been detected and a responder MUST
- resolve the conflict as described in Section 4.1.
-
-Z Reserved for future use. Implementations of this specification
- MUST set these bits to zero in both queries and responses. If
- these bits are set in a LLMNR query or response, implementations of
- this specification MUST ignore them. Since reserved bits could
- conceivably be used for different purposes than in DNS,
- implementors are advised not to enable processing of these bits in
- an LLMNR implementation starting from a DNS code base.
-
-RCODE
- Response code -- this 4 bit field is set as part of LLMNR
- responses. In an LLMNR query, the sender MUST set RCODE to zero;
- the responder ignores the RCODE and assumes it to be zero. The
- response to a multicast LLMNR query MUST have RCODE set to zero. A
- sender MUST silently discard an LLMNR response with a non-zero
- RCODE sent in response to a multicast query.
-
- If an LLMNR responder is authoritative for the name in a multicast
- query, but an error is encountered, the responder SHOULD send an
- LLMNR response with an RCODE of zero, no RRs in the answer section,
- and the TC bit set. This will cause the query to be resent using
- TCP, and allow the inclusion of a non-zero RCODE in the response to
- the TCP query. Responding with the TC bit set is preferable to not
- sending a response, since it enables errors to be diagnosed.
- Errors include those defined in [RFC2845], such as BADSIG(16),
- BADKEY(17) and BADTIME(18).
-
- Since LLMNR responders only respond to LLMNR queries for names for
- which they are authoritative, LLMNR responders MUST NOT respond
- with an RCODE of 3; instead, they should not respond at all.
-
- LLMNR implementations MUST support EDNS0 [RFC2671] and extended
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- RCODE values.
-
-QDCOUNT
- An unsigned 16 bit integer specifying the number of entries in the
- question section. A sender MUST place only one question into the
- question section of an LLMNR query. LLMNR responders MUST silently
- discard LLMNR queries with QDCOUNT not equal to one. LLMNR senders
- MUST silently discard LLMNR responses with QDCOUNT not equal to
- one.
-
-ANCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the answer section. LLMNR responders MUST silently
- discard LLMNR queries with ANCOUNT not equal to zero.
-
-NSCOUNT
- An unsigned 16 bit integer specifying the number of name server
- resource records in the authority records section. Authority
- record section processing is described in Section 2.9. LLMNR
- responders MUST silently discard LLMNR queries with NSCOUNT not
- equal to zero.
-
-ARCOUNT
- An unsigned 16 bit integer specifying the number of resource
- records in the additional records section. Additional record
- section processing is described in Section 2.9.
-
-2.2. Sender Behavior
-
- A sender MAY send an LLMNR query for any legal resource record type
- (e.g., A, AAAA, PTR, SRV, etc.) to the link-scope multicast address.
- As described in Section 2.4, a sender MAY also send a unicast query.
-
- The sender MUST anticipate receiving no replies to some LLMNR
- queries, in the event that no responders are available within the
- link-scope. If no response is received, a resolver treats it as a
- response that the name does not exist (RCODE=3 is returned). A
- sender can handle duplicate responses by discarding responses with a
- source IP address and ID field that duplicate a response already
- received.
-
- When multiple valid LLMNR responses are received with the 'C' bit
- set, they SHOULD be concatenated and treated in the same manner that
- multiple RRs received from the same DNS server would be. However,
- responses with the 'C' bit set SHOULD NOT be concatenated with
- responses with the 'C' bit clear; instead, only the responses with
- the 'C' bit set SHOULD be returned. If valid LLMNR response(s) are
- received along with error response(s), then the error responses are
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- silently discarded.
-
- If error responses are received from both DNS and LLMNR, then the
- lowest RCODE value should be returned. For example, if either DNS or
- LLMNR receives a response with RCODE=0, then this should returned to
- the caller.
-
- Since the responder may order the RRs in the response so as to
- indicate preference, the sender SHOULD preserve ordering in the
- response to the querying application.
-
-2.3. Responder Behavior
-
- An LLMNR response MUST be sent to the sender via unicast.
-
- Upon configuring an IP address, responders typically will synthesize
- corresponding A, AAAA and PTR RRs so as to be able to respond to
- LLMNR queries for these RRs. An SOA RR is synthesized only when a
- responder has another RR in addition to the SOA RR; the SOA RR MUST
- NOT be the only RR that a responder has. However, in general whether
- RRs are manually or automatically created is an implementation
- decision.
-
- For example, a host configured to have computer name "host1" and to
- be a member of the "example.com" domain, and with IPv4 address
- 192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
- authoritative for the following records:
-
- host1. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- host1.example.com. IN A 192.0.2.1
- IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
- 1.2.0.192.in-addr.arpa. IN PTR host1.
- IN PTR host1.example.com.
-
- 6.0.5.0.4.0.E.F.F.F.3.0.2.0.1.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.
- ip6.arpa IN PTR host1. (line split for formatting reasons)
- IN PTR host1.example.com.
-
- An LLMNR responder might be further manually configured with the name
- of a local mail server with an MX RR included in the "host1." and
- "host1.example.com." records.
-
- In responding to queries:
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[a] Responders MUST listen on UDP port 5355 on the link-scope multicast
- address(es) defined in Section 2, and on UDP and TCP port 5355 on
- the unicast address(es) that could be set as the source address(es)
- when the responder responds to the LLMNR query.
-
-[b] Responders MUST direct responses to the port from which the query
- was sent. When queries are received via TCP this is an inherent
- part of the transport protocol. For queries received by UDP the
- responder MUST take note of the source port and use that as the
- destination port in the response. Responses MUST always be sent
- from the port to which they were directed.
-
-[c] Responders MUST respond to LLMNR queries for names and addresses
- they are authoritative for. This applies to both forward and
- reverse lookups, with the exception of queries with the 'C' bit
- set, which do not elicit a response.
-
-[d] Responders MUST NOT respond to LLMNR queries for names they are not
- authoritative for.
-
-[e] Responders MUST NOT respond using data from the LLMNR or DNS
- resolver cache.
-
-[f] If a DNS server is running on a host that supports LLMNR, the DNS
- server MUST respond to LLMNR queries only for the RRSets relating
- to the host on which the server is running, but MUST NOT respond
- for other records for which the server is authoritative. DNS
- servers also MUST NOT send LLMNR queries in order to resolve DNS
- queries.
-
-[g] If a responder is authoritative for a name, it MUST respond with
- RCODE=0 and an empty answer section, if the type of query does not
- match a RR that the responder has.
-
- As an example, a host configured to respond to LLMNR queries for the
- name "foo.example.com." is authoritative for the name
- "foo.example.com.". On receiving an LLMNR query for an A RR with the
- name "foo.example.com." the host authoritatively responds with A
- RR(s) that contain IP address(es) in the RDATA of the resource
- record. If the responder has a AAAA RR, but no A RR, and an A RR
- query is received, the responder would respond with RCODE=0 and an
- empty answer section.
-
- In conventional DNS terminology a DNS server authoritative for a zone
- is authoritative for all the domain names under the zone apex except
- for the branches delegated into separate zones. Contrary to
- conventional DNS terminology, an LLMNR responder is authoritative
- only for the zone apex.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- For example the host "foo.example.com." is not authoritative for the
- name "child.foo.example.com." unless the host is configured with
- multiple names, including "foo.example.com." and
- "child.foo.example.com.". As a result, "foo.example.com." cannot
- reply to an LLMNR query for "child.foo.example.com." with RCODE=3
- (authoritative name error). The purpose of limiting the name
- authority scope of a responder is to prevent complications that could
- be caused by coexistence of two or more hosts with the names
- representing child and parent (or grandparent) nodes in the DNS tree,
- for example, "foo.example.com." and "child.foo.example.com.".
-
- Without the restriction on authority an LLMNR query for an A resource
- record for the name "child.foo.example.com." would result in two
- authoritative responses: RCODE=3 (authoritative name error) received
- from "foo.example.com.", and a requested A record - from
- "child.foo.example.com.". To prevent this ambiguity, LLMNR enabled
- hosts could perform a dynamic update of the parent (or grandparent)
- zone with a delegation to a child zone; for example a host
- "child.foo.example.com." could send a dynamic update for the NS and
- glue A record to "foo.example.com.". However, this approach
- significantly complicates implementation of LLMNR and would not be
- acceptable for lightweight hosts.
-
-2.4. Unicast Queries and Responses
-
- Unicast queries SHOULD be sent when:
-
- [a] A sender repeats a query after it received a response
- with the TC bit set to the previous LLMNR multicast query, or
-
- [b] The sender queries for a PTR RR of a fully formed IP address
- within the "in-addr.arpa" or "ip6.arpa" zones.
-
- Unicast LLMNR queries MUST be done using TCP and the responses MUST
- be sent using the same TCP connection as the query. Senders MUST
- support sending TCP queries, and responders MUST support listening
- for TCP queries. If the sender of a TCP query receives a response to
- that query not using TCP, the response MUST be silently discarded.
-
- Unicast UDP queries MUST be silently discarded.
-
- If TCP connection setup cannot be completed in order to send a
- unicast TCP query, this is treated as a response that no records of
- the specified type and class exist for the specified name (it is
- treated the same as a response with RCODE=0 and an empty answer
- section).
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-2.5. "Off link" Detection
-
- A sender MUST select a source address for LLMNR queries that is
- assigned on the interface on which the query is sent. The
- destination address of an LLMNR query MUST be a link-scope multicast
- address or a unicast address.
-
- A responder MUST select a source address for responses that is
- assigned on the interface on which the query was received. The
- destination address of an LLMNR response MUST be a unicast address.
-
- On receiving an LLMNR query, the responder MUST check whether it was
- sent to a LLMNR multicast addresses defined in Section 2. If it was
- sent to another multicast address, then the query MUST be silently
- discarded.
-
- Section 2.4 discusses use of TCP for LLMNR queries and responses. In
- composing an LLMNR query using TCP, the sender MUST set the Hop Limit
- field in the IPv6 header and the TTL field in the IPv4 header of the
- response to one (1). The responder SHOULD set the TTL or Hop Limit
- settings on the TCP listen socket to one (1) so that SYN-ACK packets
- will have TTL (IPv4) or Hop Limit (IPv6) set to one (1). This
- prevents an incoming connection from off-link since the sender will
- not receive a SYN-ACK from the responder.
-
- For UDP queries and responses, the Hop Limit field in the IPv6 header
- and the TTL field in the IPV4 header MAY be set to any value.
- However, it is RECOMMENDED that the value 255 be used for
- compatibility with Apple Bonjour [Bonjour].
-
- Implementation note:
-
- In the sockets API for IPv4 [POSIX], the IP_TTL and
- IP_MULTICAST_TTL socket options are used to set the TTL of
- outgoing unicast and multicast packets. The IP_RECVTTL socket
- option is available on some platforms to retrieve the IPv4 TTL of
- received packets with recvmsg(). [RFC2292] specifies similar
- options for setting and retrieving the IPv6 Hop Limit.
-
-2.6. Responder Responsibilities
-
- It is the responsibility of the responder to ensure that RRs returned
- in LLMNR responses MUST only include values that are valid on the
- local interface, such as IPv4 or IPv6 addresses valid on the local
- link or names defended using the mechanism described in Section 4.
- IPv4 Link-Local addresses are defined in [RFC3927]. IPv6 Link-Local
- addresses are defined in [RFC2373]. In particular:
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- [a] If a link-scope IPv6 address is returned in a AAAA RR,
- that address MUST be valid on the local link over which
- LLMNR is used.
-
- [b] If an IPv4 address is returned, it MUST be reachable
- through the link over which LLMNR is used.
-
- [c] If a name is returned (for example in a CNAME, MX
- or SRV RR), the name MUST be resolvable on the local
- link over which LLMNR is used.
-
- Where multiple addresses represent valid responses to a query, the
- order in which the addresses are returned is as follows:
-
- [d] If the source address of the query is a link-scope address,
- then the responder SHOULD include a link-scope address first
- in the response, if available.
-
- [e] If the source address of the query is a routable address,
- then the responder MUST include a routable address first
- in the response, if available.
-
-2.7. Retransmission and Jitter
-
- An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
- when to retransmit an LLMNR query. An LLMNR sender SHOULD either
- estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
- high initial timeout. Suggested constants are described in Section
- 7.
-
- If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
- then a sender SHOULD repeat the transmission of the query in order to
- assure that it was received by a host capable of responding to it,
- while increasing the value of LLMNR_TIMEOUT exponentially. An LLMNR
- query SHOULD NOT be sent more than three times.
-
- Where LLMNR queries are sent using TCP, retransmission is handled by
- the transport layer. Queries with the 'C' bit set MUST be sent using
- multicast UDP and MUST NOT be retransmitted.
-
- An LLMNR sender cannot know in advance if a query sent using
- multicast will receive no response, one response, or more than one
- response. An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
- has been received, or if it is necessary to collect all potential
- responses, such as if a uniqueness verification query is being made.
- Otherwise an LLMNR sender SHOULD consider a multicast query answered
- after the first response is received, if that response has the 'C'
- bit clear.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- However, if the first response has the 'C' bit set, then the sender
- SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
- responses. When multiple valid answers are received, they may first
- be concatenated, and then treated in the same manner that multiple
- RRs received from the same DNS server would. A unicast query sender
- considers the query answered after the first response is received, so
- that it only waits for LLMNR_TIMEOUT if no response has been
- received.
-
- Since it is possible for a response with the 'C' bit clear to be
- followed by a response with the 'C' bit set, an LLMNR sender SHOULD
- be prepared to process additional responses for the purposes of
- conflict detection and LLMNR_TIMEOUT estimation, even after it has
- considered a query answered.
-
- In order to avoid synchronization, the transmission of each LLMNR
- query and response SHOULD delayed by a time randomly selected from
- the interval 0 to JITTER_INTERVAL. This delay MAY be avoided by
- responders responding with names which they have previously
- determined to be UNIQUE (see Section 4 for details).
-
-2.8. DNS TTL
-
- The responder should insert a pre-configured TTL value in the records
- returned in an LLMNR response. A default value of 30 seconds is
- RECOMMENDED. In highly dynamic environments (such as mobile ad-hoc
- networks), the TTL value may need to be reduced.
-
- Due to the TTL minimalization necessary when caching an RRset, all
- TTLs in an RRset MUST be set to the same value.
-
-2.9. Use of the Authority and Additional Sections
-
- Unlike the DNS, LLMNR is a peer-to-peer protocol and does not have a
- concept of delegation. In LLMNR, the NS resource record type may be
- stored and queried for like any other type, but it has no special
- delegation semantics as it does in the DNS. Responders MAY have NS
- records associated with the names for which they are authoritative,
- but they SHOULD NOT include these NS records in the authority
- sections of responses.
-
- Responders SHOULD insert an SOA record into the authority section of
- a negative response, to facilitate negative caching as specified in
- [RFC2308]. The TTL of this record is set from the minimum of the
- MINIMUM field of the SOA record and the TTL of the SOA itself, and
- indicates how long a resolver may cache the negative answer. The
- owner name of the SOA record (MNAME) MUST be set to the query name.
- The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- by senders. Negative responses without SOA records SHOULD NOT be
- cached.
-
- In LLMNR, the additional section is primarily intended for use by
- EDNS0, TSIG and SIG(0). As a result, unless the 'C' bit is set,
- senders MAY only include pseudo RR-types in the additional section of
- a query; unless the 'C' bit is set, responders MUST ignore the
- additional section of queries containing other RR types.
-
- In queries where the 'C' bit is set, the sender SHOULD include the
- conflicting RRs in the additional section. Since conflict
- notifications are advisory, responders SHOULD log information from
- the additional section, but otherwise MUST ignore the additional
- section.
-
- Senders MUST NOT cache RRs from the authority or additional section
- of a response as answers, though they may be used for other purposes
- such as negative caching.
-
-3. Usage Model
-
- Since LLMNR is a secondary name resolution mechanism, its usage is in
- part determined by the behavior of DNS implementations. This
- document does not specify any changes to DNS resolver behavior, such
- as searchlist processing or retransmission/failover policy. However,
- robust DNS resolver implementations are more likely to avoid
- unnecessary LLMNR queries.
-
- As noted in [DNSPerf], even when DNS servers are configured, a
- significant fraction of DNS queries do not receive a response, or
- result in negative responses due to missing inverse mappings or NS
- records that point to nonexistent or inappropriate hosts. This has
- the potential to result in a large number of unnecessary LLMNR
- queries.
-
- [RFC1536] describes common DNS implementation errors and fixes. If
- the proposed fixes are implemented, unnecessary LLMNR queries will be
- reduced substantially, and so implementation of [RFC1536] is
- recommended.
-
- For example, [RFC1536] Section 1 describes issues with retransmission
- and recommends implementation of a retransmission policy based on
- round trip estimates, with exponential backoff. [RFC1536] Section 4
- describes issues with failover, and recommends that resolvers try
- another server when they don't receive a response to a query. These
- policies are likely to avoid unnecessary LLMNR queries.
-
- [RFC1536] Section 3 describes zero answer bugs, which if addressed
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- will also reduce unnecessary LLMNR queries.
-
- [RFC1536] Section 6 describes name error bugs and recommended
- searchlist processing that will reduce unnecessary RCODE=3
- (authoritative name) errors, thereby also reducing unnecessary LLMNR
- queries.
-
-3.1. LLMNR Configuration
-
- Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
- possible for a dual stack host to be configured with the address of a
- DNS server over IPv4, while remaining unconfigured with a DNS server
- suitable for use over IPv6.
-
- In these situations, a dual stack host will send AAAA queries to the
- configured DNS server over IPv4. However, an IPv6-only host
- unconfigured with a DNS server suitable for use over IPv6 will be
- unable to resolve names using DNS. Automatic IPv6 DNS configuration
- mechanisms (such as [RFC3315] and [DNSDisc]) are not yet widely
- deployed, and not all DNS servers support IPv6. Therefore lack of
- IPv6 DNS configuration may be a common problem in the short term, and
- LLMNR may prove useful in enabling link-local name resolution over
- IPv6.
-
- Where a DHCPv4 server is available but not a DHCPv6 server [RFC3315],
- IPv6-only hosts may not be configured with a DNS server. Where there
- is no DNS server authoritative for the name of a host or the
- authoritative DNS server does not support dynamic client update over
- IPv6 or DHCPv6-based dynamic update, then an IPv6-only host will not
- be able to do DNS dynamic update, and other hosts will not be able to
- resolve its name.
-
- For example, if the configured DNS server responds to a AAAA RR query
- sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
- RCODE=0 and an empty answer section, then a AAAA RR query sent using
- LLMNR over IPv6 may be successful in resolving the name of an
- IPv6-only host on the local link.
-
- Similarly, if a DHCPv4 server is available providing DNS server
- configuration, and DNS server(s) exist which are authoritative for
- the A RRs of local hosts and support either dynamic client update
- over IPv4 or DHCPv4-based dynamic update, then the names of local
- IPv4 hosts can be resolved over IPv4 without LLMNR. However, if no
- DNS server is authoritative for the names of local hosts, or the
- authoritative DNS server(s) do not support dynamic update, then LLMNR
- enables linklocal name resolution over IPv4.
-
- Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- configure LLMNR on an interface. The LLMNR Enable Option, described
- in [LLMNREnable], can be used to explicitly enable or disable use of
- LLMNR on an interface. The LLMNR Enable Option does not determine
- whether or in which order DNS itself is used for name resolution.
- The order in which various name resolution mechanisms should be used
- can be specified using the Name Service Search Option (NSSO) for DHCP
- [RFC2937], using the LLMNR Enable Option code carried in the NSSO
- data.
-
- It is possible that DNS configuration mechanisms will go in and out
- of service. In these circumstances, it is possible for hosts within
- an administrative domain to be inconsistent in their DNS
- configuration.
-
- For example, where DHCP is used for configuring DNS servers, one or
- more DHCP servers can fail. As a result, hosts configured prior to
- the outage will be configured with a DNS server, while hosts
- configured after the outage will not. Alternatively, it is possible
- for the DNS configuration mechanism to continue functioning while
- configured DNS servers fail.
-
- An outage in the DNS configuration mechanism may result in hosts
- continuing to use LLMNR even once the outage is repaired. Since
- LLMNR only enables linklocal name resolution, this represents a
- degradation in capabilities. As a result, hosts without a configured
- DNS server may wish to periodically attempt to obtain DNS
- configuration if permitted by the configuration mechanism in use. In
- the absence of other guidance, a default retry interval of one (1)
- minute is RECOMMENDED.
-
-4. Conflict Resolution
-
- By default, a responder SHOULD be configured to behave as though its
- name is UNIQUE on each interface on which LLMNR is enabled. However,
- it is also possible to configure multiple responders to be
- authoritative for the same name. For example, multiple responders
- MAY respond to a query for an A or AAAA type record for a cluster
- name (assigned to multiple hosts in the cluster).
-
- To detect duplicate use of a name, an administrator can use a name
- resolution utility which employs LLMNR and lists both responses and
- responders. This would allow an administrator to diagnose behavior
- and potentially to intervene and reconfigure LLMNR responders who
- should not be configured to respond to the same name.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-4.1. Uniqueness Verification
-
- Prior to sending an LLMNR response with the 'T' bit clear, a
- responder configured with a UNIQUE name MUST verify that there is no
- other host within the scope of LLMNR query propagation that is
- authoritative for the same name on that interface.
-
- Once a responder has verified that its name is UNIQUE, if it receives
- an LLMNR query for that name, with the 'C' bit clear, it MUST
- respond, with the 'T' bit clear. Prior to verifying that its name is
- UNIQUE, a responder MUST set the 'T' bit in responses.
-
- Uniqueness verification is carried out when the host:
-
- - starts up or is rebooted
- - wakes from sleep (if the network interface was inactive
- during sleep)
- - is configured to respond to LLMNR queries on an interface
- enabled for transmission and reception of IP traffic
- - is configured to respond to LLMNR queries using additional
- UNIQUE resource records
- - verifies the acquisition of a new IP address and configuration
- on an interface
-
- To verify uniqueness, a responder MUST send an LLMNR query with the
- 'C' bit clear, over all protocols on which it responds to LLMNR
- queries (IPv4 and/or IPv6). It is RECOMMENDED that responders verify
- uniqueness of a name by sending a query for the name with type='ANY'.
-
- If no response is received, the sender retransmits the query, as
- specified in Section 2.7. If a response is received, the sender MUST
- check if the source address matches the address of any of its
- interfaces; if so, then the response is not considered a conflict,
- since it originates from the sender. To avoid triggering conflict
- detection, a responder that detects that it is connected to the same
- link on multiple interfaces SHOULD set the 'C' bit in responses.
-
- If a response is received with the 'T' bit clear, the responder MUST
- NOT use the name in response to LLMNR queries received over any
- protocol (IPv4 or IPv6). If a response is received with the 'T' bit
- set, the responder MUST check if the source IP address in the
- response, interpreted as an unsigned integer, is less than the source
- IP address in the query. If so, the responder MUST NOT use the name
- in response to LLMNR queries received over any protocol (IPv4 or
- IPv6). For the purpose of uniqueness verification, the contents of
- the answer section in a response is irrelevant.
-
- Periodically carrying out uniqueness verification in an attempt to
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- detect name conflicts is not necessary, wastes network bandwidth, and
- may actually be detrimental. For example, if network links are
- joined only briefly, and are separated again before any new
- communication is initiated, temporary conflicts are benign and no
- forced reconfiguration is required. LLMNR responders SHOULD NOT
- periodically attempt uniqueness verification.
-
-4.2. Conflict Detection and Defense
-
- Hosts on disjoint network links may configure the same name for use
- with LLMNR. If these separate network links are later joined or
- bridged together, then there may be multiple hosts which are now on
- the same link, trying to use the same name.
-
- In order to enable ongoing detection of name conflicts, when an LLMNR
- sender receives multiple LLMNR responses to a query, it MUST check if
- the 'C' bit is clear in any of the responses. If so, the sender
- SHOULD send another query for the same name, type and class, this
- time with the 'C' bit set, with the potentially conflicting resource
- records included in the additional section.
-
- Queries with the 'C' bit set are considered advisory and responders
- MUST verify the existence of a conflict before acting on it. A
- responder receiving a query with the 'C' bit set MUST NOT respond.
-
- If the query is for a UNIQUE name, then the responder MUST send its
- own query for the same name, type and class, with the 'C' bit clear.
- If a response is received, the sender MUST check if the source
- address matches the address of any of its interfaces; if so, then the
- response is not considered a conflict, since it originates from the
- sender. To avoid triggering conflict detection, a responder that
- detects that it is connected to the same link on multiple interfaces
- SHOULD set the 'C' bit in responses.
-
- An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
- log them. Upon detecting a conflict, an LLMNR responder MUST
- immediately stop using the conflicting name in response to LLMNR
- queries received over any supported protocol, if the source IP
- address in the response, interpreted as an unsigned integer, is less
- than the source IP address in the uniqueness verification query.
-
- After stopping the use of a name, the responder MAY elect to
- configure a new name. However, since name reconfiguration may be
- disruptive, this is not required, and a responder may have been
- configured to respond to multiple names so that alternative names may
- already be available. A host that has stopped the use of a name may
- attempt uniqueness verification again after the expiration of the TTL
- of the conflicting response.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-4.3. Considerations for Multiple Interfaces
-
- A multi-homed host may elect to configure LLMNR on only one of its
- active interfaces. In many situations this will be adequate.
- However, should a host need to configure LLMNR on more than one of
- its active interfaces, there are some additional precautions it MUST
- take. Implementers who are not planning to support LLMNR on multiple
- interfaces simultaneously may skip this section.
-
- Where a host is configured to issue LLMNR queries on more than one
- interface, each interface maintains its own independent LLMNR
- resolver cache, containing the responses to LLMNR queries.
-
- A multi-homed host checks the uniqueness of UNIQUE records as
- described in Section 4. The situation is illustrated in figure 1.
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
- In this situation, the multi-homed myhost will probe for, and defend,
- its host name on both interfaces. A conflict will be detected on one
- interface, but not the other. The multi-homed myhost will not be
- able to respond with a host RR for "myhost" on the interface on the
- right (see Figure 1). The multi-homed host may, however, be
- configured to use the "myhost" name on the interface on the left.
-
- Since names are only unique per-link, hosts on different links could
- be using the same name. If an LLMNR client sends requests over
- multiple interfaces, and receives replies from more than one, the
- result returned to the client is defined by the implementation. The
- situation is illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
- If host myhost is configured to use LLMNR on both interfaces, it will
- send LLMNR queries on both interfaces. When host myhost sends a
- query for the host RR for name "A" it will receive a response from
- hosts on both interfaces.
-
- Host myhost cannot distinguish between the situation shown in Figure
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 21]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- 2, and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
- This illustrates that the proposed name conflict resolution mechanism
- does not support detection or resolution of conflicts between hosts
- on different links. This problem can also occur with DNS when a
- multi-homed host is connected to two different networks with
- separated name spaces. It is not the intent of this document to
- address the issue of uniqueness of names within DNS.
-
-4.4. API Issues
-
- [RFC2553] provides an API which can partially solve the name
- ambiguity problem for applications written to use this API, since the
- sockaddr_in6 structure exposes the scope within which each scoped
- address exists, and this structure can be used for both IPv4 (using
- v4-mapped IPv6 addresses) and IPv6 addresses.
-
- Following the example in Figure 2, an application on 'myhost' issues
- the request getaddrinfo("A", ...) with ai_family=AF_INET6 and
- ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
- interfaces and the resolver library will return a list containing
- multiple addrinfo structures, each with an associated sockaddr_in6
- structure. This list will thus contain the IPv4 and IPv6 addresses
- of both hosts responding to the name 'A'. Link-local addresses will
- have a sin6_scope_id value that disambiguates which interface is used
- to reach the address. Of course, to the application, Figures 2 and 3
- are still indistinguishable, but this API allows the application to
- communicate successfully with any address in the list.
-
-5. Security Considerations
-
- LLMNR is a peer-to-peer name resolution protocol designed for use on
- the local link. While LLMNR limits the vulnerability of responders
- to off-link senders, it is possible for an off-link responder to
- reach a sender.
-
- In scenarios such as public "hotspots" attackers can be present on
- the same link. These threats are most serious in wireless networks
- such as 802.11, since attackers on a wired network will require
- physical access to the network, while wireless attackers may mount
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 22]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- attacks from a distance. Link-layer security such as [IEEE-802.11i]
- can be of assistance against these threats if it is available.
-
- This section details security measures available to mitigate threats
- from on and off-link attackers.
-
-5.1. Denial of Service
-
- Attackers may take advantage of LLMNR conflict detection by
- allocating the same name, denying service to other LLMNR responders
- and possibly allowing an attacker to receive packets destined for
- other hosts. By logging conflicts, LLMNR responders can provide
- forensic evidence of these attacks.
-
- An attacker may spoof LLMNR queries from a victim's address in order
- to mount a denial of service attack. Responders setting the IPv6 Hop
- Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
- response may be able to reach the victim across the Internet.
-
- While LLMNR responders only respond to queries for which they are
- authoritative and LLMNR does not provide wildcard query support, an
- LLMNR response may be larger than the query, and an attacker can
- generate multiple responses to a query for a name used by multiple
- responders. A sender may protect itself against unsolicited
- responses by silently discarding them as rapidly as possible.
-
-5.2. Spoofing
-
- LLMNR is designed to prevent reception of queries sent by an off-link
- attacker. LLMNR requires that responders receiving UDP queries check
- that they are sent to a link-scope multicast address. However, it is
- possible that some routers may not properly implement link-scope
- multicast, or that link-scope multicast addresses may leak into the
- multicast routing system. To prevent successful setup of TCP
- connections by an off-link sender, responders receiving a TCP SYN
- reply with a TCP SYN-ACK with TTL set to one (1).
-
- While it is difficult for an off-link attacker to send an LLMNR query
- to a responder, it is possible for an off-link attacker to spoof a
- response to a query (such as an A or AAAA query for a popular
- Internet host), and by using a TTL or Hop Limit field larger than one
- (1), for the forged response to reach the LLMNR sender. Since the
- forged response will only be accepted if it contains a matching ID
- field, choosing a pseudo-random ID field within queries provides some
- protection against off-link responders.
-
- Since LLMNR queries can be sent when DNS server(s) do not respond, an
- attacker can execute a denial of service attack on the DNS server(s)
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 23]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- and then poison the LLMNR cache by responding to an LLMNR query with
- incorrect information. As noted in "Threat Analysis of the Domain
- Name System (DNS)" [RFC3833] these threats also exist with DNS, since
- DNS response spoofing tools are available that can allow an attacker
- to respond to a query more quickly than a distant DNS server.
- However, while switched networks or link layer security may make it
- difficult for an on-link attacker to snoop unicast DNS queries,
- multicast LLMNR queries are propagated to all hosts on the link,
- making it possible for an on-link attacker to spoof LLMNR responses
- without having to guess the value of the ID field in the query.
-
- Since LLMNR queries are sent and responded to on the local-link, an
- attacker will need to respond more quickly to provide its own
- response prior to arrival of the response from a legitimate
- responder. If an LLMNR query is sent for an off-link host, spoofing
- a response in a timely way is not difficult, since a legitimate
- response will never be received.
-
- Limiting the situations in which LLMNR queries are sent, as described
- in Section 2, is the best protection against these attacks. If LLMNR
- is given higher priority than DNS among the enabled name resolution
- mechanisms, a denial of service attack on the DNS server would not be
- necessary in order to poison the LLMNR cache, since LLMNR queries
- would be sent even when the DNS server is available. In addition,
- the LLMNR cache, once poisoned, would take precedence over the DNS
- cache, eliminating the benefits of cache separation. As a result,
- LLMNR is only used as a name resolution mechanism of last resort.
-
-5.3. Authentication
-
- LLMNR is a peer-to-peer name resolution protocol, and as a result,
- it is often deployed in situations where no trust model can be
- assumed. This makes it difficult to apply existing DNS security
- mechanisms to LLMNR.
-
- LLMNR does not support "delegated trust" (CD or AD bits). As a
- result, unless LLMNR senders are DNSSEC aware, it is not feasible to
- use DNSSEC [RFC4033] with LLMNR.
-
- If authentication is desired, and a pre-arranged security
- configuration is possible, then the following security mechanisms may
- be used:
-
-[a] LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
- [RFC2931] security mechanisms. "DNS Name Service based on Secure
- Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
- the use of TSIG to secure LLMNR responses, based on group keys.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 24]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[b] IPsec ESP with a null-transform MAY be used to authenticate unicast
- LLMNR queries and responses or LLMNR responses to multicast
- queries. In a small network without a certificate authority, this
- can be most easily accomplished through configuration of a group
- pre-shared key for trusted hosts.
-
- Where these mechanisms cannot be supported, responses to LLMNR
- queries may be unauthenticated.
-
-5.4. Cache and Port Separation
-
- In order to prevent responses to LLMNR queries from polluting the DNS
- cache, LLMNR implementations MUST use a distinct, isolated cache for
- LLMNR on each interface. The use of separate caches is most
- effective when LLMNR is used as a name resolution mechanism of last
- resort, since this minimizes the opportunities for poisoning the
- LLMNR cache, and decreases reliance on it.
-
- LLMNR operates on a separate port from DNS, reducing the likelihood
- that a DNS server will unintentionally respond to an LLMNR query.
-
-6. IANA Considerations
-
- This specification creates one new name space: the reserved bits in
- the LLMNR header. These are allocated by IETF Consensus, in
- accordance with BCP 26 [RFC2434].
-
- LLMNR requires allocation of port 5355 for both TCP and UDP.
-
- LLMNR requires allocation of link-scope multicast IPv4 address
- 224.0.0.252, as well as link-scope multicast IPv6 address
- FF02:0:0:0:0:0:1:3.
-
-7. Constants
-
- The following timing constants are used in this protocol; they are
- not intended to be user configurable.
-
- JITTER_INTERVAL 100 ms
- LLMNR_TIMEOUT 1 second (if set statically on all interfaces)
- 100 ms (IEEE 802 media, including IEEE 802.11)
-
-8. References
-
-8.1. Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 25]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
- RFC 2308, March 1998.
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
-[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
-[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
-8.2. Informative References
-
-[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
- (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
- June 2005.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness of
- Caching", IEEE/ACM Transactions on Networking, Volume 10,
- Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- Internet draft (work in progress), draft-ietf-ipv6-dns-
- discovery-07.txt, October 2002.
-
-[IEEE-802.11i]
- Institute of Electrical and Electronics Engineers, "Supplement
- to Standard for Telecommunications and Information Exchange
- Between Systems - LAN/MAN Specific Requirements - Part 11:
- Wireless LAN Medium Access Control (MAC) and Physical Layer
- (PHY) Specifications: Specification for Enhanced Security",
- IEEE 802.11i, July 2004.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 26]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-[LLMNREnable]
- Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
- in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
- Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
- Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
- 2004, Phoenix Park, Korea, February 9-11, 2004.
-
-[POSIX] IEEE Std. 1003.1-2001 Standard for Information Technology --
- Portable Operating System Interface (POSIX). Open Group
- Technical Standard: Base Specifications, Issue 6, December
- 2001. ISO/IEC 9945:2002. http://www.opengroup.org/austin
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
- Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
- Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
- RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
- 2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
- Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[RFC3315] Droms, R., et al., "Dynamic Host Configuration Protocol for
- IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
- System (DNS)", RFC 3833, August 2004.
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
- of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirement", RFC 4033, March
- 2005.
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 27]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
-Acknowledgments
-
- This work builds upon original work done on multicast DNS by Bill
- Manning and Bill Woodcock. Bill Manning's work was funded under
- DARPA grant #F30602-99-1-0523. The authors gratefully acknowledge
- their contribution to the current specification. Constructive input
- has also been received from Mark Andrews, Rob Austein, Randy Bush,
- Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
- Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
- Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
- Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
- St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 706 6605
- EMail: bernarda@microsoft.com
-
- Dave Thaler
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 703 8835
- EMail: dthaler@microsoft.com
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 28]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 29 August 2005
-
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-Open Issues
-
- Open issues with this specification are tracked on the following web
- site:
-
- http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov Standards Track [Page 29]
-
-
diff --git a/doc/draft/draft-ietf-dnsext-nsec3-04.txt b/doc/draft/draft-ietf-dnsext-nsec3-04.txt
deleted file mode 100644
index 8c6c5b1ba080..000000000000
--- a/doc/draft/draft-ietf-dnsext-nsec3-04.txt
+++ /dev/null
@@ -1,2352 +0,0 @@
-
-
-
-Network Working Group B. Laurie
-Internet-Draft G. Sisson
-Expires: August 5, 2006 R. Arends
- Nominet
- February 2006
-
-
- DNSSEC Hash Authenticated Denial of Existence
- draft-ietf-dnsext-nsec3-04
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 5, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- The DNS Security Extensions introduces the NSEC resource record for
- authenticated denial of existence. This document introduces a new
- resource record as an alternative to NSEC that provides measures
- against zone enumeration and allows for gradual expansion of
- delegation-centric zones.
-
-
-
-
-
-Laurie, et al. Expires August 5, 2006 [Page 1]
-
-Internet-Draft nsec3 February 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. NSEC versus NSEC3 . . . . . . . . . . . . . . . . . . . . . . 5
- 3. The NSEC3 Resource Record . . . . . . . . . . . . . . . . . . 5
- 3.1. NSEC3 RDATA Wire Format . . . . . . . . . . . . . . . . . 6
- 3.1.1. The Hash Function Field . . . . . . . . . . . . . . . 6
- 3.1.2. The Opt-In Flag Field . . . . . . . . . . . . . . . . 7
- 3.1.3. The Iterations Field . . . . . . . . . . . . . . . . . 8
- 3.1.4. The Salt Length Field . . . . . . . . . . . . . . . . 8
- 3.1.5. The Salt Field . . . . . . . . . . . . . . . . . . . . 8
- 3.1.6. The Next Hashed Ownername Field . . . . . . . . . . . 9
- 3.1.7. The Type Bit Maps Field . . . . . . . . . . . . . . . 9
- 3.2. The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
- 4. Creating Additional NSEC3 RRs for Empty Non-Terminals . . . . 11
- 5. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 11
- 6. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 11
- 7. Responding to NSEC3 Queries . . . . . . . . . . . . . . . . . 12
- 8. Special Considerations . . . . . . . . . . . . . . . . . . . . 13
- 8.1. Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
- 8.2. Salting . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 8.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
- 8.4. Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
- 8.4.1. Avoiding Hash Collisions during generation . . . . . . 16
- 8.4.2. Second Preimage Requirement Analysis . . . . . . . . . 16
- 8.4.3. Possible Hash Value Truncation Method . . . . . . . . 17
- 8.4.4. Server Response to a Run-time Collision . . . . . . . 17
- 8.4.5. Parameters that Cover the Zone . . . . . . . . . . . . 18
- 9. Performance Considerations . . . . . . . . . . . . . . . . . . 18
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
- 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18
- 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
- 12.2. Informative References . . . . . . . . . . . . . . . . . . 22
- Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
- Appendix A. Example Zone . . . . . . . . . . . . . . . . . . . . 22
- Appendix B. Examp