Very quickly, what is DNSSEC?A hierarchical system to authenticate (+integrity) DNS to avoid forgery using public key cryptography.
You create a set of private/public keys, use private to sign your zone and publish public to your top-level domain via your registrar (who has to support it, see ICANN's list) or publish it to ISC DLV.
When asked for a domain, DNSSEC-enabled resolvers check the hierarchy of signatures. If a domain said it was using DNSSEC but signature is bad, no result.
Why DNSSEC?I acknowledge it is far from perfect:
- Security: Daniel J. Bernstein is a fervent opponent with good arguments, see DNSCurve (alternative to DNSSEC, lists attacks and comparison), his 27c3 talk (DNSCurve vs. DNSSEC, amplification, TCPCurve) or more recently Cryptography worst practices (amplification).
- Complexity: I find it too complex for what it provides, which (IMHO) means very few will use it as it was designed.
- See also Bert Hubert's The role of DNS and DNSSEC in information security, DNSSEC: the good & very bad and DNSSEC: Reality & Utility.
DNS resolver: UnboundI was using ISC BIND. It supports DNSSEC with:
dnssec-enable yes; dnssec-validation auto; // ISC DLV https://dlv.isc.org/about/using dnssec-lookaside . trust-anchor dlv.isc.org.;But problem if you also want to resolve alternative TLDs such as .42 or .ovh, they will not resolve because insecure and BIND does not have an option to mark domains as insecure.
Solution: change software. I wanted to switch to Unbound for some time and the fact that it has the option (domain-insecure) to the previous problem made me switch.
Related fragments of my configuration:
server: # The following line will configure unbound to perform cryptographic # DNSSEC validation using the root trust anchor. auto-trust-anchor-file: "root.key" # File with DLV trusted keys. Same format as trust-anchor-file. # There can be only one DLV configured, it is trusted from root down. # http://ftp.isc.org/www/dlv/dlv.isc.org.key dlv-anchor-file: "dlv.isc.org.key" domain-insecure: 42 domain-insecure: ovh # http://wiki.42registry.org/page/Resolve stub-zone: name: "42" stub-addr: 188.8.131.52 stub-addr: 184.108.40.206 stub-addr: 220.127.116.11 stub-zone: name: "ovh" stub-addr: 18.104.22.168 stub-addr: 22.214.171.124Rest of the configuration is simple.
DNS server: PowerDNSDNSSEC is complex to set up and maintain with BIND. There are plenty docs, tools and scripts on the subject, but I wanted something simple.
So I turned to PowerDNS by Bert Hubert: it has DNSSEC support since version 3.0 (July 2011) and it's easy (quote: "minimal administrative overhead"). Indeed, PowerDNS handles all the key rotation and resigning maintenance. I acknowledge it is a security trade-off but good enough for me.
Since I like having my zones in BIND text format (easy to edit), I did not switch to MySQL/PostgreSQL/SQLite backends but used the convenient BIND backend.
Fragment from my pdns.conf:
master=yes launch=bind bind-config=named.conf bind-dnssec-db=bind-dnssec.dbThis bind-dnssec-db is very new. For older 3.0 versions and according to the doc, you need to use an extra sqlite3 backend and insert a new record for your domain (but that's all, PowerDNS takes care of the rest).
Then to enable DNSSEC on your domain:
$ pdnssec secure-zone example.com $ pdnssec set-nsec3 example.com $ pdnssec rectify-zone example.com # not needed if BIND-only mode $ invoke-rc.d pdns restartWhat if you update the zone file? Rectify + reload:
$ pdnssec rectify-zone example.com # not needed if BIND-only mode $ invoke-rc.d pdns reload
Next, extract public info from your zone: DNSKEY (public key) and DS (hashes of public key) records.
$ pdnssec show-zone example.comand publish it to your registrar (who will send it to your top-level domain) and/or to ISC DNSSEC Look-aside Validation (DLV) Registry.
Finally, check your setup with DNSSEC Analyzer and DNSViz.
Secondary DNSI was using two free secondary DNS services: BuddyNS and PUCK. Unfortunately BuddyNS does not support DNSSEC, so I switched to PUCK only. Just note that it can be a little slow to update (1+ hour).
Cool stuff in DNS which can benefit from DNSSECSSHFP (RFC 4255) records, fingerprint of your SSH server:
$ dig +short SSHFP stalkr.net 1 1 D353AA5D599D37647682566ECB8553AE851998EF 2 1 76B50825241C1A85BCFD6954C3DCE2E65D4B71A0Then use VerifyHostKeyDNS yes.
PGP keys in DNS. First, PKA (no RFC):
$ dig +short TXT stalkr._pka.stalkr.net "v=pka1\;fpr=7D6740F72080593D0F71E9863D1D15C9AFCE54F8\; uri=http://stalkr.net/pgp.asc"Second, CERT (RFC 2538, 4398):
$ dig +tcp +short CERT stalkr.stalkr.net PGP 0 0 mQGiBEnIIn0RBADwVyT0DtawUJNxHdaKM [...] full cert
DANE (RFC draft), fingerprint of web server SSL/TLS certificate. Using dane tool from sshfp version 1.2:
$ dane --rfc stalkr.net _443._tcp.stalkr.net. IN TLSA 1 1 9454E68DBD3A9C0F460 9D033E291D53563A27CAB2C5AF4B482D66024BB841670The fingerprint is indeed the one from my webserver:
$ echo | openssl s_client -connect stalkr.net:443 2>/dev/null | openssl x509 | \ python -c 'import sys, hashlib; cert="".join(sys.stdin.read().strip().split("\n")[1:-1]); print hashlib.sha256(cert.decode("base64")).hexdigest()' 9454e68dbd3a9c0f4609d033e291d53563a27cab2c5af4b482d66024bb841670Warning though, it's still an RFC draft and is changing, but when it settles it should be good!
- DNS health check: IntoDNS, no DNSSEC but it's very good
- SIDN DNSSEC test, tells you if your resolver has DNSSEC support
- VeriSign Labs DNSSEC Analyzer, very good and clear (but no ISC DLV check)
- DNSViz, visual analysis of the DNSSEC authentication chain and resolution path (also checks ISC DLV)
- ICANN's list of registrars that support end user DNSSEC management
- Unbound documentation: unbound.conf
- PowerDNS trac/wiki: PDNSSEC
- PowerDNS doc: Chapter 12. Serving authoritative DNSSEC data and 12.8.3. PowerDNSSEC hybrid BIND-mode operation
- Bert Hubert blog: Easiest DNSSEC ever when running PowerDNS in BIND mode
- DNSSEC-Tools project, useful if you want to use BIND
- Mike Cardwell blog: Understanding DNSSEC, what you can put in DNS (SSL, SSH, PGP, Email/DKIM) and explanation of DNSSEC and DNSSEC with BIND
- PGP keys in DNS, PKA (no RFC) and CERT (RFC 2538, 4398)
- sshfp for SSHFP records (RFC 4255) and since version 1.2 DANE (RFC draft)
- swede tool by Pieter Lexis to create and check TLSA records