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:
- 'gds.' is secured
- 'unsec.gds.' is NOT secured
- 'sec.unsec.gds.' is also secured
- 'unsec.gds.' becomes secure (ie we create keys, sign the zone and compute a DS in 'gds.') and compute a DS record for 'sec.unsec.gds.'
- All clients that want to validate things in the 'sec.unsec.gds.' domain sets a key of that domain as a trusted key
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:
sec.unsecure.gds. SOA .... sec.unsecure.gds. NS .... $INCLUDE "Ksec.unsec.gds.+.... $INCLUDE "Ksec.unsec.gds.+.... $INCLUDE "Ksec.unsec.gds.+....
unsecure.gds. SOA .... unsecure.gds. NS .... sec.unsecure.gds. IN NS .... sec.unsecure.gds. IN NS ...
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.'.
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.
- If you configure BIND to serve gds. and unsecure.gds., you'll get SOA answers when asking a DS for sec.unsecure.gds.(this is the answer of the unsecure.gds. zone)
- If you configure BIND to serve gds. and sec.unsecure.gds., you'll get NSEC answers when asking a DS for sec.unsecure.gds.(this is the answer of the sec.unsecure.gds. zone)
- ftp://ftp.irisa.fr/local/idsa/code/patch-bind/gds/ : the BIND patch that change the behaviour of BIND when treating DS records. This includes a modification of the BIND server and a modification of the dnssec-signzone tool