The Domain Name System (DNS) was specified way back in 1983, eliminating the need for a locally maintained HOSTS file with name resolution entries and thus contributing significantly to the success of the Internet. The decentralized approach to resolving domain names into IP addresses began, as with almost all protocols of the Internet, without a focus on security. A good 10 years later, work began on the DNS Security Extensions (DNSSEC), which today allow the operation of a reliable and cryptographically secure DNS infrastructure.

In addition to secure name resolution, DNS has established itself as a universal protocol for hardening network protocols. The best known application is probably secure email communication with Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and a combination of the two in the form of Domain-based Message Authentication, Reporting, and Conformance (DMARC).

Checking SSH Fingerprints

The first time you establish an SSH connection, you are confronted with viewing and verifying the server fingerprint. Although a reliable check is required for security reasons, the displayed fingerprints are often approved without a second thought. As a security-aware administrator, you can reliably remedy this situation thanks to SSH fingerprinting (SSHFP). When you create the required DNS entries for your server, you can run the command

ssh-keygen -r <hostname>

to output the hashes. The two digits before the fingerprint encode the algorithm and hash method used [1]. Digits 1 to 4 on the left stand for (in ascending order) RSA, DSA, ECDSA, and Ed25519. No algorithm has been assigned for 5 yet, and 6 stands for Ed448. The values 1 and 2 in the second position stand for the SHA-1 and SHA-256 hash methods.

Since version 6.6, OpenSSH has let users query fingerprints when establishing a connection and matches automatically if you enable the following option in the configuration file of your SSH client, (e.g., in ~/.ssh/config):

VerifyHostKeyDNS yes

Alternatively, you can enable this option every time you establish a connection with:

ssh -o VerifyHostKeyDNS=yes <hostname>

In this way, manual fingerprint checking when first connecting to a server – regardless of how reliably you usually do it – is a thing of the past. For example, the command

dig hostname sshfp +dnssec +multi

lets you query DNS records of the SSHFP type.

Certificate Authority Authorization

In principle, any certificate authority (CA) can issue a valid certificate for any domain, provided users or their programs trust the CA. However, CAs do not always check the legitimacy of applicants, so attackers can obtain a valid certificate for a domain for which they have no authorization at all.

One way to provide more security is with Certificate Authority Authorization (CAA). You use this DNS record to specify which CA is allowed to issue certificates for your domain. The CA is obliged to check for a corresponding entry should a request to issue a certificate for a domain be received, and it should not issue a certificate if the requester is not on the list.

The procedure was specified in RFC 6844 back in 2013 [2]. Nevertheless, its use is not particularly widespread, although since support for wildcard certificates was introduced, only one CA is frequently used and the overhead for maintaining the associated CAA entries thus remains manageable. If you want to use more than one CA in your enterprise, you can create several CAA records for each domain. Because of the hierarchical structure of DNS, CAA settings used for subdomains can be different from the main domain. These settings then overwrite the entries of the higher levels.

A CAA record comprises three elements: a byte value to represent flags, a property tag that specifies the type of record, and a string associated with the tag. The current CAA specification defines only one possible value as a flag. The value 128 means critical and has no practical meaning today. In the future, the idea is to use it to mark entries with special properties. If a flag is set, CAs are not allowed to issue certificates if they cannot interpret the specified property.

As the tag, you can specify issue , issuewild , and iodef . The issue and issuewild values define a string containing the domain name of the certification authority as the third value. The two entries differ in that issue controls the issuance of a certificate for a specific domain and issuewild controls issuing a certificate for a wildcard subdomain. In this case, entries with the issue type must not be interpreted when issuing wildcard certificates. In return, entries of the issuewild type must be left out when issuing specific domain certificates.

A CAA record for your domain that only allows the use of Let's Encrypt could look like:

domainname.tld <TTL> CAA 0 issue "letsencrypt.org"

Additionally, if you want to allow the issuing of wildcard certificates, add a second entry:

domainname.tld <TTL> CAA 0 issuewild "letsencrypt.org"

For example, to allow the issuing of wildcard certificates exclusively by provider GlobalSign, change the previous entry as follows:

domainname.tld <TTL> CAA 0 issuewild "globalsign.com"

Alternatively, by specifying both entries, you can allow wildcard certificates to be issued for the CAs Let's Encrypt and GlobalSign.

The third type, iodef , supports the specification of a contact in case of problems or security incidents. You can specify a web or email address here so your communication partners have a way of reporting incidents (e.g., if they are offered a certificate that comes from an unauthorized CA). You should specify an abuse address, as shown in the entry:

domainname.tld <TTL> CAA 0 iodef "mailto:<abuse@domainname.tld>"

If you want to check the CAA records for your domain, use the command:

dig CAA <domainname.tld>

As a result, you will see output that informs you about your defined domains and subdomains, as well as the associated certification authorities.

Conclusions

Since its introduction, and after development of the DNS Security Extensions, the Domain Name System has established itself as a reliable protocol for exchanging security-related information. In this article, I looked into application scenarios for protecting SSH connections with SSHFP records and for securing the certification of domain names with CAA records. With just a few steps, you can enable significantly more security.