Subject: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt

From: "Jiankang Yao" <[email-masked]>
Date: Fri, 29 Apr 2016 09:01:18 +0800

Dear all,

      We submit a draft about "A DNS Query including A Main Question with Accompanying Questions".

       Any comments are welcome.

      Thanks.        

Jiankang Yao

From: internet-drafts
Date: 2016-04-28 15:50
To: XiaoDong Lee; Paul A. Vixie; Jiankang Yao; Paul Vixie; Xiaodong Li; Ning Kong
Subject: New Version Notification for draft-yao-dnsop-accompanying-questions-00.txt

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

Name: draft-yao-dnsop-accompanying-questions
Revision: 00
Title: A DNS Query including A Main Question with Accompanying Questions
Document date: 2016-04-28
Group: Individual Submission
Pages: 9
URL:            https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-00.txt
Status:         https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/
Htmlized:       https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-00

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

---

From: Ray Bellis <[email-masked]>
Date: Fri, 29 Apr 2016 10:38:35 +0100

>        Any comments are welcome.

I am unconvinced that the ability to specify multiple QNAMEs offers any
benefits and can't think of any good use cases where the client knows a
priori what the other QNAMEs might be.   [ I don't consider looking up
example.com and www.example.com at the same time to be 'good' ].

The examples given all appear to show a recursor -> authority query, but
I see no hint in the draft about whether it's only for that path or also
for stub -> recursor.

My own draft in this area (draft-bellis-dnsext-multi-qtypes) where only
a single QNAME is supported and a single RCODE is returned has IMHO far
clearer semantics.  It's also appropriate both for stub -> recursor and
for recursor -> authority.

Ray

p.s. I noticed a dangling reference to RFC1321 (MD5) ?

---

From: Bob Harold <[email-masked]>
Date: Fri, 29 Apr 2016 09:44:57 -0400

> for recursor -> authority.

I am assuming that the benefits here are:
- reduced number of packets
- reduced total bytes
- possibly reduced round trips

Would it be possible to get most of these benefits with a combination of:
- tcp + pipeline - pipeline multiple queries with less packets
- tcp-fast-open - avoid extra round trip

If cookies are longer-lived than tcp sessions, could we use tcp-fast-open
with cookies to avoid spoofed source addresses?

If all of that would work together, it would be more flexible than either
of the above drafts.  But I am probably missing something.

-- 
Bob Harold

---

From: Paul Vixie <[email-masked]>
Date: Fri, 29 Apr 2016 19:27:43 -0700

> Bob Harold <mailto:[email-masked]>
> Friday, April 29, 2016 06:44
>
>
>
>     example.com <http://example.com> and www.example.com
>     <http://www.example.com> at the same time to be 'good' ].
>

yes to that last.

specifically, if one wanted to ask about a SRV RR and an A RR and an 
AAAA RR, that's two different QNAMEs, which would otherwise require 
multiple transactions.

note that the transactions can be sent in parallel, but it's currently a 
2-packet microburst without any congestion control, which is dangerous. 
once we have negotiated TCP stayopen, we can pump the queries in as fast 
as the initiator would like, and in that event, the bellis model will be 
superior by its simplicity, even if it uses more wire-octets due to the 
extra DNS header.
> - tcp-fast-open - avoid extra round trip

as to whether we should punt on all the multi-question drafts and say 
"wait for negotiable TCP keepopen, and use that", i don't know. i think 
probably so, since every code point we allocate will vastly increase the 
amount of testing implementors have to do on every new release.

by the way TFO's payload size is limited, since there's no TCP window 
yet. so, the negotiated TCP/53 keepopen signaling is likely to offer a 
greater benefit, simply by allowing long-lived TCP sessions between DNS 
initiators and DNS responders.
>
> If cookies are longer-lived than tcp sessions, could we use 
> tcp-fast-open with cookies to avoid spoofed source addresses?

if anybody in the TFO world cared about spoofed-source addresses, they 
would have supported RFC 6013 rather than inventing their own thing. so, 
no. (if i sound bitter, you'll see my name in the Usenix ;login: article 
which preceded RFC 6013, so, yes, i am a small bit bitter.)

https://www.usenix.org/publications/login/december-2009-volume-34-number-6/improving-tcp-security-robust-cookies
>
> If all of that would work together, it would be more flexible than 
> either of the above drafts.  But I am probably missing something.

i think you're mostly right-headed on this. the smallest number of 
changes that covers the largest number of use cases is probably our best 
answer.

vixie

-- 
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>