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