> 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 ualbanytest.org.db
> -rw------- 1 named named 9969 Nov 16 12:04 ualbanytest.org.db.signed
> -rw------- 1 named named 13095 Nov 16 11:52 ualbanytest.org.db.signed.jnl
The journal file is expected. When named updates a zone internally (as
it's doing with the signed version of the ualbanytest.org 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 ualbanytest.org.db.signed.jnl has been
modified. If you run "named-journalprint ualbanytest.org.db.signed.jnl",
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 "ualbanytest.org" {
type master;
file "ualbanytest.org.db";
also-notify { 127.0.0.1; };
allow-transfer { any; };
};
};
view "public" {
match-clients { any; };
zone "ualbanytest.org" {
type slave;
file "ualbanytest.org.slave.db";
masters { 127.0.0.1 key secretkey; };
auto-dnssec maintain;
inline-signing yes;
key-directory "/conf";
};
};
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
