Automatic key verification / CERT in DNS / RFC4398

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


-----BEGIN PGP SIGNED MESSAGE-----
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" 
protocol.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEN5EVwL7PKlBZWjsRAoeaAJ0UVQmGk+2NrtNT7be8sUSAUrfiDwCg938A
MXvtGFOjma2ei117DVzPdsk=
=qs8/
-----END PGP SIGNATURE-----



More information about the Gnupg-devel mailing list