[Dnssec-deployment] Dynamic nsupdate errors?
owens at nysernet.org
Wed Jun 8 14:35:09 EDT 2011
On Wed, Jun 08, 2011 at 12:04:16PM -0500, Tim Tyler wrote:
> I am primarily using the Verisign document published by Educause.
> It does a good job of getting dnssec to work, but I don't find many that
> deal with the nsupdate dynamic updates very well.
Section 2.1.1 indicates that the guide is written for BIND 9.6.x, and doesn't include the new "DNSSEC for Humans" features in 9.7.x.
I have to say that those features are well worth having, and I think you'd be a lot happier setting up your zones to use them, instead of relying on manual signing.
> If nsupdate is working but BIND is not able to sign because it can't find
> the private files, is that because it can't find the ZSK and KSK private
> files? Strange because I have them located in the same directory with my
> zone file.
I don't know whether BIND has a default key directory; the ARM says that it will look in the "working directory", which I believe is whatever you set in your "directory" statement in named.conf. If your zone files and keys aren't in that directory (for example, if you make subdirectories for the zone files), then it wouldn't find them.
The recipe I use includes three extra configuration variables in each zone stanza (in addition to type and file):
The "keys" directory is a subdirectory off of /usr/local/etc/bind. All of the signing keys go in that directory, and BIND figures out which is which based on the metadata in the key files. When creating keys, I give dnssec-keygen the path to that directory and it dumps the files there.
> Does "rndc sign zonename" replace the dnssec-signzone command?
> If so,
> does that mean "rdnc sign zonename" will automatically create the
> zone.db.signed file?
No, it signs the zone in place, and keeps track of the changes in a journal file, writing the zone file whenever you stop named (or freeze the zone).
> I am really confused by what private files this
> process can't find. Is it related to the DNSSEC keys or the TSIG keys
> which I think is just automatically created in the session key?
It needs the DNSSEC keys. The TSIG keys can't be used for signing, they're only for securing the transaction between nsupdate and named.
> Do I
> need TSIG pair keys created independently of the DNSSEC keys? And should
> I put them in a separate directory?
You don't need to manually generate any TSIG keys if you're using update-policy local - BIND will do it for you. You can generate keypairs if you like, and use them with remote machines, for example a DHCP server that updates zones based on reservations. But for what we're talking about, using nsupdate -l on the master server itself, the automatically generated TSIG keys are all that's needed.
> The steps in your instructions you sent me confuse me at the point of
> running rndc sign zonename. Just above on that page, it appears to be
> creating the ZSK and KSK files which I already created or am I wrong and
> those are actually TSIG files?
That recipe shows what you do if you're starting with an unsigned zone. The two dnssec-keygen commands create the ZSK and KSK and drop them into the keys directory; you've already done that, so you can either create a keys directory and drop them there, or add the "key-directory" entry in your zone and point it to wherever the keys are. Then when you do "rndc sign", BIND should be able to find the keys, sign the zone, and begin maintaining it.
Honestly, at this point if I were you I'd back out the signatures from beloit.edu by bumping the serial on the unsigned file and repointing named.conf to it, and then set up a sandbox zone, dump some records in it and go through the whole process from start to finish, and make sure it's nice and smooth. I splurged and spent $15 to register a real zone with a DNSSEC-capable registrar so that I could push the DS records up to them and be able to verify that everything worked. Once that's all set, signing your real zone should be a piece of cake, and you can be confident that it will work the first time. . .
More information about the Dnssec-deployment