“DNS-01 challenge” with domain redirection: is this Let’s Encrypt feature possible?

Feature Requests
1

Imagine that you own the domains "domain.com" and "domain.info."

  1. You want to generate certificates of any kind in "domain.com." For example:
    *.domain.com, node1.domain.com, node2.domain.com, sql.domain.com, etc.

  2. "domain.com" doesn't have an API or you don't want to grant access to this highly sensitive area of ​​your company DNS.

  3. "domain.info" has an API or it is dedicated exclusively to performing DNS-01 challenges.

The solution is therefore to redirect challenge from « domain.com » to « domain.info ».

I asked my best friend ChatGPT …

ChatGPT's answer:
Create a subzone "_acme-challenge.domain.com" referencing "domain.info," with following declaration in the "domain.com" zone:
_acme-challenge.domain.com. IN NS dns1.domain.info.
_acme-challenge.domain.com. IN NS dns2.domain.info.

:thinking:It seems to me that: a zone "domain name" cannot begin with an underscore "_" ? True or false ?

To summarize, do the following statements allow you to pass the DNS-01 challenge on the redirect domain "domain.info"?
_acme-challenge.domain.com. IN NS dns1.domain.info.
_acme-challenge.domain.com. IN NS dns2.domain.info.

2

Well, chatgpt is wrong here. It's perfectly valid to have a DNS label starting with an underscore.

I'd wager millions of certificates are issued daily using DNS-01 challenge, therefore querying _acme-challenge records. If it wasn't possible it wouldn't have been used by ACME spec.

Not to mention various SRV records.

2 Likes
3

The underscore in _acme-challenge is not an accident or oversight: It's entirely intentional by the specification.

There is a lot of misinformation about underscores in DNS out there, so I'm not surprised that the average AI gets it wrong. There's a good stackoverflow answer that sums it up:

Most answers given here are false. It is perfectly legal to have an underscore in a domain name. Let me quote the standard, RFC 2181, section 11, "Name syntax":

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. [...] Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs.

See also the original DNS specification, RFC 1034, section 3.5 "Preferred name syntax" but read it carefully.

Domains with underscores are very common in the wild. Check _jabber._tcp.gmail.com or _sip._udp.apnic.net.

Other RFC mentioned here deal with different things. The original question was for domain names. If the question is for host names (or for URLs, which include a host name), then this is different, the relevant standard is RFC 1123, section 2.1 "Host Names and Numbers" which limits host names to letters-digits-hyphen.

To sum up, underscores are allowd in FQDNs, but not in host names. This distrinction is often confused. The underscore in _acme-challenge is intentional such that the challenge subdomain can never (accidentally) be used for something else, i.e. you cannot host a website or similar on that subdomain. This avoids potential conflicts. Many modern DNS-specific authentication protocols use this leading underscore for this purpose (i.e. DMARC uses _dmarc, DKIM uses _domainkey).

The specific problem you seem to be trying to solve has already been solved: It is perfectly possible to "redirect" the DNS-01 challenge to another domain - all you need to do is to setup a CNAME:

_acme-challenge.example.com. IN CNAME something-else.example.org.

This means that you can answer the DNS-01 challenge for example.com from example.org. These domains can be hosted by entirely different nameservers and have different registrars even (or the same, everything is possible).

8 Likes
4

In addition to the above, I suggest reading this:

That blog post describes the exact problem you are talking about in detail, and introduces a solution that has become widely adopted – acme-dns server.

While everything can happen on a different domain (domain.info on your example), many people like to use a dedicated subdomain (acme-dns.domain.com)

5 Likes
5

I don't think ChatGPT is incorrect, I believe it's OP that claimed that the advise of ChatGPT was incorrect due to the underscore, not ChatGPT itself.

6

I'd say ChatGPT's advice/way of doing it is fine on first glance. That said, the beauty of DNS is that it's .... DNS. You can do it in a bunch of ways. This is what I did at one org with a similar setup the OP describes without the need for a new organizational domain (domain.info in OP's example).

  1. Setup DNS hosting with another vendor that does have the API and controls you desire. Setup a zone with this vendor of acme-challenges.example.net.
  2. NS acme-challenges.example.net. to the above vendor's nameservers they provide you
  3. CNAME _acme-challenge.foobar.example.net. to slotXX.acme-challenges.example.net.
  4. Configure your ACME client to publish the dns-01 challenge to slotXX.acme-challenges.example.net.

That's all she takes from a technical perspective. Just be sure to document everything and you're golden.

1 Like
7

FWIW; I've found it easier to create a organizational policy to predict/generate the CNAME targets. Predicting the CNAME targets lets you setup and check the authoritative DNS records before doing any challenges.

Using this technique, you essentially "pre-assign" the CNAME for a given record (you know exactly what the CNAME target for any domain would be), without having to do any real work.

i.e.

  • you create a policy wherein the CNAME for _acme-challenge.example.com will target example-com.auth.example.com (or whatever your policy dictates)
  • you can audit the dns records to ensure they're all set up properly
  • once things are set, you can handle configuring the delegated nameserver records

This technique be deployed with commercial and private dns servers. It is unofficially supported in acme-dns -- although acme-dns generates a random subdomain, you can update the records in it's database to easily implement this technique. I wrote a script to do it, which can easily be adapted: peter_sslers/tools/replace_domain.py at main · aptise/peter_sslers · GitHub

3 Likes
8

I was a little confused what you were getting at but your example cleared it up.

What we did was just use a table in a KB article - there were maybe a dozen or so of these things.

2 Likes