What Is DNS-01? How It Makes Fully Automated Certificate Renewal Possible

The problem DNS-01 solves

Certificate authorities won't issue a certificate for a domain to just anyone who asks. Before signing, they verify that the requester controls the domain. The ACME protocol — the standard that Let's Encrypt and other modern CAs use — defines several ways to prove that control. The default method, HTTP-01, works by asking the CA to fetch a specific URL from the server over port 80. If the server responds correctly, ownership is confirmed.

That approach works well for public-facing websites. It breaks down everywhere else. An RDS server doesn't serve HTTP. A VPN gateway doesn't have a web server. A mail server may have port 80 blocked at the network perimeter. For any of these, HTTP-01 validation either requires opening inbound access that shouldn't exist, or it simply can't be used.

DNS-01 takes a different path entirely. Instead of calling a URL on the server, the CA looks for a specific TXT record in the domain's DNS zone. The server proves ownership not by responding to an incoming HTTP request, but by writing a value into DNS that only someone with control of that zone could place there.

How DNS-01 works, step by step

The full flow happens in seconds and involves no interaction with the server itself:

1

The ACME client requests a certificate for a domain — for example, rdp.alphacorp.com — and asks the CA for a DNS-01 challenge.
2

The CA returns a token — a unique value that must be placed in a DNS TXT record at a specific location: _acme-challenge.rdp.alphacorp.com.
3

The ACME client creates the TXT record via the DNS provider's API — automatically, with no manual step.
4

The CA performs a DNS lookup for the TXT record. If the value matches the expected token, ownership is confirmed and the certificate is signed.
5

The TXT record is deleted once validation is complete. The DNS zone is left clean — no temporary records left over.

Nothing happens on the server itself:

The entire DNS-01 challenge flow — request, TXT record creation, CA validation, certificate signing, TXT record cleanup — happens between the ACME client and the DNS provider. The server receiving the certificate is not involved in the validation process at all. No inbound connections are required. No ports need to be open. No IIS or nginx instance needs to be running.

DNS-01 vs HTTP-01: when each is appropriate

	HTTP-01	DNS-01
Requires port 80	Yes	No
Requires a web server	Yes	No
Works for wildcard certificates	No	Yes
Requires DNS API access	No	Yes
Works for non-web servers	No	Yes
Suitable for automation	Yes, for web servers	Yes, for any server

For public websites already running a web server, HTTP-01 is perfectly adequate and simpler to set up. The certificate authority just needs to be able to reach the server on port 80, which is true by definition for any publicly accessible website.

DNS-01 becomes the right choice the moment the server you're issuing a certificate for doesn't fit that mould: RDS and Remote Desktop gateways, VPN appliances, mail servers, internal API endpoints exposed via DNS but not HTTP, and any server where opening port 80 is either impractical or a compliance concern. It's also the only way Let's Encrypt will issue a wildcard certificate — HTTP-01 simply cannot be used for *.domain.com.

Why DNS control is the key requirement

DNS-01 shifts the trust proof from the server to the DNS zone. This is powerful, but it has one non-negotiable prerequisite: the system requesting the certificate must have programmatic write access to the domain's DNS zone. Without that, the TXT record can't be created automatically, and the entire challenge has to be completed manually every time a certificate is issued or renewed.

For an MSP managing dozens of client domains scattered across different registrars and DNS providers — some with API access, some without, some with API keys that rotate infrequently and live on individual servers — this is where automation breaks down. DNS-01 automation is only as consistent as the MSP's access to client DNS zones.

This is one of the strongest reasons to centralise client DNS management under the MSP . When every client's DNS zone is managed in one place, there's a single API to call, a single set of credentials to maintain, and zero per-client DNS configuration required when issuing a new certificate. The MSP has everything needed to complete any DNS-01 challenge for any client domain, automatically, at any time.

How Albaspot uses DNS-01 across the full certificate lifecycle

Albaspot's certificate management is built entirely around DNS-01. When you request a new certificate — for an RDS server domain, a VPN gateway, or any other non-web endpoint — Albaspot handles the Let's Encrypt DNS-01 challenge against the domain's DNS zone automatically. No port 80. No changes to the server. No firewall rules.

Because Albaspot manages client DNS zones directly, the DNS API access needed for the challenge is already in place. There are no additional credentials to configure, no per-client setup for new certificate requests. Request a certificate for any domain in a managed zone and the issuance happens in a single flow.

autorenew Automatic renewal at 30 days

Albaspot checks all active certificates daily and triggers renewal automatically when expiry is 30 days away. The renewal runs through the same DNS-01 flow as initial issuance. The TXT record is created, validated, and cleaned up. The renewed certificate is stored and immediately available to the server's agent. No human involvement required, no calendar reminders, no manual renewal steps.

terminal PowerShell agent deployment

Once a certificate is issued, the PowerShell installer is generated from the certificate detail page. Run it once on the Windows server as Administrator and it sets up a Scheduled Task that polls Albaspot for renewed certificates and imports them into the Windows certificate store automatically. The server never needs to participate in the ACME challenge — it just receives the finished certificate when one is ready.

notifications Failure alerting before expiry

If a DNS-01 challenge fails — a TXT record that didn't propagate in time, a domain that was moved out of a managed zone — Albaspot sends an immediate email alert with the specific failure reason. The auto-renewal flow also sends expiry warnings at 30, 14, and 7 days as a backstop. Failures surface before they affect clients rather than after the certificate expires.

The complete picture on the certificate detail page:

The certificate detail page shows issuance status, expiry countdown, agent connectivity, last-seen timestamp, and any failure reason — so you can see at a glance whether each certificate is healthy, whether the server's agent is checking in, and what to do if something needs attention.

What this means for certificate lifetimes getting shorter

Certificate authorities are shortening maximum lifetimes. Let's Encrypt has always issued 90-day certificates. The CA/Browser Forum is progressing toward a 47-day limit industry-wide, with Apple already announcing that Safari will enforce it from late 2027.

Every certificate that currently requires any manual step at renewal — even a single click — becomes roughly twice as expensive to maintain at 47 days versus 90 days. DNS-01 automation through a platform that already controls the DNS zone eliminates the per-renewal cost entirely. The renewal runs on a schedule, the server receives the new certificate automatically, and the fleet scales without adding operational overhead per certificate.

The MSPs who will handle shorter certificate lifetimes without increasing headcount are the ones who have already moved issuance, DNS management, and deployment into a single platform — so that the certificate renewal process doesn't involve any individual servers, any stored credentials on endpoints, or any manual verification steps.