Lead Image © Amy Walters, 123RF.com

Lead Image © Amy Walters, 123RF.com

Hardening network services with DNS


Article from ADMIN 66/2021
The Domain Name System, in addition to assigning IP addresses, lets you protect the network communication of servers in a domain. DNS offers further hardening of network protocols – in particular, SSH fingerprinting and CAA records.

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.


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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Secure SSH connections the right way
    Admins use SSH, the proverbial Swiss army knife of system management, for many of their daily tasks, but no matter how powerful the tool might be, it typically does not offer adequate protection. We look at ways to tighten SSH security.
  • Securing the TLS ecosystem with Certificate Transparency
    With the need for home offices during the pandemic lockdown, provisional solutions instituted on the fly during the transition from office to home require more permanent solutions, especially for securing TLS connections on the Internet.
  • Certificate security
    Use public key pinning to map certificates to specific domains.
  • Transport Encryption with DANE and DNSSEC
    Those who think that enabling STARTTLS in the mail client will make their mail traffic more secure are wrong. Only those who bank on DANE can be sure that a mail server or a firewall will not switch off encryption in transit.
  • Windows security with public key infrastructures
    A rarely used feature for improving security in Windows environments relies on certificates issued for various applications, services, and procedures that is based on a public key infrastructure.
comments powered by Disqus