DNS security: use DNSSEC and CAA correctly

Which problems DNSSEC and CAA address

DNSSEC protects the origin and integrity of signed DNS record sets. A validating resolver can use it to check corresponding answers and authenticated statements that a name or record type does not exist. CAA acts elsewhere: it helps restrict permitted certificate issuance. The browser does not treat CAA as an additional ongoing certificate check.

Without DNSSEC, this cryptographic proof of origin is absent. That does not mean any attacker can arbitrarily poison a DNS cache or that redirection automatically bypasses TLS verification. In the 2018 MyEtherWallet incident described by Cloudflare, a BGP hijack diverted DNS requests. The attacker's HTTPS site served an untrusted certificate; users had to bypass the warning. The case illustrates how different protections interact, not a guarantee provided by one measure. Cloudflare report

A signed zone can also contain incorrect data signed with an authorised key, for example after an administrative account is compromised. DNSSEC therefore replaces neither account protection and delegation maintenance nor secure web operations.

DNSSEC: RRsets, the chain of trust and resolvers

DNSSEC signs RRsets: related records with the same name, type and class. It does not simply sign each DNS packet. The main components are:

A validator follows the relationships between the record, signature, zone key and parent delegation up to a trust anchor. A registrable domain is not necessarily the boundary of every DNS zone operated beneath it. Delegated subzones have their own transition. RFC 4033, §§ 3–5, RFC 9364

Four states are useful when interpreting results: secure for successfully validated data, insecure for a demonstrably unsecured branch, bogus for failed expected validation, and indeterminate where there is insufficient basis for a decision. A resolver error alone does not fully distinguish these causes. SERVFAIL, for example, may indicate a broken DNSSEC chain or other resolution problems.

The AD bit is a statement by the resolver

An AD signal indicates that the responding resolver has assessed the relevant data as authentic. A client that does not validate for itself may rely on this only if it trusts the resolver and transport path. An arbitrary UDP packet with the AD bit set is not independent cryptographic proof. A query's DO bit requests DNSSEC data; it does not itself validate that data. RFC 4035, §§ 3.2.3 and 4.9.3

AD concerns the particular response, not every name and service under a domain. An authenticated negative answer may also carry AD. An AD finding therefore does not automatically confirm the existence of an A record or website availability. If AD is absent, distinguish, among other things, an unsigned answer, resolver behaviour, aliases and a chain that cannot be fully verified.

DNSSEC does not encrypt DNS

DNSSEC does not make queries confidential. DNS over HTTPS or DNS over TLS protects a transport path, for example to the chosen resolver; neither replaces that resolver's DNSSEC validation or trustworthiness. DNSSEC likewise does not guarantee availability or protect every registrar, hosting and DNS account. These tasks complement each other.

Introduce and change DNSSEC safely

The authoritative DNS operator is responsible for the signed zone, while the registrar usually handles the DS record in the parent zone. These may be different companies and interfaces. Identify the actual nameservers and responsibilities before changing settings.

1. Check support for signing, key management and DS publication. Assign responsibility, monitoring and recovery arrangements.
2. Prepare a consistently signed zone on the authoritative servers. Check keys, signatures, time synchronisation and responses.
3. Only then publish the matching DS data through the responsible channel. An incorrect or prematurely published DS record can prevent resolution for validating resolvers.
4. Check the chain from the perspective of trusted validators. Account for existing caches, TTLs and delegated subzones.
5. Monitor signature expiry, key changes and errors. One successful activation is not lasting operational evidence.

In the common split, a KSK signs the DNSKEY RRset and a ZSK signs the remaining zone data. Combined key models are also possible. A KSK change may require updates to the parent DS linkage; the exact process depends on the method. General intervals such as ‘ZSK every one to three months, KSK every one to two years’ do not replace a coordinated plan. Managed DNS also does not automatically mean that the registrar correctly follows every transition.

A provider change is a separate process involving delegation, keys, signatures and cache lifetimes. During planned deactivation, no still-effective DS linkage may point to data that is already unsigned. In a simple withdrawal, remove the DS linkage first and account for its expiry from relevant caches before signing stops. A planned transition without interrupting protection needs a suitable procedure from both operators. When something fails, restoring the matching chain is often preferable to uncoordinated deactivation. RFC 6781, §§ 4.1–4.4

Choose algorithms using current guidance

RFC 9904 superseded RFC 8624 and moved the authoritative implementation and usage recommendations into the IANA registries. In the reviewed state, ECDSA P-256/SHA-256 (13), Ed25519 (15) and RSA/SHA-256 (8), for example, are recommended for DNSSEC signing. This is not a universal instruction to switch a working zone to algorithm 13 without a migration plan. Supported methods, packet sizes, operational tools and safe transitions belong in the decision. General claims about every major provider's defaults or a blanket replacement of all RSA methods are not a reliable basis for it. RFC 9904, IANA registry

CAA: define permitted certificate issuers

A CA processing CAA determines the relevant RRset for each requested name before issuance. For wildcards, checking starts at the name without *.. Resolution accounts for aliases and, where needed, continues searching parent names. The search ends at the first applicable CAA RRset; arbitrary lists from every parent are not added together. An empty host query therefore does not prove that no restrictive rule exists. A query error certainly does not prove this. RFC 8659, § 3

An example of a deliberately chosen combination, not a general provider recommendation:

example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issue "digicert.com"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:security@example.com"

Here, the two named issuers are intended for ordinary names; only Let's Encrypt is intended for wildcards. The entries must match all certificate services actually used, including at the CDN and for automated renewals. Do not accidentally remove the issuer needed by a fallback or hosting service.

issue ";", as the sole applicable issue rule, can prohibit issuance. It is not an absolute veto alongside another applicable issue authorisation, however: these permissions are additive. A separate issuewild rule also needs its own assessment. A configuration containing only iodef does not restrict issuers. These counterexamples matter more than the mere number of CAA records found. RFC 8659, §§ 4.1–4.5

Common documented identifiers include letsencrypt.org, digicert.com, sectigo.com and globalsign.com. Check the specific certificate service and any parameters against its current documentation, rather than guessing a CAA value from the product name. Let's Encrypt, DigiCert, Sectigo, GlobalSign

CAA controls issuance, but does not revoke certificates already issued or replace domain validation or key management. Its effect depends on the issuer processing the rules correctly. DNSSEC can also protect CAA data where a suitable chain of trust and validation exist. The two mechanisms can nevertheless be used independently.

Investigate findings with targeted checks

These diagnostic queries are examples for your own domain:

dig +dnssec www.example.com A
dig example.com DS
dig example.com DNSKEY
dig www.example.com CAA
dig example.com CAA

dig +dnssec is not a complete standalone validator. Record the queried name, type, resolver, status, AD, time and aliases. For an error, establish whether it arises from the resolver, a delegation, missing signatures or reachability. Where necessary, compare authoritative answers with a controlled validating resolver. Temporarily disabling validation is not evidence of a working DNSSEC configuration.

For CAA, intermediate names and alias targets also matter; the short command list above does not cover them completely. A safe operational test also checks a planned certificate issuance or renewal through the provider's process. Do not order unnecessary real certificates merely to increase a scanner score.

What Wolf-Agents actually measures

In the reviewed implementation, the Web Security Check analyses the requested host. This is distinct from the final host after a web page redirect:

Resolver results and incomplete CAA results may be marked as not reliably assessable. This does not mean ‘definitely absent’. A detected DS record alone does not establish a valid chain. An algorithm name in the output comes from the data read and confirms neither key strength nor every signature.

Depending on configuration, transport uses the configured resolver or an HTTPS resolver as a bounded fallback. Its provenance matters. AD: true counts only when the resolver information establishes that validation was requested, was not disabled through Checking Disabled, and was communicated over a trusted channel. If this information is absent or negative, the result is a measurement gap without a validation bonus, not a DNSSEC error attributed to the domain; older stored results are not reassessed. The finding must therefore be read explicitly as a resolver observation. It does not perform a complete DNS operations audit, DNSSEC checking at the visitor, account protection or continuous monitoring.

Legal and standards references within their scope

DNS security can form part of appropriate technical and organisational measures. This does not establish a universal legal obligation for every website to use DNSSEC or CAA. For entities within scope, § 30 of Germany's BSIG requires suitable, proportionate and effective measures. § 38 concerns their management bodies; liability follows the conditions and rules stated there, not an individual missing DNS record. § 30 BSIG, § 38 BSIG

The relevant BSI IT-Grundschutz module is APP.3.6 DNS servers, not APP.3.9. Its 2023 edition contains a standard requirement under A17 using ‘SHOULD’ for DNSSEC on resolving and authoritative DNS servers and for key changes. Whether and how it applies to a particular information system depends on modelling, scope and the assessment procedure; an individual website query does not establish BSI certification. BSI APP.3.6, A17

ENISA's guidance on Implementing Regulation (EU) 2024/2690 lists DNSSEC among DNS security practices to consider. It addresses particular entity types, including DNS, cloud and other digital service providers; it does not become a blanket requirement for every domain holder. Likewise, Article 32 GDPR requires a risk-based choice of appropriate measures, not a universal combination of these two DNS settings. Further reading: ENISA guidance, compliance guide, NIS2 checklist for Germany and management responsibility in Germany. The country overview explains other national contexts.