Bind 9.9.0B1 Inline-Signing Question

McConville, Kevin kmcconville at
Thu Nov 17 18:37:27 UTC 2011


  Thank you for responding. Unfortunately, it seems that the journal file isn't getting updated when we manually edit/increment the static zone file. The time/date stamps are off - both and show Nov 16 while the static zone file modified today shows as Nov 17.

When I do a: named-journalprint, it only shows information from yesterday.

Doing a "dig +dnssec" and also nslookup doesn't show the newly added record either.

Would running it in a chroot jail have any impact on it?

You mentioned using the rndc reload in a previous post so I have been using that since you mentioned it. Even stopped using kill or named stop - have only used rndc stop to stop the service.



Kevin McConville
University at Albany

-----Original Message-----
From: Evan Hunt [mailto:each at] 
Sent: Thursday, November 17, 2011 12:27 PM
To: McConville, Kevin
Cc: bind-users at
Subject: Re: Bind 9.9.0B1 Inline-Signing Question

> We edit the static zone, adding a resource record (of any type), 
> increment the serial, and then do a rndc reload. However, Bind is 
> still looking at the previous dnssec signed file - it's not picking up 
> the new records.  Another strange thing is that using the auto-dnssec 
> maintain option, it is still creating a journal file -

You're sure?  "dig +dnssec" doesn't return those records?

> -rw-rw-r-- 1 named root   2250 Nov 17 11:29
> -rw------- 1 named named  9969 Nov 16 12:04
> -rw------- 1 named named 13095 Nov 16 11:52 

The journal file is expected.  When named updates a zone internally (as it's doing with the signed version of the zone), it records the changes first in a journal file, and then syncs them to the zonefile later.

After updating the static file and bumping the serial number and running "rndc reload", you should see that has been modified.  If you run "named-journalprint", the last few lines should be the new changes you've made to the static zone, their associated DNSSEC records, and a new SOA.  "dig +dnssec"
should return the new data.

If you've updated the static file and then restarted named, however, instead of using "rndc reload", then the signed and unsigned zones fall out of sync and this is exactly the behavior you'd see.  This is a known problem in 9.9.0b1 and we plan to fix it before 9.9.0 final.

> Doing an rndc stop, removing the signed and signed.jnl files, the new 
> resource records are picked up when named is restarted. But, that 
> defeats the point of inline-signing.

Agreed.  Until we fix the out-of-sync problem, I'd only be comfortable using inline-signing on a slave zone.  As a temporary kluge until it's fixed, you might consider using a hidden view that holds the master zone, a publicly accessible view that holds a slave copy, and inline-signing the slave, not the master.  The advantage is that the zone being inline-signed can *only* be updated by a successful zone transfer, not by anyone editing the master file, so there's less risk of it falling out of sync.  The disadvantages, obviously, are complexity and memory use.  I haven't tried this, but it ought to work--something like this:

        key "secretkey" {

        view "hidden" {
                match-clients { key secretkey; };
                zone "" {
                        type master;
                        file "";
                        also-notify {; };
                        allow-transfer { any; };

        view "public" {
                match-clients { any; };
                zone "" {
                        type slave;
                        file "";
                        masters { key secretkey; };
                        auto-dnssec maintain;
                        inline-signing yes;
                        key-directory "/conf";

Evan Hunt -- each at
Internet Systems Consortium, Inc.

More information about the bind-users mailing list