]> OpenBSD

florian+ietf@narrans.de

This document specifies a DNS Resolver Information Key/Value pair to inform DNS clients of the presence of DNS64.

Introduction DNS64 performed by a DNS resolver together with NAT64 allows an IPv6-only client to initiate communications by name to an IPv4-only server. To achieve this, the DNS resolver synthesizes AAAA records from A records. However, this breaks DNSSEC validation for DNS clients of the resolver if they perform their own validation. Section 3 discusses this in detail. In general, a validating DNS client has to be aware that a resolver is performing DNS64. specifies a DNS resource record (RR) type RESINFO to allow resolvers to publish information about their capabilities and policies. This can be used to inform DNS clients that DNS64 is performed by the DNS resolver.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Relation to RFC 7050 describes a heuristic to learn the IPv6 prefix used by a NAT64 gateway. Nodes can use this information to perform local address synthesis, for example using 464XLAT . This has security implications, making difficult to deploy. A modern mechanism, like PREF64 is easier to deploy, leading to a desire to deprecate entirely. A validating DNS client on the other hand still needs to know about the presence of DNS64 on the DNS resolver it uses, as noted in the introduction. Using the RESINFO mechanism and not using the learned information for address synthesis avoids the security problems of .

dns64 Resolver Information Key/Value

dns64:

The presence of this key indicates that the DNS resolver performs address synthesis. Note that, per the rules for the keys defined in Section 6.4 of , if there is no '=' in a key, then it is a boolean attribute, simply identified as being present, with no value. The DNS resolver MAY return an IPv6 prefix or a comma separated list of prefixes to indicate not just that DNS64 is being performed but also to let the client know which prefix or prefixes are in use. The prefixes MUST be represented using the canonical representation format of .

Examples DNS64 address synthesis is performed by the DNS resolver. No information about the used prefix is given.

DNS64 address synthesis is performed. The Well-Known Prefix 64:ff9b::/96 is used.

DNS64 address synthesis is performed. The Well-Known Prefix 64:ff9b::/96 and the Network-Specific Prefix 2001:db8:64::/56 are used.

Security Considerations The security considerations of apply.

IANA Considerations The IANA is requested to add the key "dns64", with the description of "The presence of the key indicates that DNS64 address synthesis is performed", and a reference to this document. Name Description Reference dns64 The presence of the key indicates that DNS64 address synthesis is performed. RFC EDITOR: THIS DOCUMENT

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies a method for DNS resolvers to publish information about themselves. DNS clients can use the resolver information to identify the capabilities of DNS resolvers. How DNS clients use such information is beyond the scope of this document. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK] 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. [STANDARDS-TRACK] This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts.