On 10/01/11 04:54, Bill Owens wrote:
On Fri, Sep 30, 2011 at 10:26:34PM +0000, Raymond Drew Walker wrote:
In our initial implementation of DNSSEC, we chose to try out the
"auto" functionalities in version 9.8.0 P4 ie. using "auto-dnssec
maintain" in all master zones.
When going live, we found that though all zones that we are acting
as master for would populate their own DS records, but there would
be no population of a child zone's DS record in the corresponding
parent master zone file.
The ARM for 9.8.1 has this to say about dnssec-signzone:
"Any keyset files corresponding to secure subzones should be present.
The zone signer will generate NSEC, NSEC3 and RRSIG records for the
zone, as well as DS for the child zones if '-g' is specified. If '-g'
is not specified, then DS RRsets for the secure child zones need to
be added manually."
I take that to mean that if I have a pair of zones served by the same
master, dnssec-signzone will figure out the relationship and install
DS records in the parent zone. However, that assumes two things -
that both zones are on the same master (as seems to be the case for
you), and that there are NS records in the parent to provide a
delegation point (which doesn't seem to be true for nau.edu and
extended.nau.edu, at least).
I couldn't tell whether this also applies to auto-dnssec; either the
ARM doesn't say or I missed it ;)
I am pretty sure that it doesn't, at least not in 9.8.1. There's no
place to specify the location of the dsset or keyset files in
named.conf, and that's what the signer process needs to insert the DS
records. When I put dsset files in the parent zone's directory with the
key files and did 'rndc sign', the DS records still didn't get
automagically put in.
There are ways of getting the DS records into the zone(s). Here are
some steps that I took on some test zones:
0. First, I made sure there were proper delegation NS records in the
parent zone(s)!
1. Ensure that there are no pending dynamic updates and run 'rndc freeze'.
2. Create a central directory to hold the keyset and dsset files. I
used /var/named/etc/namedb/master/signed-zonefiles/keysets on a FreeBSD
system with named running in a chroot environment.
3. Assuming keys have already been generated, run the following command
in the *child* zones first, substituting sub1.gost.radiofreebeer.net for
your child zone and substituting 'zone.db.signed' for the signed version
of the zone that named is configured to read on startup:
/usr/sbin/dnssec-signzone -C -g -p -d
/var/named/etc/namedb/master/signed-zonefiles/keysets -o
sub1.gost.radiofreebeer.net. -e +518400 -N unixtime zone.db.signed
K*.private
This will produce zone.db.signed.signed.
NOTE that this assumes that each zone has its own directory with its
keys in that directory (and no other zone's keys).
4. Then run the same command on any parent of any signed zone, *after*
you have run the command on the signed child zone.
5. For every *parent* zone, you will need to 'mv zone.db.signed.signed
zone.db.signed' so that the version with the DS records will go into
production. This is only necessary with parent zones, but it can also
be done on the child zones just to keep things clean.
6. 'rndc thaw'
You can also use a signing tool like zkt, which will basically generate
all of the keys and do the DSification of parent zones automatically.
There are other features of tools like zkt and opendnssec that
auto-dnssec can't (yet) do, such as key rollovers. auto-dnssec will do
rollovers, once the keys with proper activation and inactivation dates
have been created. But something else needs to generate the keys, set
the metadata according to a policy defined by the administrator, and
remove stale keys so that auto-dnssec can do its work. As far as I can
tell, there isn't yet an auto-dnssec-savvy tool that can handle these
tasks so it needs to be custom-scripted.
We have since backed out DNSSEC until we can get a resolution of
the issue.
Incidentally, you haven't - you're still serving a signed zone for
nau.edu and extended.nau.edu, which causes the problems noted in the
other responses to your original note. I think you could fix it very
quickly though, by adding the NS records to the nau.edu zone.
Bill's right--this needs to be fixed right away.
michael
_______________________________________________
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
