DNSOP T. Saraj, Ed. Internet-Draft M. Yousaf Intended status: Standards Track Riphah Institute of Systems Engineering Expires: November 12, 2018 A. Qayyum Capital University of Science and Technology May 11, 2018 IVIPTR: Resource Record for DNS draft-tariq-dnsop-iviptr-01 Abstract This document proposes a new DNS Resource Record IVIPTR which provides the capability to resolve the IPv4 address to IPv6 address and IPv6 address to IPv4 address. This document assumes that the reader is familiar with all the concepts and details discussed in Domain Names Concepts and Facilities [RFC1034] , Domain Names - Implementation and Specification [RFC1035] 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 November 12, 2018. Copyright Notice Copyright (c) 2018 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 (https://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 Saraj, et al. Expires November 12, 2018 [Page 1] Internet-Draft IVIPTR: Resource Record for DNS May 2018 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation and Usecases . . . . . . . . . . . . . . . . . . . 4 2.1. Usecase-01: Firewall Automation . . . . . . . . . . . . . 4 2.2. Usecase-02: Promoting IPv6 Usage . . . . . . . . . . . . 5 2.3. Usecase-03: Customized Debugging Utilities . . . . . . . 5 2.4. Usecase-04: Spam Filtering . . . . . . . . . . . . . . . 5 3. The IVIPTR Resource Record . . . . . . . . . . . . . . . . . 5 3.1. Ideal Scenario . . . . . . . . . . . . . . . . . . . . . 6 3.2. Non-Ideal Scenario . . . . . . . . . . . . . . . . . . . 6 3.3. Reverse zone file for IPv4 network prefix . . . . . . . . 7 3.4. Reverse zone file for IPv6 network prefix . . . . . . . . 7 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Client Query: Case-01 . . . . . . . . . . . . . . . . . . 9 4.2. Client Query: Case-02 . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction 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]. The current DNS standard does not support to resolve IPv4 address to IPv6 address and IPv6 address to IPv4 address. For example, if a user program initiate a query for AAAA resource record against an IPv4 address of a domain, the current DNS will return a negative answer normally with RCODE(3)-Non-Existent Domain. Using the current DNS standard, a user program can resolve IPv6 address for a desired IPv4 address by the process as in figure-01: Saraj, et al. Expires November 12, 2018 [Page 2] Internet-Draft IVIPTR: Resource Record for DNS May 2018 Local | Foreign | +---------+ | | | rev. lookup response | | Stub |<--------------------+ | | Resolver| | | | Step-01 |----------------+ | | +---------+ rev. lookup | | | query | | | V | | +---------+ fwd. lookup +----------+ | +--------+ | | query | |queries | | | | Stub |-------------->| Recursive|---------|->|Foreign | | Resolver| | Server | | | Name | | Step-02 |<--------------| |<--------|--| Server | +---------+ fwd. lookup | |responses| | | response +----------+ | +--------+ | | | Figure 1 1. The stub-resolver in Step-01, sends a reverse lookup query for an A record to the recursive server to resolve the corresponding fully qualified domain name from the Foreign Name Server 2. The Foreign Name Server returns the PTR resource record against the query to the recursive server, which is responded back to the Stub-resolver as a response. 3. For the received domain name in Step-01, the stub-resolver in Step-02, sends a forward lookup query to recursive server to resolve the corresponding AAAA resource record from the Foreign Name Server. 4. The Foreign Name Server returns the AAAA resource record against the query to the recursive server, which is responded back to the Stub-resolver as a response. Here, the bottleneck in this process is that now a days, mostly domains has different PTR records for a corresponding A or AAAA resource record. In this case the aforementioned process in figure-01 is not suitable. Also, this process requires to make changes to the Stub-resolver functionality to pursue the aforementioned process. Even, if the Stub-resolver functionality is modified it will work only if a single domain name is used for both A and AAAA record. The proposed solution (IVIPTR) is that, when the Saraj, et al. Expires November 12, 2018 [Page 3] Internet-Draft IVIPTR: Resource Record for DNS May 2018 Stub-resolver send a query to the recursive server for resolving AAAA record against an IPv4 address and vice versa, it will respond with the desired resource record (RR) without depending upon a Fully Qualified Domain Name(FQDN) knowledge on Stub-resolver. The term IVI in the proposed IVIPTR resource record is borrowed from one of the IPv4/IPv6 transition mechanisms address translation algorithm [RFC6219]. 2. Motivation and Usecases IPv4 is the principal protocol being used for communication in most of the organizations. Primarily, the need of IVIPTR RR in DNS evolved in a lab environment during the translation of IPv4 security rules to IPv6 security rules in a network security component (Firewall). This section discuss four usecases for the proposed DNS resource record. 2.1. Usecase-01: Firewall Automation In network security components, mostly traffic monitoring is done through rule based filtering. An organization may enable IPv6 for certain reasons such as: 1. Functionality testing of a newly developed application with IPv6. 2. Performance and compatibility testing of application with IPv6. 3. Or, the organization has decided to keep their network on dual stack from onwards for transition purpose etc. As a result the security guys has to maintain dual security rules for both Inbound and Outbound network traffic. This can be done by manually configuring the security rules in all network security components for the newly enabled Internet protocol IPv6. Mistakenly, configuring any security rule can result in an undesired consequences. To automate the security configuration process in a network, there is a need to resolve IPv6 address for a corresponding IPv4 address against every security rule in a network security component (Firewall). The only resource in any network available for this automation process is the DNS. Currently in DNS, there is no such mechanism that can return IPv6 address of a domain if IPv4 address is known or vice versa. The IVIPTR Resource Record conceived as a solution to the problem for resolving IPv6 address if IPv4 address is known or IPv4 address if IPv6 address is known. Saraj, et al. Expires November 12, 2018 [Page 4] Internet-Draft IVIPTR: Resource Record for DNS May 2018 There may exist IPv4 or IPv6 address in network security components rules, which does not belong to any fully qualified domain name (FQDN) and thus, are out of the scope of this work. The presence of this IVIPTR Resource Record in the reverse zone file of an authoritative name server can result in automating a number of service for enabling them to reconfigure their security rules for the newly enabled address family protocol i.e. IPv4 or IPv6. 2.2. Usecase-02: Promoting IPv6 Usage When accessing service such as FTP for a domain say example.com, a user can connect to the server by either: 1. ftp example.com 2. Or, ftp 192.168.0.1 For the second FTP access mechanism, the IVIPTR RR will help to retrieve the IPv6 address against the IPv4 address of the FTP server. Further, the user application will use the newly retrieved IPv6 for connectivity instead of the given one to promote the usage of IPv6 as the priority Internet address for connectivity. 2.3. Usecase-03: Customized Debugging Utilities Debugging utilities such as traceroute can be customized in such a way that it will give detailed response. For example if a user gives a traceroute command as: traceroute++ 192.168.0.1 or traceroute++ example.com Thus, the output will be both PTR record and IVIPTR record. 2.4. Usecase-04: Spam Filtering When applying spam filtering policy for a mail server such as mail.example.com, the IVIPTR can be helpful in providing additional details such as: If filtering is performed on IPv4 address, the same can be done for IPv6 address for the corresponding mail server 3. The IVIPTR Resource Record The IVIPTR RR has mnemonic IVIPTR and type code TBD (decimal). The IVIPTR RR has the following format: IVIPTR Saraj, et al. Expires November 12, 2018 [Page 5] Internet-Draft IVIPTR: Resource Record for DNS May 2018 The OWNER is either unqualified or fully qualified domain name depending upon the configuration of reverse zone file optional directive $ORIGIN. The TTL and CLASS fields are the same as for all other PTR records in the reverse zone file. As for the usecases discussed in the previous section the fact of IVIPTR RR usage, it is to be believed that this resource record will not be required to access frequently or in some cases just once, so one can set a smaller TTL value for this resource record to facilitate the recursive server by reducing the cache from unnecessary increase. IVIPTR is the new RR type that points to a fully qualified domain name (FQDN) i.e. IVI target in a reverse zone file. The from onwards for simplicity written as SHOULD be a fully qualified domain name (FQDN). The presence of in a reverse zone can be elaborate by considering the domain example.com. Realistically, most of the times labels in a domain name for an IPv4 and IPv6 glue record are different. There are two possible scenarios for configuration of forward lookup zone file. 3.1. Ideal Scenario An ideal scenario for a forward lookup zone file would be the one in which, labels in a domain name are same for both IPv4 and IPv6 glue records as: ; zone file for example.com x.example.com. IN A 192.168.0.1 x.example.com. IN AAAA 2001:DB8:0::1 3.2. Non-Ideal Scenario A non-ideal scenario for a forward lookup zone file would be the one in which, labels in a domain name are slightly different for both IPv4 and IPv6 glue records as: ; zone file for example.com x.example.com. IN A 192.168.0.1 x6.example.com. IN AAAA 2001:DB8:0::1 The use of IVIPTR RR is effective only against forward lookup zone file Non-Ideal configuration scenario. Although, it will cause no issue with the Ideal scenario except additional processing overhead. Saraj, et al. Expires November 12, 2018 [Page 6] Internet-Draft IVIPTR: Resource Record for DNS May 2018 The representation of IVIPTR RR against both the IPv4 and IPv6 addresses would be as discussed in the next two sub-sections respectively. 3.3. Reverse zone file for IPv4 network prefix When configuring a reverse zone file for example.com of IPv4 network prefix, the representation of IVIPTR RR type would be as: ; reverse zone file example.com for IPv4 1.0.168.192.IN-ADDR.APRPA. IN PTR x.example.com. 1.0.168.192.IN-ADDR.ARPA. IN IVIPTR x6.example.com. 3.4. Reverse zone file for IPv6 network prefix When configuring a reverse zone file for example.com of IPv6 network prefix, the representation of IVIPTR RR type would be as: ; reverse zone file example.com for IPv6 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP 6.ARPA. IN PTR x6.example.com. 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.IP 6.ARPA. IN IVIPTR x.example.com. For the purpose of simplicity in the forward lookup zone file, there is no referral RR Type such as CNAME is listed. In case of presence of any referral record in the forward lookup zone file the in both of the reverse zone files SHOULD be the same as the CNAME < target > in the forward lookup zone file. Thus, IVIPTR MUST follow the rule of robustness principle discussed in section 3.6.2 of [RFC1034] to avoid extra indirections in accessing information. 4. Query Processing Saraj, et al. Expires November 12, 2018 [Page 7] Internet-Draft IVIPTR: Resource Record for DNS May 2018 The IVIPTR follow the top level RR format and semantics as defined in the section 3.2.1 of RFC 1035 [RFC1035]. 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME = 1.0.168.192.IN-ADDR.APRPA. / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE = IVIPTR | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS = IN | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 2 Where: NAME: the owner name, same as in any reverse lookup query. TYPE: the two octets field containing the IVIPTR RR TYPE code. CLASS: two octets containing the RR IN CLASS code value 1. TTL: the time interval in seconds that the resource record may be cached before the source of the information again to be contacted. RDLENGTH: specifies the length of RDATA field. RDATA: A variable length string of octets that represents the resource. The resource depends on the owner in the NAME field of the query. The query processing is same as any other DNS query except that when the recursive server receives the response for the IVIPTR RR, first it will cache the response like any other resource record and then it will form a new query based on the rules in the sub-sections of this section. Saraj, et al. Expires November 12, 2018 [Page 8] Internet-Draft IVIPTR: Resource Record for DNS May 2018 4.1. Client Query: Case-01 If the original query NAME field contains IPv4 representation and TYPE field is IVIPTR then: 1. Upon receiving the response at the recursive server, it SHOULD form a new query. 2. The NAME field of the new query SHOULD be mapped appropriately in the desired format to the IVIPTR target in RDATA resource. 3. The TYPE field for the new query SHOULD be AAAA. 4. This query will be resolved as any other forward lookup query. Upon receiving the response which will contain AAAA RR type target, the recursive server will place this in the answer section of the original query request from client. The IVIPTR RR SHOULD cause no additional section processing. 5. In case of failure or any error the standard error response will be send back to the stub-resolver against the original query request. 4.2. Client Query: Case-02 If the original query NAME field contains IPv6 representation and TYPE field is IVIPTR then: 1. Upon receiving the response at the recursive server, it SHOULD form a new query. 2. The NAME field of the new query SHOULD be mapped appropriately in the desired format to the target in RDATA resource. 3. The TYPE field for the new query SHOULD be A. 4. This query will be resolved as any other forward lookup query. Upon receiving the response which will contain A RR type target, the recursive server will place this in the answer section of the original query request from client. The IVIPTR RR SHOULD cause no additional section processing. 5. In case of failure or any error the standard error response will be send back to the stub-resolver against the original query request. Saraj, et al. Expires November 12, 2018 [Page 9] Internet-Draft IVIPTR: Resource Record for DNS May 2018 5. Security Considerations On a security-aware name server, while resolving the IVIPTR the query processing involves a forward lookup on recursive server in both Section 4.1 and section 4.2 when the new query is formed. The forward lookup in both the cases SHOULD comply completely with the DNSSEC on a security-aware name server and stub-resolver. 6. Acknowledgements 7. IANA Considerations 8. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, DOI 10.17487/RFC6219, May 2011, . Authors' Addresses Tariq Saraj (editor) Riphah Institute of Systems Engineering Aga Khan Road, Sector F-5/1 Islamabad, Federal Capital 44000 Pakistan Phone: 00923345755556 Email: tariqsaraj@gmail.com Saraj, et al. Expires November 12, 2018 [Page 10] Internet-Draft IVIPTR: Resource Record for DNS May 2018 Muhammad Yousaf Riphah Institute of Systems Engineering Aga Khan Road, Sector F-5/1 Islamabad, Federal Capital 44000 Pakistan Email: Muhammad.Yousaf@riu.edu.pk Amir Qayyum Capital University of Science and Technology Kahuta Road, Islamabad Expressway Islamabad, Federal Capital 44000 Pakistan Email: aq@cust.edu.pk Saraj, et al. Expires November 12, 2018 [Page 11]