| DNSOPS | T. Saraj, Ed. |
| Internet-Draft | Riphah Institute of Systems Engineering (RISE) |
| Intended status: Informational | M. Yousaf, Ed. |
| Expires: May 15, 2018 | Riphah Institute of Systems Engineering |
| A. Qayyum, Ed. | |
| Capital University of Science and Technology | |
| November 11, 2017 |
IVIPTR: Resource Record for DNS
draft-tariq-dnsop-iviptr-00.txt
This document propose 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]
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 May 15, 2018.
Copyright (c) 2017 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 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.
The current DNS standard does not support to resolve IPv4 address to IPv6 address and IPv6 address to IPv4 address. For example, when querying for AAAA against a known A record of a resource, the response code (RCODE) for such query is normally Non-Existent Domain (3). Using the current DNS standard, this requirement can be fulfilled by the following process if one of the address (i.e. IPv4 or IPv6) is known: [RFC6219].
Here, the bottleneck in this process is that now a days, mostly domains has different PTR records for a corresponding AAAA or A record in which case the aforementioned process 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 is that when the stub-resolver send a query to the locally configured recursive name server for resolving AAAA record against an A record 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
In network security components such as firewall or proxy firewall, mostly traffic monitoring rules are configured based on IPv4 or IPv6 addresses. A network running on IPv4 may enable IPv6 for certain reason such as testing a newly developed application, performance and compatibility testing of application with IPv6 or the organization has decided to keep their network from onwards as a dual stack etc. The administrator responsible for network security 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. Mistakenly, configuring any security rule can result in an undesired consequences. To automate such services in a network there is a need to resolve addresses for the newly enabled Internet protocol using the already configured one. Currently, 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. There may exist IPv4/IPv6 address in network security components rules set which does not belong to any fully qualified domain name (FQDN) and thus, are out of the scope of this work. The IVIPTR RR can have a number of use cases other than just security rules based on preconfigured IPv4 or IPv6 addresses as target. The presence of this Resource Record in the reverse zone file of a domain 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.
The IVIPTR RR has mnemonic IVIPTR and type code TBA (decimal). The IVIPTR RR has the following format: <OWNER> <TTL> <CLASS> IVIPTR <IVI target > The OWNER is the 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. Keeping the use case 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 name server cache 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 <IVI target> from onwards for simplicity written as <target> SHOULD be a fully qualified domain name (FQDN). The presence of <IVIPTR RR> in a reverse zone can be elaborate by considering the domain example.com. Realistically, most of the time the target domain labels for an A and AAAA PTR records are different. The RRs in zone files for both forward zone and reverse zone would be as: ; zone file for example.com foo.example.com IN CNAME a.x.foo.example.com. a.x.foo.example.com. IN A 192.168.0.1 a.x6.foo.example.com. IN AAAA 2001:DB8:0::1 ; reverse zone file for example.com A record 1.0.168.192.IN-ADDR.APRPA. IN PTR a.foo.example.com. 1.0.168.192.IN-ADDR.ARPA. IN IVIPTR a.x6.foo.example.com. ; reverse zone file for example.com AAAA record 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.IP6.ARPA. IN PTR a.x6.foo.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.IP6.ARPA. IN IVIPTR a.x.foo.example.com. The target a.x.foo.example.com. in the reverse zone file is a target in the forward zone file in CNAME. Thus, IVIPTR MUST follow the rule of robustness principle discussed in section 3.6.2 of RFC 1034 to avoid extra indirections in accessing information.
The IVIPTR follow the top level RR format and semantics as defined in the section 3.2.1 of RFC 1035.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME = A.IN-ADDR.ARPA. OR AAAA.IP6.ARPA. /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE = IVIPTR |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS = IN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1
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 <IVI target> 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 name server receives the response for the IVIPTR RR, first it will cache the response like any other RR and then it will form a new query in such a way that: Case-01: If the original query NAME field is A.IN-ADDR.ARPA. and TYPE field is IVIPTR then upon receiving the response at the recursive name server the NAME field of the new query should be mapped appropriately in the desired format to the RDATA resource and the TYPE field should be AAAA. Case-02: If the original query NAME field is AAAA.IP6.ARPA. and TYPE field is IVIPTR then upon receiving the response at the recursive name server the NAME field of the new query should be mapped appropriately in the desired format to the RDATA resource and the TYPE field should be A. This query will be resolved by properly following the hierarchy just like any other forward lookup query request resolution process. Upon receiving the response RR the recursive name server after caching, the answer section will be modified such that the owner NAME will be replaced with the owner NAME in the original query request and the TYPE value instead of A or AAAA should be IVIPTR. The IVIPTR RRs cause no additional section processing. In case of failure or any error the standard error response will be send back to the stub-resolver against the original query request.
Security issues are not discussed in this memo. It is expected that the new IVIPTR resource record will be treated the same way as any other PTR RR on the security aware name server.
| [RFC1034] | "Domian Concepts and Facilities", November 1987. |
| [RFC1035] | "Domian Implementation and Specification", November 1987. |
| [RFC6219] | The China Educaiton and Research Network (CERNET), "IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", MAY 2011. |