Automatic key verification / CERT in DNS / RFC4398

Julian Mehnle julian at
Sat Apr 8 12:31:49 CEST 2006

Hash: SHA1

Brad Knowles wrote:
> 	Recall that there are a whole multitude of horribly broken
> resolvers and nameservers out there, many of which will re-query for
> the same information at least once per second, ad infinitum --
> regardless of whether or not you have answered their query in the
> previous second.
> 	Recall that there are these things called "TTLs" which are placed
> on DNS records, and poorly chosen TTLs could, all by themselves,
> cause a massive increase in load on the server & clients in question.
> 	Recall that if you try to cache the entire Internet, you're
> likely to run out of disk space.
> 	Everything about this problem screams for a solution that does
> *NOT* involve the DNS.  At the very least, does not involve the DNS
> except in some peripheral manner, such as using SRV records to tell
> people where your crypto key storage server is located and how to
> access it.

How are any of the above problems specific to DNS?

For example: s/DNS/HTTP/, s/record/resource/, s/resolver/HTTP client/, 
s/nameserver/HTTP proxy/, s/TTL/Expires: header/ -- so what's changed in 
your above assessment?

Maybe I am just missing the obvious, better choice of a non-DNS, non-HTTP 
protocol for this purpose, but I think the problems you pointed out are of 
a fundamental nature and can hardly be solved by choosing a "better" 
Version: GnuPG v1.4.2.2 (GNU/Linux)


More information about the Gnupg-devel mailing list