DNS is the system that provides information on hostnames like
the IP address of
aweirdimagination.net so your browser
can connect to this website. DNSSEC is an extension which uses
cryptographic signatures in order to verify that information
is actually correct, preventing certain classes of attacks
which could cause you to believe you are connecting to one server while
actually connecting to a computer under the attacker's control. Additionally,
since DNSSEC verifies information obtained through DNS has not been
tampered with, it allows for DNS to be used for certificates,
so servers can be authenticated for encrypted protocols without the need
for relying on certificate authorities.
Unfortunately, DNSSEC support is not widespread in clients or servers.
Particularly, I did not want to run my own DNS server and have to
worry about keeping it updated and being aware of any security
vulnerabilities. I wanted to be able to, for a reasonable price, have
a domain with full DNSSEC support and use it for securely advertising
https certificate for this website and the
ssh server key
for the web server. (Admittedly, I am trusting the DNS host more than
strictly necessary, but realistically, they are also my registrar so
they could simply publish their own keys for my domain if they wanted to
take it over.)
I settled on using easyDNS, since they were the only DNS
hosting provider I could find that offered what I wanted; specifically,
they very recently added support for TLSA and SSHFP records
ssh keys, respectively). I later found mentions of
RAGE4, which also looks like it should work.
I followed easyDNS's DNSSEC guide. At first, their interface showed an error upon trying to actually create TLSA or SSHFP records, but I filed a support request and they fixed the bug within a couple days.
Of course, to get the most out of DNSSEC, we need to actually generate those records.
Generating TLSA records
TLSA records verify certificates for TLS connections, like
those used when accessing a website with an
https:// URL. To
generate the proper format, you can use the
tlsa tool in the
hash-slinger package. If you already have a
web server running with
https support, it will just read the
certificate and generate the proper record (you may need the
--insecure option if you have not yet set up DNSSEC):
$ tlsa --create aweirdimagination.net Got a certificate with Subject: /C=US/CN=www.aweirdimagination.net/emailAddressemail@example.com _443._tcp.aweirdimagination.net. IN TLSA 3 0 1 e010b00062fa5936ad1b8b3abc677c145094c54d5391c412e0c9a4c8c956a8c0
You can also generate the TLSA record from a certificate file or by pasting your certificate into this web tool.
Remember to put the TLSA records not on the actual domain, but on a
special subdomain with the port number (443) and protocol (TCP), which
correspond to the defaults for
https. When actually setting the TLSA
record, the part you want to give to your DNS host is what comes after
in the output of
tlsa. For the above, that would be
3 0 1 e010b00062fa5936ad1b8b3abc677c145094c54d5391c412e0c9a4c8c956a8c0
Client support (or lack thereof)
Do note that while
tlsa --verify will tell you whether
you have set this up correctly, no modern browser will actually use your
TLSA records unless you install a plugin. Mozilla is
in no rush to add support and Google has declared
they do not intend to add support.
Generating SSHFP records
SSHFP records store
ssh fingerprints in DNS so if you add
~/.ssh/config file, then your first login to a host will include
Matching host key fingerprint found in DNS.:
$ ssh aweirdimagination.net The authenticity of host 'aweirdimagination.net (188.8.131.52)' can't be established. RSA key fingerprint is ff:99:5a:69:08:d4:83:55:c7:95:fa:d7:4e:c2:08:46. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?
ssh-keygen command included with
generate the records:
$ ssh-keygen -r aweirdimagination.net aweirdimagination.net IN SSHFP 1 1 825a7ff74fe77b0e7354c44f675d595c177b2496 aweirdimagination.net IN SSHFP 1 2 e376ac225bd0469612860c47ac79fa51486db609ca6e8d34a0020411cf6a9f92 aweirdimagination.net IN SSHFP 2 1 0854b02a3c8b2cb116373a142d75206244775b7a aweirdimagination.net IN SSHFP 2 2 a051aa98f2a87dce8c9fd319abd87d5822d6c3bfc23707992527a965b6058287
Once again, the actual record starts after
SSHFP on each line. See
this Unix StackExchange answer for a description of what
those fields mean.