Generalized DS

About : theory

Generalized DS allows to have build a DNSSEC chain of trust over a succession of secure and unsecure domains (a domain that has insecure parents). An example:

In the actual DS definition, the only ways for 'sec.unsec.gds.' to be part of a chain of trust are:

With generalized DS, we store a DS for 'sec.unsec.gds.' in gds.. That means that we relax the constraint that a DS can be present if and only if the domain is delegated at the same place. This allows to securely jump over unsecure zone.

Building a generalized DS : practice

Following the previous example we would start from the 3 following zones:

db.sec.unsecure.gds. 
sec.unsecure.gds. SOA  ....
sec.unsecure.gds. NS   ....
     
$INCLUDE "Ksec.unsec.gds.+....
$INCLUDE "Ksec.unsec.gds.+....
$INCLUDE "Ksec.unsec.gds.+....
db.unsecure.gds. 
unsecure.gds. SOA  ....
unsecure.gds. NS   ....
     
sec.unsecure.gds. IN NS ....
sec.unsecure.gds. IN NS ...
db.gds. 
gds. SOA  ....
     NS   ....

unsecure.gds. IN NS ....
              IN NS ...

$INCLUDE "Kgds.+....
$INCLUDE "Kgds.+....
$INCLUDE "Kgds.+....

In the normal process we would sign the zone file 'db.gds.' for zone 'gds.', with the keys listed at the end of the file.
When you have signed the 'sec.unsecure.gds.' zone the dnssec-sigzone tool may have generated a 'dsset-sec.unsecure.gds.' file. To create generalized DS record for 'sec.unsecure.gds.' in 'gds.', just add $INCLUDE "dsset-sec.unsecure.gds." at the end of the 'db.gds.' file. If you sign your 'db.gds.' file using the patched dnssec-sigzone (the one ship with your patched BIND), you'll get a 'db.gds.signed' file that contains signed DS records for 'sec.unsecure.gds.'(appropriate NSEC should also be generated).

If this zone is served by the patched BIND you'll have the expected behaviour: if you ask your server "sec.unsecure.gds. DS ?" you will get the correct RR and be able to build a chain of trust from 'gds.' to 'sec.unsecure.gds.'.

Limitations

We didn't want that patch to be too intrusive in BIND, the consequence is that we have introduced some limitations for serving GDS correctly(strict delegation is a strong assumption in BIND). The only known limitation is that your BIND server can't serve correctly a top zone that contains generalized DS records, and any of the zone in the path of generalized DS.

In our example, the same BIND server can't handle correctly at the same time gds. and unsecure.gds. or sec.unsecure.gds.

Changing that behaviour in BIND looks quite heavy, and that patch is more a proof of concept than a "run me in production environment" one. So be aware of that limitation when experimenting with the patch.

Downloads

Available downloads: