DNS‑Based Certificates in ACME Protocol

The issuance and management of digital certificates are foundational to secure web communications, with the HTTPS protocol relying on valid X.509 certificates to authenticate servers and encrypt data in transit. Traditionally, obtaining a certificate from a Certificate Authority (CA) involved manual verification processes and complex tooling. This changed with the introduction of the Automated Certificate Management Environment (ACME) protocol, developed by the Internet Security Research Group and standardized in RFC 8555. ACME enables automated, secure, and scalable certificate issuance by allowing clients to prove domain control to a CA through a series of challenge-response mechanisms. Among these, DNS-based validation—specifically the dns-01 challenge—has emerged as a critical component, enabling certificate issuance through DNS modifications without requiring access to web servers or HTTP infrastructure.

In the context of the ACME protocol, the dns-01 challenge allows a domain owner to prove control over a domain by creating a specific TXT record under the _acme-challenge subdomain. When the ACME client initiates a certificate request, the CA provides a token that must be placed as a TXT record. Once the record is published, the CA queries the domain’s authoritative DNS servers to verify that the correct token is present, thereby confirming that the requester has administrative access to the DNS zone and, by extension, the domain. This method offers a clean separation between certificate management and web hosting, making it especially attractive for use cases involving multi-tenant architectures, cloud-based environments, or services that are not tied to traditional HTTP endpoints.

DNS-based validation offers numerous operational advantages. One of the most significant is the ability to issue certificates for domains that do not currently serve web content or that use non-HTTP protocols such as SMTP, SIP, or MQTT. For example, mail servers securing STARTTLS connections on MX records or IoT devices communicating over encrypted channels can benefit from ACME-issued certificates validated through DNS alone. Since the dns-01 challenge only requires changes to DNS records, it decouples certificate issuance from the specific software stack running on the server, enabling more flexible and automated deployment pipelines.

Moreover, DNS-based challenges are ideal for wildcard certificates, which allow a single certificate to cover all subdomains of a given domain. The dns-01 challenge is the only method in ACME that supports wildcard issuance, as HTTP- and TLS-based challenges validate only specific hostnames. By placing a single TXT record at _acme-challenge.example.com, a domain administrator can obtain a certificate valid for *.example.com, simplifying certificate management for dynamic environments or large-scale hosting platforms. This makes DNS-based ACME validation a critical tool for platforms that manage vast numbers of virtual hosts or offer user-customizable subdomains.

The adoption of dns-01 challenges, however, introduces new dependencies and security considerations. Since control over DNS records is equivalent to control over certificate issuance, it becomes vital to secure access to DNS management interfaces. Misconfigured access control lists, compromised credentials, or insecure DNS APIs could allow an attacker to inject malicious TXT records and obtain fraudulent certificates. This risk has led to a growing emphasis on DNS provider security, the use of multi-factor authentication, and the implementation of delegated domain validation using restricted API tokens.

To support automation, many DNS providers now offer programmable APIs that integrate directly with ACME clients. Tools like Certbot, Lego, and acme.sh include built-in support for dozens of popular DNS platforms such as Cloudflare, AWS Route 53, Google Cloud DNS, and DigitalOcean. These integrations allow the ACME client to dynamically create and delete TXT records during the validation process, enabling seamless, fully automated certificate renewals. In more advanced setups, organizations may deploy custom ACME clients with internal DNS APIs to validate large numbers of internal or external domains, further extending the scope of DNS-based validation beyond public-facing websites.

Despite its benefits, DNS-based validation is sensitive to propagation delays and caching behavior. Because authoritative DNS changes can take time to propagate and resolvers may cache stale data, timing must be carefully managed during the challenge-response process. ACME clients must ensure that the TXT record has fully propagated and is visible to the CA’s DNS resolver before triggering the challenge verification. Failure to do so can result in false negatives and failed validations. Some clients implement polling or propagation checks, querying the authoritative nameservers directly to confirm the record’s visibility before proceeding.

DNSSEC also plays an important role in the future security model of DNS-based certificate issuance. While DNS responses are typically unsigned and vulnerable to spoofing, the deployment of DNSSEC adds authenticity and integrity to DNS records. A CA validating a dns-01 challenge could, in principle, use DNSSEC to ensure that the TXT record it retrieves has not been tampered with in transit. Though not yet required by most CAs, this integration represents an important enhancement to the trustworthiness of DNS-based ACME operations and is a likely direction for future standardization efforts.

In addition to its core use in certificate issuance, DNS-based ACME validation enables powerful delegation models. A domain owner can delegate control over ACME challenges to a third party by creating specific CNAME records that redirect _acme-challenge lookups to a different domain or subdomain managed by the delegate. This mechanism allows certificate management responsibilities to be outsourced or federated without granting full DNS access. For example, a SaaS provider could manage certificate issuance for customer domains by having those customers delegate challenge resolution via CNAMEs, streamlining multi-tenant certificate provisioning while maintaining domain ownership boundaries.

The evolution of ACME and its DNS-based validation method has transformed the certificate landscape by reducing friction, increasing automation, and enabling secure communication at scale. In a digital ecosystem where certificate transparency, short-lived certificates, and continuous deployment are becoming the norm, the ability to programmatically and securely validate domain control through DNS is indispensable. As organizations continue to expand their use of encryption across diverse services and platforms, DNS-based ACME workflows will remain central to the future of trust on the internet, bridging the domain name system with the public key infrastructure that secures online communication.

The issuance and management of digital certificates are foundational to secure web communications, with the HTTPS protocol relying on valid X.509 certificates to authenticate servers and encrypt data in transit. Traditionally, obtaining a certificate from a Certificate Authority (CA) involved manual verification processes and complex tooling. This changed with the introduction of the Automated Certificate…