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