DNS-01 validation using NS delegation for ACME challenge subdomain

Help
1

Subject: DNS-01 validation using NS delegation for ACME challenge subdomain

Hi everyone,

I'm working on automating Let's Encrypt DNS-01 validation for customer-managed domains and would like to confirm whether the following approach is supported.

Scenario

  • My application manages certificate issuance.
  • The customer's DNS is managed by a third-party DNS provider.
  • My DNS is hosted in Route 53.

Instead of asking the customer to create a new TXT or CNAME record for every certificate request, I'd like them to perform a one-time DNS configuration.

Configuration

The customer delegates the ACME challenge subdomain to my Route 53 hosted zone by adding NS records such as:

_acme-challenge.example.com. NS ns-1.example.net.
_acme-challenge.example.com. NS ns-2.example.net.
_acme-challenge.example.com. NS ns-3.example.net.
_acme-challenge.example.com. NS ns-4.example.net.

My Route 53 contains a hosted zone named:

_acme-challenge.example.com

When requesting a certificate for:

host1.example.com

my automation creates the TXT record:

host1._acme-challenge.example.com TXT "<challenge-token>"

The authoritative Route 53 nameservers return the correct TXT record.

However, Let's Encrypt fails with:

DNS problem: NXDOMAIN looking up TXT for _acme-challenge.host1.example.com

Public resolvers (for example, Google Public DNS) also return NXDOMAIN for:

_acme-challenge.host1.example.com

Question

Is delegating _acme-challenge.example.com via NS expected to work for DNS-01 validation of arbitrary hostnames such as:

  • host1.example.com
  • host2.example.com
  • api.example.com

Or does ACME require a separate delegation (or CNAME) for each hostname because it queries:

_acme-challenge.<hostname>.example.com

If this approach is not supported, what is the recommended architecture for allowing customers to perform a one-time DNS configuration while enabling automated DNS-01 validation for any future subdomain?

Thanks!

2

Yes; it does.

3

To expand on the answer from @rg305, the NS record is only for a subdomain; it would not match TXT record that Let's Encrypt is looking for. I am also not sure if you can have a _ as the leading character for a subdomain.

The individual CNAME records work fine; we do that here and point each host to a record in a subdomain that ACME clients can modify.

4

One practical workaround is a wildcard cert if that fits the product model: *.example.com uses _acme-challenge.example.com, so one delegated zone can cover arbitrary first-level hosts. If you need separate certs for host1.example.com, api.example.com, etc., then yes, each name needs its own _acme-challenge.<host> path via CNAME/NS or a customer-side DNS API integration.

5

As shown above:

that is a true statement.

As it could/should be used:

_acme-challenge.<host>.example.com. NS ns-1.example.net.
_acme-challenge.<host>.example.com. NS ns-2.example.net.
_acme-challenge.<host>.example.com. NS ns-3.example.net.
_acme-challenge.<host>.example.com. NS ns-4.example.net.

is another story.

That said, if possible, a wildcard for the subdomain might work better when all hosts are required:

_acme-challenge.*.example.com. NS ns-1.example.net.

[not all DNS servers support this kind of entry]

I would recommend against delagating a wildcard cert.

I believe the simplest and most straightforward approach would be to use one CNAME for each _acme-challenge record:

_acme-challenge.HOST1.example.com CNAME acme-servicing.example.net
_acme-challenge.HOST2.example.com CNAME acme-servicing.example.net
_acme-challenge.HOST3.example.com CNAME acme-servicing.example.net
6

I do not see how that could possibly work at all.

7

What don't you understand?

DNS requests for _acme-challenge.host.example.com will be resolved by the nameservers at example.net.
OR
Do the "<" and ">" throw you off?
[they are just there to imply a placeholder for the actual names that will be used]

8

That is not what that means AT ALL. What that means is that if you are interested in any DNS records in the SUBDOMAIN _acme-challenge.<host>.example.com then you should talk to one of the listed nameservers. And RFC 1035 prohibits the use of _ in a subdomain, so you couldn't even put an apex record in that subdomain.

9

Try it.
Let me know if it fails [and why].

10

Where?
RFC 1035 - Domain names - implementation and specification
doesn't even mention "_" or "underscore"

11
  • host names cannot have underscore in them
  • domain names can have underscore in them

If a domain name is in a role of host name (A or AAAA type DNS record), then the first rule applies too to the domain name.

12

I think your approach is reasonable, and plenty of people use NS delegation for DNS-01 challenges. Since Google DNS is also returning NXDOMAIN, I'd focus on the DNS setup first. It feels more like a delegation issue than an ACME limitation.

13

Please note where you read that information.

14

It comes from my memory. I read multiple RFCs long-long time ago, and RFC 1035 is only one of those. That makes your earlier observation correct, there is no general restriction on the use of underscore in domain names.
(English is not my matter language, the term "host names cannot have underscore in them" should be read as "host names shall not have underscore in them". Legal people are picky on that, I guess.)
By the way, the named-checkzone utility from the BIND package implements this, it gives warning on the use of _ in address (A and AAAA) DNS records.

I just did now a quick Internet search using a Large Language Model (LLM) search, filtering and output formatting engine:

What is the number of the RFC that denies the use of underscore in host names?

It’s RFC 952 and RFC 1123 (hostnames/“Internet host” rules): underscores are not permitted in hostnames per those standards.

EDIT: In theory, an RFC could restrict the use of the underscore character independently of mentioning it or not. RFCs has the tendency of explicitly listing the permitted characters for example [a-zA-Z0-9-]+ in a label.

My math prof used to say even if the result matches the correct value, the solution must be considered failure if there are two mistakes in solving an equation that compensate for each other.

15

Look at section 2.3.1.

Also, RFC 1101, section 3.1 and RFC 1123, section 2.1.

16

I'll let AI respond:

RFC 2181 never mentions the underscore character (_) explicitly..

What RFC 2181 does clarify is that the DNS itself places very few restrictions on the contents of labels:

  • Section 11 ("Name syntax") states that the DNS protocol does not require labels to follow the hostname syntax from earlier RFCs. It explains that any binary string can be used as a label (subject to the DNS length limits), and that applications are responsible for imposing any additional restrictions they need.

This is the key passage (emphasis added):

"The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The DNS protocol has no other restrictions on the labels that can be used."

Since _ is just another ASCII character, it is allowed in DNS labels under this clarification.

The RFCs that do discuss underscore-prefixed names explicitly are:

  • RFC 2782 — introduces names like _ldap._tcp.example.com.

  • RFC 8552 — explains and standardizes the use of underscore-prefixed labels for protocol-specific namespaces such as _acme-challenge, _domainkey, and _dmarc.

So the relationship is:

  • RFC 2181: DNS labels are not limited to hostname syntax, so _ is not prohibited.

  • RFC 2782 and RFC 8552: Define and explain the convention of using underscore-prefixed labels for protocol-specific purposes.

17

Yes. Underscore-prefixed names can be delegated just like any other DNS subtree.

This follows from the fact that names such as _acme-challenge.example.com or _tcp.example.com are ordinary DNS domain names. There is nothing in the DNS protocol that prohibits placing NS records at an underscore-prefixed node to create a zone cut.

For example, this is a valid delegation:

_acme-challenge.example.com.  IN NS ns1.validation.example.net.
_acme-challenge.example.com.  IN NS ns2.validation.example.net.

After this delegation, the zone example.com is no longer authoritative for names beneath _acme-challenge.example.com; the delegated zone is.

Relevant RFCs

  • RFC 1034 defines DNS delegation via NS records. It does not restrict delegation based on the characters in the owner name.
  • RFC 2181 clarifies that the DNS protocol itself imposes essentially no syntax restrictions on labels beyond their length, so underscore-prefixed labels are valid DNS names.
  • RFC 8552 treats underscore-prefixed labels as normal DNS names reserved for protocol-specific use. It does not prohibit delegation.

Practical considerations

Whether delegation is useful depends on the protocol:

  • For ACME DNS-01, delegation of _acme-challenge is widely supported by DNS and many implementations, although using a CNAME is more commonly documented and deployed.
  • For other underscore namespaces (such as _dmarc or _domainkey), the relevant protocol specifications may expect the record to exist directly at the owner name. Delegating the subtree is legal DNS, but the protocol or software involved may or may not follow the delegation as intended.

So from a DNS perspective, the answer is yes: underscore-prefixed names can be delegated with NS records in exactly the same way as any other domain name. The remaining question is whether the application protocol that queries those names is designed to work with such a delegation.

18

Rather than letting AI do my thinking for me ...

I will note that this is referring to the DNS protocol, and not the actual restrictions on domain/host names. I still do not believe it is valid that an A or AAAA record has any underscore anywhere. But I will admit that that you are correct, you can delegate the whole _acme-challenge domain. Guess I learned something new today.