william(at)elan.net wrote:
On Wed, 27 Jul 2005, Jim Fenton wrote:
Public keys stored in DNS records are much larger than DNS records
used for address lookup and other typical DNS usages. Caching DNS
resolvers should limit the amount of memory consumed by the cache,
and more memory may be necessary to restore caches to their
previous effectiveness.
I agree with this, but the difference isn't as great as it might seem
at first glance. A query of nebraska._domainkey.cisco.com (TXT)
returns a 342 byte result, but www.cisco.com (A) returns 83 bytes and
cisco.com (MX) returns 426 bytes.
That is because your DNS server is configured to send ip addresses of all
your mx servers in additional section. Whilte this is helpful to a
degree, this is not a typical response to mx by dns servers (you don't
really need
to know EVERY MX ip when doing query, just one is enough).
I haven't yet found a domain that works as you describe. I did a single
"dig elan.net mx" and my DNS cache got populated with 4 NS, 4 MX, and 8
A records.
I'm not enough of a DNS geek to know if all that data is stored in
the cache.
Yes, but in different way. In particular each of those A records and MX
would be stored as separate cache entry. Cache in DNS servers is also
expecting small dns data, so large one-record data in dns cache could
slow it down depending on cache server architecture.
It could, but I would normally expect a cache to slow down more easily
with a large number of small records (more keys to search).
It seems like the difference isn't orders of magnitude.
Difference in what?
Difference in the size of the response. It's not like we're making a
factor-of-10 difference in the amount of data returned from a typical query.
This was the main reason that the shorter DNS records used by IIM for
key verification were less of an advantage than we at first thought.
IIM also proposed putting fingerprint as part of dns record query, I
don't think this is optimal way to do it either as it causes larger
then needed queries (and the query is repeated in response as well,
which nullifies
advantage of not having to use selector and saving of couple bytes
there).
Yes, we could have made the response a little bit shorter, but we still
had a lot of fixed overhead from things like the authority section of
the response.
Anyway, we're splitting hairs here. I agreed with Andy's text, and we
should probably take any further discussion on this off-list.
-Jim