<html><head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
<blockquote style="border: 0px none;"
cite="mid:alpine.LSU.2.00.1412010948090.26100@hermes-1.csi.cam.ac.uk"
type="cite">
<div style="margin:30px 25px 10px 25px;" class="__pbConvHr"><div
style="display:table;width:100%;border-top:1px solid
#EDEEF0;padding-top:5px"> <div
style="display:table-cell;vertical-align:middle;padding-right:6px;"><img
photoaddress="dot@dotat.at" photoname="Tony Finch"
src="cid:part1.01050806.09080301@redbarn.org"
name="compose-unknown-contact.jpg" height="25px" width="25px"></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a moz-do-not-send="true" href="mailto:dot@dotat.at"
style="color:#737F92
!important;padding-right:6px;font-weight:bold;text-decoration:none
!important;">Tony Finch</a></div> <div
style="display:table-cell;white-space:nowrap;vertical-align:middle;">
<font color="#9FA2A5"><span style="padding-left:6px">Monday, December
01, 2014 1:59 AM</span></font></div></div></div>
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><pre wrap="">Paul Vixie <a class="moz-txt-link-rfc2396E" href="mailto:paul@redbarn.org"><paul@redbarn.org></a> wrote:
</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">...
</pre></blockquote><pre wrap="">so, you're willing to send a query for every ancestor domain, even the
ones that turn out not to be zone cuts.
</pre></blockquote><pre wrap=""><!---->
That will usually be only one, and the server will have to send back a
proof of no zone cut whether you ask for it separately or as part of a
bulk query.</pre></div>
</blockquote>
<br>
a negative proof would span the empty nonterminal, so, no separate proof
there. use "dig vix.su nsec" to see what an NSEC looks like when the
next name is a subsubdomain and the intervening subdomain (lah1.vix.su
in this case) is empty.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:alpine.LSU.2.00.1412010948090.26100@hermes-1.csi.cam.ac.uk"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody"><blockquote
type="cite"><pre wrap="">you're also willing to transmit microburst UDP, or to depend on RDNS
servers having effectively unlimited TCB capacity. i am not hip to any
of that.
</pre></blockquote><pre wrap=""><!---->
Those are fair complaints. However your initial reason was latency, but
chain queries do not improve latency compared to the current protocol.
</pre></div>
</blockquote>
<span>if i can't use UDP microbursts because of buffer overruns all
along the
path, then my complaint about latency stands-- i'd have to synchronize
my queries to something other than "back-to-back". granted, i could send
them at 100ms intervals, or some other blind estimate, but then we'd
have a total latency which is worse with the current protocol than with
"chain" queries.<br>
</span>
<blockquote style="border: 0px none;"
cite="mid:alpine.LSU.2.00.1412010948090.26100@hermes-1.csi.cam.ac.uk"
type="cite">
<div style="color: rgb(136, 136, 136); margin-left: 24px;
margin-right: 24px;" __pbrmquotes="true" class="__pbConvBody">
<pre wrap="">... And chain queries will often require TCP so your TCB complaint applies to them
as well.</pre>
</div>
</blockquote>
not so, because of your word "often". when we start with UDP and then
fall back to TCP only if TC=1 and the data we need isn't present in the
truncated response, then it would take a rather high percentage of
tcp-requiring queries to overrun the TCB quota on either the initiator
or the responder. two other notes, to properly evaluate this
risk/benefit system: (1) it's possible that we don't need more data than
was received in the truncated response, or that we can get the part
we're missing without repeating the same query but-with-TCP; and (2) TCB
quotas on the responder side are a finite resource and therefore an
attack surface; without RFC 6013 state compression, it will always be
possible for an attacker to see to it that TCP/53 is unavailable, even
under the dickenson proposals recently floated.<br>
<br>
<blockquote style="border: 0px none;"
cite="mid:alpine.LSU.2.00.1412010948090.26100@hermes-1.csi.cam.ac.uk"
type="cite">
<div style="color:#888888;margin-left:24px;margin-right:24px;"
__pbrmquotes="true" class="__pbConvBody">
<pre wrap="">... (And if you start with UDP and have to do a TCP fallback you lose
the latency benefits.)
</pre>
</div>
</blockquote>
<br>
yes. however, i think we're all assuming that since CHAIN is an EDNS
option, that EDNS BUFSIZE will be at least 1500. with careful DNSKEY
management so that there aren't too many signatures present per node,
the only part of the namespace where we're almost sure to need TCP is in
IP6.ARPA which is very deep.<br>
<br>
<div class="moz-signature">-- <br>Paul Vixie<br>
</div>
</body></html>