hawaga.org.uk using DNSSEC so that other resolvers can verify the contents when they make a DNS lookup.The parent domain
org.uk does not do DNSSEC at the moment so I am going to use DLV (DNSSEC Lookaside Validation). DLV will let me publish my zone public keys in DLVs registry instead of in the parent org.uk zone, and my zones will be validated by anyone who has configured DLV in their resolver, rather than by all DNSSEC users (pretty much the first is a strict subset of the second). This is something of a hack - hopefully in a few months org.uk will support DNSSEC and I'll be able to directly publish my keys there instead.Most of what follows works for both normal DNSSEC and DNSSEC-with-DLV.
I need to generate two public/private keypairs: a zone signing key, and a key signing key. The key signing key will be used to sign the zone signing key, and the zone signing key will be used to sign the records inside the zone. Its not entirely clear to me which private keys need to be online at which step in the process, but for my immediate purposes I don't mind too much - I'm keeping everything online the whole time for now.
bind comes with a utility called
dnssec-keygen to generate the keys, and it is used much like any other command-line key generator such as gpg oropenssl:$ /usr/sbin/dnssec-keygen -a RSASHA1 -b 768 -n ZONE hawaga.org.uk Generating key pair...................++++++++ ..++++++++ Khawaga.org.uk.+005+48075 $ /usr/sbin/dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE hawaga.org.uk ... $ ls Khawaga* Khawaga.org.uk.+005+48075.key Khawaga.org.uk.+005+48196.key Khawaga.org.uk.+005+48075.private Khawaga.org.uk.+005+48196.private
Now, I'm going to sign the zone:
$ /usr/sbin/dnssec-signzone -S -l dlv.isc.org -o hawaga.org.uk db.hawaga
Fetching KSK 48196/RSASHA1 from key repository.
Verifying the zone using the following algorithms: RSASHA1.
Zone signing complete:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
db.hawaga.signed
and I get these output files:
-rw-r--r-- 1 benc benc 35505 2011-01-04 21:47 db.hawaga.signed -rw-r--r-- 1 benc benc 195 2011-01-04 21:47 dlvset-hawaga.org.uk. -rw-r--r-- 1 benc benc 171 2011-01-04 21:47 dsset-hawaga.org.uk.
The signed zone lives in
db.hawaga.signed. It looks like my input zone but with some new records added. For every input records, there is a new RRSIG record; there are DNSKEY records which contain the public keys generated above; and there are NSEC records which are used to securely deny the existence of entries.In my bind directory, I replace my original
db.hawaga zone file with the new signed version and restart bind.Now bind will serving the appropriate DNSSEC records. I can see them by querying using the
+dnssec flag to dig:$ dig +dnssec www.hawaga.org.uk [...] ;; ANSWER SECTION: www.hawaga.org.uk. 3600 IN CNAME paella.hawaga.org.uk. www.hawaga.org.uk. 3600 IN RRSIG CNAME 5 4 3600 20110208095742 20110109095742 48075 hawaga.org.uk. lNdWf71In/J8F7evBxxi1yTw7Fx4WRkcHK9vOilEyLmDq31uwYlTtf+d bAZ4WHSeF9aHGRlvy1c6bAWEgWs64K8RNr/7pkZW+y0kmP8qL+Eu0nOH DvvQQ32eShnoEYGc paella.hawaga.org.uk. 3600 IN A 174.143.245.7 paella.hawaga.org.uk. 3600 IN RRSIG A 5 4 3600 20110208095742 20110109095742 48075 hawaga.org.uk. EeUBihcnpDJad9JJnwLcR0nm9ef1E58fxdwio/SK1iSorkFZLZjxvk7r GYkCR0aCwAw1F2/lJ3kb6pTk+10H00lyowQc8crtBPIDkwiqDE0pTtEE JPCm51XuAc3bz/lX [...]
So now my zone is signed.
But! (and this is a big but) there is no trust path for any resolver to validate that - there is no reason for any resolver to believe that it really was *me* that generated the keys rather than some random attacker.
In X.509, certificate authorities tell you how to trust someone by signing certificates. In plain DNSSEC, the parent zone acts as a CA by providing a signed DS (delegation signer) record in addition to an NS record. In DLV, ISC's DLV service fills this role by providing the signed DS record.
I'm going to use ISC's DLV zone (which appears to be the only serious one). There's a web interface to sign up, at https://dlv.isc.org/. When you sign up there, the interface authenticates your ownership of the zone by giving you a cookie TXT record to put in your zone. Once that authentication has happened, you can upload a
DNSKEY, DS or DLV record.Then ISC will publish a DLV record set for you (presumably it constructs one for you if you give a
DNSKEY or DS record?). For example, mine looks like this:hawaga.org.uk.dlv.isc.org. 877 IN DLV 48196 5 2 FD144A3B36AC7E939DD7A04D5C6F967A07D01FB0029CA8B440F6CC2D 6F2415B8 hawaga.org.uk.dlv.isc.org. 877 IN DLV 48196 5 1 0DE399B36303676F1243A923B6FC3893AE248F90
It takes a few hours for that DLV record to appear, but when it does, that is enough for a DLV-enabled resolver to be able to authenticate.
DNS-OARC has some open DNSSEC-enabled resolvers that can be used for testing this. I can check my DNSSEC using one of them:
$ dig +dnssec @2001:4f8:3:2bc:1::64:20 -t a www.hawaga.org.uk [...] ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 3, ADDITIONAL: 5 [...]
and look out for the
ad bit to appear in the flags field. It does, which means that resolver trusts my results.OK. That's the setup pretty much done. Two last notes:
Firstly, when a bind resolver is authoritative for a zone, then it won't check signatures and give an
ad flag on results for that zone. That left me puzzling for a while, wondering why it wasn't checking my results, and is why I have to use one of DNS-OARC's resolvers above.Secondly, this zone is only signed for 30 days. After that period (specifically, 30 days after I ran the dnssec-signzone command), the signatures will become invalid. This is quite a change from my previous non-DNSSEC zone update habits - I changed my zone a few times per year and only when I needed a change, but now I'm going to need to update it at least every month, and inaction will cause it to break. In a subsequent post, I'm going to write about some of the automation I did to do this.
Thanks, that helps. ;)
ReplyDelete