|
|
# DNSSEC
|
|
|
|
|
|
## Survey: DNSSEC
|
|
|
|
|
|
Purpose of this survey is to help us determine main goals when designing online DNSSEC signing in Knot DNS server. In his case, *online signing* means creating of `NSEC`, `NSEC3` and `RRSIG` records automatically by the server when the zone is loaded into the server and also when the zone is modified using DDNS mechanism.
|
|
|
|
|
|
### Configuration
|
|
|
|
|
|
* How do you think the simpliest (minimal) configuration of DNSSEC on the server side should look like?
|
|
|
|
|
|
### Utilities
|
|
|
|
|
|
* Do the current DNSSEC utilities provided by other servers (Bind, NSD, PowerDNS, ...) satisfy your needs?
|
|
|
* What do you (not) like about current utilities?
|
|
|
* Is key format compatibility with other servers important for you?
|
|
|
* Do you prefer to manage the keys using specialized command? Or do you prefer to manually edit some configuration file (and eventually just reload the server configuration)?
|
|
|
|
|
|
### Signatures handling
|
|
|
|
|
|
* Do you agree that online-signing makes sense only for master servers? (Online DNSSEC signing doesn't mix with incoming XFRs.)
|
|
|
* What do you expect the server should do when a (partialy) signed zone is loaded into the server while online DNSSEC signing is enabled? Should all existing signatures be dropped and created by the server?
|
|
|
* Do you know about a use case for multiple NSEC3 chains in the zone?
|
|
|
* Do you think an opt-out flag for NSEC3 records makes sense with online signing? And how do you want to set this flag?
|
|
|
* Do you think the server should dump the created records into the original zone file, into a separate file, or do not dump them at all?
|
|
|
|
|
|
### Dynamic updates (DDNS)
|
|
|
|
|
|
* Is it acceptable to reject all `NSEC`, `NSEC3`, and `RRSIG` records in dynamic updates when online signing is enabled?
|
|
|
* Do you expect you should be able to change `NSEC3PARAM` using dynamic update?
|
|
|
|
|
|
## Survey Results: DNSSEC
|
|
|
|
|
|
### Configuration
|
|
|
|
|
|
* start with simple implementation
|
|
|
* ideally just one option, which will enable everything with reasonable defaults
|
|
|
* automatic self checking, management, and DS updates
|
|
|
* alerts to sysadmin (e-mail, etc.) instead of performing critical operations individually
|
|
|
* keys and NSEC options in configuration file, rather than in zone file
|
|
|
* adding/removing key via callback programs
|
|
|
* these key/signing operations are usual: http://member.wide.ad.jp/~fujiwara/dnssec/dnsseczonetool
|
|
|
* possibility to enable/disable DNSSEC per zone
|
|
|
* OpenDNSSEC has nice architecture and readable configuration
|
|
|
* should work with HSM (PKCS#11)
|
|
|
* some people want separate signer and authoritative server (not relevant for what we want to do)
|
|
|
|
|
|
### Current utilities
|
|
|
|
|
|
* PowerDNS has nice control tool
|
|
|
* OpenDNSSEC is fragile in corner cases
|
|
|
* Bind allows easy signing, but skips key maintainance
|
|
|
* need better utilities for configuration inspection, DS retrieval, and monitoring
|
|
|
* key format important, key conversion tool will work
|
|
|
* ideally no cron jobs and custom scripts around
|
|
|
* more end-user oriented, than DNSSEC-geek oriented
|
|
|
* get rid of Bind format for keys, and creepy names for key files
|
|
|
|
|
|
### Key management
|
|
|
|
|
|
* maybe a little more people would like to manage the keys using specialized tools, other prefere manual key management
|
|
|
* online-signing does not make sense on slave servers
|
|
|
* if partialy signed zone is loaded, keep what is valid, remove the rest
|
|
|
* multiple NSEC3 chains when there is an incremental rollover
|
|
|
* opt-out flag is necessary, at least for TLDs
|
|
|
* most people want to dump signatures into separate zone file ($INCLUDE), less people want to not dump them at all, and just a few people want to modify the original zone file
|
|
|
* `NSEC`, `NSEC3`, `RRSIG`, `NSEC3PARAM` should be refused via DDNS |