diff --git a/doc/draft/draft-ietf-behave-dns64-06.txt b/doc/draft/draft-ietf-behave-dns64-07.txt similarity index 80% rename from doc/draft/draft-ietf-behave-dns64-06.txt rename to doc/draft/draft-ietf-behave-dns64-07.txt index f648a21029..e287a984a8 100644 --- a/doc/draft/draft-ietf-behave-dns64-06.txt +++ b/doc/draft/draft-ietf-behave-dns64-07.txt @@ -4,17 +4,17 @@ BEHAVE WG M. Bagnulo Internet-Draft UC3M Intended status: Standards Track A. Sullivan -Expires: August 19, 2010 Shinkuro +Expires: September 6, 2010 Shinkuro P. Matthews Alcatel-Lucent I. van Beijnum IMDEA Networks - February 15, 2010 + March 5, 2010 DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers - draft-ietf-behave-dns64-06 + draft-ietf-behave-dns64-07 Abstract @@ -47,14 +47,14 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 19, 2010. + This Internet-Draft will expire on September 6, 2010. -Bagnulo, et al. Expires August 19, 2010 [Page 1] +Bagnulo, et al. Expires September 6, 2010 [Page 1] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 Copyright Notice @@ -108,65 +108,121 @@ Copyright Notice -Bagnulo, et al. Expires August 19, 2010 [Page 2] +Bagnulo, et al. Expires September 6, 2010 [Page 2] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 7 - 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 9 - 5.1. Resolving AAAA queries and the answer section . . . . . . 10 - 5.1.1. The answer when there is AAAA data available . . . . . 10 - 5.1.2. The answer when there is an error . . . . . . . . . . 10 - 5.1.3. Special exclusion set for AAAA records . . . . . . . . 10 - 5.1.4. Dealing with CNAME and DNAME . . . . . . . . . . . . . 11 - 5.1.5. Data for the answer when performing synthesis . . . . 11 - 5.1.6. Performing the synthesis . . . . . . . . . . . . . . . 12 - 5.1.7. Querying in parallel . . . . . . . . . . . . . . . . . 12 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Background to DNS64-DNSSEC interaction . . . . . . . . . . . . 8 + 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 5. DNS64 Normative Specification . . . . . . . . . . . . . . . . 10 + 5.1. Resolving AAAA queries and the answer section . . . . . . 11 + 5.1.1. The answer when there is AAAA data available . . . . . 11 + 5.1.2. The answer when there is an error . . . . . . . . . . 11 + 5.1.3. Dealing with timeouts . . . . . . . . . . . . . . . . 12 + 5.1.4. Special exclusion set for AAAA records . . . . . . . . 12 + 5.1.5. Dealing with CNAME and DNAME . . . . . . . . . . . . . 12 + 5.1.6. Data for the answer when performing synthesis . . . . 13 + 5.1.7. Performing the synthesis . . . . . . . . . . . . . . . 13 + 5.1.8. Querying in parallel . . . . . . . . . . . . . . . . . 14 5.2. Generation of the IPv6 representations of IPv4 - addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.3. Handling other RRs and the Additional Section . . . . . . 13 - 5.3.1. PTR queries . . . . . . . . . . . . . . . . . . . . . 13 - 5.3.2. Handling the additional section . . . . . . . . . . . 14 - 5.3.3. Other records . . . . . . . . . . . . . . . . . . . . 15 - 5.4. Assembling a synthesized response to a AAAA query . . . . 15 - 5.5. DNSSEC processing: DNS64 in recursive server mode . . . . 16 - 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 17 - 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 17 - 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 17 - 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 17 - 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 18 - 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 18 - 7. Deployment scenarios and examples . . . . . . . . . . . . . . 19 + addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 + 5.3. Handling other Resource Records and the Additional + Section . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5.3.1. PTR Resource Record . . . . . . . . . . . . . . . . . 15 + 5.3.2. Handling the additional section . . . . . . . . . . . 16 + 5.3.3. Other Resource Records . . . . . . . . . . . . . . . . 16 + 5.4. Assembling a synthesized response to a AAAA query . . . . 17 + 5.5. DNSSEC processing: DNS64 in recursive resolver mode . . . 17 + 6. Deployment notes . . . . . . . . . . . . . . . . . . . . . . . 18 + 6.1. DNS resolvers and DNS64 . . . . . . . . . . . . . . . . . 18 + 6.2. DNSSEC validators and DNS64 . . . . . . . . . . . . . . . 19 + 6.3. DNS64 and multihomed and dual-stack hosts . . . . . . . . 19 + 6.3.1. IPv6 multihomed hosts . . . . . . . . . . . . . . . . 19 + 6.3.2. Accidental dual-stack DNS64 use . . . . . . . . . . . 20 + 6.3.3. Intentional dual-stack DNS64 use . . . . . . . . . . . 20 + 7. Deployment scenarios and examples . . . . . . . . . . . . . . 21 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with - DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 20 + DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 22 7.2. An example of an-IPv6-network-to-IPv4-Internet setup - with DNS64 in stub-resolver mode . . . . . . . . . . . . . 21 + with DNS64 in stub-resolver mode . . . . . . . . . . . . . 23 7.3. Example of IPv6-Internet-to-an-IPv4-network setup - DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 23 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 + DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 25 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 Appendix A. Motivations and Implications of synthesizing AAAA - RR when real AAAA RR exists . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 + Resource Records when real AAAA Resource Records - -Bagnulo, et al. Expires August 19, 2010 [Page 3] +Bagnulo, et al. Expires September 6, 2010 [Page 3] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 + + + exist . . . . . . . . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bagnulo, et al. Expires September 6, 2010 [Page 4] + +Internet-Draft DNS64 March 2010 1. Introduction @@ -220,9 +276,9 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 4] +Bagnulo, et al. Expires September 6, 2010 [Page 5] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 available to the server). Each IPv6/IPv4 translator used in @@ -276,9 +332,9 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 5] +Bagnulo, et al. Expires September 6, 2010 [Page 6] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 configured to be the same on both; there is no communication between @@ -305,11 +361,12 @@ Internet-Draft DNS64 February 2010 has been assigned for the specific purpose of representing IPv4 addresses in IPv6 address space. - The DNS64 function can be performed in any of three places. + The DNS64 function can be performed in any of three places. The + terms below are more formally defined in Section 4. The first option is to locate the DNS64 function in authoritative servers for a zone. In this case, the authoritative server provides - a synthetic AAAA RRs for an IPv4-only host in its zone. This is one + synthetic AAAA RRs for an IPv4-only host in its zone. This is one type of DNS64 server. Another option is to locate the DNS64 function in recursive name @@ -318,9 +375,9 @@ Internet-Draft DNS64 February 2010 server can perform the synthesis of AAAA RRs and pass them back to the IPv6-only initiator. The main advantage of this mode is that current IPv6 nodes can use this mechanism without requiring any - modification. This mode is called "DNS64 in DNS recursive mode". - This is a second type of DNS64 server, and it is also one type of - DNS64 resolver. + modification. This mode is called "DNS64 in DNS recursive resolver + mode" . This is a second type of DNS64 server, and it is also one + type of DNS64 resolver. The last option is to place the DNS64 function in the end hosts, coupled to the local (stub) resolver. In this case, the stub @@ -328,31 +385,32 @@ Internet-Draft DNS64 February 2010 available, the DNS64 function will synthesize AAAA RRs for internal usage. This mode is compatible with some advanced functions like DNSSEC validation in the end host. The main drawback of this mode is - its deployability, since it requires changes in the end hosts. This -Bagnulo, et al. Expires August 19, 2010 [Page 6] +Bagnulo, et al. Expires September 6, 2010 [Page 7] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 + its deployability, since it requires changes in the end hosts. This mode is called "DNS64 in stub-resolver mode". This is the second type of DNS64 resolver. 3. Background to DNS64-DNSSEC interaction - DNSSEC presents a special challenge for DNS64, because DNSSEC is - designed to detect changes to DNS answers, and DNS64 may alter - answers coming from an authoritative server. + DNSSEC ([RFC4033], [RFC4034], [RFC4035]) presents a special challenge + for DNS64, because DNSSEC is designed to detect changes to DNS + answers, and DNS64 may alter answers coming from an authoritative + server. A recursive resolver can be security-aware or security-oblivious. - Moreover, a security-aware recursive name server can be validating or + Moreover, a security-aware recursive resolver can be validating or non-validating, according to operator policy. In the cases below, - the recursive server is also performing DNS64, and has a local policy - to validate. We call this general case vDNS64, but in all the cases - below the DNS64 functionality should be assumed needed. + the recursive resolver is also performing DNS64, and has a local + policy to validate. We call this general case vDNS64, but in all the + cases below the DNS64 functionality should be assumed needed. DNSSEC includes some signaling bits that offer some indicators of what the query originator understands. @@ -382,17 +440,18 @@ Internet-Draft DNS64 February 2010 non-DNS64 case: the server doesn't support it, so the querying agent is out of luck. + + + + +Bagnulo, et al. Expires September 6, 2010 [Page 8] + +Internet-Draft DNS64 March 2010 + + 3. A security-aware and non-validating DNS64 receives a query with the DO bit set and the CD bit clear. Such a resolver is not validating responses, likely due to local policy (see [RFC4035], - - - -Bagnulo, et al. Expires August 19, 2010 [Page 7] - -Internet-Draft DNS64 February 2010 - - section 4.2). For that reason, this case amounts to the same as the previous case, and no validation happens. @@ -435,20 +494,20 @@ Internet-Draft DNS64 February 2010 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. + + + + + + +Bagnulo, et al. Expires September 6, 2010 [Page 9] + +Internet-Draft DNS64 March 2010 + + Authoritative server: A DNS server that can answer authoritatively a given DNS question. - - - - - - -Bagnulo, et al. Expires August 19, 2010 [Page 8] - -Internet-Draft DNS64 February 2010 - - DNS64: A logical function that synthesizes DNS resource records (e.g AAAA records containing IPv6 addresses) from DNS resource records actually contained in the DNS (e.g., A records containing IPv4 @@ -494,17 +553,17 @@ Internet-Draft DNS64 February 2010 multicast address handling is out of the scope of this document. A possible approach is specified in [I-D.venaas-behave-mcast46]. + + + +Bagnulo, et al. Expires September 6, 2010 [Page 10] + +Internet-Draft DNS64 March 2010 + + DNS64 also responds to PTR queries involving addresses containing any of the IPv6 prefixes it uses for synthesis of AAAA RRs. - - - -Bagnulo, et al. Expires August 19, 2010 [Page 9] - -Internet-Draft DNS64 February 2010 - - 5.1. Resolving AAAA queries and the answer section When the DNS64 receives a query for RRs of type AAAA and class IN, it @@ -520,7 +579,7 @@ Internet-Draft DNS64 February 2010 section, the result is returned to the requesting client as per normal DNS semantics, except in the case where any of the AAAA records match a special exclusion set of prefixes, considered in - Section 5.1.3. If there is (non-excluded) AAAA data available, DNS64 + Section 5.1.4. If there is (non-excluded) AAAA data available, DNS64 SHOULD NOT include synthetic AAAA RRs in the response (see Appendix A for an analysis of the motivations for and the implications of not complying with this recommendation). By default DNS64 @@ -548,19 +607,26 @@ Internet-Draft DNS64 February 2010 of the meaning of RCODE 3, and it is expected that they will decline in use as IPv6 deployment increases. -5.1.3. Special exclusion set for AAAA records + + + + + +Bagnulo, et al. Expires September 6, 2010 [Page 11] + +Internet-Draft DNS64 March 2010 + + +5.1.3. Dealing with timeouts + + If the query receives no answer before the timeout, it is treated as + RCODE=2 (Server failure). + +5.1.4. Special exclusion set for AAAA records Some IPv6 addresses are not actually usable by IPv6-only hosts. If they are returned to IPv6-only querying agents as AAAA records, therefore, the goal of decreasing the number of failure modes will - - - -Bagnulo, et al. Expires August 19, 2010 [Page 10] - -Internet-Draft DNS64 February 2010 - - not be attained. Examples include AAAA records with addresses in the ::ffff:0:0/96 network, and possibly (depending on the context) AAAA records with the site's Pref::64/n or the Well-Known Prefix (see @@ -585,7 +651,7 @@ Internet-Draft DNS64 February 2010 answer, and proceed accordingly. It MUST NOT return the offending AAAA records as part of a response. -5.1.4. Dealing with CNAME and DNAME +5.1.5. Dealing with CNAME and DNAME If the response contains a CNAME or a DNAME, then the CNAME or DNAME chain is followed until the first terminating A or AAAA record is @@ -598,31 +664,32 @@ Internet-Draft DNS64 February 2010 included as part of the answer, and the synthetic AAAA, if appropriate, is included. -5.1.5. Data for the answer when performing synthesis + + + + +Bagnulo, et al. Expires September 6, 2010 [Page 12] + +Internet-Draft DNS64 March 2010 + + +5.1.6. Data for the answer when performing synthesis If the query results in no error but an empty answer section in the response, the DNS64 attempts to retrieve A records for the name in question, either by performing another query or, in the case of an - authortiative server, by examining its own results. If this new A RR + authoritative server, by examining its own results. If this new A RR query results in an empty answer or in an error, then the empty result or error is used as the basis for the answer returned to the querying client. (Transient errors may result in retrying the query, depending on the mode and operation of the underlying resolver; this is just as in Section 5.1.2.) If instead the query results in one or - - - -Bagnulo, et al. Expires August 19, 2010 [Page 11] - -Internet-Draft DNS64 February 2010 - - more A RRs, the DNS64 synthesizes AAAA RRs based on the A RRs - according to the procedure outlined in Section 5.1.6. The DNS64 + according to the procedure outlined in Section 5.1.7. The DNS64 returns the synthesized AAAA records in the answer section, removing the A records that form the basis of the synthesis. -5.1.6. Performing the synthesis +5.1.7. Performing the synthesis A synthetic AAAA record is created from an A record as follows: @@ -637,7 +704,12 @@ Internet-Draft DNS64 February 2010 RR and the SOA RR for the queried domain. (Note that in order to obtain the TTL of the SOA RR, the DNS64 does not need to perform a new query, but it can remember the TTL from the SOA RR in the - negative response to the AAAA query.) + negative response to the AAAA query. If the SOA RR was not + delivered with the negative response to the AAAA query, then the + DNS64 SHOULD use a default value of 600 seconds. It is possible + instead to query explicitly for the SOA RR and use the result of + that query, but this will increase query load and time to + resolution for little additional benefit.) o The RDLENGTH field is set to 16 @@ -648,7 +720,16 @@ Internet-Draft DNS64 February 2010 See Section 5.2 for discussion of the algorithms to be used in effecting the transformation. -5.1.7. Querying in parallel + + + + +Bagnulo, et al. Expires September 6, 2010 [Page 13] + +Internet-Draft DNS64 March 2010 + + +5.1.8. Querying in parallel The DNS64 MAY perform the query for the AAAA RR and for the A RR in parallel, in order to minimize the delay. However, this would result @@ -665,14 +746,6 @@ Internet-Draft DNS64 February 2010 DNS64 supports multiple algorithms for the generation of the IPv6 representation of an IPv4 address. The constraints imposed on the - - - -Bagnulo, et al. Expires August 19, 2010 [Page 12] - -Internet-Draft DNS64 February 2010 - - generation algorithms are the following: The same algorithm to create an IPv6 address from an IPv4 address @@ -694,16 +767,24 @@ Internet-Draft DNS64 February 2010 For each prefix Pref64::/n, n MUST the less than or equal to 96. If one or more Pref64::/n are configured in the DNS64 - through any means in the DNS64 (such as manually configured, or - other automatic means not specified in this document), the - default algorithm MUST use these prefixes (and not use the - Well-Know Prefix). If no prefix is available, the algorithm - MUST use the Well-Known prefix 64:FF9B::/96 defined in + through any means (such as manually configured, or other + automatic means not specified in this document), the default + algorithm MUST use these prefixes (and not use the Well-Known + Prefix). If no prefix is available, the algorithm MUST use the + Well-Known Prefix 64:FF9B::/96 defined in [I-D.ietf-behave-address-format] to represent the IPv4 unicast address range - [[anchor9: Note in document: The value 64:FF9B::/96 is proposed as + [[anchor8: Note in document: The value 64:FF9B::/96 is proposed as the value for the Well-Known prefix and needs to be confirmed + + + +Bagnulo, et al. Expires September 6, 2010 [Page 14] + +Internet-Draft DNS64 March 2010 + + whenis published as RFC.]][I-D.ietf-behave-address-format] A DNS64 MUST support the algorithm for generating IPv6 @@ -715,56 +796,58 @@ Internet-Draft DNS64 February 2010 algorithm and its application to different scenarios is provided in Section 7 for illustration purposes. -5.3. Handling other RRs and the Additional Section +5.3. Handling other Resource Records and the Additional Section -5.3.1. PTR queries +5.3.1. PTR Resource Record If a DNS64 server receives a PTR query for a record in the IP6.ARPA domain, it MUST strip the IP6.ARPA labels from the QNAME, reverse the - - - -Bagnulo, et al. Expires August 19, 2010 [Page 13] - -Internet-Draft DNS64 February 2010 - - address portion of the QNAME according to the encoding scheme outlined in section 2.5 of [RFC3596], and examine the resulting address to see whether its prefix matches any of the locally- configured Pref64::/n. There are two alternatives for a DNS64 server to respond to such PTR queries. A DNS64 server MUST provide one of these, and SHOULD NOT provide both at the same time unless different - IP6.ARPA zones require answers of different sorts. + IP6.ARPA zones require answers of different sorts: - The first option is for the DNS64 server to respond authoritatively - for its prefixes. If the address prefix matches any Pref64::/n used - in the site, either a NSP or the Well-Known Prefix (i.e. 64: - FF9B::/96), then the DNS64 server MAY answer the query using locally- - appropriate RDATA. The DNS64 server MAY use the same RDATA for all - answers. Note that the requirement is to match any Pref64::/n used - at the site, and not merely the locally-configured Pref64::/n. This - is because end clients could ask for a PTR record matching an address - received through a different (site-provided) DNS64, and if this - strategy is in effect, those queries should never be sent to the - global DNS. The advantage of this strategy is that it makes plain to - the querying client that the prefix is one operated by the (DNS64) - site, and that the answers the client is getting are generated by - DNS64. The disadvantage is that any useful reverse-tree information - that might be in the global DNS is unavailable to the clients - querying the DNS64. + 1. The first option is for the DNS64 server to respond + authoritatively for its prefixes. If the address prefix matches + any Pref64::/n used in the site, either a NSP or the Well-Known + Prefix (i.e. 64:FF9B::/96), then the DNS64 server MAY answer the + query using locally-appropriate RDATA. The DNS64 server MAY use + the same RDATA for all answers. Note that the requirement is to + match any Pref64::/n used at the site, and not merely the + locally-configured Pref64::/n. This is because end clients could + ask for a PTR record matching an address received through a + different (site-provided) DNS64, and if this strategy is in + effect, those queries should never be sent to the global DNS. + The advantage of this strategy is that it makes plain to the + querying client that the prefix is one operated by the (DNS64) + site, and that the answers the client is getting are generated by + DNS64. The disadvantage is that any useful reverse-tree + information that might be in the global DNS is unavailable to the + clients querying the DNS64. - The second option is for the DNS64 nameserver to synthesize a CNAME - mapping the IP6.ARPA namespace to the corresponding IN-ADDR.ARPA - name. The rest of the response would be the normal DNS processing. - The CNAME can be signed on the fly if need be. The advantage of this - approach is that any useful information in the reverse tree is - available to the querying client. The disadvantage is that it adds - additional load to the DNS64 (because CNAMEs have to be synthesized - for each PTR query that matches the Pref64::/n), and that it may - require signing on the fly. In addition, the generated CNAME could - correspond to an unpopulated in-addr.arpa zone, so the CNAME would - provide a reference to a non-existent record. + 2. The second option is for the DNS64 nameserver to synthesize a + CNAME mapping the IP6.ARPA namespace to the corresponding IN- + ADDR.ARPA name. The rest of the response would be the normal DNS + processing. The CNAME can be signed on the fly if need be. The + advantage of this approach is that any useful information in the + + + +Bagnulo, et al. Expires September 6, 2010 [Page 15] + +Internet-Draft DNS64 March 2010 + + + reverse tree is available to the querying client. The + disadvantage is that it adds additional load to the DNS64 + (because CNAMEs have to be synthesized for each PTR query that + matches the Pref64::/n), and that it may require signing on the + fly. In addition, the generated CNAME could correspond to an + unpopulated in-addr.arpa zone, so the CNAME would provide a + reference to a non-existent record. If the address prefix does not match any Pref64::/n, then the DNS64 server MUST process the query as though it were any other query; i.e. @@ -778,13 +861,6 @@ Internet-Draft DNS64 February 2010 additional section of synthesized answers. The DNS64 MUST pass the additional section unchanged. - - -Bagnulo, et al. Expires August 19, 2010 [Page 14] - -Internet-Draft DNS64 February 2010 - - It may appear that adding synthetic records to the additional section is desirable, because clients sometimes use the data in the additional section to proceed without having to re-query. There is @@ -804,12 +880,22 @@ Internet-Draft DNS64 February 2010 NAT64 in question. The result in this case will be resolution failure anyway, only later in the resolution operation. -5.3.3. Other records +5.3.3. Other Resource Records If the DNS64 is in recursive resolver mode, then considerations outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant. - All other RRs MUST be returned unchanged. + All other RRs MUST be returned unchanged. This includes responses to + queries for A RRs. + + + + + +Bagnulo, et al. Expires September 6, 2010 [Page 16] + +Internet-Draft DNS64 March 2010 + 5.4. Assembling a synthesized response to a AAAA query @@ -820,30 +906,20 @@ Internet-Draft DNS64 February 2010 an error, an answer that can be used as a basis for synthesis, or an empty (authoritative) answer. If there is an empty answer, then the DNS64 responds to the original querying client with the answer the - DNS64 received to the original AAAA query. Otherwise, the response - is assembled as follows. + DNS64 received to the original (initiator's) query. Otherwise, the + response is assembled as follows. The header fields are set according to the usual rules for recursive or authoritative servers, depending on the role that the DNS64 is - serving. The question section is copied from the original AAAA - query. The answer section is populated according to the rules in - Section 5.1.6. The authority and additional sections are copied from - the response to the A query that the DNS64 performed. + serving. The question section is copied from the original + (initiator's) query. The answer section is populated according to + the rules in Section 5.1.7. The authority and additional sections + are copied from the response to the final query that the DNS64 + performed, and used as the basis for synthesis. +5.5. DNSSEC processing: DNS64 in recursive resolver mode - - - - - -Bagnulo, et al. Expires August 19, 2010 [Page 15] - -Internet-Draft DNS64 February 2010 - - -5.5. DNSSEC processing: DNS64 in recursive server mode - - We consider the case where a recursive server that is performing + We consider the case where a recursive resolver that is performing DNS64 also has a local policy to validate the answers according to the procedures outlined in [RFC4035] Section 5. We call this general case vDNS64. @@ -853,7 +929,9 @@ Internet-Draft DNS64 February 2010 accordingly: 1. If CD is not set and DO is not set, vDNS64 SHOULD perform - validation and do synthesis as needed. + validation and do synthesis as needed. See the next item for + rules about how to do validation and synthesis. In this case, + however, vDNS64 MUST NOT set the AD bit in any response. 2. If CD is not set and DO is set, then vDNS64 SHOULD perform validation. Whenever vDNS64 performs validation, it MUST @@ -867,6 +945,14 @@ Internet-Draft DNS64 February 2010 answer to the client. This is acceptable, because [RFC4035], section 3.2.3 says that the AD bit is set by the name server side of a security-aware recursive name server if and only if it + + + +Bagnulo, et al. Expires September 6, 2010 [Page 17] + +Internet-Draft DNS64 March 2010 + + considers all the RRSets in the Answer and Authority sections to be authentic. In this case, the name server has reason to believe the RRSets are all authentic, so it SHOULD set the AD @@ -889,14 +975,6 @@ Internet-Draft DNS64 February 2010 resolver, and depend on the client to do the validation and the synthesis itself. The disadvantage to this approach is that an end point that is - - - -Bagnulo, et al. Expires August 19, 2010 [Page 16] - -Internet-Draft DNS64 February 2010 - - translation-oblivious but security-aware and validating will not be able to use the DNS64 functionality. In this case, the end point will not have the desired benefit of NAT64. In effect, @@ -923,6 +1001,14 @@ Internet-Draft DNS64 February 2010 point obtain IPv4-only glue records and attempt to use them for resolution. The result that is returned will contain only A records, and without the ability to perform the DNS64 function the resolver + + + +Bagnulo, et al. Expires September 6, 2010 [Page 18] + +Internet-Draft DNS64 March 2010 + + will be unable to answer the necessary AAAA queries. 6.2. DNSSEC validators and DNS64 @@ -945,19 +1031,19 @@ Internet-Draft DNS64 February 2010 will receive answers from a DNS64 without all of them being connected via a NAT64. For instance, suppose a system has two interfaces, i1 and i2. Whereas i1 is connected to the IPv4 Internet via NAT64, i2 - - - -Bagnulo, et al. Expires August 19, 2010 [Page 17] - -Internet-Draft DNS64 February 2010 - - has native IPv6 connectivity only. I1 might receive a AAAA answer from a DNS64 that is configured for a particular NAT64; the IPv6 address contained in that AAAA answer will not connect with anything via i2. + +---------------+ +-------------+ + | i1 (IPv6)+----NAT64--------+IPv4 Internet| + | | +-------------+ + | host | + | | +-------------+ + | i2 (IPv6)+-----------------+IPv6 Internet| + +---------------+ +-------------+ + This example illustrates why it is generally preferable that hosts treat DNS answers from one interface as local to that interface. The answer received on one interface will not work on the other @@ -969,6 +1055,16 @@ Internet-Draft DNS64 February 2010 there are two networks involved. The same results could be achieved with a single interface routed to two different networks. + + + + + +Bagnulo, et al. Expires September 6, 2010 [Page 19] + +Internet-Draft DNS64 March 2010 + + 6.3.2. Accidental dual-stack DNS64 use Similarly, suppose that i1 has IPv6 connectivity and can connect to @@ -977,40 +1073,55 @@ Internet-Draft DNS64 February 2010 that would better be reached via native IPv4. Again, it is worth emphasising that this arises because there are two networks involved. - Since it is most likely that the host will attempt AAAA resolution - first, in this arrangement the host will often use the NAT64 when - native IPv4 would be preferable. For this reason, hosts with IPv4 - connectivity to the Internet should avoid using DNS64. This can be - partly resolved by ISPs when providing DNS resolvers to clients, but - that is not a guarantee that the NAT64 will never be used when a - native IPv4 connection should be used. There is no general-purpose - mechanism to ensure that native IPv4 transit will always be - preferred, because to a DNS64-oblivious host, the DNS64 looks just - like an ordinary DNS server. Operators of a NAT64 should expect - traffic to pass through the NAT64 even when it is not necessary. + +---------------+ +-------------+ + | i1 (IPv6)+----NAT64--------+IPv4 Internet| + | | +-------------+ + | host | + | | +-------------+ + | i2 (IPv4)+-----------------+IPv4 Internet| + +---------------+ +-------------+ + + The default configuration of dual-stack hosts is that IPv6 is + preferred over IPv4 ([RFC3484]). In that arrangement the host will + often use the NAT64 when native IPv4 would be more desirable. For + this reason, hosts with IPv4 connectivity to the Internet should + avoid using DNS64. This can be partly resolved by ISPs when + providing DNS resolvers to clients, but that is not a guarantee that + the NAT64 will never be used when a native IPv4 connection should be + used. There is no general-purpose mechanism to ensure that native + IPv4 transit will always be preferred, because to a DNS64-oblivious + host, the DNS64 looks just like an ordinary DNS server. Operators of + a NAT64 should expect traffic to pass through the NAT64 even when it + is not necessary. 6.3.3. Intentional dual-stack DNS64 use Finally, consider the case where the IPv4 connectivity on i2 is only - to a LAN, with an IPv6-only connection on i1 to the Internet, - connecting to the IPv4 Internet via NAT64. Traffic to the LAN may - not be routable from the global Internet, as is often the case (for - instance) with LANs using RFC1918 addresses. In this case, it is - critical that the DNS64 not synthesize AAAA responses for hosts in - the LAN, or else that the DNS64 be aware of hosts in the LAN and - provide context-sensitive answers ("split view" DNS answers) for - hosts inside the LAN. As with any split view DNS arrangement, - operators must be prepared for data to leak from one context to + with a LAN, and not with the IPv4 Internet. The IPv4 Internet is + only accessible using the NAT64. In this case, it is critical that + the DNS64 not synthesize AAAA responses for hosts in the LAN, or else + that the DNS64 be aware of hosts in the LAN and provide context- + sensitive answers ("split view" DNS answers) for hosts inside the + LAN. As with any split view DNS arrangement, operators must be + prepared for data to leak from one context to another, and for + failures to occur because nodes accessible from one context are not + accessible from the other. + + +---------------+ +-------------+ + | i1 (IPv6)+----NAT64--------+IPv4 Internet| + | | +-------------+ + | host | + | | + | i2 (IPv4)+---(local LAN only) -Bagnulo, et al. Expires August 19, 2010 [Page 18] +Bagnulo, et al. Expires September 6, 2010 [Page 20] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 - another, and for failures to occur because nodes accessible from one - context are not accessible from the other. + +---------------+ It is important for deployers of DNS64 to realise that, in some circumstances, making the DNS64 available to a dual-stack host will @@ -1040,7 +1151,7 @@ Internet-Draft DNS64 February 2010 communication from these IPv6-only connected hosts to the IPv4 Internet. This case is called An-IPv6-network-to-IPv4-Internet [I-D.ietf-behave-v6v4-framework]. In this case, the IPv6/IPv4 - Translator is used to connect the end site or the ISP to the IPv4 + translator is used to connect the end site or the ISP to the IPv4 Internet and the DNS64 function is provided by the end site or the ISP. @@ -1060,9 +1171,10 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 19] + +Bagnulo, et al. Expires September 6, 2010 [Page 21] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server @@ -1116,9 +1228,9 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 20] +Bagnulo, et al. Expires September 6, 2010 [Page 22] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 For this example, assume the typical DNS situation where IPv6 hosts @@ -1172,9 +1284,9 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 21] +Bagnulo, et al. Expires September 6, 2010 [Page 23] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 +---------------------+ +---------------+ @@ -1228,9 +1340,9 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 22] +Bagnulo, et al. Expires September 6, 2010 [Page 24] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 IPv6 address in the AAAA record contains the prefix assigned to @@ -1284,9 +1396,9 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 23] +Bagnulo, et al. Expires September 6, 2010 [Page 25] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 is recommended over the second option (i.e. the synthesis upon @@ -1340,9 +1452,9 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 24] +Bagnulo, et al. Expires September 6, 2010 [Page 26] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending @@ -1370,7 +1482,7 @@ Internet-Draft DNS64 February 2010 8. Security Considerations See the discussion on the usage of DNSSEC and DNS64 described in - section 3, section 5.5, and section 6.2. . + Section 3, Section 5.5, and Section 6.2. 9. IANA Considerations @@ -1392,22 +1504,22 @@ Internet-Draft DNS64 February 2010 This draft contains the result of discussions involving many people, including the participants of the IETF BEHAVE Working Group. The following IETF participants made specific contributions to parts of - the text, and their help is gratefully acknowledged: Mark Andrews, + the text, and their help is gratefully acknowledged: Jaap Akkerhuis, -Bagnulo, et al. Expires August 19, 2010 [Page 25] +Bagnulo, et al. Expires September 6, 2010 [Page 27] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 - Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, Doug Barton, - Marc Blanchet, Cameron Byrne, Brian Carpenter, Hui Deng, Francis - Dupont, Patrik Faltstrom, Ed Jankiewicz, Peter Koch, Suresh Krishnan, - Ed Lewis, Xing Li, Bill Manning, Matthijs Mekking, Hiroshi Miyata, - Simon Perrault, Teemu Savolainen, Jyrki Soini, Dave Thaler, Mark - Townsley, Rick van Rein, Stig Venaas, Magnus Westerlund, Florian - Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui. + Mark Andrews, Jari Arkko, Rob Austein, Timothy Baldwin, Fred Baker, + Doug Barton, Marc Blanchet, Cameron Byrne, Brian Carpenter, Zhen Cao, + Hui Deng, Francis Dupont, Patrik Faltstrom, Ed Jankiewicz, Peter + Koch, Suresh Krishnan, Ed Lewis, Xing Li, Bill Manning, Matthijs + Mekking, Hiroshi Miyata, Simon Perrault, Teemu Savolainen, Jyrki + Soini, Dave Thaler, Mark Townsley, Rick van Rein, Stig Venaas, Magnus + Westerlund, Florian Weimer, Dan Wing, Xu Xiaohu, Xiangsong Cui. Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy, a research project supported by the European Commission @@ -1452,9 +1564,9 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 26] +Bagnulo, et al. Expires September 6, 2010 [Page 28] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 [RFC3484] Draves, R., "Default Address Selection for Internet @@ -1476,17 +1588,13 @@ Internet-Draft DNS64 February 2010 Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. - [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network - Address Translator - Protocol Translator (NAT-PT) to - Historic Status", RFC 4966, July 2007. - [RFC5735] Cotton, M. and L. Vegoda, "iSpecial Use IPv4 Addresses", BCP 153, RFC 5735, January 2010. [I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", - draft-ietf-behave-v6v4-framework-06 (work in progress), + draft-ietf-behave-v6v4-framework-07 (work in progress), February 2010. [I-D.venaas-behave-mcast46] @@ -1502,22 +1610,23 @@ Internet-Draft DNS64 February 2010 [I-D.savolainen-mif-dns-server-selection] Savolainen, T., "DNS Server Selection on Multi-Homed - Hosts", draft-savolainen-mif-dns-server-selection-01 (work - in progress), October 2009. + Hosts", draft-savolainen-mif-dns-server-selection-02 (work + in progress), February 2010. + + +Appendix A. Motivations and Implications of synthesizing AAAA Resource + Records when real AAAA Resource Records exist -Bagnulo, et al. Expires August 19, 2010 [Page 27] +Bagnulo, et al. Expires September 6, 2010 [Page 29] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 -Appendix A. Motivations and Implications of synthesizing AAAA RR when - real AAAA RR exists - - The motivation for synthesizing AAAA RRs when a real AAAA RRs exist - is to support the following scenario: + The motivation for synthesizing AAAA RRs when real AAAA RRs exist is + to support the following scenario: An IPv4-only server application (e.g. web server software) is running on a dual-stack host. There may also be dual-stack server @@ -1538,7 +1647,7 @@ Appendix A. Motivations and Implications of synthesizing AAAA RR when a DNS64 service may want to enable the synthesis of AAAA RRs even when real AAAA RRs exist. - The implication of including synthetic AAAA RR when real AAAA RR + The implication of including synthetic AAAA RRs when real AAAA RRs exist is that translated connectivity may be preferred over native connectivity in some cases where the DNS64 is operated in DNS server mode. @@ -1553,26 +1662,26 @@ Appendix A. Motivations and Implications of synthesizing AAAA RR when This means that without further configuration: - In "An IPv6 network to the IPv4 Internet" scenario , the host will - prefer translated connectivity if an NSP is used. If the Well- - Known Prefix defined in [I-D.ietf-behave-address-format] is used, - it will probably prefer native connectivity. + In the "An IPv6 network to the IPv4 Internet" scenario, the host + will prefer translated connectivity if an NSP is used. If the + Well-Known Prefix defined in [I-D.ietf-behave-address-format] is + used, it will probably prefer native connectivity. In the "IPv6 Internet to an IPv4 network" scenario, it is possible to bias the selection towards the real AAAA RR if the DNS64 resolver returns the real AAAA first in the DNS reply, when an NSP - - - -Bagnulo, et al. Expires August 19, 2010 [Page 28] - -Internet-Draft DNS64 February 2010 - - is used (the Well-Known Prefix usage is not supported in this case) - In "an IPv6 network to IPv4 network" scenario, for local + + + +Bagnulo, et al. Expires September 6, 2010 [Page 30] + +Internet-Draft DNS64 March 2010 + + + In the "An IPv6 network to IPv4 network" scenario, for local destinations (i.e., target hosts inside the local site), it is likely that the NSP and the destination prefix are the same, so we can use the order of RR in the DNS reply to bias the selection @@ -1620,9 +1729,12 @@ Authors' Addresses -Bagnulo, et al. Expires August 19, 2010 [Page 29] + + + +Bagnulo, et al. Expires September 6, 2010 [Page 31] -Internet-Draft DNS64 February 2010 +Internet-Draft DNS64 March 2010 Philip Matthews @@ -1676,5 +1788,5 @@ Internet-Draft DNS64 February 2010 -Bagnulo, et al. Expires August 19, 2010 [Page 30] +Bagnulo, et al. Expires September 6, 2010 [Page 32] diff --git a/doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt b/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt similarity index 84% rename from doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt rename to doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt index f651d1351e..7bb5ab72f8 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-gost-06.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-gost-07.txt @@ -1,12 +1,12 @@ DNS Extensions working group V.Dolmatov, Ed. Internet-Draft Cryptocom Ltd. -Intended status: Standards Track December 12, 2009 -Expires: June 12, 2010 +Intended status: Standards Track March 06, 2010 +Expires: September 06, 2010 Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC - draft-ietf-dnsext-dnssec-gost-06 + draft-ietf-dnsext-dnssec-gost-07 Status of this Memo @@ -29,7 +29,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on June 12 2010. + This Internet-Draft will expire on September 06 2010. Copyright Notice @@ -37,19 +37,23 @@ Copyright Notice document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with + respect to this document. Code Components extracted from this + document must include Simplified BSD License text as described in + Section 4.e of the Trust Legal Provisions and are provided without + warranty as described in the Simplified BSD License. Abstract - This document describes how to produce signature and hash using - GOST algorithms [DRAFT1, DRAFT2, DRAFT3] for DNSKEY, RRSIG and DS - resource records for use in the Domain Name System Security - Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). - -V.Dolmatov Expires June 12, 2010 [Page 1] + This document describes how to produce signature and hash using + GOST (R 34.10-2001, R 34.11-94) algorithms foor DNSKEY, RRSIG and DS + resource records for use in the Domain Name System Security + Extensions (DNSSEC). + +V.Dolmatov Expires September 06, 2010 [Page 1] Table of Contents @@ -98,7 +102,8 @@ Table of Contents The term "GOST" is not officially defined, but is usually used to refer to the collection of the Russian cryptographic algorithms - GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. + GOST R 34.10-2001[DRAFT1], GOST R 34.11-94[DRAFT2], + GOST 28147-89[DRAFT3]. Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to the GOST R 34.10-2001 and GOST R 34.11-94 in this document. @@ -106,7 +111,7 @@ Table of Contents "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. -V.Dolmatov Expires June 12, 2010 [Page 2] +V.Dolmatov Expires September 06, 2010 [Page 2] 2. DNSKEY Resource Records @@ -155,12 +160,12 @@ V.Dolmatov Expires June 12, 2010 [Page 2] private key file it must be in one line): Private-key-format: v1.2 - Algorithm: {TBA1} (GOST) + Algorithm: {TBA1} (ECC-GOST) GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA= -V.Dolmatov Expires June 12, 2010 [Page 3] +V.Dolmatov Expires September 06, 2010 [Page 3] The following DNSKEY RR stores a DNS zone key for example.net @@ -215,11 +220,11 @@ V.Dolmatov Expires June 12, 2010 [Page 3] Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W HRFSm0XS5YST5g== ) -V.Dolmatov Expires June 12, 2010 [Page 4] +V.Dolmatov Expires September 06, 2010 [Page 4] - Note: Several GOST signatures calculated for the same message text - differ because of using of a random element is used in signature - generation process. + Note: Several ECC-GOST signatures calculated for the same message text + will differ because of using of a random element is used in signature + generation process. 4. DS Resource Records @@ -269,25 +274,25 @@ V.Dolmatov Expires June 12, 2010 [Page 4] 6.1. Support for GOST signatures - DNSSEC aware implementations SHOULD be able to support RRSIG and + DNSSEC aware implementations MAY be able to support RRSIG and DNSKEY resource records created with the GOST algorithms as defined in this document. -V.Dolmatov Expires June 12, 2010 [Page 5] +V.Dolmatov Expires September 06, 2010 [Page 5] 6.2. Support for NSEC3 Denial of Existence - Any DNSSEC-GOST implementation is required to have either NSEC or - NSEC3 support. + Any DNSSEC-GOST implementation MUST support both NSEC[RFC4035] and + NSEC3 [RFC5155] 6.3 Byte order Due to the fact that all existing industry implementations of GOST - cryptographic libraries are returning GOST blobs in little-endian - format and in order to avoid the necessity for DNSSEC developers - to handle different cryptographic algorithms differently, it was - chosen to send these blobs on the wire "as is" without - transformation of endianness. + cryptographic libraries are returning GOST blobs without + transformation from little-endian format and in order to avoid the + necessity for DNSSEC developers to handle different cryptographic + algorithms differently, it was chosen to send these blobs on the + wire "as is" without transformation of endianness. 7. Security considerations @@ -307,12 +312,12 @@ V.Dolmatov Expires June 12, 2010 [Page 5] 8. IANA Considerations This document updates the IANA registry "DNS Security Algorithm - Numbers [RFC4034]" + Numbers" [RFC4034] (http://www.iana.org/assignments/dns-sec-alg-numbers). The following entries are added to the registry: Zone Trans. Value Algorithm Mnemonic Signing Sec. References Status - {TBA1} GOST R 34.10-2001 GOST Y * (this memo) OPTIONAL + {TBA1} GOST R 34.10-2001 ECC-GOST Y * (this memo) OPTIONAL This document updates the RFC 4034 Digest Types assignment (section A.2)by adding the value and status for the GOST R 34.11-94 @@ -329,7 +334,7 @@ V.Dolmatov Expires June 12, 2010 [Page 5] contributors to these documents are gratefully acknowledged for their hard work. -V.Dolmatov Expires June 12, 2010 [Page 6] +V.Dolmatov Expires September 06, 2010 [Page 6] The following people provided additional feedback and text: Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen @@ -385,8 +390,11 @@ V.Dolmatov Expires June 12, 2010 [Page 6] Infrastructure Certificate and CRL Profile", RFC 4491, May 2006. -V.Dolmatov Expires June 12, 2010 [Page 7] - +V.Dolmatov Expires September 06, 2010 [Page 7] + +[RFC5155] B. Laurie, G. Sisson, R. Arends and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, February 2008. 10.2. Informative References @@ -395,21 +403,21 @@ V.Dolmatov Expires June 12, 2010 [Page 7] [DRAFT1] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., "GOST R 34.10-2001 digital signature algorithm" - draft-dolmatov-cryptocom-gost34102001-07, 12.12.09 + draft-dolmatov-cryptocom-gost34102001-08, 12.12.09 work in progress. [DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., "GOST R 34.11-94 Hash function algorithm" - draft-dolmatov-cryptocom-gost341194-06, 12.12.09 + draft-dolmatov-cryptocom-gost341194-07, 12.12.09 work in progress. [DRAFT3] Dolmatov V., Kabelev D., Ustinov I., Emelyanova I., "GOST 28147-89 encryption, decryption and MAC algorithms" - draft-dolmatov-cryptocom-gost2814789-06, 12.12.09 + draft-dolmatov-cryptocom-gost2814789-08, 12.12.09 work in progress. -V.Dolmatov Expires June 12, 2010 [Page 8] +V.Dolmatov Expires September 06, 2010 [Page 8] Authors' Addresses @@ -436,9 +444,5 @@ Moscow, 117218, Russian Federation EMail: igus@cryptocom.ru -V.Dolmatov Expires June 12, 2010 [Page 9] - - - - +V.Dolmatov Expires September 06, 2010 [Page 9]