Hope you like it..

How to automatically sign the RRSIG in DNSSEC Zones.

For those who are working with CRON jobs would have realized that */20 for the day place holder in crontab , will be taking the Calendar Days only or in other words 20th of Every month. However , my requirement was to run a batch job every N days since the last run. After several hours of Googling I came across this Blog (https://backreference.org/2013/08/25/run-cron-job-every-n-days/index.html.) which do exactly what I was looking for.

In this post , I will leverage this approach to renew my RRSIG once in every 25 days. Below is the extract from the original website.

====================================================================

Let’s say we want to run a job every N days, or weeks, regardless of month or year boundaries. For example, once every three tuesdays, or once every 17 days, or whatever.

Cron itself (at least the variants I have access to) has no way to specify these time periods, so it would seem this could not be done.

But there’s a simple way to do it. It is based on modular arithmetic and on the fact that we know that measurement of time on Unix starts on a concrete date, which is the well-known January the 1st, 1970 (also known as “the Epoch”). For the remainder, I’m assuming UTC and a running time of midnight for simplicity; it should be easy to consider the appropriate time differences where needed.

With this kind of requirement we need to have an actual starting date for the job, that is, when it has to run for the first time, so we can use it as a starting point for the “every N days” intervals.
Once we have an actual date of first execution for our task (say, 2013-01-15, a Tuesday, at 00:00), we can divide the time passed since the Epoch until our date into groups of N days. For this first example, let’s say N == 14, two weeks. With the following calculation we can see which place our starting day occupies in a period of 14 days (two weeks):

Dividing by 86400 gives the number of days passed since the Epoch, from which the modulo 14 is calculated. The result is 11, which tells us that at any given time, performing the above calculation using the current date will yield 11 only on $startdate, of course, and on every second Tuesday (well, every 14 days, which is the same) starting from $startdate (or going backwards from $startdate, which is not important here). Simple test code to show that it’s true:

Sample run:

So there we have it, every second Tuesday starting from 2013-01-15. The code shown in modcheck.sh can be made generic so that values can be passed from the command line:

Another test: let’s say we want every fifth day starting from 2012-12-02. Let’s calculate the modulo first:

And let’s verify it:

So to use all this in our crons, we need to know the starting date, the frequency (every N days) and calculate the modulo. Once the modulo is known, we run the job if the modulo calculated for “now” (when the job is invoked) matches the modulo we want. So for instance if the period is 13 days and the modulo we want is 6, in our script we do:

Or as usual it can also be done in the crontab itself so the script does not need to have special knowledge (it may not even be a script, so in that case the check would have to be external anyway):

Note: so far, it doesn’t seem to have trouble with DST time changes. Corrections welcome.

====================================================================

Below is a screenshot of my Crontab , I am using to resign the RRSIG once in 25 Days.

That’s it and Let me know your thoughts in the comments section.

October 23, 2023 at 10:41 am Leave a comment

rndc dumpdb -all
grep problem.domain /var/named/data/cache_dump.db

(The location of the cache_dump.db may be varied based on the bind configuration)

dig +norec <ip address of nameserver> <name> <type>

rndc flushname name

rndc flushtree name

rndc flush && rndc reload