IVIPTR: Resource Record for DNS
draft-tariq-dnsop-iviptr-00

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

Abstract

   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]

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 May 15, 2018.

Copyright Notice

   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

Saraj, et al.             Expires May 15, 2018                  [Page 1]
Internet-Draft                   IVIPTR                    November 2017

   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.

1.  Introduction

   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:

      The stub-resolver send a query request to the locally configured
      recursive name server to resolve a domain name against an A record

      The recursive name server respond with a PTR record in query
      response if there exists a domain name on corresponding
      authoritative name server.

      The stub-resolver then further request the recursive name server
      to resolve the AAAA record against the corresponding domain name

      The recursive name server respond with an AAAA record if it exists
      in the authoritative name server zone file.

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

2.  Motivation

   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

Saraj, et al.             Expires May 15, 2018                  [Page 2]
Internet-Draft                   IVIPTR                    November 2017

   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.

3.  The IVIPTR Resource Record

   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

Saraj, et al.             Expires May 15, 2018                  [Page 3]
Internet-Draft                   IVIPTR                    November 2017

   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 [RFC1034]
   to avoid extra indirections in accessing information.

4.  Query Processing

   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 = A.IN-ADDR.ARPA. OR AAAA.IP6.ARPA.  /
       |                                               |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                      TYPE = IVIPTR            |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                     CLASS = IN                |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                      TTL                      |
       |                                               |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
       |                   RDLENGTH                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
       /                     RDATA                     /
       /                                               /
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                                 Figure 1

   Where: b" NAME: the owner name, same as in any reverse lookup query.
   b" TYPE: the two octets field containing the IVIPTR RR TYPE code.  b"
   CLASS: two octets containing the RR IN CLASS code value 1.  b" TTL:
   the time interval in seconds that the resource record may be cached
   before the source of the information again to be contacted.  b"
   RDLENGTH: specifies the length of RDATA field.  b" 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

Saraj, et al.             Expires May 15, 2018                  [Page 4]
Internet-Draft                   IVIPTR                    November 2017

   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.

5.  Security considerations

   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.

6.  Acknowledgement

7.  Informative References

   [RFC1034]  "Domian Concepts and Facilities", November 1987,
              <https://www.ietf.org/rfc/rfc1034.txt>.

   [RFC1035]  "Domian Implementation and Specification", November 1987,
              <https://www.ietf.org/rfc/rfc1035.txt>.

   [RFC6219]  The China Educaiton and Research Network (CERNET), "IVI
              Translation Design and Deployment for the IPv4/IPv6
              Coexistence and Transition", MAY 2011,
              <https://www.ietf.org/rfc/rfc6219.txt>.

Authors' Addresses

Saraj, et al.             Expires May 15, 2018                  [Page 5]
Internet-Draft                   IVIPTR                    November 2017

   Tariq Saraj (editor)
   Riphah Institute of Systems Engineering (RISE)
   Agha Khan Road Evacuee Trust
   Islamabad, Federal Capital  44000
   Pakistan

   Phone: +923345755556
   Email: tariqsaraj@gmail.com

   Muhammad Yousaf (editor)
   Riphah Institute of Systems Engineering
   Agha Khan Road, Evacuee Trust
   Islamabad, Federal Capital  44000
   Pakistan

   Amir Qayyum (editor)
   Capital University of Science and Technology
   Main Sihala Road
   Islamabad, Federal Capital  44000
   Pakistan

Saraj, et al.             Expires May 15, 2018                  [Page 6]