IPv6 Operations (v6ops) Martin Hunek Internet-Draft Technical University of Liberec Intended status: Standards Track March 11, 2019 Expires: September 11, 2019 NAT64/DNS64 detection via SRV Records draft-ietf-v6ops-nat64-srv-00 Abstract This document specifies the way of discovering the NAT64 pools in use as well as DNS servers providing DNS64 service to the local clients. The discovery is done via SRV records, which also allows asignment of priorities to the NAT64 pools as well as DNS64 servers. It also allows clients to have diferent DNS providers than NAT64 provider, while providing a secure way via DNSSEC validation of provided SRV records. This way, it provides DNS64 service even in case where DNS over HTTPS is used. 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 September 11, 2019 Copyright Notice Copyright (c) 2019 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 Simplified BSD License. Martin Hunek Expires September 11, 2019 [Page 1] INTERNET-DRAFT NAT64/DNS64 detection via SRV Records March, 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. NAT64 service SRV record . . . . . . . . . . . . . . . . . . . 3 4. DNS64 service SRV record . . . . . . . . . . . . . . . . . . . 4 5. Node Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Martin Hunek Expires September 11, 2019 [Page 2] INTERNET-DRAFT NAT64/DNS64 detection via SRV Records March, 2019 1. Introduction The simultaneous use of NAT64/DNS64 and DNSSEC outlined by [RFC7050], does not solve all the aspects of such use. Namely [RFC7050] does not allow assignment of NAT64 priorities in case when multiple network prefixes are in use. [RFC7050] also doesn't work in the case when network operator and DNS operator are not the same subject, like in the case when the end node is using some public DNS resolvers. This document describes the way how to circumvent that limitation while maintaining added security provided by DNSSEC. 1.1. Requirements Language 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. Terminology End node: Either DNS stub resolver or the DNS recursive resolver serving a local area network or station. Pref64::/n: an IPv6 prefix used for IPv6 address synthesis [RFC6146]. Pref64::WKA: an IPv6 address consisting of Pref64::/n and WKA at any of the locations allowed by [RFC6052]. Well-Known IPv4 Address (WKA): an IPv4 address that is well-known and present in an A record for the well-known name. Two well-known IPv4 addresses are defined for Pref64::/n discovery purposes: 192.0.0.170 and 192.0.0.171. 3. NAT64 service SRV record This document specifies two new well-known SRV records. The one for NAT64 prefix which validation end node MUST implement: nat64. ipv6.Name TTL Class SRV Priority Weight Port Target The TTL, Class, Priority and Weight follows the same scheme as defined in [RFC2782] and have theirs standard meaning. Port: IPv6 as L3 protocol doesn't use port numbers. Because of that this field SHOULD be either set to zero, or SHOULD be used to indicate length of network prefix mask in both IPv6 and IPv4 protocol, used NAT64. In such case the port 16b integer MUST be constructed by directly appending IPv4 pool prefix mask after the Martin Hunek Expires September 11, 2019 [Page 3] INTERNET-DRAFT NAT64/DNS64 detection via SRV Records March, 2019 IPv6 prefix mask decadicaly. Usually this would mean 9632 stating that IPv6 prefix with mask /96 is translated into single IPv4 address (/32). Target: MUST point to AAAA record formed from Pref64::/n prefix and WKA same way as in [RFC7050] (Pref64::WKA). Target MAY also point to A record, in which case it SHOULD point to IPv4 address used for NAT64 (or base address of the NAT64 IPv4 prefix). 4. DNS64 service SRV record The second SRV record is for the discovery of DNS64 service. Support of this record is OPTIONAL but end node SHOULD implement it. dns64.Protocol.Name TTL Class SRV Priority Weight Port Target Record informs about location of DNS64 service. This might be used in case that network operator doesn't want to deploy DNS64 in their main DNS infrastructure. A DNS64 SRV record follows the rules specified by [RFC2782] and does not modify meaning of any field. Server provided by this record SHOULD only be used for domain names which have returned NODATA for AAAA record. 5. Node Behavior In early stage of end node connection to the network - after the end node is configured with IP address, the end node MUST get local domains used in the network. Method of obtaining such information is out of scope of this document, but it might contain one or more methods, like the SLAAC-DNSSL [RFC8106], the DHCPv6 - option 24 or a manual configuration. In case, when no local domain can be discovered, the end node SHOULD continue NAT64/DNS64 detection by other means, like [RFC7050]. After the list of local domains has been established, the end node MUST ask for NAT64 SRV record for every domain in the list. Result of such queries SHOULD be ordered by following the rules of [RFC2782]. In case when multiple records do have a same values of both priority and weight, the records SHOULD maintain the same order as its domain in the discovered domain list. For every domain with NAT64 SRV record the end node SHOULD perform query for DNS64 SRV record. If such a record is obtained and the end node is not configured to make DNS64 synthesis itself, the end node SHOULD use preferred target of DNS64 SRV record to query for FQDN without AAAA record - when it received NODATA response. If the end node is capable of validation of DNS records via DNSSEC, the end node MUST perform validation of NAT64/DNS64 SRV record. Default behavior of end node SHOULD be to ignore any NAT64/DNS64 SRV records which cannot be validated or did not pass the validation. Martin Hunek Expires September 11, 2019 [Page 4] INTERNET-DRAFT NAT64/DNS64 detection via SRV Records March, 2019 5.1. Example The end node is a home router connected to the ISP network in which the NAT64/DNS64 is used and the ISP has the following SRV records in their zones: - nat64.ipv6.example.com. IN SRV 5 10 9632 nat64-pool-1.example.com. - nat64-pool-1.example.com. IN AAAA 2001:db8:64:ff9b:1::c000:aa - nat64-pool-1.example.com. IN A 192.0.2.64 - nat64.ipv6.example.com. IN SRV 10 10 9632 nat64-pool-2.example.com. - nat64-pool-2.example.com. IN AAAA 2001:db8:64:ff9b:2::c000:aa - nat64-pool-2.example.com. IN A 192.0.2.164 - nat64.ipv6.example.net. IN SRV 10 10 9624 nat64-pool.example.net. - nat64-pool.example.net. IN AAAA 2001:db8:64:ff9b:abc::c000:aa - nat64-pool.example.net. IN A 198.51.100.0 - nat64.ipv6.example.invalid. IN SRV 10 10 9624 nat64-pool.example.org. - nat64-pool.example.org. IN AAAA 2001:db8:64:ff9b:def::c000:aa - nat64-pool.example.org. IN A 203.0.113.0 In addition the zones "example.net" and "example.invalid" has got DNS64 SRV records: - dns64.tcp.example.net. IN SRV 5 10 53 dns64.example.net. - dns64.udp.example.net. IN SRV 10 10 53 dns64.example.net. - dns64.example.net. IN AAAA 2001:db8::53 - dns64.udp.example.invalid. IN SRV 10 10 53 dns64.example.org. - dns64.example.org. IN AAAA 2001:db8:123::53 The zones "example.com" and "example.net" are secured and successfully validated by the DNSSEC. Domain "example.invalid" is either not secured by the DNSSEC or its validation failed. Domain "example.org" is DNSSEC secured but does not have any NAT64/DNS64 SRV records. The end node has been supplied with the following list of domains via SLAAC-DNSSL: 1. example.net 2. example.invalid 3. example.com 4. example.org The end node would fetch all available SRV records and its A and AAAA counterparts and sort it in following order: pool DNSSEC priority reason nat64-pool-1.example.com. yes 5 lowest priority field nat64-pool.example.net. yes 10 discovered first nat64-pool-2.example.com. yes 10 higher priority field nat64-pool.example.org. no 10 no valid DNSSEC chain Martin Hunek Expires September 11, 2019 [Page 5] INTERNET-DRAFT NAT64/DNS64 detection via SRV Records March, 2019 After sorting, the end node SHOULD graylist any record which cannot be validated by the DNSSEC. In this example it would be "nat64-pool.example.org." because it has been obtained from insecure domain "example.invalid". A such pool SHOULD NOT be used if it is not confirmed by other DNSSEC secured record. If the end node is capable to act as recursive or caching DNS server and it is configured to provide the DNS64 service, it MUST provide this service using sorted list of NAT64 pools. For such end node a process of the NAT64/DNS64 ends here. However, when the end node is not capable of record synthesis or it is not configured to provide DNS64 service, it SHOULD perform detection of DNS64 by querying for "ipv4only.arpa" like in the case of [RFC7050]. If the reply contains a pool listed in the NAT64 pool list, the corresponding entry is marked as having DNS64 provided by recursive DNS. When the end node supports DNS64 SRV record and there is at least one non-graylisted NAT64 pool, which is not reachable by using the end node's recursive DNS, the end node MUST make a sorted list of DNS64 servers from the DNS64 SRV records. The DNS64 sorted list would look like this: server proto DNSSEC priority reason dns64.example.net. tcp yes 5 lowest priority field dns64.example.net. udp yes 10 higher priority field dns64.example.org. udp no 10 no valid DNSSEC chain Sorting is done in the same fashion as any other SRV record with the same exception of graylisting records without valid DNSSEC chain. Those SHOULD NOT be used when not confirmed by DNSSEC validated record and SHOULD be kept in the end of the list. For example when ISP is providing DNS64 service in their main DNS infrastructure only for pools in the domains "example.com" and "example.org" and the pool "nat64-pool.example.net" is used only with corresponding DNS64 server. The final sorted list of NAT64 prefixes used by the end node in the ISP network would be: pool state priority reason nat64-pool-1.example.com. active 5 lowest priority field nat64-pool-2.example.com. backup 10 higher priority field nat64-pool.example.net. backup* 10 main DNS has priority nat64-pool.example.org. inactive 10 no valid DNSSEC chain As the pool "nat64-pool.example.net" is used only with the server "dns64.example.net" this would effectively put this pool to the end of the list. Because it would be used only for FQDN for which the regular DNS infrastructure returns NODATA. Martin Hunek Expires September 11, 2019 [Page 6] INTERNET-DRAFT NAT64/DNS64 detection via SRV Records March, 2019 Now the end node has successfully identified NAT64 pools and the DNS64 servers in the ISP infrastructure. The discovered prefixes SHOULD be considered safe and DNSSEC validation of answers in these prefixes MUST be either disabled or performed by validating only the suffix. 6. IANA Considerations. This document proposes a usage of "ipv6" in Proto field and two services "nat64" and "dns64" in Service field of SRV RR ([RFC2782]). 7. Security considerations Method proposed by this document relies on security principles based on DNSSEC and secure discovery of local domain. In order to be secure, the network operator MUST deploy DNSSEC on at least one domain (advertised to end node) and establish secure channel to this advertisement. 8. References 8.1. Normative References [RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119. RFC Editor, Mar. 1997, pp. 1-3. url: https://www.rfc-editor.org/rfc/rfc2119.txt. [RFC2782] A. Gulbrandsen, P. Vixie, and L. Esibov. A DNS RR for specifying the location of services (DNS SRV). RFC 2782. RFC Editor, Feb. 2000, pp. 1-12. url: https://www.rfc-editor.org/rfc/rfc2782.txt. [RFC6146] M. Bagnulo, P. Matthews, and I. van Beijnum. Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. RFC 6146. RFC Editor, Apr. 2011, pp. 1-45. url: https://www.rfc-editor.org/rfc/rfc6146.txt. [RFC7050] T. Savolainen, J. Korhonen, and D. Wing. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis. RFC 7050. RFC Editor, Nov. 2013, pp. 1-22. url: https://www.rfc-editor.org/rfc/rfc7050.txt. [RFC8174] B. Leiba. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. RFC 8174. RFC Editor, May 2017, pp. 1-4. url: https://www.rfc-editor.org/rfc/rfc8174.txt. Martin Hunek Expires September 11, 2019 [Page 7] INTERNET-DRAFT NAT64/DNS64 detection via SRV Records March, 2019 8.2. Informative References [RFC6052] C. Bao et al. IPv6 Addressing of IPv4/IPv6 Translators. RFC 6052. RFC Editor, Oct. 2010, pp. 1-18. url: https://www.rfc-editor.org/rfc/rfc6052.txt. [RFC8106] J. Jeong et al. IPv6 Router Advertisement Options for DNS Configuration. RFC 8106. RFC Editor, Mar. 2017, pp. 1-19. url: https://www.rfc-editor.org/rfc/rfc8106.txt. Acknowledgments This work has been supported by Student Grant Scheme (SGS 2019) at Technical University of Liberec. Authors' Addresses Martin Hunek Technical University of Liberec Studentska 1402/2 Liberec, 46017 Czech Republic phone: +420 485 35 3792 e-mail: martin.hunek@tul.cz Martin Hunek Expires September 11, 2019 [Page 8]