1opendnssec(7)                 OpenDNSSEC overview                opendnssec(7)
2
3
4

NAME

6       OpenDNSSEC - making DNSSEC easy for DNS administrators
7

SYNOPSIS

9       ods-control start
10
11       ods-control stop
12
13       ods-ksmutil subcommand...
14
15       ods-signer [subcommand...]
16

DESCRIPTION

18       OpenDNSSEC  is  a  complete  DNSSEC zone signing system which maintains
19       stability and security of signed  domains.  DNSSEC  adds  many  crypto‐
20       graphic  concerns  to  DNS; OpenDNSSEC automates those to allow current
21       DNS administrators to adopt DNSSEC.
22
23       Domain signing is done by placing OpenDNSSEC between  the  place  where
24       the  zone  files  are edited and where they are published.  The current
25       version of OpenDNSSEC supports files and AXFR to communicate  the  zone
26       data;  effectively,  OpenDNSSEC  acts  as  a "bump in the wire" between
27       editing and publishing a zone.
28
29       OpenDNSSEC has two daemons, which  are  unitedly  started  and  stopped
30       through  the  ods-control(8)  command.   The two daemons in turn invoke
31       other programs to get their work done.
32
33       One of the daemons is the KASP Enforcer, which enforces  policies  that
34       define  security  and  timing  requirements  for  each individual zone.
35       Operators tend to interact with the KASP Enforcer a  lot,  through  the
36       ods-ksmutil(1) command.
37
38       The  other  daemon  is  the Signer Engine, which in turn signs the zone
39       content.  It retrieves that content from a file or  through  AXFR,  and
40       publishes  a  signed  version  of the zone into a file or through AXFR.
41       Direct interaction with the Signer Engine, although not normally neces‐
42       sary, is possible through the ods-signer(8) command.
43
44       The  keys that sign the zones are managed by an independent repository,
45       which is accessed over a PKCS #11 interface.   The  principle  idea  of
46       this interface being to unleash access to cryptographic hardware, there
47       are implementations in software.  Also, implementations range from open
48       to  commercial,  and  from  very  simple to highly secure.  By default,
49       OpenDNSSEC is configured to run on top of a SoftHSM, but  a  few  other
50       commands  exist to test any Hardware Security Module that may sit under
51       the PKCS #11 API.
52

OPERATIONAL PRACTICES

54       The approach used by OpenDNSSEC follows the best  current  practice  of
55       two kinds of key per zone:
56
57       KSK or Key Signing Key
58              This key belongs in the apex of a zone, and is referenced in the
59              parent zone (quite possibly  a  registry)  in  the  form  of  DS
60              records  alongside NS records.  These parent references function
61              as trust delegations.
62
63              The KSK is usually a longer key, and it  could  harm  the  effi‐
64              ciency  of  secure  resolvers if all individual resource records
65              were signed with it.  This is why it is advisable to use the KSK
66              only to sign the ZSK.
67
68              In  DNS records, the KSK can usually be recognised by having its
69              SEP (Secure Entry Point) flag set.
70
71       ZSK or Zone Signing Key
72              This key also belongs in the apex of a  zone,  and  is  actually
73              used  to  sign  the resource records in a zone.  It is a shorter
74              key for reasons of efficiency, that is rolled over on  a  fairly
75              regular  basis.   To detach these rollovers from the parent, the
76              ZSK is not directly trusted by the parent zone, but instead  its
77              trust  is  established  by  way of a signature by the KSK on the
78              ZSK.
79
80       OpenDNSSEC is mindful about the period of validity  of  each  key,  and
81       will rollover in time to keep the domain signed, with new keys, without
82       any downtime for the secure domain.  The only thing that is  not  stan‐
83       dardised,  and  thus cannot be automated at the moment is the interface
84       between a zone and its parent, so this has  to  be  done  manually,  or
85       scripted around OpenDNSSEC.
86

SEE ALSO

88       ods-control(8),   ods-enforcerd(8),   ods-hsmspeed(1),  ods-hsmutil(1),
89       ods-kaspcheck(1),   ods-ksmutil(1),   ods-signer(8),    ods-signerd(8),
90       ods-timing(5), http://www.opendnssec.org/
91

AUTHORS

93       OpenDNSSEC  was  made  by  the  OpenDNSSEC  project,  to  be  found  on
94       http://www.opendnssec.org/
95
96
97
98OpenDNSSEC                       February 2010                   opendnssec(7)
Impressum