DNSSEC deployment hurdles

[bert hubert]

Dear DNSSEC Deployment community,

As I posted here some weeks ago, PowerDNS is dipping its toes into the
brave new world of DNSSEC. In doing so, we've moved from being an
opposed party to being one with an interest to seeing DNSSEC succeed,
as we'd hate to spend time on technology that is not going anywhere.

To say the least, I personally am a bit worried about the silence
about some very bad datapoints regarding DNSSEC deployment. This
silence can only cause problems, since it leaves the implementation
community uninformed about what is going on. In addition, a lot of
time is currently being wasted by people speculating about solutions
for problems which little is known about.

In short, this message is a request for more data & statistics,
especially from Afilias/PIR and those responsible for .GOV. Rationale
follows:

Data from OARC/Afilias/PIR/.ORG appears to show that, on DNSSEC
deployment, around 2.0% of all incoming UDP queries got converted to
UDP EDNS0 at 512 queries. In turn, 75% of these converted into TCP
queries. Given that almost all of these converted queries came from
the 70% of resolvers running a recent do=1 BIND, from this we can
derive that around 2.0% of queries come from a host that is unable to
deal with >512 byte responses.

In addition, of those 2%, around 25% also can't do TCP, it appears (or
perhaps the EDNS0 at 512 response was not truncated).

Since (on a query basis) almost nobody is running a DNSSEC validating
resolver, the packets that are too large must be the answers that BIND
receives on do=1 queries, and not the answers related to further
DNSSEC processing.

Here are some packet sizes I measured today:

       dnskey  nxdomain (do=1)  unsigned-ref    signed-referral
.org    1334    1013            586             308
.gov    1166    1508            541 [*]         529
.se     1769    681             307             399
.br     749     709             303             ?

(for .gov, it is interesting to note that the whitehouse.gov Akamai
servers give a FORMERR on do=1 queries!)
(note that all .gov do=1 NXDOMAIN responses are fragmented!)

On the IETF DNS mailinglists we've seen a torrent of activity to deal
with the problems of large response sizes, responses which even today
appear too be to big. Where today means, 1024 bit RSA keys and single
signing, with a single algorithm and a single key.

The work observed includes:
* DNS extensions that allow a resolver to select RRSIGs of only one
specified signing algorithm
* TCP/IP extensions that make TCP suitable for DNS use (!!)
* Proposed changes to RFC 1034 to clarify that DNS/TCP servers need
not keep open a connection for 2 minutes
* Proposed changes to RFC 1034 to make DNS/TCP mandatory
* GOST elliptic curve algorithm (which might deliver smaller signatures)
* SCTP experiments
* EDNS "Paging" to allow one big response to be spread out over
several UDP datagrams (versus several UDP packets)

I probably missed a few other things going on. This is clearly a lot
of activity.

The problem is that from the IETF side of things, we (or at least, I)
operate in a hard vacuum of no data. From the chart above, it is
apparent that the issues seen over at .ORG should also be occurring,
even more frequently, for .GOV, and to a lesser extent for .SE and
.BR.

These problems need to be resolved or at least analysed in depth in
order for DNSSEC to become feasible to deploy.
For example, if we see 2% of the internet unable to deal with 1013
byte responses, we can wonder how many can deal with 1508 byte
responses. This number determines if we'll ever have the option to
move to >1024 byte ZKS, or to SHA256, or if we'll be able to perform
double signing (for emergency key rollover, or for multiple algorithm
support).

If these numbers point in the wrong direction, it is time for a
serious rethink. A rethink that might as well be starting earlier than
later.

Please do not interpret this message as 'DNSSEC bashing'! But I do
want to say that the lack of list traffic about the important issues
mentioned above is worrying.

I hope and trust that the DNSSEC deployment community is willing to
ponder these issues, and come up with numbers that will guide the
discussion.


Kind regards,

Bert Hubert
PowerDNS.COM BV