Subject: [dnsext] Rethinking the security too large for UDP problem

From: William Allen Simpson <[email-masked]>
Date: Tue, 11 Aug 2009 01:36:47 -0400

I'm already on record elsewhere in support of dnsssec-algo-signal-03,
as that may very well solve most packet too large problems.

But in the hopefully rare cases, there's simply not enough information
to autonomously make a deterministic decision about the next step.

What we really need to know:

  1) The security algorithms supported.  Easy.  The Algorithm Understood
     (AU) option could be passed in the response, with a list of all the
     available algorithms.  That means the truncation routine should
     ensure there's enough room for the option.

  2) The RRTypes of the truncated records.  I just don't see how to pass
     that in the current protocol.  If we knew this, we could just ask
     for the rest of the records by type.

  3) The total size of the untruncated data.  Again, I just don't see how
     to pass that in the current protocol.  If we knew this, we could
     decide whether TCP is required, or 2 or 1 should be done instead.

  4) Ideally, the size of the untruncated security data per algorithm.

Any ideas?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: William Allen Simpson <[email-masked]>
Date: Tue, 11 Aug 2009 12:02:33 -0400

> to autonomously make a deterministic decision about the next step.
After sleeping on the idea, I'm pretty sure that we can limit the scope
to only those queries that already have the EDNS0.  Without it, all
implementations will already go directly to TCP -- do not pass Go -- do
not collect $200.

>     ensure there's enough room for the option.
It seems reasonable that the EDNS0 response could *always* list the
Algorithm Understood (AU) option.  It doesn't take much space, and it
could be useful even without the DO bit set, to help formulate future
queries (indicating that the AU option is understood, *and* security
records are available).

>     for the rest of the records by type.
Proposing a new TRUNCATED option for DNS0, listing each truncated
RRType, and the size of the buffer needed to contain them.  As above,
the truncation routine should ensure there's enough room for the option.

This simple extension could be a really big win, as it could rapidly
indicate whether relevant records could be gathered with fewer UDP RTT
than TCP (minimum 3 RTT).

Each query can have more than one RRType, so it can be estimated for fit.
(But, the code might be fairly complex.)

>     decide whether TCP is required, or 2 or 1 should be done instead.
That could be determined by adding the records already received, and
the list of others not received (above).

>  4) Ideally, the size of the untruncated security data per algorithm.
Probably too hard.  If the second UDP request for a desired limited set
of algorithms is truncated, 2 RTTs have passed, try TCP instead.

> Any ideas?
I'd consider proposing a generic SIZE RRType for the Additional section to
solve #3, that could be cached, and would rapidly indicate whether UDP or
TCP should be used for future queries.  But then I realized that there has
to be a UDP request to get the SIZE.  Might as well get real data at the
same time, and not waste the round trip.