hello,
     
     Based on Seoul IETF's discussion, I refine the introduction of this 
document to explain the motivation and compare with other mechanisms.
the key text is here:
---------------------------------------------
1.  Introduction

   Sometimes, when DNS lookup of X, an application will lookup Y if X
   fails.  For examples, the initiator may fall back to A record if the
   lookup of MX record fails.

   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.

   Some initiators use concurrent X/Y lookups and a state machine to
   decide whether to use X or Y.  If an answer to Y arrives but none to
   X, the initiator needs to wait a little or else fall back to Y
   inappropriately.  Concurrent lookup is faster if the X lookup takes
   time and falling back to Y is appropriate, but rather complex, with
   four states to test, and the initiator needs to wait for an answer to
   X or a timeout before it can use Y.

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


--------------------------------------------






Jiankang Yao

From: internet-drafts
Date: 2017-06-23 15:41
To: XiaoDong Lee; Ning Kong; Paul Vixie; Jiankang Yao; Xiaodong Li
Subject: New Version Notification for 
draft-yao-dnsop-accompanying-questions-03.txt

A new version of I-D, draft-yao-dnsop-accompanying-questions-03.txt
has been successfully submitted by Jiankang Yao and posted to the
IETF repository.

Name: draft-yao-dnsop-accompanying-questions
Revision: 03
Title: A DNS Query including A Main Question with Accompanying Questions
Document date: 2017-06-23
Group: dnsop
Pages: 11
URL:            
https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-03.txt
Status:         
https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/
Htmlized:       
https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-03
Htmlized:       
https://datatracker.ietf.org/doc/html/draft-yao-dnsop-accompanying-questions-03
Diff:           
https://www.ietf.org/rfcdiff?url2=draft-yao-dnsop-accompanying-questions-03

Abstract:
   This document enables DNS initiators to send a main question
   accompanying with several related questions in a single DNS query,
   and enables DNS responders to put the answers into a single DNS
   response.  This extension enables a range of initiators to look up
   "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.

                                                                                
  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to