+++ /dev/null
-
-
-
-BEHAVE WG M. Bagnulo
-Internet-Draft UC3M
-Intended status: Standards Track A. Sullivan
-Expires: August 19, 2010 Shinkuro
- P. Matthews
- Alcatel-Lucent
- I. van Beijnum
- IMDEA Networks
- February 15, 2010
-
-
-DNS64: DNS extensions for Network Address Translation from IPv6 Clients
- to IPv4 Servers
- draft-ietf-behave-dns64-06
-
-Abstract
-
- DNS64 is a mechanism for synthesizing AAAA records from A records.
- DNS64 is used with an IPv6/IPv4 translator to enable client-server
- communication between an IPv6-only client and an IPv4-only server,
- without requiring any changes to either the IPv6 or the IPv4 node,
- for the class of applications that work through NATs. This document
- specifies DNS64, and provides suggestions on how it should be
- deployed in conjunction with IPv6/IPv4 translators.
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on August 19, 2010.
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 1]
-\f
-Internet-Draft DNS64 February 2010
-
-
-Copyright Notice
-
- Copyright (c) 2010 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents
- (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 BSD License.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 2]
-\f
-Internet-Draft DNS64 February 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
- 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
- 7.1. Example of An-IPv6-network-to-IPv4-Internet setup with
- DNS64 in DNS server mode . . . . . . . . . . . . . . . . . 20
- 7.2. An example of an-IPv6-network-to-IPv4-Internet setup
- with DNS64 in stub-resolver mode . . . . . . . . . . . . . 21
- 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
- Appendix A. Motivations and Implications of synthesizing AAAA
- RR when real AAAA RR exists . . . . . . . . . . . . . 28
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 3]
-\f
-Internet-Draft DNS64 February 2010
-
-
-1. Introduction
-
- This document specifies DNS64, a mechanism that is part of the
- toolbox for IPv6-IPv4 transition and co-existence. DNS64, used
- together with an IPv6/IPv4 translator such as stateful NAT64
- [I-D.ietf-behave-v6v4-xlate-stateful], allows an IPv6-only client to
- initiate communications by name to an IPv4-only server.
-
- DNS64 is a mechanism for synthesizing AAAA resource records (RRs)
- from A RRs. A synthetic AAAA RR created by the DNS64 from an
- original A RR contains the same owner name of the original A RR but
- it contains an IPv6 address instead of an IPv4 address. The IPv6
- address is an IPv6 representation of the IPv4 address contained in
- the original A RR. The IPv6 representation of the IPv4 address is
- algorithmically generated from the IPv4 address returned in the A RR
- and a set of parameters configured in the DNS64 (typically, an IPv6
- prefix used by IPv6 representations of IPv4 addresses and optionally
- other parameters).
-
- Together with an IPv6/IPv4 translator, these two mechanisms allow an
- IPv6-only client to initiate communications to an IPv4-only server
- using the FQDN of the server.
-
- These mechanisms are expected to play a critical role in the IPv4-
- IPv6 transition and co-existence. Due to IPv4 address depletion, it
- is likely that in the future, many IPv6-only clients will want to
- connect to IPv4-only servers. In the typical case, the approach only
- requires the deployment of IPv6/IPv4 translators that connect an
- IPv6-only network to an IPv4-only network, along with the deployment
- of one or more DNS64-enabled name servers. However, some advanced
- features require performing the DNS64 function directly in the end-
- hosts themselves.
-
-
-2. Overview
-
- This section provides a non-normative introduction to the DNS64
- mechanism.
-
- We assume that we have one or more IPv6/IPv4 translator boxes
- connecting an IPv4 network and an IPv6 network. The IPv6/IPv4
- translator device provides translation services between the two
- networks enabling communication between IPv4-only hosts and IPv6-only
- hosts. (NOTE: By IPv6-only hosts we mean hosts running IPv6-only
- applications, hosts that can only use IPv6, as well as cases where
- only IPv6 connectivity is available to the client. By IPv4-only
- servers we mean servers running IPv4-only applications, servers that
- can only use IPv4, as well as cases where only IPv4 connectivity is
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 4]
-\f
-Internet-Draft DNS64 February 2010
-
-
- available to the server). Each IPv6/IPv4 translator used in
- conjunction with DNS64 must allow communications initiated from the
- IPv6-only host to the IPv4-only host.
-
- To allow an IPv6 initiator to do a standard AAAA RR DNS lookup to
- learn the address of the responder, DNS64 is used to synthesize a
- AAAA record from an A record containing a real IPv4 address of the
- responder, whenever the DNS64 cannot retrieve a AAAA record for the
- queried name. The DNS64 service appears as a regular DNS server or
- resolver to the IPv6 initiator. The DNS64 receives a AAAA DNS query
- generated by the IPv6 initiator. It first attempts a resolution for
- the requested AAAA records. If there are no AAAA records available
- for the target node (which is the normal case when the target node is
- an IPv4-only node), DNS64 performs a query for A records. For each A
- record discovered, DNS64 creates a synthetic AAAA RR from the
- information retrieved in the A RR.
-
- The owner name of a synthetic AAAA RR is the same as that of the
- original A RR, but an IPv6 representation of the IPv4 address
- contained in the original A RR is included in the AAAA RR. The IPv6
- representation of the IPv4 address is algorithmically generated from
- the IPv4 address and additional parameters configured in the DNS64.
- Among those parameters configured in the DNS64, there is at least one
- IPv6 prefix. If not explicitly mentioned, all prefixes are treated
- equally and the operations described in this document are performed
- using the prefixes available. So as to be general, we will call any
- of these prefixes Pref64::/n, and describe the operations made with
- the generic prefix Pref64::/n. The IPv6 address representing IPv4
- addresses included in the AAAA RR synthesized by the DNS64 contain
- Pref64::/n and they also embed the original IPv4 address.
-
- The same algorithm and the same Pref64::/n prefix(es) must be
- configured both in the DNS64 device and the IPv6/IPv4 translator(s),
- so that both can algorithmically generate the same IPv6
- representation for a given IPv4 address. In addition, it is required
- that IPv6 packets addressed to an IPv6 destination address that
- contains the Pref64::/n be delivered to an IPv6/IPv4 translator, so
- they can be translated into IPv4 packets.
-
- Once the DNS64 has synthesized the AAAA RRs, the synthetic AAAA RRs
- are passed back to the IPv6 initiator, which will initiate an IPv6
- communication with the IPv6 address associated with the IPv4
- receiver. The packet will be routed to an IPv6/IPv4 translator which
- will forward it to the IPv4 network.
-
- In general, the only shared state between the DNS64 and the IPv6/IPv4
- translator is the Pref64::/n and an optional set of static
- parameters. The Pref64::/n and the set of static parameters must be
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 5]
-\f
-Internet-Draft DNS64 February 2010
-
-
- configured to be the same on both; there is no communication between
- the DNS64 device and IPv6/IPv4 translator functions. The mechanism
- to be used for configuring the parameters of the DNS64 is beyond the
- scope of this memo.
-
- The prefixes to be used as Pref64::/n and their applicability are
- discussed in [I-D.ietf-behave-address-format]. There are two types
- of prefixes that can be used as Pref64::/n.
-
- The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved
- by [I-D.ietf-behave-address-format] for the purpose of
- representing IPv4 addresses in IPv6 address space.
-
- The Pref64::/n can be a Network-Specific Prefix (NSP). An NSP is
- an IPv6 prefix assigned by an organization to create IPv6
- representations of IPv4 addresses.
-
- The main difference in the nature of the two types of prefixes is
- that the NSP is a locally assigned prefix that is under control of
- the organization that is providing the translation services, while
- the Well-Known Prefix is a prefix that has a global meaning since it
- 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 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
- type of DNS64 server.
-
- Another option is to locate the DNS64 function in recursive name
- servers serving end hosts. In this case, when an IPv6-only host
- queries the name server for AAAA RRs for an IPv4-only host, the name
- 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.
-
- The last option is to place the DNS64 function in the end hosts,
- coupled to the local (stub) resolver. In this case, the stub
- resolver will try to obtain (real) AAAA RRs and in case they are not
- 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]
-\f
-Internet-Draft DNS64 February 2010
-
-
- 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.
-
- A recursive resolver can be security-aware or security-oblivious.
- Moreover, a security-aware recursive name server 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.
-
- DNSSEC includes some signaling bits that offer some indicators of
- what the query originator understands.
-
- If a query arrives at a vDNS64 device with the "DNSSEC OK" (DO) bit
- set, the query originator is signaling that it understands DNSSEC.
- The DO bit does not indicate that the query originator will validate
- the response. It only means that the query originator can understand
- responses containing DNSSEC data. Conversely, if the DO bit is
- clear, that is evidence that the querying agent is not aware of
- DNSSEC.
-
- If a query arrives at a vDNS64 device with the "Checking Disabled"
- (CD) bit set, it is an indication that the querying agent wants all
- the validation data so it can do checking itself. By local policy,
- vDNS64 could still validate, but it must return all data to the
- querying agent anyway.
-
- Here are the possible cases:
-
- 1. A DNS64 (DNSSEC-aware or DNSSEC-oblivious) receives a query with
- the DO bit clear. In this case, DNSSEC is not a concern, because
- the querying agent does not understand DNSSEC responses.
-
- 2. A security-oblivious DNS64 receives a query with the DO bit set,
- and the CD bit clear or set. This is just like the case of a
- non-DNS64 case: the server doesn't support it, so the querying
- agent is out of luck.
-
- 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]
-\f
-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.
-
- 4. A security-aware and non-validating DNS64 receives a query with
- the DO bit set and the CD bit set. In this case, the resolver is
- supposed to pass on all the data it gets to the query initiator
- (see section 3.2.2 of [RFC4035]). This case will be problematic
- with DNS64. If the DNS64 server modifies the record, the client
- will get the data back and try to validate it, and the data will
- be invalid as far as the client is concerned.
-
- 5. A security-aware and validating DNS64 node receives a query with
- the DO bit clear and CD clear. In this case, the resolver
- validates the data. If it fails, it returns RCODE 2 (Server
- failure); otherwise, it returns the answer. This is the ideal
- case for vDNS64. The resolver validates the data, and then
- synthesizes the new record and passes that to the client. The
- client, which is presumably not validating (else it should have
- set DO and CD), cannot tell that DNS64 is involved.
-
- 6. A security-aware and validating DNS64 node receives a query with
- the DO bit set and CD clear. This ought to work like the
- previous case, except that the resolver should also set the
- "Authentic Data" (AD) bit on the response.
-
- 7. A security-aware and validating DNS64 node receives a query with
- the DO bit set and CD set. This is effectively the same as the
- case where a security-aware and non-validating recursive resolver
- receives a similar query, and the same thing will happen: the
- downstream validator will mark the data as invalid if DNS64 has
- performed synthesis.
-
-
-4. Terminology
-
- This section provides definitions for the special terms used in the
- document.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [RFC2119].
-
- Authoritative server: A DNS server that can answer authoritatively a
- given DNS question.
-
-
-
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 8]
-\f
-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
- addresses).
-
- DNS64 recursor: A recursive resolver that provides the DNS64
- functionality as part of its operation. This is the same thing as
- "DNS64 in recursive resolver mode".
-
- DNS64 resolver: Any resolver (stub resolver or recursive resolver)
- that provides the DNS64 function.
-
- DNS64 server: Any server providing the DNS64 function.
-
- Recursive resolver: A DNS server that accepts requests from one
- resolver, and asks another server (of some description) for the
- answer on behalf of the first resolver.
-
- Synthetic RR: A DNS resource record (RR) that is not contained in
- any zone data file, but has been synthesized from other RRs. An
- example is a synthetic AAAA record created from an A record.
-
- IPv6/IPv4 translator: A device that translates IPv6 packets to IPv4
- packets and vice-versa. It is only required that the
- communication initiated from the IPv6 side be supported.
-
- For a detailed understanding of this document, the reader should also
- be familiar with DNS terminology from [RFC1034], [RFC1035] and
- current NAT terminology from [RFC4787]. Some parts of this document
- assume familiarity with the terminology of the DNS security
- extensions outlined in [RFC4035].
-
-
-5. DNS64 Normative Specification
-
- DNS64 is a logical function that synthesizes AAAA records from A
- records. The DNS64 function may be implemented in a stub resolver,
- in a recursive resolver, or in an authoritative name server.
-
- The implementation SHOULD support mapping of separate IPv4 address
- ranges to separate IPv6 prefixes for AAAA record synthesis. This
- allows handling of special use IPv4 addresses [RFC5735]. Support of
- multicast address handling is out of the scope of this document. A
- possible approach is specified in [I-D.venaas-behave-mcast46].
-
- 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]
-\f
-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
- first attempts to retrieve non-synthetic RRs of this type and class,
- either by performing a query or, in the case of an authoritative
- server, by examining its own results. DNS64 operation for classes
- other than IN is undefined, and a DNS64 MUST behave as though no
- DNS64 function is configured.
-
-5.1.1. The answer when there is AAAA data available
-
- If the query results in one or more AAAA records in the answer
- 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
- 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
- implementations MUST NOT synthesize AAAA RRs when real AAAA RRs
- exist.
-
-5.1.2. The answer when there is an error
-
- If the query results in a response with RCODE other than 0 (No error
- condition), then there are two possibilities. A result with RCODE=3
- (Name Error) is handled according to normal DNS operation (which is
- normally to return the error to the client). This stage is still
- prior to any synthesis having happened, so a response to be returned
- to the client does not need any special assembly than would usually
- happen in DNS operation.
-
- Any other RCODE is treated as though the RCODE were 0 and the answer
- section were empty. This is because of the large number of different
- responses from deployed name servers when they receive AAAA queries
- without a AAAA record being available.
-
- It is important to note that, as of this writing, some servers
- respond with RCODE=3 to a AAAA query even if there is an A record
- available for that owner name. Those servers are in clear violation
- 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
-
- 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]
-\f
-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
- below for more about the Well-Known Prefix). A DNS64 implementation
- SHOULD provide a mechanism to specify IPv6 prefix ranges to be
- treated as though the AAAA containing them were an empty answer. An
- implementation SHOULD include the ::ffff/96 network in that range by
- default. Failure to provide this facility will mean that clients
- querying the DNS64 function may not be able to communicate with hosts
- that would be reachable from a dual-stack host.
-
- When the DNS64 performs its initial AAAA query, if it receives an
- answer with only AAAA records containing addresses in the excluded
- range(s), then it MUST treat the answer as though it were an empty
- answer, and proceed accordingly. If it receives an answer with at
- least one AAAA record containing an address outside any of the
- excluded range(s), then it MAY build an answer section for a response
- including only the AAAA record(s) that do not contain any of the
- addresses inside the excluded ranges. That answer section is used in
- the assembly of a response as detailed in Section 5.4.
- Alternatively, it MAY treat the answer as though it were an empty
- 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
-
- 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
- reached. This may require the DNS64 to ask for an A record, in case
- the response to the original AAAA query is a CNAME or DNAME without a
- AAAA record to follow. The resulting AAAA or A record is treated
- like any other AAAA or A case, as appropriate.
-
- When assembling the answer section, the original CNAME or DNAME RR is
- included as part of the answer, and the synthetic AAAA, if
- appropriate, is included.
-
-5.1.5. 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
- 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]
-\f
-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
- 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
-
- A synthetic AAAA record is created from an A record as follows:
-
- o The NAME field is set to the NAME field from the A record
-
- o The TYPE field is set to 28 (AAAA)
-
- o The CLASS field is set to the original CLASS field, 1. Under this
- specification, DNS64 for any CLASS other than 1 is undefined.
-
- o The TTL field is set to the minimum of the TTL of the original A
- 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.)
-
- o The RDLENGTH field is set to 16
-
- o The RDATA field is set to the IPv6 representation of the IPv4
- address from the RDATA field of the A record. The DNS64 SHOULD
- check each A RR against configured IPv4 address ranges and select
- the corresponding IPv6 prefix to use in synthesizing the AAAA RR.
- See Section 5.2 for discussion of the algorithms to be used in
- effecting the transformation.
-
-5.1.7. 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
- in performing unnecessary A RR queries in the case where no AAAA RR
- synthesis is required. A possible trade-off would be to perform them
- sequentially but with a very short interval between them, so if we
- obtain a fast reply, we avoid doing the additional query. (Note that
- this discussion is relevant only if the DNS64 function needs to
- perform external queries to fetch the RR. If the needed RR
- information is available locally, as in the case of an authoritative
- server, the issue is no longer relevant.)
-
-5.2. Generation of the IPv6 representations of IPv4 addresses
-
- 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]
-\f
-Internet-Draft DNS64 February 2010
-
-
- generation algorithms are the following:
-
- The same algorithm to create an IPv6 address from an IPv4 address
- MUST be used by both a DNS64 to create the IPv6 address to be
- returned in the synthetic AAAA RR from the IPv4 address contained
- in an original A RR, and by a IPv6/IPv4 translator to create the
- IPv6 address to be included in the source address field of the
- outgoing IPv6 packets from the IPv4 address included in the source
- address field of the incoming IPv4 packet.
-
- The algorithm MUST be reversible; i.e., it MUST be possible to
- derive the original IPv4 address from the IPv6 representation.
-
- The input for the algorithm MUST be limited to the IPv4 address,
- the IPv6 prefix (denoted Pref64::/n) used in the IPv6
- representations and optionally a set of stable parameters that are
- configured in the DNS64 and in the NAT64 (such as fixed string to
- be used as a suffix).
-
- 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
- [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
- the value for the Well-Known prefix and needs to be confirmed
- whenis published as RFC.]][I-D.ietf-behave-address-format]
-
- A DNS64 MUST support the algorithm for generating IPv6
- representations of IPv4 addresses defined in Section 2 of
- [I-D.ietf-behave-address-format]. Moreover, the aforementioned
- algorithm MUST be the default algorithm used by the DNS64. While the
- normative description of the algorithm is provided in
- [I-D.ietf-behave-address-format], a sample description of the
- 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.1. PTR queries
-
- 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]
-\f
-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.
-
- 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.
-
- 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.
- a recursive nameserver MUST attempt to resolve the query as though it
- were any other (non-A/AAAA) query, and an authoritative server MUST
- respond authoritatively or with a referral, as appropriate.
-
-5.3.2. Handling the additional section
-
- DNS64 synthesis MUST NOT be performed on any records in the
- additional section of synthesized answers. The DNS64 MUST pass the
- additional section unchanged.
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 14]
-\f
-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
- in general no promise, however, that the additional section will
- contain all the relevant records, so any client that depends on the
- additional section being able to satisfy its needs (i.e. without
- additional queries) is necessarily broken. An IPv6-only client that
- needs a AAAA record, therefore, will send a query for the necessary
- AAAA record if it is unable to find such a record in the additional
- section of an answer it is consuming. For a correctly-functioning
- client, the effect would be no different if the additional section
- were empty.
-
- The alternative, of removing the A records in the additional section
- and replacing them with synthetic AAAA records, may cause a host
- behind a NAT64 to query directly a nameserver that is unaware of the
- NAT64 in question. The result in this case will be resolution
- failure anyway, only later in the resolution operation.
-
-5.3.3. Other 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.
-
-5.4. Assembling a synthesized response to a AAAA query
-
- A DNS64 uses different pieces of data to build the response returned
- to the querying client.
-
- The query that is used as the basis for synthesis results either in
- 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.
-
- 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.
-
-
-
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 15]
-\f
-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
- 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.
-
- The vDNS64 uses the presence of the DO and CD bits to make some
- decisions about what the query originator needs, and can react
- accordingly:
-
- 1. If CD is not set and DO is not set, vDNS64 SHOULD perform
- validation and do synthesis as needed.
-
- 2. If CD is not set and DO is set, then vDNS64 SHOULD perform
- validation. Whenever vDNS64 performs validation, it MUST
- validate the negative answer for AAAA queries before proceeding
- to query for A records for the same name, in order to be sure
- that there is not a legitimate AAAA record on the Internet.
- Failing to observe this step would allow an attacker to use DNS64
- as a mechanism to circumvent DNSSEC. If the negative response
- validates, and the response to the A query validates, then the
- vDNS64 MAY perform synthesis and SHOULD set the AD bit in the
- 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
- 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
- bit. If the data does not validate, the vDNS64 MUST respond with
- RCODE=2 (Server failure).
- A security-aware end point might take the presence of the AD bit
- as an indication that the data is valid, and may pass the DNS
- (and DNSSEC) data to an application. If the application attempts
- to validate the synthesized data, of course, the validation will
- fail. One could argue therefore that this approach is not
- desirable, but security aware stub resolvers must not place any
- reliance on data received from resolvers and validated on their
- behalf without certain criteria established by [RFC4035], section
- 4.9.3. An application that wants to perform validation on its
- own should use the CD bit.
-
- 3. If the CD bit is set and DO is set, then vDNS64 MAY perform
- validation, but MUST NOT perform synthesis. It MUST return the
- data to the query initiator, just like a regular recursive
- 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]
-\f
-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,
- this strategy means that any end point that wishes to do
- validation in a NAT64 context must be upgraded to be translation-
- aware as well.
-
-
-6. Deployment notes
-
- While DNS64 is intended to be part of a strategy for aiding IPv6
- deployment in an internetworking environment with some IPv4-only and
- IPv6-only networks, it is important to realise that it is
- incompatible with some things that may be deployed in an IPv4-only or
- dual-stack context.
-
-6.1. DNS resolvers and DNS64
-
- Full-service resolvers that are unaware of the DNS64 function can be
- (mis)configured to act as mixed-mode iterative and forwarding
- resolvers. In a native IPv4 context, this sort of configuration may
- appear to work. It is impossible to make it work properly without it
- being aware of the DNS64 function, because it will likely at some
- 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
- will be unable to answer the necessary AAAA queries.
-
-6.2. DNSSEC validators and DNS64
-
- Existing DNSSEC validators (i.e. that are unaware of DNS64) might
- reject all the data that comes from DNS64 as having been tampered
- with (even if it did not set CD when querying). If it is necessary
- to have validation behind the DNS64, then the validator must know how
- to perform the DNS64 function itself. Alternatively, the validating
- host may establish a trusted connection with a DNS64, and allow the
- DNS64 recursor to do all validation on its behalf.
-
-6.3. DNS64 and multihomed and dual-stack hosts
-
-6.3.1. IPv6 multihomed hosts
-
- Synthetic AAAA records may be constructed on the basis of the network
- context in which they were constructed. If a host sends DNS queries
- to resolvers in multiple networks, it is possible that some of them
- 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]
-\f
-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.
-
- 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
- interface. Hosts that attempt to use DNS answers globally may
- encounter surprising failures in these cases. For more discussion of
- this topic, see [I-D.savolainen-mif-dns-server-selection].
-
- Note that the issue is not that there are two interfaces, but that
- there are two networks involved. The same results could be achieved
- with a single interface routed to two different networks.
-
-6.3.2. Accidental dual-stack DNS64 use
-
- Similarly, suppose that i1 has IPv6 connectivity and can connect to
- the IPv4 Internet through NAT64, but i2 has native IPv4 connectivity.
- In this case, i1 could receive an IPv6 address from a synthetic AAAA
- 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.
-
-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
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 18]
-\f
-Internet-Draft DNS64 February 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
- cause the host to prefer to send packets via NAT64 instead of via
- native IPv4, with the associated loss of performance or functionality
- (or both) entailed by the NAT. At the same time, some hosts are not
- able to learn about DNS servers provisioned on IPv6 addresses, or
- simply cannot send DNS packets over IPv6.
-
-
-7. Deployment scenarios and examples
-
- In this section, we walk through some sample scenarios that are
- expected to be common deployment cases. It should be noted that this
- is provided for illustrative purposes and this section is not
- normative. The normative definition of DNS64 is provided in
- Section 5 and the normative definition of the address transformation
- algorithm is provided in [I-D.ietf-behave-address-format].
-
- There are two main different setups where DNS64 is expected to be
- used (other setups are possible as well, but these two are the main
- ones identified at the time of this writing).
-
- One possible setup that is expected to be common is the case of an
- end site or an ISP that is providing IPv6-only connectivity or
- connectivity to IPv6-only hosts that wants to allow the
- 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
- Internet and the DNS64 function is provided by the end site or the
- ISP.
-
- The other possible setup that is expected is an IPv4 site that
- wants that its IPv4 servers to be reachable from the IPv6
- Internet. This case is called IPv6-Internet-to-an-IPv4-network
- [I-D.ietf-behave-v6v4-framework]. It should be noted that the
- IPv4 addresses used in the IPv4 site can be either public or
- private. In this case, the IPv6/IPv4 translator is used to
- connect the IPv4 end site to the IPv6 Internet and the DNS64
- function is provided by the IPv4 end site itself.
-
- In this section we illustrate how the DNS64 behaves in the different
- scenarios that are expected to be common. We consider then 3
- possible scenarios, namely:
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 19]
-\f
-Internet-Draft DNS64 February 2010
-
-
- 1. An-IPv6-network-to-IPv4-Internet setup with DNS64 in DNS server
- mode
-
- 2. An-IPv6-network-to-IPv4-Internet setup with DNS64 in stub-
- resolver mode
-
- 3. IPv6-Internet-to-an-IPv4-network setup with DNS64 in DNS server
- mode
-
-7.1. Example of An-IPv6-network-to-IPv4-Internet setup with DNS64 in
- DNS server mode
-
- In this example, we consider an IPv6 node located in an IPv6-only
- site that initiates a communication to an IPv4 node located in the
- IPv4 Internet.
-
- The scenario for this case is depicted in the following figure:
-
-
- +---------------------+ +---------------+
- |IPv6 network | | IPv4 |
- | | +-------------+ | Network |
- | |--| Name server |--| |
- | | | with DNS64 | | +----+ |
- | +----+ | +-------------+ | | H2 | |
- | | H1 |---| | | +----+ |
- | +----+ | +-------+ | 192.0.2.1 |
- | |------| NAT64 |----| |
- | | +-------+ | |
- | | | | |
- +---------------------+ +---------------+
-
- The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
- address 192.0.2.1 and FQDN h2.example.com
-
- A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
- Internet. This IPv6/IPv4 Translator has an IPv4 address 203.0.113.1
- assigned to its IPv4 interface and it is using the WKP 64:FF9B::/96
- to create IPv6 representations of IPv4 addresses, as defined in
- [I-D.ietf-behave-address-format].
-
- The other element involved is the local name server. The name server
- is a dual-stack node, so that H1 can contact it via IPv6, while it
- can contact IPv4-only name servers via IPv4.
-
- The local name server is configured to represent the whole IPv4
- unicast space with using the WKP 64:FF9B::/96. For the purpose of
- this example, we assume it learns this through manual configuration.
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 20]
-\f
-Internet-Draft DNS64 February 2010
-
-
- For this example, assume the typical DNS situation where IPv6 hosts
- have only stub resolvers, and they are configured with the IP address
- of a name server that they always have to query and that performs
- recursive lookups (henceforth called "the recursive nameserver").
-
- The steps by which H1 establishes communication with H2 are:
-
- 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
- a DNS query for a AAAA record for H2 to the recursive name
- server. The recursive name server implements DNS64
- functionality.
-
- 2. The recursive name server resolves the query, and discovers that
- there are no AAAA records for H2.
-
- 3. The recursive name server queries for A records for H2 and gets
- back a single A records containing the IPv4 address 192.0.2.1.
- The name server then synthesizes a AAAA records. The IPv6
- address in the AAAA record contains the prefix assigned to the
- IPv6/IPv4 Translator in the upper 96 bits then the received IPv4
- address i.e. the resulting IPv6 address is 64:FF9B::192.0.2.1
-
- 4. H1 receives the synthetic AAAA record and sends a packet towards
- H2. The packet is sent to the destination address 64:FF9B::
- 192.0.2.1.
-
- 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
- translator and the subsequent communication flows by means of the
- IPv6/IPv4 translator mechanisms.
-
-7.2. An example of an-IPv6-network-to-IPv4-Internet setup with DNS64 in
- stub-resolver mode
-
- This case is depicted in the following figure:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 21]
-\f
-Internet-Draft DNS64 February 2010
-
-
- +---------------------+ +---------------+
- |IPv6 network | | IPv4 |
- | | +--------+ | Network |
- | |-----| Name |----| |
- | +-----+ | | server | | +----+ |
- | | H1 | | +--------+ | | H2 | |
- | |with |---| | | +----+ |
- | |DNS64| | +-------+ | 192.0.2.1 |
- | +----+ |------| NAT64 |----| |
- | | +-------+ | |
- | | | | |
- +---------------------+ +---------------+
-
-
- The figure shows an IPv6 node H1 implementing the DNS64 function and
- an IPv4 node H2 with IPv4 address 192.0.2.1 and FQDN h2.example.com
-
- A IPv6/IPv4 Translator connects the IPv6 network to the IPv4
- Internet. This IPv6/IPv4 Translator is using the WKP 64:FF9B::/96
- and an IPv4 address T 203.0.113.1 assigned to its IPv4 interface.
-
- H1 needs to know the prefix assigned to the local IPv6/IPv4
- Translator (64:FF9B::/96). For the purpose of this example, we
- assume it learns this through manual configuration.
-
- Also shown is a name server. For the purpose of this example, we
- assume that the name server is a dual-stack node, so that H1 can
- contact it via IPv6, while it can contact IPv4-only name servers via
- IPv4.
-
- For this example, assume the typical situation where IPv6 hosts have
- only stub resolvers and always query a name server that provides
- recursive lookups (henceforth called "the recursive name server").
- The recursive name server does not perform the DNS64 function.
-
- The steps by which H1 establishes communication with H2 are:
-
- 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
- a DNS query for a AAAA record for H2 to the recursive name
- server.
-
- 2. The recursive DNS server resolves the query, and returns the
- answer to H1. Because there are no AAAA records in the global
- DNS for H2, the answer is empty.
-
- 3. The stub resolver at H1 then queries for an A record for H2 and
- gets back an A record containing the IPv4 address 192.0.2.1. The
- DNS64 function within H1 then synthesizes a AAAA record. The
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 22]
-\f
-Internet-Draft DNS64 February 2010
-
-
- IPv6 address in the AAAA record contains the prefix assigned to
- the IPv6/IPv4 translator in the upper 96 bits, then the received
- IPv4 address i.e. the resulting IPv6 address is 64:FF9B::
- 192.0.2.1.
-
- 4. H1 sends a packet towards H2. The packet is sent to the
- destination address 64:FF9B::192.0.2.1.
-
- 5. The packet is routed to the IPv6 interface of the IPv6/IPv4
- translator and the subsequent communication flows using the IPv6/
- IPv4 translator mechanisms.
-
-7.3. Example of IPv6-Internet-to-an-IPv4-network setup DNS64 in DNS
- server mode
-
- In this example, we consider an IPv6 node located in the IPv6
- Internet that initiates a communication to an IPv4 node located in
- the IPv4 site.
-
- In some cases, this scenario can be addressed without using any form
- of DNS64 function. This is so because in principle it is possible to
- assign a fixed IPv6 address to each of the IPv4 nodes. Such an IPv6
- address would be constructed using the address transformation
- algorithm defined in [I-D.ietf-behave-address-format] that takes as
- input the Pref64::/96 and the IPv4 address of the IPv4 node. Note
- that the IPv4 address can be a public or a private address; the
- latter does not present any additional difficulty, since an NSP must
- be used as Pref64::/96 (in this scenario the usage of the Well-Known
- prefix is not supported as discussed in
- [I-D.ietf-behave-address-format]). Once these IPv6 addresses have
- been assigned to represent the IPv4 nodes in the IPv6 Internet, real
- AAAA RRs containing these addresses can be published in the DNS under
- the site's domain. This is the recommended approach to handle this
- scenario, because it does not involve synthesizing AAAA records at
- the time of query.
-
- However, there are some more dynamic scenarios, where synthesizing
- AAAA RRs in this setup may be needed. In particular, when DNS Update
- [RFC2136] is used in the IPv4 site to update the A RRs for the IPv4
- nodes, there are two options: One option is to modify the DNS server
- that receives the dynamic DNS updates. That would normally be the
- authoritative server for the zone. So the authoritative zone would
- have normal AAAA RRs that are synthesized as dynamic updates occur.
- The other option is modify all the authoritative servers to generate
- synthetic AAAA records for a zone, possibly based on additional
- constraints, upon the receipt of a DNS query for the AAAA RR. The
- first option -- in which the AAAA is synthesized when the DNS update
- message is received, and the data published in the relevant zone --
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 23]
-\f
-Internet-Draft DNS64 February 2010
-
-
- is recommended over the second option (i.e. the synthesis upon
- receipt of the AAAA DNS query). This is because it is usually easier
- to solve problems of misconfiguration and so on when the DNS
- responses are not being generated dynamically. However, it may be
- the case where the primary server (that receives all the updates)
- cannot be upgraded for whatever reason, but where a secondary can be
- upgraded in order to handle the (comparatively small amount) of AAAA
- queries. In such case, it is possible to use the DNS64 as described
- next. The DNS64 behavior that we describe in this section covers the
- case of synthesizing the AAAA RR when the DNS query arrives.
-
- The scenario for this case is depicted in the following figure:
-
-
- +-----------+ +----------------------+
- | | | IPv4 site |
- | IPv6 | +-------+ | +----+ |
- | Internet |------| NAT64 |-----|---| H2 | |
- | | +-------+ | +----+ |
- | | | | 192.0.2.1 |
- | | +------------+ | |
- | |----| Name server|--| |
- | | | with DNS64 | | |
- +-----------+ +------------+ | |
- | | | |
- +----+ | |
- | H1 | +----------------------+
- +----+
-
- The figure shows an IPv6 node H1 and an IPv4 node H2 with IPv4
- address X 192.0.2.1 and FQDN h2.example.com.
-
- A IPv6/IPv4 translator connects the IPv4 network to the IPv6
- Internet. This IPv6/IPv4 translator has a NSP 2001:DB8::/96.
-
- Also shown is the authoritative name server for the local domain with
- DNS64 functionality. For the purpose of this example, we assume that
- the name server is a dual-stack node, so that H1 or a recursive
- resolver acting on the request of H1 can contact it via IPv6, while
- it can be contacted by IPv4-only nodes to receive dynamic DNS updates
- via IPv4.
-
- The local name server needs to know the prefix assigned to the local
- IPv6/IPv4 Translator (2001:DB8::/96). For the purpose of this
- example, we assume it learns this through manual configuration.
-
- The steps by which H1 establishes communication with H2 are:
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 24]
-\f
-Internet-Draft DNS64 February 2010
-
-
- 1. H1 does a DNS lookup for h2.example.com. H1 does this by sending
- a DNS query for a AAAA record for H2. The query is eventually
- forwarded to the server in the IPv4 site.
-
- 2. The local DNS server resolves the query (locally), and discovers
- that there are no AAAA records for H2.
-
- 3. The name server verifies that h2.example.com and its A RR are
- among those that the local policy defines as allowed to generate
- a AAAA RR from. If that is the case, the name server synthesizes
- a AAAA record from the A RR and the prefix 2001:DB8::/96. The
- IPv6 address in the AAAA record is 2001:DB8::192.0.2.1.
-
- 4. H1 receives the synthetic AAAA record and sends a packet towards
- H2. The packet is sent to the destination address 2001:DB8::
- 192.0.2.1.
-
- 5. The packet is routed through the IPv6 Internet to the IPv6
- interface of the IPv6/IPv4 translator and the communication flows
- using the IPv6/IPv4 translator mechanisms.
-
-
-8. Security Considerations
-
- See the discussion on the usage of DNSSEC and DNS64 described in
- section 3, section 5.5, and section 6.2. .
-
-
-9. IANA Considerations
-
- This memo makes no request of IANA.
-
-
-10. Contributors
-
- Dave Thaler
-
- Microsoft
-
- dthaler@windows.microsoft.com
-
-
-11. Acknowledgements
-
- 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,
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 25]
-\f
-Internet-Draft DNS64 February 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.
-
- Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by
- Trilogy, a research project supported by the European Commission
- under its Seventh Framework Program.
-
-
-12. References
-
-12.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
- (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
- RFC 4787, January 2007.
-
- [I-D.ietf-behave-address-format]
- Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
- Li, "IPv6 Addressing of IPv4/IPv6 Translators",
- draft-ietf-behave-address-format-04 (work in progress),
- January 2010.
-
-12.2. Informative References
-
- [I-D.ietf-behave-v6v4-xlate-stateful]
- Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
- NAT64: Network Address and Protocol Translation from IPv6
- Clients to IPv4 Servers",
- draft-ietf-behave-v6v4-xlate-stateful-08 (work in
- progress), January 2010.
-
- [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)",
- RFC 2136, April 1997.
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 26]
-\f
-Internet-Draft DNS64 February 2010
-
-
- [RFC3484] Draves, R., "Default Address Selection for Internet
- Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
- [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
- "DNS Extensions to Support IP Version 6", RFC 3596,
- October 2003.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [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),
- February 2010.
-
- [I-D.venaas-behave-mcast46]
- Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An
- IPv4 - IPv6 multicast translator",
- draft-venaas-behave-mcast46-01 (work in progress),
- July 2009.
-
- [I-D.ietf-dnsop-default-local-zones]
- Andrews, M., "Locally-served DNS Zones",
- draft-ietf-dnsop-default-local-zones-09 (work in
- progress), November 2009.
-
- [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.
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 27]
-\f
-Internet-Draft DNS64 February 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:
-
- An IPv4-only server application (e.g. web server software) is
- running on a dual-stack host. There may also be dual-stack server
- applications also running on the same host. That host has fully
- routable IPv4 and IPv6 addresses and hence the authoritative DNS
- server has an A and a AAAA record as a result.
-
- An IPv6-only client (regardless of whether the client application
- is IPv6-only, the client stack is IPv6-only, or it only has an
- IPv6 address) wants to access the above server.
-
- The client issues a DNS query to a DNS64 resolver.
-
- If the DNS64 only generates a synthetic AAAA if there's no real AAAA,
- then the communication will fail. Even though there's a real AAAA,
- the only way for communication to succeed is with the translated
- address. So, in order to support this scenario, the administrator of
- 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
- exist is that translated connectivity may be preferred over native
- connectivity in some cases where the DNS64 is operated in DNS server
- mode.
-
- RFC3484 [RFC3484] rules use longest prefix match to select the
- preferred destination address to use. So, if the DNS64 resolver
- returns both the synthetic AAAA RRs and the real AAAA RRs, then if
- the DNS64 is operated by the same domain as the initiating host, and
- a global unicast prefix (called an NSP in
- [I-D.ietf-behave-address-format]) is used, then a synthetic AAAA RR
- is likely to be preferred.
-
- 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 "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]
-\f
-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
- 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
- through native connectivity. If the Well-Known Prefix is used,
- the longest prefix match rule will select native connectivity.
-
- So this option introduces problems in the following cases:
-
- An IPv6 network to the IPv4 internet with an NSP
-
- IPv6 to IPv4 in the same network when reaching external
- destinations and an NSP is used.
-
- In any case, the problem can be solved by properly configuring the
- RFC3484 [RFC3484] policy table, but this requires effort on the part
- of the site operator.
-
-
-Authors' Addresses
-
- Marcelo Bagnulo
- UC3M
- Av. Universidad 30
- Leganes, Madrid 28911
- Spain
-
- Phone: +34-91-6249500
- Fax:
- Email: marcelo@it.uc3m.es
- URI: http://www.it.uc3m.es/marcelo
-
-
- Andrew Sullivan
- Shinkuro
- 4922 Fairmont Avenue, Suite 250
- Bethesda, MD 20814
- USA
-
- Phone: +1 301 961 3131
- Email: ajs@shinkuro.com
-
-
-
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 29]
-\f
-Internet-Draft DNS64 February 2010
-
-
- Philip Matthews
- Unaffiliated
- 600 March Road
- Ottawa, Ontario
- Canada
-
- Phone: +1 613-592-4343 x224
- Fax:
- Email: philip_matthews@magma.ca
- URI:
-
-
- Iljitsch van Beijnum
- IMDEA Networks
- Av. Universidad 30
- Leganes, Madrid 28911
- Spain
-
- Phone: +34-91-6246245
- Email: iljitsch@muada.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bagnulo, et al. Expires August 19, 2010 [Page 30]
-\f
+++ /dev/null
-
-
-
-Network Working Group S. Weiler
-Internet-Draft SPARTA, Inc.
-Updates: 4033, 4034, 4035, 5155 D. Blacka
-(if approved) VeriSign, Inc.
-Intended status: Standards Track September 5, 2009
-Expires: March 9, 2010
-
-
- Clarifications and Implementation Notes for DNSSECbis
- draft-ietf-dnsext-dnssec-bis-updates-09
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on March 9, 2010.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-Abstract
-
- This document is a collection of technical clarifications to the
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 1]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
- DNSSECbis document set. It is meant to serve as a resource to
- implementors as well as a repository of DNSSECbis errata.
-
-
-Table of Contents
-
- 1. Introduction and Terminology . . . . . . . . . . . . . . . . . 3
- 1.1. Structure of this Document . . . . . . . . . . . . . . . . 3
- 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Important Additions to DNSSSECbis . . . . . . . . . . . . . . 3
- 2.1. NSEC3 Support . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2. SHA-256 Support . . . . . . . . . . . . . . . . . . . . . 3
- 3. Security Concerns . . . . . . . . . . . . . . . . . . . . . . 4
- 3.1. Clarifications on Non-Existence Proofs . . . . . . . . . . 4
- 3.2. Validating Responses to an ANY Query . . . . . . . . . . . 4
- 3.3. Check for CNAME . . . . . . . . . . . . . . . . . . . . . 5
- 3.4. Insecure Delegation Proofs . . . . . . . . . . . . . . . . 5
- 4. Interoperability Concerns . . . . . . . . . . . . . . . . . . 5
- 4.1. Errors in Canonical Form Type Code List . . . . . . . . . 5
- 4.2. Unknown DS Message Digest Algorithms . . . . . . . . . . . 5
- 4.3. Private Algorithms . . . . . . . . . . . . . . . . . . . . 6
- 4.4. Caution About Local Policy and Multiple RRSIGs . . . . . . 7
- 4.5. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 7
- 4.6. Setting the DO Bit on Replies . . . . . . . . . . . . . . 7
- 4.7. Setting the AD bit on Replies . . . . . . . . . . . . . . 7
- 4.8. Setting the CD bit on Requests . . . . . . . . . . . . . . 8
- 4.9. Nested Trust Anchors . . . . . . . . . . . . . . . . . . . 8
- 5. Minor Corrections and Clarifications . . . . . . . . . . . . . 8
- 5.1. Finding Zone Cuts . . . . . . . . . . . . . . . . . . . . 8
- 5.2. Clarifications on DNSKEY Usage . . . . . . . . . . . . . . 9
- 5.3. Errors in Examples . . . . . . . . . . . . . . . . . . . . 9
- 5.4. Errors in RFC 5155 . . . . . . . . . . . . . . . . . . . . 9
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
- Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 2]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
-1. Introduction and Terminology
-
- This document lists some additions, clarifications and corrections to
- the core DNSSECbis specification, as originally described in
- [RFC4033], [RFC4034], and [RFC4035].
-
- It is intended to serve as a resource for implementors and as a
- repository of items that need to be addressed when advancing the
- DNSSECbis documents from Proposed Standard to Draft Standard.
-
-1.1. Structure of this Document
-
- The clarifications to DNSSECbis are sorted according to their
- importance, starting with ones which could, if ignored, lead to
- security problems and progressing down to clarifications that are
- expected to have little operational impact.
-
-1.2. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-
-2. Important Additions to DNSSSECbis
-
- This section updates the set of core DNSSEC protocol documents
- originally specified in Section 10 of [RFC4033].
-
-2.1. NSEC3 Support
-
- [RFC5155] describes the use and behavior of the NSEC3 and NSEC3PARAM
- records for hashed denial of existence. Validator implementations
- are strongly encouraged to include support for NSEC3 because a number
- of highly visible zones are expected to use it. Validators that do
- not support validation of responses using NSEC3 will likely be
- hampered in validating large portions of the DNS space.
-
- [RFC5155] should be considered part of the DNS Security Document
- Family as described by [RFC4033], Section 10.
-
-2.2. SHA-256 Support
-
- [RFC4509] describes the use of SHA-256 as a digest algorithm for use
- with Delegation Signer (DS) RRs. [I-D.ietf-dnsext-dnssec-rsasha256]
- describes the use of the RSASHA256 algorithm for use in DNSKEY and
- RRSIG RRs. Validator implementations are strongly encouraged to
- include support for this algorithm for DS, DNSKEY, and RRSIG records.
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 3]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
- Both [RFC4509] and [I-D.ietf-dnsext-dnssec-rsasha256] should also be
- considered part of the DNS Security Document Family as described by
- [RFC4033], Section 10.
-
-
-3. Security Concerns
-
- This section provides clarifications that, if overlooked, could lead
- to security issues.
-
-3.1. Clarifications on Non-Existence Proofs
-
- [RFC4035] Section 5.4 under-specifies the algorithm for checking non-
- existence proofs. In particular, the algorithm as presented would
- incorrectly allow an NSEC or NSEC3 RR from an ancestor zone to prove
- the non-existence of RRs in the child zone.
-
- An "ancestor delegation" NSEC RR (or NSEC3 RR) is one with:
-
- o the NS bit set,
- o the SOA bit clear, and
- o a signer field that is shorter than the owner name of the NSEC RR,
- or the original owner name for the NSEC3 RR.
-
- Ancestor delegation NSEC or NSEC3 RRs MUST NOT be used to assume non-
- existence of any RRs below that zone cut, which include all RRs at
- that (original) owner name other than DS RRs, and all RRs below that
- owner name regardless of type.
-
- Similarly, the algorithm would also allow an NSEC RR at the same
- owner name as a DNAME RR, or an NSEC3 RR at the same original owner
- name as a DNAME, to prove the non-existence of names beneath that
- DNAME. An NSEC or NSEC3 RR with the DNAME bit set MUST NOT be used
- to assume the non-existence of any subdomain of that NSEC/NSEC3 RR's
- (original) owner name.
-
-3.2. Validating Responses to an ANY Query
-
- [RFC4035] does not address how to validate responses when QTYPE=*.
- As described in Section 6.2.2 of [RFC1034], a proper response to
- QTYPE=* may include a subset of the RRsets at a given name. That is,
- it is not necessary to include all RRsets at the QNAME in the
- response.
-
- When validating a response to QTYPE=*, all received RRsets that match
- QNAME and QCLASS MUST be validated. If any of those RRsets fail
- validation, the answer is considered Bogus. If there are no RRsets
- matching QNAME and QCLASS, that fact MUST be validated according to
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 4]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
- the rules in [RFC4035] Section 5.4 (as clarified in this document).
- To be clear, a validator must not expect to receive all records at
- the QNAME in response to QTYPE=*.
-
-3.3. Check for CNAME
-
- Section 5 of [RFC4035] says little about validating responses based
- on (or that should be based on) CNAMEs. When validating a NOERROR/
- NODATA response, validators MUST check the CNAME bit in the matching
- NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
- type. Without this check, an attacker could successfully transform a
- positive CNAME response into a NOERROR/NODATA response.
-
-3.4. Insecure Delegation Proofs
-
- [RFC4035] Section 5.2 specifies that a validator, when proving a
- delegation is not secure, needs to check for the absence of the DS
- and SOA bits in the NSEC (or NSEC3) type bitmap. The validator also
- needs to check for the presence of the NS bit in the matching NSEC
- (or NSEC3) RR (proving that there is, indeed, a delegation), or
- alternately make sure that the delegation is covered by an NSEC3 RR
- with the Opt-Out flag set. If this is not checked, spoofed unsigned
- delegations might be used to claim that an existing signed record is
- not signed.
-
-
-4. Interoperability Concerns
-
-4.1. Errors in Canonical Form Type Code List
-
- When canonicalizing DNS names, DNS names in the RDATA section of NSEC
- and RRSIG resource records are not downcased.
-
- [RFC4034] Section 6.2 item 3 has a list of resource record types for
- which DNS names in the RDATA are downcased for purposes of DNSSEC
- canonical form (for both ordering and signing). That list
- erroneously contains NSEC and RRSIG. According to [RFC3755], DNS
- names in the RDATA of NSEC and RRSIG should not be downcased.
-
- The same section also erroneously lists HINFO, and twice at that.
- Since HINFO records contain no domain names, they are not subject to
- downcasing.
-
-4.2. Unknown DS Message Digest Algorithms
-
- Section 5.2 of [RFC4035] includes rules for how to handle delegations
- to zones that are signed with entirely unsupported public key
- algorithms, as indicated by the key algorithms shown in those zone's
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 5]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
- DS RRsets. It does not explicitly address how to handle DS records
- that use unsupported message digest algorithms. In brief, DS records
- using unknown or unsupported message digest algorithms MUST be
- treated the same way as DS records referring to DNSKEY RRs of unknown
- or unsupported public key algorithms.
-
- The existing text says:
-
- If the validator does not support any of the algorithms listed in
- an authenticated DS RRset, then the resolver has no supported
- authentication path leading from the parent to the child. The
- resolver should treat this case as it would the case of an
- authenticated NSEC RRset proving that no DS RRset exists, as
- described above.
-
- To paraphrase the above, when determining the security status of a
- zone, a validator disregards any DS records listing unknown or
- unsupported algorithms. If none are left, the zone is treated as if
- it were unsigned.
-
- Modified to consider DS message digest algorithms, a validator also
- disregards any DS records using unknown or unsupported message digest
- algorithms.
-
-4.3. Private Algorithms
-
- As discussed above, section 5.2 of [RFC4035] requires that validators
- make decisions about the security status of zones based on the public
- key algorithms shown in the DS records for those zones. In the case
- of private algorithms, as described in [RFC4034] Appendix A.1.1, the
- eight-bit algorithm field in the DS RR is not conclusive about what
- algorithm(s) is actually in use.
-
- If no private algorithms appear in the DS set or if any supported
- algorithm appears in the DS set, no special processing will be
- needed. In the remaining cases, the security status of the zone
- depends on whether or not the resolver supports any of the private
- algorithms in use (provided that these DS records use supported hash
- functions, as discussed in Section 4.2). In these cases, the
- resolver MUST retrieve the corresponding DNSKEY for each private
- algorithm DS record and examine the public key field to determine the
- algorithm in use. The security-aware resolver MUST ensure that the
- hash of the DNSKEY RR's owner name and RDATA matches the digest in
- the DS RR. If they do not match, and no other DS establishes that
- the zone is secure, the referral should be considered Bogus data, as
- discussed in [RFC4035].
-
- This clarification facilitates the broader use of private algorithms,
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 6]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
- as suggested by [RFC4955].
-
-4.4. Caution About Local Policy and Multiple RRSIGs
-
- When multiple RRSIGs cover a given RRset, [RFC4035] Section 5.3.3
- suggests that "the local resolver security policy determines whether
- the resolver also has to test these RRSIG RRs and how to resolve
- conflicts if these RRSIG RRs lead to differing results." In most
- cases, a resolver would be well advised to accept any valid RRSIG as
- sufficient. If the first RRSIG tested fails validation, a resolver
- would be well advised to try others, giving a successful validation
- result if any can be validated and giving a failure only if all
- RRSIGs fail validation.
-
- If a resolver adopts a more restrictive policy, there's a danger that
- properly-signed data might unnecessarily fail validation, perhaps
- because of cache timing issues. Furthermore, certain zone management
- techniques, like the Double Signature Zone-signing Key Rollover
- method described in section 4.2.1.2 of [RFC4641] might not work
- reliably.
-
-4.5. Key Tag Calculation
-
- [RFC4034] Appendix B.1 incorrectly defines the Key Tag field
- calculation for algorithm 1. It correctly says that the Key Tag is
- the most significant 16 of the least significant 24 bits of the
- public key modulus. However, [RFC4034] then goes on to incorrectly
- say that this is 4th to last and 3rd to last octets of the public key
- modulus. It is, in fact, the 3rd to last and 2nd to last octets.
-
-4.6. Setting the DO Bit on Replies
-
- [RFC4035] does not provide any instructions to servers as to how to
- set the DO bit. Some authoritative server implementations have
- chosen to copy the DO bit settings from the incoming query to the
- outgoing response. Others have chosen to never set the DO bit in
- responses. Either behavior is permitted. To be clear, in replies to
- queries with the DO-bit set servers may or may not set the DO bit.
-
-4.7. Setting the AD bit on Replies
-
- Section 3.2.3 of [RFC4035] describes under which conditions a
- validating resolver should set or clear the AD bit in a response. In
- order to protect legacy stub resolvers and middleboxes, validating
- resolvers SHOULD only set the AD bit when a response both meets the
- conditions listed in RFC 4035, section 3.2.3, and the request
- contained either a set DO bit or a set AD bit.
-
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 7]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
- Note that the use of the AD bit in the query was previously
- undefined. This document defines it as a signal indicating that the
- requester understands and is interested in the value of the AD bit in
- the response. This allows a requestor to indicate that it
- understands the AD bit without also requesting DNSSEC data via the DO
- bit.
-
-4.8. Setting the CD bit on Requests
-
- When processing a request with the CD bit set, the resolver MUST set
- the CD bit on its upstream queries.
-
-4.9. Nested Trust Anchors
-
- A DNSSEC validator may be configured such that, for a given response,
- more than one trust anchor could be used to validate the chain of
- trust to the response zone. For example, imagine a validator
- configured with trust anchors for "example." and "zone.example."
- When the validator is asked to validate a response to
- "www.sub.zone.example.", either trust anchor could apply.
-
- When presented with this situation, DNSSEC validators SHOULD try all
- applicable trust anchors until one succeeds.
-
- There are some scenarios where different behaviors, such as choosing
- the trust anchor closest to the QNAME of the response, may be
- desired. A DNSSEC validator MAY enable such behaviors as
- configurable overrides.
-
-
-5. Minor Corrections and Clarifications
-
-5.1. Finding Zone Cuts
-
- Appendix C.8 of [RFC4035] discusses sending DS queries to the servers
- for a parent zone. To do that, a resolver may first need to apply
- special rules to discover what those servers are.
-
- As explained in Section 3.1.4.1 of [RFC4035], security-aware name
- servers need to apply special processing rules to handle the DS RR,
- and in some situations the resolver may also need to apply special
- rules to locate the name servers for the parent zone if the resolver
- does not already have the parent's NS RRset. Section 4.2 of
- [RFC4035] specifies a mechanism for doing that.
-
-
-
-
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 8]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
-5.2. Clarifications on DNSKEY Usage
-
- Questions of the form "can I use a different DNSKEY for signing this
- RRset" have occasionally arisen.
-
- The short answer is "yes, absolutely". You can even use a different
- DNSKEY for each RRset in a zone, subject only to practical limits on
- the size of the DNSKEY RRset. However, be aware that there is no way
- to tell resolvers what a particularly DNSKEY is supposed to be used
- for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
- authenticate any RRset in the zone. For example, if a weaker or less
- trusted DNSKEY is being used to authenticate NSEC RRsets or all
- dynamically updated records, that same DNSKEY can also be used to
- sign any other RRsets from the zone.
-
- Furthermore, note that the SEP bit setting has no effect on how a
- DNSKEY may be used -- the validation process is specifically
- prohibited from using that bit by [RFC4034] section 2.1.2. It is
- possible to use a DNSKEY without the SEP bit set as the sole secure
- entry point to the zone, yet use a DNSKEY with the SEP bit set to
- sign all RRsets in the zone (other than the DNSKEY RRset). It's also
- possible to use a single DNSKEY, with or without the SEP bit set, to
- sign the entire zone, including the DNSKEY RRset itself.
-
-5.3. Errors in Examples
-
- The text in [RFC4035] Section C.1 refers to the examples in B.1 as
- "x.w.example.com" while B.1 uses "x.w.example". This is painfully
- obvious in the second paragraph where it states that the RRSIG labels
- field value of 3 indicates that the answer was not the result of
- wildcard expansion. This is true for "x.w.example" but not for
- "x.w.example.com", which of course has a label count of 4
- (antithetically, a label count of 3 would imply the answer was the
- result of a wildcard expansion).
-
- The first paragraph of [RFC4035] Section C.6 also has a minor error:
- the reference to "a.z.w.w.example" should instead be "a.z.w.example",
- as in the previous line.
-
-5.4. Errors in RFC 5155
-
- A NSEC3 record that matches an Empty Non-Terminal effectively has no
- type associated with it. This NSEC3 record has an empty type bit
- map. Section 3.2.1 of [RFC5155] contains the statement:
-
- Blocks with no types present MUST NOT be included.
-
- However, the same section contains a regular expression:
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 9]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
- Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
- The plus sign in the regular expression indicates that there is one
- or more of the preceding element. This means that there must be at
- least one window block. If this window block has no types, it
- contradicts with the first statement. Therefore, the correct text in
- RFC 5155 3.2.1 should be:
-
- Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )*
-
-
-6. IANA Considerations
-
- This document specifies no IANA Actions.
-
-
-7. Security Considerations
-
- This document adds two cryptographic features to the core DNSSEC
- protocol. Additionally, it addresses some ambiguities and omissions
- in the core DNSSEC documents that, if not recognized and addressed in
- implementations, could lead to security failures. In particular, the
- validation algorithm clarifications in Section 3 are critical for
- preserving the security properties DNSSEC offers. Furthermore,
- failure to address some of the interoperability concerns in Section 4
- could limit the ability to later change or expand DNSSEC, including
- adding new algorithms.
-
-
-8. References
-
-8.1. Normative References
-
- [I-D.ietf-dnsext-dnssec-rsasha256]
- Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY
- and RRSIG Resource Records for DNSSEC",
- draft-ietf-dnsext-dnssec-rsasha256-14 (work in progress),
- June 2009.
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- RFC 1034, STD 13, November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, BCP 14, March 1997.
-
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 10]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
- Security (DNSSEC) Hashed Authenticated Denial of
- Existence", RFC 5155, March 2008.
-
-8.2. Informative References
-
- [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer (DS)", RFC 3755, May 2004.
-
- [RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
- RFC 4641, September 2006.
-
- [RFC4955] Blacka, D., "DNS Security (DNSSEC) Experiments", RFC 4955,
- July 2007.
-
-
-Appendix A. Acknowledgments
-
- The editors would like the thank Rob Austein for his previous work as
- an editor of this document.
-
- The editors are extremely grateful to those who, in addition to
- finding errors and omissions in the DNSSECbis document set, have
- provided text suitable for inclusion in this document.
-
- The lack of specificity about handling private algorithms, as
- described in Section 4.3, and the lack of specificity in handling ANY
- queries, as described in Section 3.2, were discovered by David
- Blacka.
-
- The error in algorithm 1 key tag calculation, as described in
- Section 4.5, was found by Abhijit Hayatnagarkar. Donald Eastlake
- contributed text for Section 4.5.
-
- The bug relating to delegation NSEC RR's in Section 3.1 was found by
- Roy Badami. Roy Arends found the related problem with DNAME.
-
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 11]
-\f
-Internet-Draft DNSSECbis Implementation Notes September 2009
-
-
- The errors in the [RFC4035] examples were found by Roy Arends, who
- also contributed text for Section 5.3 of this document.
-
- The editors would like to thank Ed Lewis, Danny Mayer, Olafur
- Gudmundsson, Suzanne Woolf, and Scott Rose for their substantive
- comments on the text of this document.
-
-
-Authors' Addresses
-
- Samuel Weiler
- SPARTA, Inc.
- 7110 Samuel Morse Drive
- Columbia, Maryland 21046
- US
-
- Email: weiler@tislabs.com
-
-
- David Blacka
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Email: davidb@verisign.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Blacka Expires March 9, 2010 [Page 12]
-\f
+++ /dev/null
-DNS Extensions working group V.Dolmatov, Ed.
-Internet-Draft Cryptocom Ltd.
-Intended status: Standards Track December 12, 2009
-Expires: June 12, 2010
-
-
- Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records
- for DNSSEC
- draft-ietf-dnsext-dnssec-gost-06
-
-Status of this Memo
-
- This Internet-Draft is submitted to IETF in full conformance with the
- provisions of BCP 78 and BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on June 12 2010.
-
-Copyright Notice
-
- Copyright (c) 2009 IETF Trust and the persons identified as the
- document authors. All rights reserved.
-
- This document is subject to BCP 78 and the IETF Trust's Legal
- Provisions Relating to IETF Documents in effect on the date of
- publication of this document (http://trustee.ietf.org/license-info).
- Please review these documents carefully, as they describe your rights
- and restrictions with respect to this document.
-
-Abstract
-
- This document describes how to produce 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]\f
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
- 2.1. Using a public key with existing cryptographic libraries. . 3
- 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . 3
- 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4
- 3.1 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 4
- 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5
- 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5
- 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5
- 5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . 5
- 6. Implementation Considerations . . . . . . . . . . . . . . . . . 5
- 6.1. Support for GOST signatures . . . . . . . . . . . . . . . . 5
- 6.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 5
- 6.3. Byte order . . . . . . . . . . . . . . . . . . . . . . . . 5
- 7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
- 10.2. Informative References . . . . . . . . . . . . . . . . . . 7
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical distributed
- database for Internet Naming. The DNS has been extended to use
- cryptographic keys and digital signatures for the verification of the
- authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034
- [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
- Extensions, called DNSSEC.
-
- RFC 4034 describes how to store DNSKEY and RRSIG resource records,
- and specifies a list of cryptographic algorithms to use. This
- document extends that list with the signature and hash algorithms
- GOST [GOST3410, GOST3411],
- and specifies how to store DNSKEY data and how to produce
- RRSIG resource records with these hash algorithms.
-
- Familiarity with DNSSEC and GOST signature and hash
- algorithms is assumed in this document.
-
- The term "GOST" is not officially defined, but is usually used to
- refer to the collection of the Russian cryptographic algorithms
- GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89.
- Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to
- the GOST R 34.10-2001 and GOST R 34.11-94 in this document.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
-V.Dolmatov Expires June 12, 2010 [Page 2]\f
-
-2. DNSKEY Resource Records
-
- The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
-
- GOST R 34.10-2001 public keys are stored with the algorithm number
- {TBA1}.
-
- The wire format of the public key is compatible with
- RFC 4491 [RFC4491]:
-
- According to [GOST3410], a public key is a point on the elliptic
- curve Q = (x,y).
-
- The wire representation of a public key MUST contain 64 octets,
- where the first 32 octets contain the little-endian representation
- of x and the second 32 octets contain the little-endian
- representation of y.
- This corresponds to the binary representation of (<y>256||<x>256)
- from [GOST3410], ch. 5.3.
-
- Corresponding public key parameters are those identified by
- id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
- and the digest parameters are those identified by
- id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
-
-2.1. Using a public key with existing cryptographic libraries
-
- Existing GOST-aware cryptographic libraries at the time of this
- document writing are capable to read GOST public keys via a generic
- X509 API if the key is encoded according to RFC 4491 [RFC4491],
- section 2.3.2.
-
- To make this encoding from the wire format of a GOST public key
- with the parameters used in this document, prepend the 64 octets
- of key data with the following 37-byte sequence:
-
- 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
- 0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
- 0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
-
-2.2. GOST DNSKEY RR Example
-
- Given a private key with the following value (the value of GostAsn1
- field is split here into two lines to simplify reading; in the
- private key file it must be in one line):
-
- Private-key-format: v1.2
- Algorithm: {TBA1} (GOST)
- GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c
- t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA=
-
-
-V.Dolmatov Expires June 12, 2010 [Page 3]\f
-
- The following DNSKEY RR stores a DNS zone key for example.net
-
- example.net. 86400 IN DNSKEY 256 3 {TBA1} (
- GtTJjmZKUXV+lHLG/6crB6RCR+EJR51Islpa
- 6FqfT0MUfKhSn1yAo92+LJ0GDssTiAnj0H0I
- 9Jrfial/yyc5Og==
- ) ; key id = 10805
-
-3. RRSIG Resource Records
-
- The value of the signature field in the RRSIG RR follows RFC 4490
- [RFC4490] and is calculated as follows. The values for the RDATA
- fields that precede the signature data are specified
- in RFC 4034 [RFC4034].
-
- hash = GOSTR3411(data)
-
- where "data" is the wire format data of the resource record set
- that is signed, as specified in RFC 4034 [RFC4034].
-
- Hash MUST be calculated with GOST R 34.11-94 parameters identified
- by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
- Signature is calculated from the hash according to the
- GOST R 34.10-2001 standard and its wire format is compatible with
- RFC 4490 [RFC4490].
-
- Quoting RFC 4490:
-
- "The signature algorithm GOST R 34.10-2001 generates a digital
- signature in the form of two 256-bit numbers, r and s. Its octet
- string representation consists of 64 octets, where the first 32
- octets contain the big-endian representation of s and the second 32
- octets contain the big-endian representation of r."
-
-3.1. RRSIG RR Example
-
- With the private key from section 2.2 sign the following RRSet,
- consisting of one A record:
-
- www.example.net. 3600 IN A 192.0.2.1
-
- Setting the inception date to 2000-01-01 00:00:00 UTC and the
- expiration date to 2030-01-01 00:00:00 UTC, the following signature
- should be created (assuming {TBA1}==249 until proper code is
- assigned by IANA)
-
- www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 (
- 20000101000000 10805 example.net.
- k3m0r5bm6kFQmcRlHshY3jIj7KL6KTUsPIAp
- Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W
- HRFSm0XS5YST5g== )
-
-V.Dolmatov Expires June 12, 2010 [Page 4]\f
-
- Note: Several GOST signatures calculated for the same message text
- differ because of using of a random element is used in signature
- generation process.
-
-4. DS Resource Records
-
- GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest
- type {TBA2}.The wire format of a digest value is compatible with
- RFC4490 [RFC4490], that is digest is in little-endian representation.
-
-
- The digest MUST always be calculated with GOST R 34.11-94 parameters
- identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
-
-4.1. DS RR Example
-
- For key signing key (assuming {TBA1}==249 until proper code is
- assigned by IANA)
-
- example.net. 86400 DNSKEY 257 3 {TBA1} (
- 1aYdqrVz3JJXEURLMdmeI7H1CyTFfPVFBIGA
- EabZFP+7NT5KPYXzjDkRbPWleEFbBilDNQNi
- q/q4CwA4WR+ovg==
- ) ; key id = 6204
-
- The DS RR will be
-
- example.net. 3600 IN DS 6204 {TBA1} {TBA2} (
- 0E6D6CB303F89DBCF614DA6E21984F7A62D08BDD0A05B3A22CC63D1B
- 553BC61E )
-
-5. Deployment Considerations
-
-5.1. Key Sizes
-
- According to RFC4357 [RFC4357], the key size of GOST public keys
- MUST be 512 bits.
-
-5.2. Signature Sizes
-
- According to the GOST signature algorithm specification [GOST3410],
- the size of a GOST signature is 512 bits.
-
-5.3. Digest Sizes
-
- According to the GOST R 34.11-94 [GOST3411], the size of a GOST
- digest is 256 bits.
-
-6. Implementation Considerations
-
-6.1. Support for GOST signatures
-
- DNSSEC aware implementations SHOULD be able to support RRSIG and
- DNSKEY resource records created with the GOST algorithms as
- defined in this document.
-
-V.Dolmatov Expires June 12, 2010 [Page 5]\f
-
-6.2. Support for NSEC3 Denial of Existence
-
- Any DNSSEC-GOST implementation is required to have either NSEC or
- NSEC3 support.
-
-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.
-
-7. Security considerations
-
- Currently, the cryptographic resistance of the GOST 34.10-2001
- digital signature algorithm is estimated as 2**128 operations
- of multiple elliptic curve point computations on prime modulus
- of order 2**256.
-
-
- Currently, the cryptographic resistance of GOST 34.11-94 hash
- algorithm is estimated as 2**128 operations of computations of a
- step hash function. (There is known method to reduce this
- estimate to 2**105 operations, but it demands padding the
- colliding message with 1024 random bit blocks each of 256 bit
- length, thus it cannot be used in any practical implementation).
-
-8. IANA Considerations
-
- This document updates the IANA registry "DNS Security Algorithm
- 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
-
- 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
- algorithm:
-
- Value Algorithm Status
- {TBA2} GOST R 34.11-94 OPTIONAL
-
-9. Acknowledgments
-
- This document is a minor extension to RFC 4034 [RFC4034]. Also, we
- tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
- and RFC 4357 [RFC4357] for consistency. The authors of and
- contributors to these documents are gratefully acknowledged for
- their hard work.
-
-V.Dolmatov Expires June 12, 2010 [Page 6]\f
-
- The following people provided additional feedback and text: Dmitry
- Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen
- and Wouter Wijngaards.
-
-
-10. References
-
-10.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [RFC3110] Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
- Name System (DNS)", RFC 3110, May 2001.
-
- [RFC4033] Arends R., Austein R., Larson M., Massey D., and S.
- Rose, "DNS Security Introduction and Requirements",
- RFC 4033, March 2005.
-
- [RFC4034] Arends R., Austein R., Larson M., Massey D., and S.
- Rose, "Resource Records for the DNS Security Extensions",
- RFC 4034, March 2005.
-
- [RFC4035] Arends R., Austein R., Larson M., Massey D., and S.
- Rose, "Protocol Modifications for the DNS Security
- Extensions", RFC 4035, March 2005.
-
- [GOST3410] "Information technology. Cryptographic data security.
- Signature and verification processes of [electronic]
- digital signature.", GOST R 34.10-2001, Gosudarstvennyi
- Standard of Russian Federation, Government Committee of
- the Russia for Standards, 2001. (In Russian)
-
- [GOST3411] "Information technology. Cryptographic Data Security.
- Hashing function.", GOST R 34.11-94, Gosudarstvennyi
- Standard of Russian Federation, Government Committee of
- the Russia for Standards, 1994. (In Russian)
-
- [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional
- Cryptographic Algorithms for Use with GOST 28147-89,
- GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
- Algorithms", RFC 4357, January 2006.
-
- [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89,
- GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001
- Algorithms with Cryptographic Message Syntax (CMS)",
- RFC 4490, May 2006.
-
- [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST
- R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
- Algorithms with the Internet X.509 Public Key
- Infrastructure Certificate and CRL Profile", RFC 4491,
- May 2006.
-
-V.Dolmatov Expires June 12, 2010 [Page 7]\f
-
-
-10.2. Informative References
-
- [RFC4509] Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer
- (DS) Resource Records (RRs)", RFC 4509, May 2006.
-
- [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
- 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
- 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
- work in progress.
-
-V.Dolmatov Expires June 12, 2010 [Page 8]\f
-
-
-Authors' Addresses
-
-
-Vasily Dolmatov, Ed.
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: dol@cryptocom.ru
-
-Artem Chuprina
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: ran@cryptocom.ru
-
-Igor Ustinov
-Cryptocom Ltd.
-Kedrova 14, bld.2
-Moscow, 117218, Russian Federation
-
-EMail: igus@cryptocom.ru
-
-V.Dolmatov Expires June 12, 2010 [Page 9]\f
-
-
-
-
-
projects / thirdparty / bind9.git / commitdiff
