Project

General

Profile

Actions

Enhancement #66

closed

DNSSEC support

Added by Marc Dequènes about 14 years ago. Updated over 13 years ago.

Status:
Resolved
Priority:
Low
Category:
Service :: DNS
Start date:
Due date:
% Done:

100%

Estimated time:
Patch Available:
No
Confirmed:
No
Branch:
Entity:
DuckCorp
Security:
Yes
Help Needed:

Description

Root servers now support DNSSEC, so should we.


Related issues 3 (0 open3 closed)

Related to DuckCorp Infrastructure - Enhancement #166: Implement secure zone tranfert (TSIG)ResolvedMarc Dequènes2010-10-26

Actions
Related to DuckCorp Infrastructure - Documentation #169: DNS documentationResolvedMarc Dequènes2010-10-29

Actions
Blocked by DuckCorp Infrastructure - Enhancement #176: Move HQ zones to ElwingResolvedMarc Dequènes2010-10-31

Actions
Actions #1

Updated by Marc Dequènes almost 14 years ago

OpenSSH 1:5.4p1-2 has got DNSSEC support using secured SSHFP entries (glibc 2.11 needed !).

Actions #2

Updated by Marc Dequènes almost 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.

Actions #3

Updated by Marc Dequènes over 13 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).

Actions #4

Updated by Marc Dequènes over 13 years ago

edns0 option has been activated on all servers (except Daneel, which is down). Desktops should come soon.

Actions #5

Updated by Marc Dequènes over 13 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

Actions #7

Updated by Marc Dequènes over 13 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

Actions #9

Updated by Marc Dequènes over 13 years ago

  • % Done changed from 40 to 50
Two sites to test DNSSEC config:

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.

Actions #10

Updated by Marc Dequènes over 13 years ago

Information about DLV: https://dlv.isc.org/about/using
(the up-to-date trusted key was already provided by the Debian package)

Actions #11

Updated by Marc Dequènes over 13 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.

Actions #12

Updated by Marc Dequènes over 13 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.

Actions #13

Updated by Marc Dequènes over 13 years ago

  • Security changed from No to Yes
Actions #14

Updated by Marc Dequènes over 13 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).

Actions #15

Updated by Marc Dequènes over 13 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.

Actions #16

Updated by Marc Dequènes over 13 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

Actions #17

Updated by Marc Dequènes over 13 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).

Actions #18

Updated by Marc Dequènes over 13 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

Actions #19

Updated by Marc Dequènes over 13 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.

Actions #20

Updated by Marc Dequènes over 13 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.

Actions #21

Updated by Marc Dequènes over 13 years ago

How to solve Not enough keys to satisfy ksk policy for zone: <zone>:
  • 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
How to solve Key (<ods-key-id>) has gone straight to active use without a prepublished phase:
  • 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>
Actions #22

Updated by Marc Dequènes over 13 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.

Actions #23

Updated by Marc Dequènes over 13 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.

Actions #24

Updated by Marc Dequènes over 13 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF