RE: Scalability of keys

From: Murray S. Kucherawy <>
Date: Wed, 4 Aug 2010 12:08:18 -0700

> -----Original Message-----
> From: [mailto:opendkim-users-
>] On Behalf Of Zenon Panoussis
> Sent: Tuesday, August 03, 2010 4:20 PM
> To:
> Subject: Re: Scalability of keys
> BIND works wonderfully with LDAP. All my zones have been served by BIND
> out of an LDAP back-end since 2003. Indeed, when this posting hits the
> opendkim mail server, that server will make a DNS query to my BIND to
> get my public key, and my BIND will fetch it fresh from LDAP before it
> replies, no reloads involved. And BIND works the same way with MySQL
> too.

Wow, that got past me. I didn't realize bind had those interfaces.

Your arguments seem pretty sound. Some additional comments, just for the sake of being thorough:

> If DNS were to be replaced, the replacement should be at least as fast
> and
> lightweight and globally referenced.

The argument against use of DNS, mostly from the DNS operations people, from the beginning was twofold: (a) that's not what the DNS is for; and (b) it will create undue load on the DNS infrastructure. The first is a religious argument, but the second is unknown still as DKIM hasn't got as wide a deployment as would be sufficient to gauge its true impact.

> Keys on the web, on the other hand, would first require a DNS query in
> order
> to find the webserver to query for the key, and then an HTTP
> transaction for
> the key itself.

In theory, the A or AAAA query for the key server would be cached, and since (also in theory) most signed mail comes from a small number of common sources (the big ESPs and big senders), the DNS impact would ultimately be minimal. And if a domain signs with multiple keys, the A or AAAA query is the same for all keys rather than having to query and cache a TXT for every selector the receiver sees.

> With the TCP overhead of the web query, this gets
> expensive.

With many sites trending toward larger keys, the DNS work would involve a UDP query whose reply comes back truncated, necessitating a second TCP query anyway.
Received on Wed Aug 04 2010 - 19:08:26 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:19:48 PST