Simple addition

To add some records to the bar.com.au domain at 2AM the following Friday, you can simply:

# cd /home/cron/named/at.d
# vi YYYYmmdd02.bar.com.au

where YYYYmmdd02.bar.com.au might contain:

:
cat <<!EOF! >> hosts/bar.com.au.db
fu  IN      A       192.168.1.1
foo IN      A       192.168.2.1
...
...
!EOF!

Change of address

A change of IP address is a more interesting example. The simple approach will do for many folk:

       # cat /home/cron/named/at.d/YYYYmmddHH.fu
       :
       perl -p -i.bak -e 's/192.168.1\.1($|[^\d])/192.168.2.2/' hosts/bar.com.au.db

or if you prefer::

       # cat /home/cron/named/at.d/YYYYmmddHH.fu
       :
       perl -p -i.bak -e 's/192.168.1\.1/192.168.2.2/ if (m/^fu\s/)' hosts/bar.com.au.db

Note that one must be careful to only change the intended address.

Often when a host changes IP address it is desired that the change propagate quickly. If all the nameservers for the domain run BIND-8, then this is quite simple, to make it clearer assume we which to change the address of fu.bar on Jun 13, 1997 at 4am and that the zone refresh time is 1 hour and the default time to live is 4 hours:

# cat /home/cron/named/at.d/1997061222.fu
:
perl -p -i.bak -e 's/^(fu\s+)\d*\s*IN/${1}300 IN/i' hosts/bar.com.au.db

# cat /home/cron/named/at.d/1997061304.fu
:
perl -p -i.bak -e
's/^(fu\s+)\d*\s*(IN\s+A\s+)192.168.1\.1/$1${2}192.168.2.2/i' hosts/bar.com.au.db

With the above, the TTL for the fu A record is reduced to 300 seconds at least 4 hours before the cut over. Then at 4am we remove the TTL qualification and update the IP address.

If the master and all the slave nameservers are running BIND-8 or later, they will pick up the zone change immediately and any host that had looked up fu.bar.com.au will pickup the change within 300 seconds.

SOA changes

If in the example above, one or more nameserver runs BIND-4 (they probably shouldn't be on the Internet ;-), then it is necessary to play with the zone's refresh time in addition to the TTL of the individual A records.

The SOA records are NOT under CVS so they must actually be edited in the live DNS tree! This alone is a good reason to upgrade to BIND-9. But for the die hards something like:

# cat /home/cron/named/at.d/1997061222.fu
:
perl -p -i.bak -e 's/00/0/ if (m/refresh|retry/i)' \
/var/named/hosts/bar.com.au.soa
perl -p -i.bak -e 's/^(fu\s+)\d*\s*IN/${1}300 IN/i' \
hosts/bar.com.au.db
updsoa /var/named/hosts/bar.com.au.soa

will do the trick assuming that the .soa file was created by updsoa(8) the fact that the .soa file contains little other than the SOA record simplifies things greatly. Again note that it is the .soa file in the live tree that needs to be updated.

Scheduling

Obviously the commands can be as simple or as complex as you like. The important thing is that atjobs will execute that file the first time it (atjobs) is run after the time identified by the leading YYYmmddHHMMSS specification. Thus if your hourly cron job runs at HH:20 then the above job will run at 02:20 on the date specified but if it were named YYYYmmdd0230, then it would not be run at 02:20 but more likely at 03:20.

Sometimes changes need to be run with finer granularity. There is nothing to stop you setting up a cron job that runs every five minutes. Using the appropriate jobs as described in DNS Magic cronjobs will ensure that the DNS data is updated appropriately.

The lastest version of this page can be found at:

http://www.crufty.net/help/dns/atjobs.htm