Home page logo
/

nanog logo nanog mailing list archives

Re: DNS caches that support partitioning ?
From: Jimmy Hess <mysidia () gmail com>
Date: Sat, 18 Aug 2012 07:44:48 -0500

On 8/17/12, Michael Thomas <mike () 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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault