Bob Harold <mailto:rharo...@umich.edu>
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>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
