Internet DRAFT - draft-tariq-dnsop-iviptr
draft-tariq-dnsop-iviptr
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:
<OWNER> <TTL> <CLASS> IVIPTR <IVI target >
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 <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 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 <IVI
target > 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 <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 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,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc6219>.
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]
