Enhancement #66
closed
DNSSEC support
100%
Description
Root servers now support DNSSEC, so should we.
Updated by Marc Dequènes over 14 years ago
OpenSSH 1:5.4p1-2 has got DNSSEC support using secured SSHFP entries (glibc 2.11 needed !).
Updated by Marc Dequènes over 14 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
glibc 2.11 is now in testing.
Since 00:00 UTC on 1 July 2010 all root servers are ready. Nevertheless, Gandi does not support DNSSEC at all (list of DNSSEC-enabled .org registrars).
Interim trust anchors (IANA ITAR) are only a stopgap, and will probably not help push DNSSEC as an important matter. Then, signing zones is possible but not really useful nowadays. Nevertheless, we should learn and prepare our zones, to be able to provide the service for our users.
Updated by Marc Dequènes over 14 years ago
We should also check configuration of all our server to be sure the chain verification is activated (probably feeding root anchors will be suffisant).
Updated by Marc Dequènes over 14 years ago
edns0 option has been activated on all servers (except Daneel, which is down). Desktops should come soon.
Updated by Marc Dequènes over 14 years ago
- % Done changed from 10 to 20
All 3 servers have been configured for root zone validation (but without DLV or ITAR, which are stopgaps and not a real solution).
The following documentation (and script) was helful: https://calomel.org/dns_bind.html
Updated by Marc Dequènes over 14 years ago
Updated by Marc Dequènes about 14 years ago
- % Done changed from 20 to 40
Testing opendnssec. Log:
apt-get install opendnssec opendnssec-auditor libsofthsm softhsm adduser opendnssec softhsm setfacl -m o::- /var/lib/softhsm/slot0.db setfacl -m u:opendnssec:rw /var/lib/softhsm/slot0.db softhsm --init-token --slot 0 --label "OpenDNSSEC" -> (PIN) 1234 ods-ksmutil setup /etc/init.d/opendnssec-enforcer restart setfacl -m g:opendnssec:rx /etc/bind setfacl -m g:opendnssec:rx /etc/bind/master setfacl -m d:g:opendnssec:rx /etc/bind/master setfacl -m g:opendnssec:r /etc/bind/master/*.zone mkdir /etc/bind/master/signed setfacl -m g:opendnssec:rwx /etc/bind/master/signed setfacl -m d:g:opendnssec:rwx /etc/bind/master/signed setfacl -m g:opendnssec:r /etc/bind/rndc.key ods-ksmutil zone add --zone plop.net --input /etc/bind/master/plop.net.zone --output /etc/bind/master/signed/plop.net.zon ods-ksmutil key list -v
Updated by Marc Dequènes about 14 years ago
Updated by Marc Dequènes about 14 years ago
- % Done changed from 40 to 50
I'm testing key publishing with 'plop.net' fake zone.
According to http://www.gandibar.net/post/2010/08/25/What-you-can-expect-this-fall Gandi is far from having DNSSEC available. Seems many other providers are late to support DNSSEC. The DLV system seems clean, so we may try providing signed zones using it, even if it a shamy situation.
Updated by Marc Dequènes about 14 years ago
Information about DLV: https://dlv.isc.org/about/using
(the up-to-date trusted key was already provided by the Debian package)
Updated by Marc Dequènes about 14 years ago
Rollover procedure considerations: http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing-01
An Account to the ISC DLV Registry was created for MilkyPond. We should try with a not so important zone, like hq.duckcorp.org for example.
Updated by Marc Dequènes about 14 years ago
- % Done changed from 50 to 60
I don't want to handle the migration from DLV to our parent zone for hq.duckcorp.org, so i'm choosing milkypond.org which is not as critical as the other zones. The signed zone is now propagating and the KSK is in the publish state.
Updated by Marc Dequènes about 14 years ago
- % Done changed from 60 to 70
The publish state was reached. I used the following command to switch it to active, but i'm not sure it was needed (need to wait another enforcer run perhaps):
ods-ksmutil key ds-seen --keytag <key-tag> --no-retire
I then registered the domain and added the cookie, and now the DLV is published. We can check this with:
host -t dlv <domain>.dlv.isc.org
DNSViz is nice to check the secured path.
I need to have a look at published-only KSK keys (like org. is doing).
Updated by Marc Dequènes about 14 years ago
I got a kind reply from ISC today:
Yep, as things are today, we only support the dual-publish mode. This is mostly because people make mistakes all the time, and we only want to publish good keys. The dual publish only needs to occur for a short time though, 4 hours or so with the current TTLs on the dlv zone, where you can add the new key and sign, wait at least 2 hours, remove the old DLV entry, wait at least 2 hours, then remove the old key.
Unfortunately it is not possible to use Double-DS rollover, and i already moved the second key to DSREADY state by mistake. It is not a big deal through.
Updated by Marc Dequènes about 14 years ago
According to the ML, there is no way to support rollover mechanism, so i kept the mp.o state to DSREADY, so it is ready to be published as soon as needed.
Accoring to the following meeting notes, rollover workflows will be implemented in the next major version, not coming soon: http://trac.opendnssec.org/wiki/Meetings/Minutes/2010-10-20to22
Updated by Marc Dequènes about 14 years ago
To check if the DLV record is published:
host -t dlv milkypond.org.dlv.isc.org.
To check if the zone is secured, look fot the ad flag (authenticated data):
dig +dnssec milkypond.org.
Interrogating the primary server for the zone would get the aa flag (authoritative) and no ad flag. Also beware traversing an unsecured zone would not get the ad flag either (for example, www.milkypond.org is a CNAME to www.duckcorp.org which is not secured yet).
Updated by Marc Dequènes about 14 years ago
- % Done changed from 70 to 80
duckcorp.org is on the way. I had to switch to partial mode for the OpenDNSSEC Auditor because of a bug: http://trac.opendnssec.org/ticket/189
Updated by Marc Dequènes about 14 years ago
Added reverse zones, except the HQ ones, which should move to Elwing (see #176). I found another auditor bug while handling reverse zones: http://trac.opendnssec.org/ticket/190
I need to install a new OpenDNSSEC instance on Elwing to handle HQ zones.
Updated by Marc Dequènes about 14 years ago
- % Done changed from 0 to 80
OpenDNSSEC installed and working on Elwing. hq.duckcorp.org is now on the way.
I found in hs.duckcorp.org the DNS-SD SRV records where rejected by OpenDNSSEC, and that was because the spaces in the RR name was not properly encoded ('\ ' -> '\032').
Note: wait for the published KSK key to become active before pushing a dssub KSK KEY to dsready, or it will end-up with 2 active KSK keys.
Updated by Marc Dequènes about 14 years ago
- enter database: sqlite3 /var/lib/opendnssec/db/kasp.db
- find unassigned keys: select * from keypairs where id not in (select keypair_id from dnsseckeys);
- delete them would unblock the enforcer (reference to these keys can be safely removed, even if purging them in the HSM too would be cleaner)
- then restart services
- find the HSM key id: ods-ksmutil key list -v | grep -E "\b<ods-key-id>\b"
- enter database: sqlite3 /var/lib/opendnssec/db/kasp.db
- check the key state-reached date: select generate, publish, ready, active from keypairs where HSMkey_id = '<hsm-key-id>';
- add fake dates for missing ones, like this for exemple: update keypairs set ready=publish where active is not null and ready is null;
- then restart services
- you may also force signing manually with: ods-signer sign <zone-name>
Updated by Marc Dequènes about 14 years ago
- % Done changed from 80 to 90
HQ IPv6 zones are now signed. Waiting for publishing time before adding them in the DLV Registry.
hq.duckcorp.org is now secured using a DS in the duckcorp.org zone.
Note: no need to publish SHA1 DS, which is now considered unsecure, only one DS line is sufficient.
Updated by Marc Dequènes about 14 years ago
- % Done changed from 90 to 100
All remaining HQ zones are now in the DLV Registry.
All secondary KSK keys have been moved to dspublish. Waiting to get them to dsready.
Updated by Marc Dequènes about 14 years ago
- Status changed from In Progress to Resolved