Internet-Draft Resinfo DNS64 October 2024
Obser Expires 24 April 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-fobser-resinfo-dns64-01
Published:
Intended Status:
Informational
Expires:
Author:
F. Obser
OpenBSD

DNS Resolver Information Key for DNS64

Abstract

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

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on 24 April 2025.

Table of Contents

1. Introduction

DNS64 [RFC6147] performed by a DNS resolver together with NAT64 [RFC6146] 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 [RFC4033] [RFC4034] [RFC4035] validation for DNS clients of the resolver if they perform their own validation. [RFC6147] Section 3 discusses this in detail. In general, a validating DNS client has to be aware that a resolver is performing DNS64.

[RFC9606] 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.

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Relation to RFC 7050

[RFC7050] 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 [RFC6877].

This has security implications, making [RFC7050] difficult to deploy. A modern mechanism, like PREF64 [RFC8781] is easier to deploy, leading to a desire to deprecate [RFC7050] 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 [RFC9606] RESINFO mechanism and not using the learned information for address synthesis avoids the security problems of [RFC7050].

3. 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 [RFC6763], if there is no '=' in a key, then it is a boolean attribute, simply identified as being present, with no value.

4. Security Considerations

The security considerations of [RFC9606] apply.

5. 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.

Table 1
Name Description Reference
dns64 The presence of the key indicates that DNS64 address synthesis is performed. RFC EDITOR: THIS DOCUMENT

6. References

6.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6763]
Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, , <https://www.rfc-editor.org/rfc/rfc6763>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9606]
Reddy.K, T. and M. Boucadair, "DNS Resolver Information", RFC 9606, DOI 10.17487/RFC9606, , <https://www.rfc-editor.org/rfc/rfc9606>.

6.2. Informative References

[RFC4033]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, , <https://www.rfc-editor.org/rfc/rfc4033>.
[RFC4034]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, , <https://www.rfc-editor.org/rfc/rfc4034>.
[RFC4035]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, , <https://www.rfc-editor.org/rfc/rfc4035>.
[RFC6146]
Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, , <https://www.rfc-editor.org/rfc/rfc6146>.
[RFC6147]
Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, , <https://www.rfc-editor.org/rfc/rfc6147>.
[RFC6877]
Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, , <https://www.rfc-editor.org/rfc/rfc6877>.
[RFC7050]
Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, , <https://www.rfc-editor.org/rfc/rfc7050>.
[RFC8781]
Colitti, L. and J. Linkova, "Discovering PREF64 in Router Advertisements", RFC 8781, DOI 10.17487/RFC8781, , <https://www.rfc-editor.org/rfc/rfc8781>.

Author's Address

Florian Obser
OpenBSD