draft-yao-dnsop-accompanying-questions-02.txt   draft-yao-dnsop-accompanying-questions-03.txt 
dnsop J. Yao dnsop J. Yao
Internet-Draft P. Vixie Internet-Draft P. Vixie
Intended status: Standards Track CNNIC-Farsight Joint Laboratory Intended status: Standards Track CNNIC-Farsight Joint Laboratory
Expires: May 3, 2017 N. Kong Expires: December 25, 2017 N. Kong
X. Li X. Li
CNNIC CNNIC
October 30, 2016 June 23, 2017
A DNS Query including A Main Question with Accompanying Questions A DNS Query including A Main Question with Accompanying Questions
draft-yao-dnsop-accompanying-questions-02 draft-yao-dnsop-accompanying-questions-03
Abstract Abstract
This document enables DNS initiators to send a main question This document enables DNS initiators to send a main question
accompanying with several related questions in a single DNS query, accompanying with several related questions in a single DNS query,
and enables DNS responders to put the answers into a single DNS and enables DNS responders to put the answers into a single DNS
response. This mechanism can reduce the number of DNS round-trips response. This extension enables a range of initiators to look up
per application work-unit. "X, or failing that, Y" in a better way than both current
alternatives. This mechanism can reduce the number of DNS round-
trips per application work-unit.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2017. This Internet-Draft will expire on December 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 27
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanism for a main question with accompanying questions . . 3 3. Mechanism for a main question with accompanying questions . . 3
4. Responder Processing . . . . . . . . . . . . . . . . . . . . 5 4. Responder Processing . . . . . . . . . . . . . . . . . . . . 6
5. Initiator Processing . . . . . . . . . . . . . . . . . . . . 6 5. Initiator Processing . . . . . . . . . . . . . . . . . . . . 7
6. Query and Response Example . . . . . . . . . . . . . . . . . 7 6. Query and Response Example . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. Change History . . . . . . . . . . . . . . . . . . . . . . . 8 10. Change History . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. draft-yao-dnsop-accompanying-questions: Version 00 . . . 9 10.1. draft-yao-dnsop-accompanying-questions: Version 00 . . . 9
10.2. draft-yao-dnsop-accompanying-questions: Version 01 . . . 9 10.2. draft-yao-dnsop-accompanying-questions: Version 01 . . . 9
10.3. draft-yao-dnsop-accompanying-questions: Version 02 . . . 9 10.3. draft-yao-dnsop-accompanying-questions: Version 02 . . . 9
10.4. draft-yao-dnsop-accompanying-questions: Version 03 . . . 9
11. Normative References . . . . . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
There are many scenarios in which an application must send several Sometimes, when DNS lookup of X, an application will lookup Y if X
related questions to a DNS responder. For examples, when asking fails. For examples, the initiator may fall back to A record if the
about a QTYPE=A RRset, a QTYPE=AAAA RRset may also be of use [RFC lookup of MX record fails.
5321]; When asking for some RRset of www.example.com about A and
AAAA, records of a sub-domain name such as _443._tcp.www.example.com
for TLSA may be of interest[RFC 6698].
Query example.com for A and AAAA Some initiators do it in sequence, X and after a few seconds, then Y.
Although it is simple, this leads to unpleasant waiting whenever X
times out or answers negatively.
Query www.example.com for A and AAAA, and _443._tcp.www.example.com Some initiators use concurrent X/Y lookups and a state machine to
for TLSA decide whether to use X or Y. If an answer to Y arrives but none to
This document describes a method by which DNS initiators can send a X, the initiator needs to wait a little or else fall back to Y
main question accompanying with several related questions in a single inappropriately. Concurrent lookup is faster if the X lookup takes
DNS query, and enables DNS responders place all related answers into time and falling back to Y is appropriate, but rather complex, with
a single DNS response. This mechanism can reduce the number of DNS four states to test, and the initiator needs to wait for an answer to
round-trips per application work-unit, by carrying several related X or a timeout before it can use Y.
queries in a single query transaction.
This document enables a quicker, more easily tested failover. There
is no need to test different answer sequences, there's no need for a
state machine, there's no need for timeouts beyond receiving the
reply. This document describes a method by which DNS initiators can
send a main question accompanying with several related questions in a
single DNS query, and enables DNS responders place all related
answers into a single DNS response. This mechanism can reduce the
number of DNS round-trips per application work-unit, by carrying
several related queries in a single query transaction. It has the
following advantages compared to other solutions.
o Compared to sequential lookups: It's roughly as simple, but much
faster in case a fallback to Y is necessary.
o Compared to the concurrent mechanism: It is slightly faster (if
the initiator needs to wait for an X timeout) and/or prevents
inappropriate fallback (if the answer to X arrives too late), and
it has a simpler state machine.
This mechanism can also be used in the scenarios when the application
needs more records of the same domain name or its sub-domain name.
For examples, when asking about a QTYPE=A RRset, a QTYPE=AAAA RRset
may also be of use [RFC 5321]; When asking for some RRset of
www.example.com about A and AAAA, records of a sub-domain name such
as _443._tcp.www.example.com for TLSA may be of interest[RFC 6698].
2. Terminology 2. Terminology
The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT", The basic key words such as "MUST", "MUST NOT", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as "SHOULD", "SHOULD NOT", "MAY", and "MAYNOT" are to be interpreted as
described in [RFC2119]. described in [RFC2119].
The basic DNS terms used in this specification are defined in the The basic DNS terms used in this specification are defined in the
documents [RFC1034] and [RFC1035]. documents [RFC1034] and [RFC1035].
skipping to change at page 8, line 39 skipping to change at page 9, line 18
document. IANA should reserve RCODE with the value of 111111110100 document. IANA should reserve RCODE with the value of 111111110100
bits for this document. bits for this document.
8. Security Considerations 8. Security Considerations
TBD TBD
9. Acknowledgements 9. Acknowledgements
The authors thank the members in DNSOP mailing list for helpful The authors thank the members in DNSOP mailing list for helpful
discussions, and especially thank Kazunori Fujiwara, JINMEI Tatuya discussions, and especially thank Kazunori Fujiwara, JINMEI Tatuya,
and Bob Harold for kind comments, suggestions and improvements for Bob Harold, Arnt Gulbrandsen and Olafur Gudmundsson for kind
the document. The authors also thanks Likun Zhang for helpful comments, suggestions and improvements for the document. The authors
discussion about some topics related to implementation. also thanks Likun Zhang for helpful discussion about some topics
related to implementation.
10. Change History 10. Change History
RFC Editor: Please remove this section. RFC Editor: Please remove this section.
10.1. draft-yao-dnsop-accompanying-questions: Version 00 10.1. draft-yao-dnsop-accompanying-questions: Version 00
o A Mechanism for DNS query including one main question with several o A Mechanism for DNS query including one main question with several
accompanying questions accompanying questions
10.2. draft-yao-dnsop-accompanying-questions: Version 01 10.2. draft-yao-dnsop-accompanying-questions: Version 01
o Simpilfy the mechanism. o Simpilfy the mechanism.
10.3. draft-yao-dnsop-accompanying-questions: Version 02 10.3. draft-yao-dnsop-accompanying-questions: Version 02
o Remove the AQ and Count bits, and add AQ-ANCOUNT AQ-ARCOUNT AQ- o Remove the AQ and Count bits, and add AQ-ANCOUNT AQ-ARCOUNT AQ-
NSCOUNT NSCOUNT
10.4. draft-yao-dnsop-accompanying-questions: Version 03
o Improve the introduction and explains the motivation of this draft
11. Normative References 11. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
 End of changes. 15 change blocks. 
33 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/