DNS

DNS is the system that translates human-readable domain names (e.g. google.com) into IP addresses (e.g. 216.58.209.174). DNS is a critical piece of internet infrastructure and must be configured correctly to be secure.

Security testing tools

For clients

For domains

Lists of DNS providers

| Name | Location | .fi | DNSSEC | ACME | DynDNS | CAA | DANE/TLSA | |—————————————————————–|————-|——|—————————————————————————————|——————————————————-|——–|————————————————————————–|————————————————–| | BunnyDNS | Slovenia | No | Yes | No | ? | Yes | ? | | ClouDNS | Bulgaria | Yes | Yes | Yes | Yes | Yes | Yes | | DNScale | Estonia | No | Yes | No | ? | Yes | Yes | | deSEC | Germany | No | Yes | Yes | Yes | Yes | Yes | | EuroDNS | Luxembourg | Yes | Yes | Yes | ? | Yes | ? | | Nanelo | Germany | No | Yes | ? | ? | Yes | ? | | OVH | France | Yes | Yes | Yes | Yes | Yes | Yes | | RCodeZero | Austria | No | Yes | Yes | No | Yes | Yes | | Scaleway DNS | France | No | Yes | Yes | Yes | Yes | Yes |

Explanations of the columns:

Domain Name System Security Extensions (DNSSEC)

By default, DNS records are transmitted without encryption and signing. This makes it possible for an attacker to intercept and modify them in transit, which is known as a man-in-the-middle attack. DNSSEC fixes this by cryptographically signing the DNS records.

To enable DNSSEC for client devices, configure a DNS resolver that supports DNSSEC validation. One such resolver is Cloudflare’s 1.1.1.1.

To enable DNSSEC for your domain, contact your domain registrar. If your registrar does not support DNSSEC, I recommend transferring the domain to a registrar that does.

DNS over HTTPS (DoH)

DNS over HTTPS (DoH) is a protocol for performing DNS resolution over HTTPS. This prevents eavesdropping and manipulation of DNS data between the DNS server and client. However, it does not verify the authenticity of the DNS data, so it should be used together with DNSSEC for maximum security. Please also note that the DNS provider will still be able to see all the DNS queries.

DNS over TLS (DoT)

DNS over TLS (DoT) is a protocol similar to DoH, but it uses bare TLS instead of HTTPS for encrypting the DNS traffic.

Certificate Authority Authorization (CAA)

CAA is used to restrict, which certificate authorities are allowed to issue certificates for your domain.

Let’s Encrypt instructions

# Any validation method
example.org CAA 0 issue "letsencrypt.org"
# HTTP validation only
example.org CAA 0 issue "letsencrypt.org;validationmethods=http-01"
# DNS validation only
example.org CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

DomainKeys Identified Mail (DKIM)

  • Microsoft 365 instructions
    • You can create the DKIM keys in the Microsoft Defender portal. Then copy-paste the two generated CNAME records to your DNS configuration.

Sender Policy Framework (SPF)

Domain-based Message Authentication, Reporting and Conformance (DMARC)

  • Requires SPF and DKIM to be configured first.
  • Microsoft 365 instructions
  • TXT record
    • Hostname: _dmarc
    • TXT value: v=DMARC1; p=reject; rua=mailto:<REPORT_EMAIL_ADDRESS>; ruf=mailto:<REPORT_EMAIL_ADDRESS>

MTA-STS

DNS-based Authentication of Named Entities (DANE)

DANE is used to authenticate certificates and keys using DNSSEC. Therefore, DNSSEC is a prerequisite for DANE. The primary use of DANE is authenticating TLS certificates using DNSSEC instead of a CA. This is done by TLSA DNS records.

HTTPS

As of 2026, DANE is not supported by major web browsers such as Chrome and Firefox. This is due to several reasons. First of all, DNSSEC adoption has been quite slow. Also, web browsers currently rely on their DNS-over-HTTPS (DoH) providers or system DNS resolver for DNS resolution and DNSSEC validation. In order to properly support DANE securely, web browsers would need to implement their own DNS resolver with DNSSEC validation. This would require them to manage their own trust anchors for DNSSEC validation, which would be parallel to their existing CA trust store. This adds both technical and administrative complexity, as the browsers would need to decide on how to handle possible conflicts between the DNSSEC trust anchors and the CA trust store. (What if a certificate is valid according to the CA trust store but invalid according to DNSSEC, or vice versa? Which one to trust in such a case?) Together, these issues have made web browsers hesitant to implement DANE support, at least until DNSSEC adoption becomes more widespread.

SMTP

The TLSA record can be used to enforce TLS for incoming email.

PGP

DANE can also be used to publish PGP keys in DNS.

  • kernel.org instructions
  • Quick instructions Please note that RSA keys can be quite large, and size of DNS records should be kept as small as possible. Therefore, it’s highly recommended to use some other algorithm than RSA to create the PGP key. A good option is to use Ed25519 + Curve25519.

SSHFP

SSHFP is a DNS record used to publish a SSH host key in DNS. It’s for SSH what DANE is for TLS and PGP. Similarly as DANE, SSHFP relies on DNSSEC for verifying the authenticity of the published key. You can enable SSHFP verification in your SSH client by adding the following lines to your ~/.ssh/config file:

Host SERVER_NAME
    HostName SERVER_FQDN
    VerifyHostKeyDNS yes

As with DANE PGP, using Ed25519 keys is highly recommended over RSA keys to reduce the size of the DNS records. For the hash algorithm, use SHA-256 (value 2) over SHA-1 (value 1), since SHA-1 is broken and should not be used.