Bind 9.9.x operation with dnssec

Alan Batie alan at peak.org
Fri Jun 1 23:25:03 UTC 2012


I'm a little confused wading through the massive amount of detail about
dnssec, and have two main questions:

1.  General key management
2.  Specific problems with my test domain setup (raindrop.us)

For general key management:

With "auto-dnssec maintain", I expect the Zone Signing Keys and the
individual RRSIGs to be completely managed and rotated as needed by
bind, per
https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-Examples.html
and the Admin Reference, however, at the end of 4.9.7, it says:

"By default, this rollover completes in 30 days, after which it will be
safe to remove the old key from the DNSKEY RRset."

This implies that I'm going to have to go in and do housekeeping in the
keys directory, though I'm not sure when - I set this up in early March
(according to the key activation comments - who remembers details that
far back? ;-) ) and they haven't rotated yet...

I found some other tools based around "rollerd", but I think that's
intended for managing pre-9.9.x keys, as it seems to assume a slightly
different key structure with ".krf" files in the zone file directory.

When it comes to the DS records registered at the registrar, I'm not
sure where that comes from: the only way I can see to get it is to do a
DS query from the nameserver (and at least one document basically said
that).  First, I'd like to know where it comes from, and second, it
seems much too small, given ksks are supposed to be bigger as a result
of being longer lived:

raindrop.us.		1903	IN	DS	41190 5 2
C2927E697D868DB1AEF54642E9B59079CF5412AAA36846290AB20215 9CBAFBEA

vs

raindrop.us.		3600	IN	DNSKEY	256 3 5
AwEAAb3vNnkqkoG7brIDkPDSbnFDeFV2FmD+RktZFL3DDIIkM9Xkpker
sFTscUWFeta/DEBg8Jvgznyw6iiBCPob5Q9Vluv4mT+HNAm5F2W5wLww
FkJ8ia1xuZoAAl3jCHW3Cj5Dkkr0yVSSZrbORJ1/PnnKhb09o2LPjMr6 /hUjzlzV

When it comes time to roll the DS key, it looks like I pick a lifetime,
say 3 months, generate a new DS key (how, such that 9.9.x will use it?
"rndc sign zone" seems like the way, but that looks like it will take
effect immediately; "rndc loadkeys <zone>" says it will update keys
without signing immediately, which looks good, will "sign <zone>" then
use those keys later?), add it at the registrar, wait the ttl, then tell
bind to switch (again, how?)




As for specific problems:

I have bind 9.9.1 setup and the zones configured with:

        key-directory "/var/named/keys";
        auto-dnssec maintain;
        inline-signing yes;

This is a "Slave server, hidden master" per example 2 in
https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-Examples.html

/var/named/keys appears to have the zone signing keys/DNSKEY records.
/var/named/slaves have the .signed files with RRSIG records, presumably
signed with the zsks in the keys directory.

Next, I have a DS record configured at my registrar obtained with dig
from my nameserver, but that doesn't seem to be right, as

http://dnsviz.net/d/raindrop.us/dnssec/
and
http://dnssec-debugger.verisignlabs.com/raindrop.us

both complain about the link from the parent to my nameserver in the
chain.  dnsviz just says "bogus" without explaining what's bogus (though
RFC4641 4.2 implies that the keys *have* rolled somehow, without the
registrar being updated); verisign says it couldn't get a dnskey rr from
the nameservers, though I can:

# dig @ns1.raindrop.us dnskey raindrop.us
...
;; ANSWER SECTION:
raindrop.us.		3600	IN	DNSKEY	256 3 5
AwEAAb3vNnkqkoG7brIDkPDSbnFDeFV2FmD+RktZFL3DDIIkM9Xkpker
sFTscUWFeta/DEBg8Jvgznyw6iiBCPob5Q9Vluv4mT+HNAm5F2W5wLww
FkJ8ia1xuZoAAl3jCHW3Cj5Dkkr0yVSSZrbORJ1/PnnKhb09o2LPjMr6 /hUjzlzV

# dig @ns2.raindrop.us dnskey raindrop.us
...
;; ANSWER SECTION:
raindrop.us.		3600	IN	DNSKEY	256 3 5
AwEAAb3vNnkqkoG7brIDkPDSbnFDeFV2FmD+RktZFL3DDIIkM9Xkpker
sFTscUWFeta/DEBg8Jvgznyw6iiBCPob5Q9Vluv4mT+HNAm5F2W5wLww
FkJ8ia1xuZoAAl3jCHW3Cj5Dkkr0yVSSZrbORJ1/PnnKhb09o2LPjMr6 /hUjzlzV

Somehow, I think the DS isn't matching the DNSKEYs, causing them to be
rejected, but since bind generated both, I would hope it's internally
consistent...





More information about the bind-users mailing list