DNSSEC not populating parent zone files with DS records

Michael Sinatra michael at rancid.berkeley.edu
Sat Oct 1 18:58:49 UTC 2011


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



More information about the bind-users mailing list