Entry

How do you expire a record from dnscache?

Aug 22nd, 2005 09:54
Paul Jarc, Paul Theodoropoulos, Brian Coogan,

Occasionally an A record (giving an IP address for a hostname) may 
change, but dnscache will still have an old IP address cached for it.  
If you can't afford to wait until the cache entry expires in due 
course (which is the simplest solution!), you can simply restart 
dnscache which will completely flush the cache for you:
     svc -t  /service/dnscache
This may not always be convenient;  in particular you may have a large 
cache which you don't really want to lose (see notes below though), or 
have production reasons why shutting down dnscache even momentarily is 
not a good idea.  Or, you may simply want to get rid of a single 
cached record quickly on a one-off basis.
In that case you should use the following horrible hack to allow you 
to replace an old cached entry for www.example.com with a newer cached 
entry.
The hack to force expiration of the single cache entry www.example.com 
is to add a record patterned after the following, replacing these 
example records with your corresponding records:
     .foo.example.com::www.example.com:0
'foo' should be any random, not-currently-existing record. you could 
use asdf.example.com, blah.example.com - whatever.
write the record to your data file; 
run make; 
perform the following lookup:
    'dnsqr ns foo.example.com'
edit your data file again and remove the record just added; 
run make again.
Rob Mayoff explained how this works thus:
When you request the NS for foo.example.com, dnscache will 
forward the request to the tinydns of example.com. Tinydns will put 
the (new) A record for www.example.com in the additional section of 
the response. Dnscache will replace its cached A record for 
www.example.com with the new one because tinydns is authoritative for 
example.com.
[This tip originally came from Dan Bernstein via Paul Jarc.]
Another solution to this is to consider using Florent Guillame's patch 
which allows you to save and reload the cache on restart.  You could 
save the cache, delete the offending entry manually, then restart 
dnscache and reload the new cache entry.  See http://tinydns.org 
for details of the patch.
A more stable solution in the long term is to structure your DNS 
architecture so that you have a small forwarding dnscache in front of 
the real dnscache.  The forwarding caches would talk to your local 
tinydns instances and you could flush cache entries for local data 
easily by restarting the forwarding caches at any time, without losing 
your cached data which would be retained by your real dnscaches.  At 
least one large ISP uses this technique with great success, allowing 
them to make frequent changes without losing their large accumulated 
cache.  Note that this technique has the side-benefit of lending 
itself to beautifully simple load balancing.
Matt Simerson details his experience with the small forwarding 
dnscache technique in his mailing list article archived at:
  http://marc.theaimsgroup.com/?l=djbdns&m=99498145100484&w=2