Automatic key verification / CERT in DNS / RFC4398
julian at mehnle.net
Sat Apr 8 12:31:49 CEST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v184.108.40.206 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Gnupg-devel