diff --git a/doc/draft/draft-ietf-dnsext-aaaa-a6-00.txt b/doc/draft/draft-ietf-dnsext-aaaa-a6-00.txt new file mode 100644 index 0000000000..ac62b2d2b3 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-aaaa-a6-00.txt @@ -0,0 +1,709 @@ + +Internet Engineering Task Force Jun-ichiro itojun Hagino +INTERNET-DRAFT IIJ Research Laboratory +Expires: November 27, 2001 May 27, 2001 + + + Comparison of AAAA and A6 (do we really need A6?) + draft-ietf-dnsext-aaaa-a6-00.txt + +Status of this Memo + + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other groups +may also distribute working documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of six months +and may be updated, replaced, or obsoleted by other documents at any +time. It is inappropriate to use Internet-Drafts as reference material +or to cite them other than as ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/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. + +The internet-draft will expire in 6 months. The date of expiration will +be November 27, 2001. + + +Abstract + +At this moment, there are two resource record types defined for holding +IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6 [Crawford, +2000] . AAAA has been used for IPv6 network operation since 1996. +Questions arose whether we really need A6 or not, or whether it is +really possible to migrate to A6 or not. Some says AAAA is enough and +A6 is not necessary. Some says A6 is necessary and AAAA should get +deprecated. + +The draft tries to understand pros and cons between these two record +types, and makes suggestions on deployment of IPv6 record type. + +The draft does not cover the use of bit string label and DNAME resource +record (reverse mapping), as it seems that nibble form is well accepted +in the community, newer formats have too much deployment costs, thus we +see few need/voice that calls for migration. Refer to IETF50 dnsext +working group minutes for more details. + + + + +HAGINO Expires: November 27, 2001 [Page 1] + + +DRAFT Comparison of AAAA and A6 May 2001 + +1. A brief summary of the IPv6 resource record types + +1.1. AAAA record + +AAAA resource record is formatted as follows. DNS record type value for +AAAA is 28 (assigned by IANA). Note that AAAA record is formatted as a +fixed-length data. + + +------------+ + |IPv6 Address| + | (16 octets)| + +------------+ + +With AAAA, we can define DNS records for IPv6 address resolution as +follows, just like A records for IPv4. + + $ORIGIN X.EXAMPLE. + N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 + N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 + N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 + + +1.2. A6 record + +A6 resource record is formatted as follows. DNS record type value for +A6 is 38 (assigned by IANA). Note that A6 record is formatted as a +variable-length data. + + +-----------+------------------+-------------------+ + |Prefix len.| Address suffix | Prefix name | + | (1 octet) | (0..16 octets) | (0..255 octets) | + +-----------+------------------+-------------------+ + +With A6, it is possible to define an IPv6 address by using multiple DNS +records. Here is an example taken from RFC2874: + + + + + + + + + + + + + + + + + + + +HAGINO Expires: November 27, 2001 [Page 2] + + +DRAFT Comparison of AAAA and A6 May 2001 + + $ORIGIN X.EXAMPLE. + N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 + SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 + IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. + IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. + + SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. + SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. + + SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. + + A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. + + A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. + + B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. + + C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: + D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: + E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: + +If we translate the above into AAAA records, it will be as follows: + + $ORIGIN X.EXAMPLE. + N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 + N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 + N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 + +It is also possible to use A6 records in ``non-fragmented'' manner, like +below. + + $ORIGIN X.EXAMPLE. + N A6 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 + N A6 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 + N A6 0 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 + +There is a large design difference between A6 and AAAA. A6 imposes +address resolutions tasks more to the resolver side, to reduce the +amount of zone file maintenance cost. The complexity is in the resolver +side. AAAA asks zone file maintainers to supply the full 128bit IPv6 +address in one record, and the resolver side can be implemented very +simple. + + +2. Deployment status + +2.1. Name servers/resolvers + +As of writing, AAAA is deployed pretty widely. BIND4 (since 4.9.4), +BIND8, BIND9 and other implementations support AAAA, as both DNS servers +and as resolver libraries. On the contrary, the author knows of only +one DNS server/resolver implementation that supports A6; BIND9. + + +HAGINO Expires: November 27, 2001 [Page 3] + + +DRAFT Comparison of AAAA and A6 May 2001 + +Almost all of the IPv6-ready operating systems ship with BIND4 or BIND8 +resolver library. Even for the implementations that use resolver +library other than BIND, they only support AAAA. Therefore, they cannot +query A6 records (unless aplications gets linked with BIND9 libraries +explicitly). + +2.2. IPv6 network + +IPv6 network has been deployed widely since 1996. Though many of the +participants consider it to be experimental, commercial IPv6 services +has been deployed since around 1999, especially in asian countries. + +2.3. DNS database + +There are no IPv6-reachable root DNS servers, partly because we have +both AAAA and A6, and we are not decided about which is the one we would +like to really deploy (so we cannot put IPv6 root NS records). The lack +of IPv6-reachable root DNS servers is now preventing IPv6-only or +IPv4/v6 dual stack network operations. + +At this moment, very small number of ccTLD registries accept +registeration requests for IPv6 glue records. Many of the ccTLDs and +gTLDs do not take IPv6 glue records, partly because of the lack of +consensus between AAAA and A6. Again, the lack of IPv6 glue records is +causing pain in IPv6-ready network operations. For example, JP ccTLD +accepts IPv6 glue records and registers them as AAAA records. IPv6 NS +records (with AAAA) works flawlessly from our experiences. For example, +try the following commands to see how JP ccTLD registers IPv6 glue +records (``/e'' is for English-language output): + + % whois -h whois.nic.ad.jp wide.ad.jp/e + % whois -h whois.nic.ad.jp ns1.v6.wide.ad.jp/e + + +3. Deploying DNS records + +At this moment, the following four strategies are proposed for the +deployment of IPv6 DNS resource record; AAAA, fragmented A6 records, +non-fragmented A6 records, and AAAA synthesis. + +3.1. AAAA records + +AAAA records have been used on IPv6 network (also known as 6bone) since +it has started in 1996 and has been working just fine ever since. AAAA +record is a straight extension of A records; it needs a single query- +response roundtrip to resolve a name into an IPv6 address. + +A6 was proposed to add network renumbering friendliness to AAAA. With +AAAA, a full 128bit IPv6 address needs to be supplied in a DNS resource +record. Therefore, in the event of network renumber, administrators +need to update the whole DNS zone file with the new IPv6 address +prefixes. We will discuss the issues with renumbering in a dedicated + + +HAGINO Expires: November 27, 2001 [Page 4] + + +DRAFT Comparison of AAAA and A6 May 2001 + +section. + +3.2. Fragmented A6 records + +If we are to use fragmented A6s (128bit splitted into multiple A6s), we +have a lot of issues/worries. + +If we are to resolve IPv6 addresses using fragmented A6 records, we need +to query DNS multiple times to resolve a single DNS name into an IPv6 +address. Since there has been no DNS record types that require multiple +queries for resolution of the address itself, we have very little +experience on such resource records. + +There will be more delays in name resolution compared to queries to +A/AAAA records. If we define a record with more number of fragments, +there will be more query roundtrips. There are only few possibilities +to query fragments in parallel. In the above example, we can resolve +A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others. + +If the DNS record TTL is smaller than the communication delays between +the querier and the DNS servers, the querier will not be able to +reassemble a complete IPv6 record. With the following records, you +cannot reassemble an IPv6 address if the delay is larger than 1 second. +By the time you get the topmost 64 bits in the address, the lowermost 64 +bits get invalidated. If the querier tries to query lowermost 64 bits +again, the querier can go into an infinite loop (see the section on +security considration). [BIND 9.2.0snap: resolver does not go into +infinite loop, meaning that BIND 9.2.0snap resolver does not really +honor DNS record TTL during A6 reassembly] + + ; resolver can go into an infinite loop if RTT > 1 second + $ORIGIN X.EXAMPLE. + $TTL 1 + N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 + SUBNET-1.IP6 A6 0 2345:00C1:CA11:1:: + +Some says that caches will avoid querying fragmented A6s again and +again. However, most of the library resolver implementations do not +cache anything. The traffic between library resolver and the first-hop +nameserver will not be decreased by the cached records. The TTL problem +(see above) is unavoidable for the library resolver without cache. [XXX +will they interpret TTL field? BIND8 resolver does not] + +If some of the fragments are DNSSEC-signed and some are not, how should +we treat that address? RFC2874 section 6 briefly talks about it, not +sure if complete answer is given. + +It is much harder to implement A6 fragment reassemble code, than to +implement AAAA record resolver. AAAA record resolver can be implemented +as a straight extension of A record resolver. + + + + +HAGINO Expires: November 27, 2001 [Page 5] + + +DRAFT Comparison of AAAA and A6 May 2001 + +o It is much harder to design timeout handling for the A6 reassembly. + There would be multiple timeout parameters, including (1) communcation + timeout for a single A6 fragment, (2) communcation timeout for the + IPv6 address itself (total time needed for reassembly) and (3) TTL + timeout for A6 fragment records. + +o In the case of library resolver implementation, it is harder to deal + with exceptions (signals in UNIX case) for the large code fragment for + resolvers. + +o When A6 prefix length field is not multiple of 8, address suffix + portion needs to be shifted bitwise while A6 fragments are + reassembled. Also, resolver implementations must be careful about + overwraps of the bits. From our implementatation experiences, the + logic gets very complex and we (unfortunately) expect to see a lot of + security-critical bugs in the future. + +In RFC2874, a suggestion is made to use limited number of fragments per +an IPv6 address. However, there is no protocol limitation defined. The +lack makes it easier for malicious parties to impose DoS attacks using +lots of A6 fragments (see the section on security consideration). [BIND +9.2.0snap: The implementation limits the number of fragments to be +smaller than 16; It is not a protocol limitation but an implementation +choice. Not sure if it is the right choice or not] + +With fragmented A6 records, in multi-prefix network configuration, it is +not possible for us to limit the address on the DNS database to the +specific set of records, like for load distribution purposes. Consider +the following example. Even if we would like to advertise only +2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible +to do so. It becomes mandatory for us to define the whole IPv6 address +by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6 +(renumber friendliness) goes away. + + ; with the following record we would advertise both records + $ORIGIN X.EXAMPLE. + N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 + M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6 + SUBNET-1.IP6 A6 0 2345:00C1:CA11:1:: + A6 0 2345:00D2:DA11:1:: + + ; we need to do the following, jeopardizing renumbering + ; friendliness for N.X.EXAMPLE + $ORIGIN X.EXAMPLE. + N A6 0 2345:00C1:CA11:1:1234:5678:9ABC:DEF0 + M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6 + SUBNET-1.IP6 A6 0 2345:00C1:CA11:1:: + A6 0 2345:00D2:DA11:1:: + +A6 resource record type and A6 fragment/reassembly were introduced to +help administrators on network renumber. When network gets renumbered, +the administrator needs to update A6 fragment for the higher address + + +HAGINO Expires: November 27, 2001 [Page 6] + + +DRAFT Comparison of AAAA and A6 May 2001 + +bits (prefixes) only. Again, we will discuss the issues with +renumbering in a dedicated section. + + +3.3. Non-fragmented A6 records + +There are proposals to use non-fragmented A6 records in most of the +places, like ``A6 0 <128bit>'', so that we would be able to switch to +fragmented A6 records when we find a need for A6. + +>From the packet format point of view, the approach has no benefit +against AAAA. Rather, there is a one-byte overhead to every +(unfragmented) A6 record compared to an AAAA record. + +If the nameserver/resolver programs hardcode A6 processing to handle no +fragments, there will be no future possibility for us to introduce +fragmented A6 records. When there is no need for A6 reassembly, there +will be no code deployment, and even if the reassembly code gets +deployed they will not be tested enough. The author believes that the +``prepare for the future, use non-fragmented A6'' argument is not +worthwhile. + +In the event of renumbering, non-fragmented A6 record has the same +property as AAAA (the whole zone file has to be updated). + +3.4. AAAA synthesis (A6 and AAAA hybrid approach) + +At this moment, end hosts support AAAA records only. Some people would +like to see A6 deployment in DNS databases even with the lack of end +hosts support. To workaround the deployment issues of A6, the following +approach is proposed in IETF50 dnsext working group slot. It is called +``AAAA synthesis'': + +o Deploy A6 DNS records worldwide. The proposal was not specific about + whether we would deploy fragmented A6 records, or non-fragmented A6 + records (``A6 0''). + +o When a host queries AAAA record to a DNS server, the DNS server + queries A6 fragments, reassemble it, and respond with an AAAA record. + +The approach needs to be diagnosed/specified in far more detail. For +example, the following questions need to be answered: + +o What is the DNS error code against AAAA querier, if the A6 reassembly + fails? + +o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap + uses TTL=0] + +o Which nameserver should synthesize the AAAA record, in the DNS + recursize query chain? Is the synthesis mandatory for every DNS + server implementation? + + +HAGINO Expires: November 27, 2001 [Page 7] + + +DRAFT Comparison of AAAA and A6 May 2001 + +o What should we do if the A6 reassembly takes too much time? + +o What should we do about DNSSEC signatures? + +o What if the resolver wants no synthesis? Do we want to have a flag + bit in DNS packet, to enable/disable AAAA synthesis? + +o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query + timeouts, and other timeout parameters? + +The approach seems to be vulnerable against DoS attacks, because the +nameserver reassembles A6 fragments on behalf of the AAAA querier. See +security consideration section for more details. + +3.5. Issues in keeping both AAAA and A6 + +If we are to keep both AAAA and A6 records onto the worldwide DNS +database, it would impose more query delays to the client resolvers. +Suppose we have a dual-stack host implementation. If they need to +resolve a name into addresses, the node would need to query in the +following order (in the order which RFC2874 suggests): + +o Query A6 records, and get full IPv6 addresses by chasing and + reassembling A6 fragment chain. + +o Query AAAA records. + +o Query A records. + +o Sort the result based on destination address ordering rule. An + example of the ordering rule is presented as a draft [Draves, 2000] . + +o Contact the destination addresses in sequence. + +The ordering imposes additional delays to the resolvers. The above +ordering would be necessary for all approaches that use A6, as there are +existing AAAA records in the world. + + +4. Network renumbering + +Some says that there will be more frequent renumbers in IPv6 network +operation, and A6 is necessary to reduce the zone modification cost as +well as zone signing costs on renumber operation. + +It is not clear if we really want to renumber that frequently. With +IPv6, it should be easier for ISPs to assign addresses statically to the +downstream customers, rather than dynamically like we do in IPv4 dialup +connectivity today. If ISPs do assign static IPv6 address block to the +customers, there is no need to renumber customer network that frequently +(unless the customer decides to switch the upstream ISPs that often). +NOTE: Roaming dialup users, like those who carry laptop computers + + +HAGINO Expires: November 27, 2001 [Page 8] + + +DRAFT Comparison of AAAA and A6 May 2001 + +worldwide, seems to have a different issue from stationary dialup users. +See [Hagino, 2000] for more discussions. + +It is questionable if it is possible to renumber IPv6 networks more +frequently than with IPv4. Router renumbering protocol [Crawford, 2000] +, IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998] +can help us renumber the IPv6 network, however, network renumbering +itself is not an easy task. If you would like to maintain reachability +from the outside world, a site administrator needs to carefully +coordinate site renumber. The minimal interval between renumber is +restricted by DNS record timeouts, as DNS records will be cached around +the world. If the TTL of DNS records are X, the interval between +renumber must be longer than 2 * X. If we consider clients/servers that +tries to validate addresses using reverse lookups, we also need to care +about the relationship between IPv6 address lifetime [Thomson, 1998] and +the interval between renumber. At IETF50 ipngwg session, there was a +presentation by JINMEI Tatsuya regarding to site renumbering experiment. +It is recommend to read through the IETF49 minutes and slides. [XXX +Fred Baker had a draft on this - where?] For the network renumbering to +be successful, no configuration files should have hardcoded (numeric) IP +addresses. It is a very hard requrement to meet. We fail to satisfy +this in many of the network renumbering events, and the failure causes a +lot of troubles. + +At this moment there is no mechanism defined for ISPs to renumber +downstream customers at will. Router renumbering protocol [Crawford, +2000] is defined only for a single administrative domain (customers will +not want to share IPsec authentication key for routers, with the +upstream ISP). Even though it may sound interesting for ISPs, it would +cause a lot of (social and political) issues in doing so, so the author +would say it is rather unrealistic to pursue this route. + +A6 was designed to help administators update zone files during network +renumbering events. Even with AAAA, zone file modification itself is +easy; you can just query-replace the addresses in the zone files. The +difficulty of network renumber comes from elsewhere. + +With AAAA, we need to sign the whole zone again with DNSSEC keys, after +renumbering the network. With A6, we need to sign upper bits only with +DNSSEC keys. Therefore, A6 will impose less zone signing cost on the +event of network renumbering. As seen above, it is questionable if we +renumber network that often, so it is questionable if A6 brings us an +overall benefit. + + +5. Security consideration + +There are a couple of security worries mentioned in the above. To give +a brief summary: + +o There will be a higher delay imposed by query/reply roundtrips for + fragmented A6 records. This could affect every services that relies + + +HAGINO Expires: November 27, 2001 [Page 9] + + +DRAFT Comparison of AAAA and A6 May 2001 + + upon DNS records. + +o There is no upper limit defined for the number of A6 fragments for + defining an IPv6 address. Malicious parties may try to put a very + complex A6 chains and confuse nameservers worldwide. + +o A6 resolver/nameserver is much harder to implement correctly than AAAA + resolver/nameserver. A6 fragment reassembly code needs to take care + of bitwise data reassembly, bitwise overwrap checks, and others. From + our implementatation experiences, we expect to see a lot of security- + issue bugs in the future. + +o Interaction between DNS record TTL and the DNS query delays leads to + non-trivial timeout problem. + +We would like to go into more details for some of these. + +5.1. DoS attacks against AAAA synthesis + +When a DNS server is configured for AAAA synthesis, malicious parties +can impose DoS attacks using the interaction between DNS TTL and query +delays. The attack can chew CPU time and/or memory, as well as some +network bandwidth on a victim nameserver, by the following steps: + +o Bad guy configures a record with very complex A6 chain, onto some + nameservers. (bad guy has to have controls over the servers). The + nameservers can be located anywhere in the world. The A6 chain should + have a very low TTL (like 1 or 0 seconds). The attack works better if + we have higher delays between the victim nameservers and the + nameservers that serve A6 fragments. + +o Bad guy queries the record using AAAA request, to the victim + nameserver. + +o The victim nameserver will try to reassemble A6 fragments. During the + reassembly process, the victim nameserver puts A6 fragments into the + local cache. The cached records will expire during the reassembly + process. The nameserver will need to query a lot of A6 fragments + (more traffic). The server can go into an infinite loop, if it tries + to query the expired A6 fragments again. + +To remedy this problem, we have a couple of solutions: + +(1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the + problem goes away. + +(2) Even if we use A6, do not configure nameservers for AAAA synthesis. + Deployment issues with existing IPv6 hosts get much harder. + +(3) Impose a protocol limitation to the number of A6 fragments. + + + + +HAGINO Expires: November 27, 2001 [Page 10] + + +DRAFT Comparison of AAAA and A6 May 2001 + +(4) Do not query the expired records in A6 chain again. In other words, + implement resolvers that ignore TTL on DNS records. Not sure if it + is the right thing to do. + + +6. Conclusion + +NOTE: the section expresses the impressions of the author. + +A6/AAAA discussion has been an obstacle for IPv6 deployment, as the +deployment of IPv6 NS recodrs have been deferred because of the +discussion. The author do not see benefit in keeping both AAAA and A6 +records, as it imposes more query delays to the clients. So the author +believes that we need to pick one of them. + +Given the unlikeliness of frequent network renumbering, the author +believes that the A6's benefit in lower zone signing cost is not +significant. The benefit of A6 (in zone signing cost) is much less than +the expected complication that will be imposed by A6 operations. + +>From the above discussions, the author suggests to keep AAAA and +deprecate A6. The author believes that A6 can cause a lot of problem +than the benefits it may have. A6 will make IPv6 DNS operation more +complicated and vulnerable to attacks. AAAA is proven to work right in +our IPv6 network operation since 1996. AAAA has been working just fine +in existing IPv6 networks, and the author believes that it will in the +coming days. + + + +References + +Thomson, 1995. +S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in +RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt. + +Crawford, 2000. +M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6 +Address Aggregation and Renumbering" in RFC2874 (July 2000). +ftp://ftp.isi.edu/in-notes/rfc2874.txt. + +Draves, 2000. +Richard Draves, "Default Address Selection for IPv6," Internet Draft +(November 2000). work in progress material. + +Hagino, 2000. +Jun-ichiro Hagino and Kazu Yamamoto, "Requirements for IPv6 dialup PPP +operation" in draft-itojun-ipv6-dialup-requirement-00.txt (July 2000). +work in progress material. + +Crawford, 2000. +Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000). + + +HAGINO Expires: November 27, 2001 [Page 11] + + +DRAFT Comparison of AAAA and A6 May 2001 + +ftp://ftp.isi.edu/in-notes/rfc2894.txt. + +Thomson, 1998. +S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in +RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt. + + +Change history + +none. + + +Acknowledgements + +The draft was written based on discussions in IETF IPv6 and dnsext +working groups, and help from WIDE research group. + + +Author's address + + Jun-ichiro itojun HAGINO + Research Laboratory, Internet Initiative Japan Inc. + Takebashi Yasuda Bldg., + 3-13 Kanda Nishiki-cho, + Chiyoda-ku,Tokyo 101-0054, JAPAN + Tel: +81-3-5259-6350 + Fax: +81-3-5259-6351 + Email: itojun@iijlab.net + + + + + + + + + + + + + + + + + + + + + + + + + + +HAGINO Expires: November 27, 2001 [Page 12] + diff --git a/doc/draft/draft-ietf-dnsext-delegation-signer-00.txt b/doc/draft/draft-ietf-dnsext-delegation-signer-00.txt new file mode 100644 index 0000000000..ca51f4368e --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-delegation-signer-00.txt @@ -0,0 +1,557 @@ + DNSEXT Working Group Olafur Gudmundsson + INTERNET-DRAFT May 2001 + + + Updates: RFC 1035, RFC 2535, RFC 3008. + + + Delegation Signer record in parent. + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering Task + Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Comments should be sent to the authors or the DNSEXT WG mailing list + namedroppers@ops.ietf.org + + This draft expires on November 30, 2001. + + Copyright Notice + + Copyright (C) The Internet Society (2001). All rights reserved. + + + +Abstract + + One of the biggest problems in DNS occur when records of the same type + can appear on both sides of an delegation. If the contents of these + sets differs clients can get confused. RFC2535 KEY records follows + the same model as for NS records, parent is responsible for the + records but the child is responsible for the contents. This document + + + +Gudmundsson Expires November 2001 [Page 1] + +INTERNET-DRAFT Delegation Signer Record May 2001 + + + proposes to store a different record in the parent that specifies + which one of the child's keys can sign the child's KEY set. This + change is not backwards compatible with RFC2535 but simplifies DNSSEC + operation. + + +1 - Introduction + + Familiarity with the DNS system [RFC1035], DNS security extensions + [RFC2535] and DNSSEC terminology [RFC3090] is important. + + When the same data can reside in two administratively different DNS + zones sources it is common that the data gets out of sync. NS record + in a zone indicates that there is a delegation at this name and the NS + record lists the authorative servers for the real zone. Based on + actual measurements 10-30% of all delegations in the Internet have + differing NS sets at parent and child. There are number of reasons for + this including lack of communication between parent and child, and + bogus nameservers are listed to meet registrar requirements. + + DNSSEC [RFC2535,RFC3008,RFC3090] specifies that child must have its + KEY set signed by the parent to create a verifiable chain of KEYs. + There is some debate, where the signed KEY set should reside, + parent[Parent] or child[RFC2535]. If the KEY set resides at the child, + frequent communication is needed between the two to transmit keysets + up to parent and signatures down to child. If the KEY set resides at + the parent[Parent] the communication is reduced having only child send + updated key sets to parent. DNSSEC requires that the parent store NULL + key set for unsecure children, this complicates resolution process as + in many cases as servers for both parent and child need to be queried + for KEY set. + + Further complication of the DNSSEC KEY model is that KEY record is + used to store DNS zone keys and public keys for other protocols. This + can lead to large key sets at delegation points. There are number of + potential problems with this. + 1. KEY set may become quite large if many applications/protocols store + their keys at the zone apex. Example of protocols are IPSEC, HTTP, + SMTP, SSH etc. + 2. Key set may require frequent updates, + 3. Probability of compromised/lost keys increases and triggers + emergency key rollover. + 4. Parent may refuse sign key sets with NON DNS zone keys. + 5. Parent may not have QoS on key changes that meets child's + expectations. + + Given these and other reasons there is good reason to explore + alternatives to using only KEY records to create chain of trust. + + + +Gudmundsson Expires November 2001 [Page 2] + +INTERNET-DRAFT Delegation Signer Record May 2001 + + + Some of these problems can be reduced or eliminated by operational + rules or protocol changes. To reduce the number of keys at apex, rule + to require applications to store their KEY records at the SRV name for + that application is one possibility. Another is to restrict KEY record + to DNS keys only and create a new type for all non DNS keys. Third + possible solution is to ban the storage of non DNS related keys at + zone apex. There are other possible solutions but they are outside the + scope of this draft. + +1.1 - Delegation Signer Record model + + This draft proposes an alternative to the KEY record chain of trust, + that uses a special record that can only reside at the parent. This + record will identify the key(s) that child will use to self sign its + KEY set. + + The chain of trust is now established by verifying the parent KEY set, + the DK set from the parent and then the KEY set at the child. This is + cryptographically equivalent to just using KEY records. + + Communication between the parent and child is reduced as the parent + only needs to know of changes in DNS zone KEY records used to sign the + apex KEY set. If other KEY records are stored at the zone apex, the + parent does not to be aware of them. + + If child wants to have frequent key rollover for its DNS keys it is + possible to do that without communicating to the parent, in this case + the child uses on strong key to sign its apex KEY set and other + smaller keys to sign the zone for a short time. + + This approach has the advantage that communication between the parent + and child is kept to a minimum and the child is the authority for the + KEY set with full control over the contents. The load on the parent + is reduced and it can maintain its zone as it sees fit. + + The main disadvantage of this approach is to double the number of + signatures that need to be verified for the each KEY set. The + advantage on the other hand is that child only needs to update data in + parent when it changes DNS signing key. + + + + + + + + + + + + +Gudmundsson Expires November 2001 [Page 3] + +INTERNET-DRAFT Delegation Signer Record May 2001 + + +1.2 - Reserved words + + The key words "CAN", "MUST", "MUST NOT", "SHOULD", "DOES NOT" and + "MAY" in this document are to be interpreted as described in RFC2119. + + + +2 - DK (Delegation KEY signer) record: + +2.1 Protocol change + + DK record MUST only appear at a delegation in the parent zone. The + record lists the child's keys that CAN sign the child's key set. + Insecure delegation MUST NOT have a DK record, the presence of DK + record SHOULD be considered a hint that the child might be secure. + Resolver MUST only trust KEY records that match a DK record. + NOTE: It has been suggested that NULL DK record for insecure children + is better than no record. The advantage is to have authenticated + denial of child's security status, the drawback is for large + delegating zones there will be many NULL DK records. + WG please comment on which approach is better. + + Updates RFC2535 sections 2.3.4 and 3.4, as well as RFC3008 section + 2.7: Delegating zones MUST NOT store KEY records for delegations. The + only records that can appear at delegation in parent are NS, SIG, NXT + and DK. + + Zone MUST self sign its apex KEY set, it SHOULD sign it with a key + that corresponds to a DK record in the parent. + + If child apex KEY RRset is not signed with one of the keys specified + in the DK record the child is locally secure[RFC3090] and SHOULD only + be considered secure the resolver has been instructed to trust the key + used, via preconfiguration. + + Authorative server answering a query, that has the OK bit set[OKbit], + MUST include the DK set in the additional section if the answer is a + referral and there is space. Caching servers MAY return the DK record + in the additional section under the same condition. + + + + + + + + + + + + +Gudmundsson Expires November 2001 [Page 4] + +INTERNET-DRAFT Delegation Signer Record May 2001 + + +2.1.1 - Comments on protocol change + + DK record is the first DNS record to be only stored at the upper side + of a delegation. NS records appear at both sides as do SIG and NXT. + All other records can only appear at the lower side. This will cause + some problems as servers authorative for parent may reject DK record + even if the server understands unknown types. Similarly a nameserver + acting as a authorative for child and as a caching recursive server + may never return the DK record. A caching server does not care from + which side DK record comes from and thus should not have to be changed + if it supports unknown types. + + Secure resolvers need to know about the DK record and how to interpret + it. In the worst case, introducing the DK record, doubles the + signatures that need to be checked to validate a KEY set, this is a + small price to pay to have a cleaner delegations structure. + + Over the years there has been various discussions on that the + delegation model in DNS is broken as there is no real good way to + assert if delegation exists. In RFC2535 version of DNSSEC the + authentication of a delegation is the NS bit in the NXT bitmap at the + delegation point. Something more explicit is needed and the DK record + addresses this for secure delegations. + +2.2 Wire format of DK record + + There are two possible ways to represent the DK record at the parent + and this draft presents both for discussion, the WG is expected to + select one and only one. The two formats is either to reuse the RDATA + definition of the KEY record and the other one is to store an + identifier of the key. + +2.2.1 Compact DK format + + The DK record consists of algorithm, size, key tag and SHA-1 digest of + the public key KEY record allowed to sign the child's delegation. + + 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 | size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | algorithm | SHA-1 digest | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (20 bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + + +Gudmundsson Expires November 2001 [Page 5] + +INTERNET-DRAFT Delegation Signer Record May 2001 + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+ + + The key tag is calculated as specified in RFC2535, the size is the + size of the public key in bits as specified in the document specifying + the algorithm. Algorithm MUST be an algorithm number assigned in the + range 1..251. The SHA-1 digest is calculated over the canonical name + of the delegation followed by the RDATA of the KEY record. + +2.2.1.1 Justifications for fields + + The algorithm and size fields are here to allow resolvers to quickly + identify the candidate KEY records to examine. Key Tag is to allow + quick check if this is a good candidate. The key tag is redundant but + provides some greater assurance than SHA-1 digest on its own. SHA-1 is + a strong cryptographic checksum, it is hard for attacker to generate a + KEY record that has the same SHA-1 digest. Making sure that the KEY + record is a valid public key is much harder. Combining the SHA-1 all + the checks, the task of the attacker is as hard breaking the public + key. Even if someone creates a database of all SHA-1 key hashes seen + so far, the addition of the name renders that database useless for + attacks. + +2.2.2 Verbose DK format + + The RDATA of the DK record is identical to the KEY record as specified + in RFC2535 sections 3.1, 3.1.2, 3.1.3 and 3.2. + +2.3 Presentation format of DK record + + Only one of these subsections will be used in RFC. + + + + + + + + + + + + + + + + +Gudmundsson Expires November 2001 [Page 6] + +INTERNET-DRAFT Delegation Signer Record May 2001 + + +2.3.1 Presentation format for the compact DK record + + The presentation format of DK record consists of 2 numbers, followed + by either the name of the signature algorithm or the algorithm number. + The digest is to be presented in hex. + +2.3.2 Presentation format for the verbose DK record + + Identical to KEY record. + +2.4 Justifications for each format + +2.4.1 Justification for compact format + + This format allows concise representation of the keys that child will + use, thus keeping down the size of the answer for the delegation, + reducing the probability of packet overflow. The SHA-1 hash is strong + enough to uniquely identify the key. This is similar to PGP footprint. + + Each DK record has RDATA size of 25, regardless of the size of the + keys, keeping the answers from the parent smaller than if public key + was used. The smallest currently defined KEY record RDATA is 70 bytes. + + Compact DK format is also better suited to list trusted keys for + islands of security in configuration files. + +2.4.2 Justifications for verbose format + + Even though this format results in larger DK set the effect on + implementations is smaller. Supporting I/O for DK record type is a + matter of reusing the code for reading/writing KEY records. For + finding DK to KEY matches simple compare will do, instead of digesting + the public KEYS. + +3 Resolver Example + + This example uses compact notation for both DK and KEY for clarity. + + To create a chain of trust resolver goes from trusted KEY to DK to + KEY. + + Assume the key for domain example. is trusted. In zone example we + have + example. KEY + secure.example. DK tag=12345 size=1024 alg=dsa + secure.example. NS ns1.secure.example. + NS ns1.secure.example. + secure.example. NXT NS SIG NXT DK tail.example. + + + +Gudmundsson Expires November 2001 [Page 7] + +INTERNET-DRAFT Delegation Signer Record May 2001 + + + secure.example. SIG(NXT) + secure.example. SIG(DK) + + In zone secure.example. we have + secure.example. SOA + secure.example. NS ns1.secure.example. + NS ns1.secure.example. + secure.example. KEY + KEY + KEY + secure.example. SIG(KEY) + secure.example. SIG(SOA) + secure.example. SIG(NS) + + In this example the trusted key for example signs the DK record for + secure.example, making that a trusted record. The DK record states + what key is supposed to sign the KEY record at secure.example. In + this example secure.example. has three KEY records and the correct one + signs the KEY set, thus the key set is validated and trusted. One of + the other keys in the keyset actually signs the zone data, and + resolvers will trust the signatures as the key appears in the KEY set + that was correctly signed. + + This example has only one DK record for the child but there no reason + to outlaw multiple DK records. More than one DK record is needed + during signing key rollover. + +4 Acknowledgments + + Number of people have over the last few years contributed number of + ideas that are captured in this document. + +4 - Security Considerations: + + This document proposes a change to the validation chain of KEY records + in DNS. The change in is not believed to reduce security in the + overall system, in RFC2535 DNSSEC child must communicate keys to + parent and prudent parents will require some authentication on that + handshake. The modified protocol will require same authentication but + allows the child to exert more local control over its own KEY set. + + In the compact representation of DK record, there is a possibility + that an attacker can generate an valid KEY that matches all the checks + thus starting to forge data from the child. This is considered + impractical as on average more than 2**80 keys must be generated + before one is found that will match. + + + + + +Gudmundsson Expires November 2001 [Page 8] + +INTERNET-DRAFT Delegation Signer Record May 2001 + + + DK record is a change to DNSSEC protocol and there is some installed + base of implementations, as well as text books on how to set up + secured delegations. Implementations that do not understand DK record + will not be able to follow the KEY to DK to KEY chain and consider all + zone secured that way insecure. + +5 - IANA Considerations: + + IANA needs to allocate RR type code for DK from the standard RR type + space. + +References: + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification'', STD 13, RFC 1035, November 1987. + + +[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC + 2535, March 1999. + +[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing + Authority'', RFC 3008, November 2000. + +[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone + Status'', RFC 3090, March 2001. + +[IDbit] D. Conrad, ``Indicating Resolver Support of DNSSEC'', work in + progress , April 2001. + +[Parent] R. Gieben, T. Lindgreen, ``Parent stores the child's zone + KEYs'', work in progress , May 2001. + +Author Address + + Olafur Gudmundsson + 3826 Legation Street, NW + Washington, DC, 20015 + USA + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published and + + + +Gudmundsson Expires November 2001 [Page 9] + +INTERNET-DRAFT Delegation Signer Record May 2001 + + + 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." + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gudmundsson Expires November 2001 [Page 10] + diff --git a/doc/draft/draft-ietf-dnsext-not-existing-rr-01.txt b/doc/draft/draft-ietf-dnsext-not-existing-rr-01.txt new file mode 100644 index 0000000000..fbc9506e93 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-not-existing-rr-01.txt @@ -0,0 +1,953 @@ + + +Network Working Group S. Josefsson +Internet-Draft RSA Security +Expires: May 25, 2001 November 24, 2000 + + + Authenticating denial of existence in DNS with minimum disclosure + (or; An alternative to DNSSEC NXT records) + draft-ietf-dnsext-not-existing-rr-01 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other documents + at any time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on May 25, 2001. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This draft present an alternative to NXT records, used to achieve + authenticated denial of existence of a domain name, class and type. + Problems with NXT records, as specified in RFC 2535, are identified. + One solution, the NO record, is presented. + + The NO record differ from the NXT record by using a cryptographic + hash value instead of the domain name. This prevent an adversery + from collecting information by "chaining" through a zone. It also + remove delegation point concerns that was a side effect of NXT + records. The document also describe hash truncation and record + merging that reduces storage/network load. + + + +Josefsson Expires May 25, 2001 [Page 1] + +Internet-Draft The NO Record November 2000 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The NO Resource Record . . . . . . . . . . . . . . . . . . 4 + 3.1 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2 NO RDATA Format . . . . . . . . . . . . . . . . . . . . . 4 + 3.3 NO RDATA on-the-wire format example . . . . . . . . . . . 6 + 3.4 Owner Names . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.5 Additional Complexity Due To Wildcards . . . . . . . . . . 7 + 3.6 No Considerations at Delegation Points . . . . . . . . . . 7 + 3.7 Hash Truncation and Dynamic Updates . . . . . . . . . . . 8 + 3.8 Reducing Number of Records . . . . . . . . . . . . . . . . 9 + 3.9 Hash Collisions . . . . . . . . . . . . . . . . . . . . . 9 + 3.10 Authenticating Denial of NO Records . . . . . . . . . . . 9 + 3.11 Case Considerations . . . . . . . . . . . . . . . . . . . 10 + 3.12 Presentation Format . . . . . . . . . . . . . . . . . . . 10 + 3.13 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.13.1 Adding NO Records to a Zone . . . . . . . . . . . . . . . 10 + 3.13.2 Simple NO creating entity . . . . . . . . . . . . . . . . 11 + 3.13.3 Advanced NO creating entity . . . . . . . . . . . . . . . 11 + 3.13.4 Resolver Query for Non-existing Domain . . . . . . . . . . 11 + 3.13.5 Resolver Query for Non-existing Type At Existing Domain . 12 + 4. Comparing NO and NXT . . . . . . . . . . . . . . . . . . . 13 + 4.1 Denial Of Existence Of Non-Existing Names . . . . . . . . 13 + 4.2 Denial Of Types Of Existing Names . . . . . . . . . . . . 13 + 4.3 Information disclosure (chain problem) . . . . . . . . . . 13 + 4.4 Delegation problem . . . . . . . . . . . . . . . . . . . . 13 + 4.5 Zone size (Bytes) . . . . . . . . . . . . . . . . . . . . 13 + 4.6 Zone size (Number Of Records) . . . . . . . . . . . . . . 13 + 4.7 Zone size (Number Of Owner names) . . . . . . . . . . . . 14 + 4.8 SIG Labels field and Wildcard records . . . . . . . . . . 14 + 4.9 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 14 + 5. Security Considerations . . . . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 + References . . . . . . . . . . . . . . . . . . . . . . . . 16 + Author's Address . . . . . . . . . . . . . . . . . . . . . 16 + Full Copyright Statement . . . . . . . . . . . . . . . . . 17 + + + + + + + + + + + + + +Josefsson Expires May 25, 2001 [Page 2] + +Internet-Draft The NO Record November 2000 + + +1. Introduction + + "Domain Name Security Extensions", RFC 2535 [1], specifies several + extensions to DNS that provides data integrity and authentication. + Among them is the NXT record, used to achieve authenticated denial + of existence of domains, and authenticated denial of existence on + certain class/types on existing domains. + + As a consequence of NXT records it is possible to "chain" through a + zone secured by DNS security extensions, collecting all names and/or + records in the zone. NXT records also introduce a complication at + delegation points. These are the main problems that motivated this + draft. + +2. Context + + There have been arguments that the "chain" problem of NXT records is + a non-issue. Often used is the argument that information in DNS is + public, and if you wish to keep information private, you shouldn't + publish it in DNS. This might be true, but nonetheless major + service providers and companies are restricting access to zone + transfers. Also, people have debated whether NXT records should be + part of DNSSEC at all because of this problem [5]. + + Another aspect exist. When DNS is used to store certificates, as + described in RFC 2538 [2], certificates can identify individuals + and/or carry authentication information for special purposes. This + context has been the motivation for developing this draft. + + The "chain" problem is not the only concern with NXT records. The + delegation considerations for NXT records (different RRsets in the + parent and child for the same domain) has also been regarded as a + flaw of the NXT records. + + + + + + + + + + + + + + + + + + +Josefsson Expires May 25, 2001 [Page 3] + +Internet-Draft The NO Record November 2000 + + +3. The NO Resource Record + + This section describe the NO Resource Record. + +3.1 Idea + + A straight-forward extension to the NXT record that minimize + disclosure of information is to store a one-way function value + instead of the actual domain name. This is similar to NXT records; + where NXT records secure a interval where no existing domain names + are to be found, NO records secure a interval where no one-way value + of existing domain names are to be found. + + The benefit, of course, is that an adversary does not yield any + useful information from the record. Specifically, "chaining" + through a zone to collect all records is no longer possible. + + This idea has been extended in this document into allowing (but not + requiring) one record to deny existence of several records, and + truncating the hash value to the shortest unique prefix to preserve + space. + +3.2 NO RDATA Format + + The RDATA for a NO RR consists of one or more fields with the + following structure. The structure have the following elements: a + zero-terminated list of RR types, a hash length specifier, and a + hash value, as shown below. Both the "RR type" list and the "next + hash value" fields are of variable width. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / owner RR type list / + / | + +---------------+-----------------------------------------------+ + | # hash octets | SHA-1 hash value / + +---------------+ / + / / + +---------------------------------------------------------------+ + + Replacing the NXT RR "type bit map" field is a variable length list + of RR types. Each RR type is 16 bits. As the list is of variable + length, a end-of-list indicator is require. End of the list is + signalled by a all-zero RR type. Each element is a 2 byte RR type. + The list MUST be sorted in RR type order. The change from NXT's + bitmap field removes the limit of authenticating only the first 127 + RR types. + + +Josefsson Expires May 25, 2001 [Page 4] + +Internet-Draft The NO Record November 2000 + + + The RR type list indicates what types exist at the previous hash + value -- i.e. the first RR type list in the RRdata of a NO record + indicate what RR types exist at the domain name that hashes to the + owner name of that NO record. The second RR type list, if any, in + the RRdata of a NO record indicate what RR types exist at the domain + name that hashes the first SHA-1 value in the RRdata. And so on. + See below for a complete example of the on-the-wire-format of a NO + record with hash truncation and record merging and its + interpretation. + + Length of the hash value field is denoted by the # hash octets + fields, it is a unsigned integer ranging from 0 to 255. The meaning + of a zero length integer is reserved. + + The SHA-1 hash value field is a variable length field containing the + actual hash value. + + The NO RRs for a zone SHOULD be automatically calculated and added + to the zone when SIGs are added. The NO RR's TTL SHOULD NOT exceed + the zone minimum TTL. + + The type number for the NO RR is TBD. + + NO RR's MUST only be signed by zone level keys [7]. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires May 25, 2001 [Page 5] + +Internet-Draft The NO Record November 2000 + + +3.3 NO RDATA on-the-wire format example + + The following is a example of the on-the-wire-format of a complete + NO resource record were hash truncation and record merging is used. + It is the on-the-wire format of the NO record in section 3.13.1.2. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RR type 1 (A) | RR type 0 (end-of-list) | + +---------------+-----------------------------------------------+ + | 1 hash octet | Hash 0x22 | RR type 2 (NS) | + +---------------+---------------+-------------------------------+ + | RR type 6 (SOA) | RR type 15 (MX) | + +-------------------------------+---------------+---------------+ + | RR type 0 (end-of-list) | 1 hash octet | Hash 0x83 | + +-------------------------------+---------------+---------------+ + | RR type 1 (A) | RR type 0 (end-of-list) | + +---------------+-----------------------------------------------+ + | 1 hash octet | Hash 0x90 | RR type 1 (A) | + +---------------+---------------+-------------------------------+ + | RR type 16 (TXT) | RR type 0 (end-of-list) | + +---------------+---------------+-------------------------------+ + | 1 hash octet | Hash 0x1b | + +-------------------------------+ + + The intepretation here is that the domain that corresponds with the + NO owner name ("1b._no.example.org.", not shown above) have a A + record, that the domain that hash to 0x22 (truncated to one octet) + have a NS, SOA and MX record, that the domain that hash to 0x83 + (truncated to 1 octet) have a A record etc. Note that the last hash + value of NO RRdata does not have a RR type list in the same record. + +3.4 Owner Names + + As the previous NO RR format describe, the "next domain name" of NXT + records is replaced by its hash value. This removes the possibility + of chaining both backwards and forwards through a zone. + + But without also modifying the owner names of NO records it is still + not difficult to chain through a zone. Consider querying a server + for (say) "m._no.example.org", the reply could contain a NO record + for "g._no.example.org", now an adversary can lookup records for + "g._no.example.org", and then issue a query for a domain that would + sort (in "the canonical order" described in RFC 2535) just before + "g._no.example.org". Applying the technique over and over again, all + records in the zone can still be collected. + + To prevent this, the owner names of NO records is replaced by its + + +Josefsson Expires May 25, 2001 [Page 6] + +Internet-Draft The NO Record November 2000 + + + hash value. As DNS places limits on what characters can be used in + owner names, the owner name uses a base 16 "hex" encoding [6]. + + In order to remove the (very small) chance of generated NO record + names colliding with existing, "real", domains, all NO records MUST + be stored directly in the "_no" domain of the zone. I.e., a zone + "example.org." store its NO records as, say, + "35a4d1._no.example.org.". + + This change in owner names also make sure that the delegation point + concerns of NXT records does not occur in NO records. + +3.5 Additional Complexity Due To Wildcards + + Proving that a non-existent name response is correct, or that a + wildcard expansion response is correct, makes things a little more + complex. + + In particular, when a non-existent name response is returned, an NO + must be returned showing that the exact name did not exist and, in + general, one or more additional NO need to be returned to also prove + that there wasn't a wildcard whose expansion should have been + returned. (There is no need to return multiple copies of the same + NO.) These NOs, if any, are returned in the authority section of the + response. + + Furthermore, if a wildcard expansion is returned in a response, in + general one or more NOs needs to also be returned in the authority + section to prove that no more specific name (including possibly more + specific wildcards in the zone) existed on which the response should + have been based. + +3.6 No Considerations at Delegation Points + + When NXT records are used to deny existance, there exists a special + case at delegation points. Namely, that two distinct RRsets exist + for the same owner name, one in the parent zone and one in the child + zone. + + $ORIGIN parent.example.org. + @ SOA + NS + NXT child SOA NS SIG NXT + child NS foo + NXT next NS SIG NXT + next A 127.0.0.2 + + + + + +Josefsson Expires May 25, 2001 [Page 7] + +Internet-Draft The NO Record November 2000 + + + $ORIGIN child.parent.example.org. + @ SOA + NS + NXT name SOA NS SIG NXT + name A 127.0.2.1 + NXT child.parent.example.org. + + With NO records, the parent would deny existance of domains in + "_no.parent.example" and the child in + "_no.child.parent.example.org". Thus no NO RRset collision occur. + +3.7 Hash Truncation and Dynamic Updates + + Entities that create NO records MAY truncate the hash field. It + MUST NOT truncate hash fields so they are no longer unique + throughout a zone. Hash truncations MUST only be done to octet + offsets. Truncation MUST be such that less significant bits are + truncated, i.e. higher-order bits are preserved (see the examples). + + Zones that are dynamically updated will have to calculate and add NO + records on-the-fly. If hash truncation is used, adding a new name + to the zone will require updating (and signing) NO records for the + conflicting name(s). + + Since truncation (and also "compression" described in the next + section) make it impossible to predict the corresponding NO record + given a domain name, resolvers should not ask for a hashed NO record + (aaaa._no.example.org. IN NO) for a known domain name if they want + to find out what types exist at the domain. Instead, a resolver + might ask for NO records on the original name (www.example.org. IN + NO). Such records will never exist, and the correct NO record will + be returned by the server. + + To summarize, the behaviour of hash truncation should be + configurable in the entity that creates NO records, to accomodate + different usage-patterns. If the zone is intended to be dynamicly + updated, hash truncation may be considered not worth the extra + on-the-fly processing required. + + + + + + + + + + + + + +Josefsson Expires May 25, 2001 [Page 8] + +Internet-Draft The NO Record November 2000 + + +3.8 Reducing Number of Records + + Entitities that create NO records MAY deny existence for several + records per NO record. Entities that create NO records should take + care so that each resulting NO record is not "too large". [Comments + on this? Should there be a specific limit? It might be left as a + DNS Operational consideration] + + Merging several NO records into one record also place more work on + the resolver. Instead of parsing two hash values for each NO record + to determine if it's applicaple, a resolver will have to parse + several hash values and compare each. + + The NO RR record consist of one or more RR type list / hash values, + described above, and a resolver need to parse the entire record to + collect each individual field. I.e., a NO parse algorithm could + looke like: read RRs, stop when you read a zero RR type, read hash + length indicator, read hash size, if the entire record is read stop, + otherwise read RRs, stop when you read a zero RR type, etc.. + +3.9 Hash Collisions + + Hash value collisions are expected not to occur. For SHA-1, the + probability that this should happen is 1 out of 2^80 on average. + + However, collisions are actually only a problem if the domain names + producing the same hash value have different sets of existing types. + + Consider the following records + + ; SHA-1(one.example.org) = SHA-1(two.example.org) + + one.example.org. IN A 1.2.3.4 + two.example.org. IN A 5.6.7.8 + + Given that no other RR types exist for neither domain, both + "one.example.org" and "two.example.org" would be authenticated not + to exist by the same NO record. + +3.10 Authenticating Denial of NO Records + + NO records (together with SIG records) authenticate denial for other + types in a zone. Unlike NXT records that re-use the namespace in + the zone, NO records are not intended to authenticate denial of + other NO records. + + + + + + +Josefsson Expires May 25, 2001 [Page 9] + +Internet-Draft The NO Record November 2000 + + +3.11 Case Considerations + + Before calculating SHA-1 hash values, domain names MUST be converted + into canonical format as described in RFC 2535. This is to make hash + comparisons possible. + +3.12 Presentation Format + + NO RRs do not appear in original unsigned zone master files since + they should be derived from the zone as it is being signed. + + If a signed file with NO records is printed or NO records are + printed by debugging code, they appear as a list of unsigned + integers or RR mnemonics, and the hash value in base 16 hex + representation [6] with "0x" prepended (to distinguish it from + integer RR codes). The zero RR that terminate the list of RR types, + and the hash value length indicator, does not appear. + + See the next section for examples of printed NO RRs. + +3.13 Examples + + This section contain examples of NO records, using the reserved + domain exmaple.org [3]. + +3.13.1 Adding NO Records to a Zone + + Consider the following zone file. + + $ORIGIN example.org. + @ IN SOA ... + @ IN NS ns + @ IN MX 0 server + ns IN A ... + www IN A ... + sERVEr IN A ... + sERVEr IN TXT "text" + + ; SHA1(example.org.) = 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 + ; SHA1(ns.example.org.) = 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5 + ; SHA1(www.example.org.) = 0x839ebd4386c0b26d81f147421b5b7036e61438cf + ; SHA1(server.example.org.) = 0x906a0ad5e604b1905828499dc8672ecb8de73e2f + + Note that hash values are calculcated on the canonical form. + + The following two sections describe two valid ways of adding NO + records to a zone. + + + + +Josefsson Expires May 25, 2001 [Page 10] + +Internet-Draft The NO Record November 2000 + + +3.13.2 Simple NO creating entity + + A simple NO creator entity might not implement truncation or provide + the possibility to deny more than one records per NO record. In + this case, the following would be added to the zone file. + + $ORIGIN _no.example.org. + 1b7838c69a66eb50cc215f66ee4554d0c4c940a5 + IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 + 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 + IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf + 839ebd4386c0b26d81f147421b5b7036e61438cf + IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f + 906a0ad5e604b1905828499dc8672ecb8de73e2f + IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5 + +3.13.3 Advanced NO creating entity + + A more advanced NO creator entity might append the following + instead, using both truncation and "compression". + + $ORIGIN _no.example.org + 1b IN NO A 0x22 NS SOA MX 0x83 A 0x90 A TXT 0x1b A + + Note that this contain 5 hash values while the zone only contain 4 + records, the last value in the line above is in fact the first hash + value in the zone, closing the circular NO chain. + +3.13.4 Resolver Query for Non-existing Domain + + Consider a client looking up the non-existant domain name + "baz.example.org.", using the zone file from the previous section. + First, we note the following calculations. + + SHA-1(baz.example.org.) = 0xd5d0f98783eec6e9943750f35904304bd1a4090e + SHA-1(*.example.org.) = 0x7ab3776e3b529eb42467cc5d279c88ec951cf021 + + A server would reply with an RCODE of NXDOMAIN and the authority + section data including the following: + + + + + + + + + + + + +Josefsson Expires May 25, 2001 [Page 11] + +Internet-Draft The NO Record November 2000 + + + ; backwards compatibility + example.org. IN SOA + + ; prove no baz.example.org + 906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org. + IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5 + 906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org. IN SIG NO + + ; prove no *.example.org: + 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org. + IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf + 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org. IN SIG NO + + In order for a client to verify the authenticity of this reply, in + addition of verifying the SIG record, it will also need to calculate + the one-way hash of "baz.example.org." and verify it is contained + inside the interval of any NO record in the authority section. + Also, to prove there are no wildcard records for baz.example.org., + NO records for possible wildcard expansions are returned. A client + should similarily calculate hash values of possible wildcards and + compare them to the authority section. + + Of course, if the zone was generated with the more advanced NO + creating entity, only the NO record from the previous section would + have to be returned. + +3.13.5 Resolver Query for Non-existing Type At Existing Domain + + Consider a client looking up TXT records for the existing domain + "www.example.org.", again, using the same zone file as previous. A + server would reply with an authority section like the following: + + 839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. + IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f + 839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. IN SIG NO + + The resolver verifies the signature and make sure + SHA-1("bar.example.org.") hashes correctly. + + + + + + + + + + + + + +Josefsson Expires May 25, 2001 [Page 12] + +Internet-Draft The NO Record November 2000 + + +4. Comparing NO and NXT + + To ease comparison between NXT and NO records, this section + summarize (mis-)features of the NXT and the NO record formats. The + intent here is to address all operational differences between NO and + NXT records. + +4.1 Denial Of Existence Of Non-Existing Names + + Both NXT and NO provide strong data non-existance for non-existing + names. + + NXT records authenticate data non-existance up to the probability of + finding a collision in the signature algorithm (1 in 2^64 for + RSA/MD5). NO records authenticate data non-existance up to the + probability of finding a collision in the signature algorithm (1 in + 2^64 for RSA/MD5) and the NO record hash value (varies due to + truncation). If the RSA/MD5 scheme is used, hash values in NO + records may be truncated to 64 bits. + +4.2 Denial Of Types Of Existing Names + + Both NXT and NO provide strong data non-existance of types for + existing names. The previous discussion also apply here. + +4.3 Information disclosure (chain problem) + + NXT records make it possible to collect all names (and records) in a + zone. NO records prohibit this. + +4.4 Delegation problem + + NXT records require a special case where two different RRsets exist + at the same owner name, class and type. NO records does not have + this problem. + +4.5 Zone size (Bytes) + + The size difference is due to changing complete domain names with + hash values (SHA1 20 bytes). Without truncation, NO records are + probably larger than most NXT records. With truncation, NO records + uses a few byte per hash value instead of the (possibly compressed) + complete owner name. + +4.6 Zone size (Number Of Records) + + When NO compression is not used, NXT and NO uses the same number of + records. + + + +Josefsson Expires May 25, 2001 [Page 13] + +Internet-Draft The NO Record November 2000 + + + However, NO compression can greatly reduce the number of records. + As an example, considering a zone with records of 100.000 different + names. NXT uses 200.000 records (NXT+SIG). Using NO compression + with 10 hash values on each reduce this number to 20.000 records + (NO+SIG). + +4.7 Zone size (Number Of Owner names) + + NO uses twice the amount of owner names as NXT. + + However, NO compression can be used to reduce this to a fraction of + the normal amount. From the previous example with 10 hash values + per NO record, it will uses 10.000 additional owner names in a zone + with 100.000 names + +4.8 SIG Labels field and Wildcard records + + It is marginally faster to verify signatures for NXT records when + wildcard records are involved -- the SIG "Label fields" hints can be + used to determine the canonical name. With NO records this hint + cannot be used, because it relies on knowing the full name whereas + only the hash is available. One need to try a few SHA1 hashes to + find the correct canonical name. The number of hashes required to + try depend on the number of labels in the name, and scale linearly. + + N.B. This penalty only apply to wildcard records. + +4.9 Dynamic Updates + + Resigning dynamically updated records is required both with NXT and + NO records. + + However, when NO truncation and compression is used, the additional + penalty of re-hashing might also be required. + + + + + + + + + + + + + + + + + +Josefsson Expires May 25, 2001 [Page 14] + +Internet-Draft The NO Record November 2000 + + +5. Security Considerations + + Chaining through all NO records is still technically possible, + altough it cannot be used to collect names and/or records in the + zone (other than NO records themself). + + The security of NO record hash values is dependent on the security + of the SHA-1 hash functions used. Truncation may affect this, but + the birthday-paradox argument does not apply. One must find a hash + collision given an existing hash value -- not simply find any hash + collision. It is thus reasonably to truncate NO records to half the + hash length used in the signature scheme (this would mean 64 bits in + the RSA/MD5 case). + + It should be pointed out that given this scheme, it is easy to + estimate the number of records within a zone, considering hash + values are supposed to be equally distributed. This can be foiled + by adding any number of bogus records in the zone. + + The authentication of NO records is provided by DNS SIG records, as + specified in RFC 2535. The security considerations of RFC 2535 is + not affected by this document, and should also be considered. + +6. IANA Considerations + + The NO RR type number should be selected by the IANA from the normal + RR type space. + + The meaning of a zero hash length value can only be assigned by a + standards action. + +Acknowledgement + + The idea of encrypting names, that later evolved into just hashing + them, was originally proposed by Jonas Holmerin in private + discussions about DNS Security. Magnus Nystr÷m proposed truncating + the hash values. + + Thanks to John Linn and Magnus Nystr÷m for comments on a early + version of this draft. + + Olafur Gudmundsson pointed out delegation point issues, suggested + the use of a "_no" subdomain, and suggested replacing the type bit + map field with a sorted list. From the namedroppers mailing list, + I'd like to thank Alan Barrett, Andrew Draper, Andreas Gustafsson, + Peter Koch and Brian Wellington for comments and suggestions. Ed + Lewis noted that truncation to shortest unique prefix would not work. + + + + +Josefsson Expires May 25, 2001 [Page 15] + +Internet-Draft The NO Record November 2000 + + +References + + [1] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [2] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the + Domain Name System (DNS)", RFC 2538, March 1999. + + [3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC + 2606, June 1999. + + [4] NIST, , "Secure Hash Standard", FIPS PUB 180-1, April 1995. + + [5] Massey, D., Lehman, T. and E. Lewis, "DNSSEC Implementation in + the CAIRN Testbed.", I.D. draft-ietf-dnsop-dnsseccairn-00.txt, + October 1999. + + [6] Josefsson, S.A. (editor), "Base 64, 32 and 16 Encodings", I.D. + draft-josefsson-base-encoding-00.txt, August 2000. + + [7] Wellington, B, "Domain Name System Security (DNSSEC) Signing + Authority", I.D. draft-ietf-dnsext-signing-auth-01.txt, May + 2000. + + +Author's Address + + Simon Josefsson + RSA Security + Arenav„gen 29 + Stockholm 121 29 + Sweden + + Phone: +46 8 7250914 + EMail: sjosefsson@rsasecurity.com + + + + + + + + + + + + + + + + +Josefsson Expires May 25, 2001 [Page 16] + +Internet-Draft The NO Record November 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph + are included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Josefsson Expires May 25, 2001 [Page 17] + +