Murray S. Kucherawy wrote:
> In a conversation I was having with someone at the IETF last week, the
> idea came up of having DKIM keys retrieved in a way other than the DNS.
> In particular, apart from something like PowerDNS, there aren’t many DNS
> implementations that allow data to be served from within an SQL or LDAP
> database. This means adding a key for a new domain involves creating or
> updating a zone file, incrementing a serial number and requesting a reload.
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.
> On the other hand, most or all web servers have plugins that enable them
> to become SQL- or LDAP-capable. That means storing keys in such
> databases is easily interfaced to web servers. So perhaps that means
> serving DKIM keys via a web server rather than via the DNS is something
> the DKIM community should explore.
The one does not exclude the other for informational purposes, and indeed
nothing stops us from publishing keys on the web, but there must be at
least one standard method which *always* works. Now it's DNS because it's
very fast and lightweight compared to its alternatives, but also because
DNS is the only system that has an established truly global referencing
infrastructure, so that any domain can always rely on DNS to find information
about any other domain.
If DNS were to be replaced, the replacement should be at least as fast and
lightweight and globally referenced. Native LDAP would be a decent candidate
on the "fast and lightweight" parts, but a terrible loser on the "globally
referenced" part. Refrencing has been technically possible in LDAP for years,
but the way people all over the world have built their LDAP trees, it is
unfeasible in reality.
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. With the TCP overhead of the web query, this gets expensive.
And it introduces an additional point of failure. In classic DNS, if DNS
fails you're fried. In DNS with an LDAP back-end, if either fails you're
fried. In a web-based system with an LDAP back-end, if any of DNS, LDAP or
HTTPd fails, you're fried. In my view, this is an unnecessary bigger risk.
So, all in all, considering that sysadmin convenience is the sole subject of
this thread, I think that DNS-LDAP (or scripting around the small annoyances
of pure DNS) is the better alternative.
Z
Received on Tue Aug 03 2010 - 23:20:04 PST
This archive was generated by hypermail 2.3.0
: Mon Oct 29 2012 - 23:19:48 PST