DNSSec turned on by default in bind9 package

Registered by Marc Deslauriers

This session is about turning DNSSec support on out-of-the-box in the bind9 package. One of the issues in doing this is setting up the initial key, which could get changed during the life of the LTS release. How do we deal with key rotation in new installs?

Blueprint information

Status:
Complete
Approver:
Jamie Strandboge
Priority:
Low
Drafter:
Marc Deslauriers
Direction:
Needs approval
Assignee:
LaMont Jones
Definition:
Approved
Series goal:
Accepted for precise
Implementation:
Implemented
Milestone target:
None
Started by
Jamie Strandboge
Completed by
Jamie Strandboge

Related branches

Sprints

Whiteboard

Work items:
[lamont] turn on by default with blurb and ship bind.keys (0.5): DONE
[lamont] add note to README.Debian how to get the key, verify it and put it in place (0.5): DONE
[mdeslaur] add cronjob to poll for when the key singing key changes (0.5): POSTPONED
[mdeslaur] make sure QRT script tests the default dnssec option (0.5): POSTPONED

Installing and enabling DNSSEC using the package-creation-time-current keys is very straight forward, the cases that complicate that are (at least):
- need to verify at install time that DNSSEC is working, or offer to disable it at install time.
- missing a key roll because the release was on the other side of the key roll from the install.
- machines isolated from the Internet

Bind ships with keys compiled-in, and also in the bind.keys file. An updated bind.keys file is available with a gpg signature from isc.org (http://ftp.isc.org/isc/bind9/keys/9.8)

"dnssec-validation auto" in named.conf will read the root key from bind.keys the first time it executes.

https://www.isc.org/bind-keys

From the etherpad:
This session is about turning DNSSec support on out-of-the-box in the bind9 package. One of the issues in doing this is setting up the initial key, which could get changed during the life of the LTS release. How do we deal with key rotation in new installs?

Installing and enabling DNSSEC using the package-creation-time-current keys is very straight forward, the cases that complicate that are (at least):
- need to verify at install time that DNSSEC is working, or offer to disable it at install time.
- missing a key roll because the release was on the other side of the key roll from the install.
- machines isolated from the Internet
Bind ships with keys compiled-in, and also in the bind.keys file. An updated bind.keys file is available with a gpg signature from isc.org (http://ftp.isc.org/isc/bind9/keys/9.8)
"dnssec-validation auto" in named.conf will read the root key from bind.keys the first time it executes.
https://www.isc.org/bind-keys
Why?
- shiny
- chock full of goodness
Issues
- key signing key for toplevel domain can be shipped, but what about key rotation. If server running, no problem. If person installs from package after key rotated, bind fails
- 9.8 in source code and bind.keys. looks first in bind.keys and then falls back
- how about turn on by default but then check in postinst if it is working. warn if not
- reads bind.keys or hardcoded, then creates a database
- checking for whether or not it works is problematic
 - construed as phone home
 - if in init script-- potentially a lot of traffic
 - postinst?
 - requires network connectivity
 - when is bind.keys referenced?

Seems key doesn't change (we are only shipping the key singing key), so turning this on by default isn't a problem for users installing. If the key is revoked, an update can be pushed through -security
dnssec-trigger? for people on the go. integrated into network-manager, uses unbound, and resistant to hostile networks. nsd is unbound authoritative server

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.