1opendnssec(7) OpenDNSSEC overview opendnssec(7)
2
6 OpenDNSSEC - making DNSSEC easy for DNS administrators
7
9 ods-control start | stop
10 ods-enforcer subcommand...
12 ods-signer [subcommand...]
14
16 OpenDNSSEC is a complete DNSSEC zone signing system which maintains
17 stability and security of signed domains. DNSSEC adds many crypto‐
18 graphic concerns to DNS; OpenDNSSEC automates those to allow current
19 DNS administrators to adopt DNSSEC.
20 Domain signing is done by placing OpenDNSSEC between the place where
22 the zone files are edited and where they are published. The current
23 version of OpenDNSSEC supports files and AXFR to communicate the zone
24 data; effectively, OpenDNSSEC acts as a "bump in the wire" between
25 editing and publishing a zone.
26 OpenDNSSEC has two daemons, which are unitedly started and stopped
28 through the ods-control(8) command. The two daemons in turn invoke
29 other programs to get their work done.
30 One of the daemons is the KASP Enforcer, which enforces policies that
32 define security and timing requirements for each individual zone.
33 Operators tend to interact with the KASP Enforcer a lot, through the
34 ods-enforcer(8) command.
35 The other daemon is the Signer Engine, which in turn signs the zone
37 content. It retrieves that content from a file or through AXFR, and
38 publishes a signed version of the zone into a file or through AXFR.
39 Direct interaction with the Signer Engine, although not normally neces‐
40 sary, is possible through the ods-signer(8) command.
41 The keys that sign the zones are managed by an independent repository,
43 which is accessed over a PKCS #11 interface. The principle idea of
44 this interface being to unleash access to cryptographic hardware, there
45 are implementations in software. Also, implementations range from open
46 to commercial, and from very simple to highly secure. By default,
47 OpenDNSSEC is configured to run on top of a SoftHSM, but a few other
48 commands exist to test any Hardware Security Module that may sit under
49 the PKCS #11 API.
50
52 The approach used by OpenDNSSEC follows the best current practice of
53 two kinds of key per zone:
54 KSK or Key Signing Key
56 This key belongs in the apex of a zone, and is referenced in the
57 parent zone (quite possibly a registry) in the form of DS
58 records alongside NS records. These parent references function
59 as trust delegations.
60 The KSK is usually a longer key, and it could harm the effi‐
62 ciency of secure resolvers if all individual resource records
63 were signed with it. This is why it is advisable to use the KSK
64 only to sign the ZSK.
65 In DNS records, the KSK can usually be recognised by having its
67 SEP (Secure Entry Point) flag set.
68 ZSK or Zone Signing Key
70 This key also belongs in the apex of a zone, and is actually
71 used to sign the resource records in a zone. It is a shorter
72 key for reasons of efficiency, that is rolled over on a fairly
73 regular basis. To detach these rollovers from the parent, the
74 ZSK is not directly trusted by the parent zone, but instead its
75 trust is established by way of a signature by the KSK on the
76 ZSK.
77 OpenDNSSEC is mindful about the period of validity of each key, and
79 will rollover in time to keep the domain signed, with new keys, without
80 any downtime for the secure domain. The only thing that is not stan‐
81 dardised, and thus cannot be automated at the moment is the interface
82 between a zone and its parent, so this has to be done manually, or
83 scripted around OpenDNSSEC.
84
86 ods-control(8), ods-enforcerd(8), ods-enforcer(8), ods-hsmspeed(1),
87 ods-hsmutil(1), ods-kaspcheck(1), ods-kasp(5), ods-signer(8), ods-sign‐
88 erd(8), ods-timing(5), http://www.opendnssec.org/
89
91 OpenDNSSEC was made by the OpenDNSSEC project, to be found on
92 http://www.opendnssec.org/
93OpenDNSSEC February 2010 opendnssec(7)