db.cache (DNS)
  db.cache (DNS) - Home  

  Part of Home site:
  http://akakul.co.uk/

  Scripts Home

Summarizer Summarizer
RAQ RAQ File Convertor
FAQ
Useful Links
db.cache (DNS)
CPU Temp Alert
Resolving NS Check
OverQuota Check


 

Welcome to the home of Kuls 'db.cache (DNS)' scripts

This section deals with DNS db.cache files on Cobalt/Sun RaQ3's & RaQ4's specifically, though is EASILY customizable to regular Linux machines....if the db.cache file (or similar) is not auto-updated.



Receiving messages like this from your /var/log/messages log file?
date host named[nnnn]: check_hints: A records for J.ROOT-SERVERS.NET class 1 do not match hint records?

I had been searching around for a couple of hours the night this all changed, and some more the neext day, and found almost nothign except an obscure reference to the problem highlighted above.
There does not seem to be any BIG annnouncement, but I found this reference at slashdot:

    http://slashdot.org/articles/02/11/07/1613256.shtml?tid=95 reads....
  • Posted by michael on Thursday 2002 November 07, @03:01PM
    from the verisign-causing-instability-as-usual dept.

    An anonymous reader writes "The day before yesterday the root zone was silently changed for the first time in 5 years. The change was to J.ROOT-SERVERS.NET that is now managed by Verisign. The usual sites don't breathe a word about this change however as one would expect for such a change to be properly announced. An interesing sidenote is this thread on the IETF discussion list." the_proton writes "The server j.root-servers.net has changed IP address to 192.58.128.30. The new root zone hints can be grabbed from ftp://rs.internic.net/domain/named.root or ftp://ftp.internic.net/domain/named.root. The new zone serial number is 2002110501."


I did also find a couple more claiming to be emails from craig@iana. But strangley nothing officially announcing or clarifying the first change to the root servers IP's in about 5 years. Well none that i can find !!

So what does it all mean?
It often means what it says...you are out of date, and is best to sort out if possible, as your server will be slightly slower at resolution for domains it cant find locally or in its search servers.

This can happen if/when your local db gets out of sync with the root nameservers. It can also happen if your server cant connect to one of the nameservers correctly.

If your server's db.cache/named.root is really is out of date, you could force an update manually to your local cached copy.

How to fix this:

RaQ3 & RaQ4 compatible, with ANY subsequent version of BIND on the RaQ's.

Well this is easy for Cobalt/Sun RaQ3/4's, by using this quick and simple PKG I wrote that can be installed through the web interface: http://scripts.akakul.co.uk/db.cache/UK2Raq.com-db.cache.1.0.3.pkg

This .pkg is for those that dont like SSH/Telnet :)
If a ROOT Nameserver changes its details this is required - unless you like errors and weird things happening with http/email and such. This PKG/Script *may* be installed/run mutiple times !!

This PKG will ONLY update the db.cache file if it is NOT current. There is also a delayed delete script placed in /etc/cron.quarter-hourly/ that will REMOVE the pkg and itself within 15minutes of being installed. This *IS* removed as it is a ONCE only script that does the update, and is no longer needed. Also this means that should the ROOT NameServers be updated again, you can re-install the SAME pkg and it will not complain it is already installed.
This Package is safe to run as many times as you like, it ONLY makes changes IF the db.cache file is out of date.

*OR*

Follow these instructions to acheive the same Goal:
Log into your raq3/4 as root

su -

{ENTER YOUR ROOT PASSWORD WHEN PROMPTED}

cd ~
wget ftp://ftp.rs.internic.net/domain/db.cache
grep -v "^;\|^$\|^\." db.cache | sort > db.cache.new
grep -v "^;\|^$\|^\." /etc/named/db.cache | sort > db.cache.old
diff db.cache.new db.cache.old

Now if you see ANY results from that last command, then your db.cache file is out of date and you should perform the following:

cp /etc/named/db.cache /etc/db.cache.bak-`date +%Y%m%d-%H%M%S`
cat db.cache.new > /etc/named/db.cache
/etc/rc.d/init.d/named restart

NOW tidy up:

rm db.cache.old db.cache.new db.cache
Refernces:

 © akaKul.co.uk