[dns-operations] reopening discussion of stalled i-d: draft-ietf-dnsop-edns-chain-query

[Paul Vixie]

> Tony Finch <mailto:dot at dotat.at>
> Monday, December 01, 2014 1:59 AM
> Paul Vixie <paul at redbarn.org> wrote:
>>> ...
>> so, you're willing to send a query for every ancestor domain, even the
>> ones that turn out not to be zone cuts.
>
> 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.

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.

>> 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.
>
> Those are fair complaints. However your initial reason was latency, but
> chain queries do not improve latency compared to the current protocol.
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.
> ... And chain queries will often require TCP so your TCB complaint applies to them
> as well.
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.

> ... (And if you start with UDP and have to do a TCP fallback you lose
> the latency benefits.)

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.

-- 
Paul Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141201/51badb89/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141201/51badb89/attachment.jpg>