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

[Paul Vixie <[e-mail]>]

> Bob Harold <mailto:[e-mail]>
> Friday, April 29, 2016 06:44
>
>
>
>     On 29/04/2016 02:01, Jiankang Yao wrote:
>     > Dear all,
>     >
>     >       We submit a draft about "A DNS Query including A Main Question
>     > with Accompanying Questions".
>     >
>     >        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 <http://example.com> and www.example.com
>     <http://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
>
>
> I am assuming that the benefits here are:
> - reduced number of packets
> - reduced total bytes
> - possibly reduced round trips

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

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>