DNS caches that support partitioning ?

Sat Aug 18 12:44:48 UTC 2012

On 8/17/12, Michael Thomas <mike at mtcc.com> wrote:
> If the dnsbl queries are not likely to be used again, why don't they
> set their ttl way down?
Because the DNSBLs don't tune the TTLs for individual responses; they
likely still benefit from extended caching,  high TTLs for responses
makes sense for controlling load on the DNSBL servers,   and your
cache efficiency is not the DNSBL operators' problem.  There are
/some/  IP addresses that generate a lot of mail;  and I would suggest
there are /plenty/ of low-traffic recursive DNS servers in the world
that may still make DNSBL queries.

The  /real/ problem to be addressed is the poor caching discipline
used by DNS recursive servers.      A recursive server with
intelligent caching,  would not simply allocate a chunk of heap space
and hold for TTL, and when assigned cache space runs out, evict the
oldest query,  when space is short,  eg.  Least-Recently Hit cache
entry;LRU; Least-Recent RR Response; Least-Recently Queried;  or
Lowest-Remaining TTL,
are all naive.

An intelligent recursive DNS caching system would leverage both RAM
and Disk when appropriate,  store the cache efficiently and
persistently,  keep track of  cache evictions  that occured,  and the
number of times a RR  was requested   would factor into  not only
avoiding eviction of the cache,  but  for popular RR,   it would make
sense for the  recursive DNS server to make a pre-emptive query,   to
refresh a RR  that is about to expire due to TTL,

So that the response latency for some random time that RR is queried
in the future doesn't go up due to the cache entry expiring.

And I say that, because some very popular RRs have insanely low TTLs.

Case in point:
www.l.google.com.	300	IN	A	74.125.227.148
www.l.google.com.	300	IN	A	74.125.227.144
www.l.google.com.	300	IN	A	74.125.227.146
www.l.google.com.	300	IN	A	74.125.227.145
www.l.google.com.	300	IN	A	74.125.227.147
www.l.google.com.	300	IN	A	74.125.227.148

> In any case, DNSBL's use of DNS has always been a hack. If v6
> causes the hack to blow up, they should create their own protocol
> rather than ask how we can make the global DNS accommodate
> their misuse of DNS.
>
> Mike
[snip]

--
-JH