Subject: [dnsext] CD=1 RD=1 response content

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Jul 2010 19:14:37 +0000

i have no dog in the CD=1 race.  when it's set, when it's cleared, or whether
to maintain a separate cache for it, are questions i'm not interested in and
i expect to be equally happy no matter how that thread resolves.  however, i'm
interested in stub validation, which relies on CD=1 in the "last mile" (toward
the stub), and after discussing this with dan kaminsky i've come to realize
that the response content for CD=1 RD=1 leaves a lot to be desired.

basically we need the full chain, not just the RRSIGs for the answer.  to do
stub validation with a limited cache and only the root TA under control of an
RFC 5011 monitor of some kind, we're currently facing a serious performance
challenge iterating all the way back to the root.  some of you have heard me
complain about this before, and recently i saw a proposal here that we add
signalling for this including a "TA" field so that the responder would know
how much of the chain the requestor needed.  i now think that no new
signalling is needed.  RD=1 CD=1 can be redefined to do what we need here,
without invalidating any existing DNSSEC endpoint.

if RD=1 CD=1 responders would add the full RRSIG/DNSKEY/DS chain, deepest
first, to the additional data section of the response, then requestors
would have the option of specifying a very large EDNS0 buffer size and
getting it all.  responders in this case would never set TC=1 since if
there was an overflow it would be in the additional data section and would
be unrelated to the answer.  (obviously the RRsets would still be atomic.)

this *cannot* break any existing RD=1 CD=1 requestors, who must be looking
at owner/class/type when processing additional data sections, and who must
already be prepared to ignore things they weren't specifically programmed
for.

i can imagine a stub validator someday trying TCP first, or using an EDNS0
buffer size of 32KB or 48KB, just to increase the chances of not having to
iterate backward along the RRSIG/DNSKEY/DS chain.  recursive servers can be
placed close to clients and provisioned accordingly, to avoid WAN problems
like dropped IP fragments or overloaded TCP PCB tables.  if we do stub
validation through iteration, then only a change to the speed of light can
restore or improve performance, due to the increased number of RTT's.

if there's general agreement about this, i'll write up an I-D on the topic.

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 12 Jul 2010 16:00:08 -0400

I think its an excellent idea with a couple of caveats:

A stub resolver SHOULD validate that it can receive fragments from the resolver:

Whenever it gets a new IP, it should have a very fast failover to EDNS0 MTU = 1400B on timeout (less than a second), to allow it to quickly determine whether the stub can receive fragments or not, and if it determines it can't receive fragments, shift its default EDNS MTU to 1400B, otherwise RD=1 CD=1 will cause VERY long (3 second+) timeouts.

Also, I disagree on not setting TC.  TC should be set, because that means that a requery over TCP will get more records, and such a query will almost certainly be faster than walking the signature chain manually.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Jul 2010 21:10:25 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Mon, 12 Jul 2010 16:00:08 -0400
> 
> Whenever it gets a new IP, it should have a very fast failover to EDNS0
> MTU = 1400B on timeout (less than a second), to allow it to quickly
> determine whether the stub can receive fragments or not, and if it
> determines it can't receive fragments, shift its default EDNS MTU to
> 1400B, otherwise RD=1 CD=1 will cause VERY long (3 second+) timeouts.

this seems like general advice for edns buffer sizes over some limit, where
if that limit was 1400 then we're asking for changes to the installed base,
and if it's 4096 then we're not addressing your concern at all.  i suggest
that this advice be discussed within the RFC2671bis effort rather than as a
specific RD=1 CD=1 issue.

> Also, I disagree on not setting TC.  TC should be set, because that means
> that a requery over TCP will get more records, and such a query will
> almost certainly be faster than walking the signature chain manually.

but that would redefine TC.  i don't want to muck with the meaning of TC at
all.  the rule is, if the thing that won't fit is additional data, it's up
to the requestor to decide whether to retry with TCP (or EDNS with a larger
buffer size).  making TC mean something different for RD=1 CD=1 would scare
me a bit, not just because of the length and breadth and depth of the
discussion we'd have to have here in DNSEXT, but in the QA that would be
required by implementors to catch this particular version of "meaning of TC".

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 13 Jul 2010 11:11:38 +0900

Paul Vixie wrote:

> however, i'm

What if, there are middle boxes?

Isn't it better to introduce extended ID (DNS-0x20, XQID or whatever,
though I personally recommend a new RR type in additional sections
of queries, which should be copied to answers) than to tweak DNSSEC
for decades and wait additional several aeons expecting all the
existing and new middle boxes adopt for it?

Meanwhile, resolvers can ask name servers without extended ID twice
with different IDs to confirm that the answers are same (or three or
four times to confirm that the answers are randomized for load
balancing, which means answers should not be cached, which means
these is no cache poisoning and extra load of which should motivate
related name server operators adopt extended ID).

Caching middle boxes may still merge the two queries with two IDs
into one with one ID but do not cause more serious problem
than with DNSSEC.

						Masataka Ohta