Digging further into the issue, it seems like a problem partially caused by my DNS records setup, and the assumption of ns_getdomain.

My DNS setup on jc666.xyz subdomains is a CNAME to jc666.xyz. That means all subdomains mirror records on jc666.xyz.

On jc666.xyz, it would return the SOA record in the answer section instead of the authority section. On subdomains however, that's not the case, instead it has SOA records in the authority section. But because I have a CNAME from the subdomains to jc666.xyz, it would always have the SOA in the answer section, which is what ns_getdomain doesn't care about, and so it returns literally nothing, causing issues trying to create records.

I think this is a problem with my DNS setup, not the script itself. Although the script is definitely involved.

I am going to try my best to explain this complicated mess that is my DNS setup, and how my script is affected...

There will be the following stuff:

1. My wildcard subdomains setup
2. My certificate setup and how that ties into this script
3. My solution (for my own problems)

#Wildcard subdomains setup

I want to provide additional stuff under subdomains under the jacksonchen666.com domain. Like https://videos.jacksonchen666.com.

The DNS configuration is a CNAME record on *.jacksonchen666.com. which points to s.jacksonchen666.com.. It does not point to jacksonchen666.com., as I do not want the other unrelated records (TXT, CAA, etc.) to be included under all subdomains, as that felt unclean.

I pointed the CNAME record to s.jacksonchen666.com. which actually is another "zone" (I think). In my deSEC.io account, I have the following domains setup:

• jacksonchen666.com
• s.jacksonchen666.com

This setup was made to circumvent the rate limiting on DynDNS updates (see https://desec.readthedocs.io/en/latest/rate-limits.html and search for dyndns), so I can provide my server on both jacksonchen666.com and any subdomains under that without dealing with constant rate limits.

Another thing I do is get wildcard certificates so that setting up new services is much easier.

#Certificate setup (and the script)

In order to also get wildcard certificates from Let's Encrypt, the DNS validation method must be used (https://community.letsencrypt.org/t/acme-v2-production-environment-wildcards/55578).

Let's assume that I want a certificate with the domain name *.hazmat.jacksonchen666.com.

Let's Encrypt checks for a TXT record at _acme-challenge.hazmat.jacksonchen666.com for getting a certificate with a domain like *.hazmat.jacksonchen666.com. My uacme-desec-hook script is used to create that required TXT record. However, it also needs to know what domain so that the script can create the TXT with the deSEC.io APIs.

The deSEC.io API for creating a DNS record requires the following information:

• The domain (e.g. when trying to create a record at _acme-challenge.hazmat.jacksonchen666.com., the domain is jacksonchen666.com)
• The subname (e.g. when trying to create a record at _acme-challenge.hazmat.jacksonchen666.com., the subname should be _acme-challenge.hazmat)
• The rest of the DNS record details (not relevant here)

The script itself currently knows the full name thing, but it has to split it up into those 2 parts for the deSEC.io API. To do the splitting, the script must know the domain, so the script calls the ns_getdomain function, which would get the name of the zone(?) by running dig +noall +authority "_acme-challenge.hazmat.jacksonchen666.com." SOA, which should be returning jacksonchen666.com. at minimum. However, that's not the case, because of the wildcard CNAME I put up.

The wildcard CNAME would point to s.jacksonchen666.com. which is actually a different zone from jacksonchen666.com, and that would result in getting a different SOA which is not part of the authority answer. That would mean nothing would be output when running the dig command (in the previous paragraph), so the script would be calling the API at the following URL: https://desec.io/api/v1/domains//rrsets/. The correct URL would be https://desec.io/api/v1/domains/jacksonchen666.com/rrsets/ in the case of _acme-challenge.hazmat.jacksonchen666.com.

For some clarification, this is what the script expects to be output from dig +noall +authority "_acme-challenge.hazmat.jacksonchen666.com." SOA:

jacksonchen666.com.	300	IN	SOA	get.desec.io. get.desec.io. 2024023039 86400 3600 2419200 3600

However, this is what actually gets output with my broken setup:

Yes, absolutely nothing got output. Because there's no authority answer part anymore.

#My solution

The solution for me was to put a TXT record under destroyer-of-cnames._acme-challenge.hazmat.jacksonchen666.com., and do that for every domain I plan to get certificates for (with DNS validation). Of course, the destroyer-of-cnames can be anything, but it pretty much has to be something.

Doing that makes the wildcard CNAME not exist anymore on and under _acme-challenge.hazmat.jacksonchen666.com., so that when the script calls ns_getdomain for _acme-challenge.hazmat.jacksonchen666.com., the script would get the authoritative and correct SOA record.

Some relevant links:

• https://www.rfc-editor.org/rfc/rfc4592#section-2.2
• https://www.rfc-editor.org/rfc/rfc4592#section-4.9

I felt like making a shorter explanation, so here it is.

To create a DNS record at _acme-challenge.hazmat.jacksonchen666.com (for Let's Encrypt DNS verification):

• deSEC.io API needs the domain, which in this case is jacksonchen666.com
• uacme-desec-hook uses ns_getdomain to get that info, which gets the SOA records in the Authority section.
• I have a CNAME at *.hazmat.jacksonchen666.com pointing to s.jacksonchen666.com which is in a different zone (or a different deSEC.io domain), so the SOA record from that is returned instead, and nothing is included in the Authority section.
  • s.jacksonchen666.com is a separate deSEC.io domain, so that I can use dynDNS on both the top level domain jacksonchen666.com and the rest of the subdomains without deSEC.io rate limiting issues. It's therefore a different zone.
• Solution was to create some type of DNS record under _acme-challenge.hazmat.jacksonchen666.com (directly on that name (not preferred), or in subnames of that), so that the SOA records would be what's expected.
  • I put a random TXT record at destroyer-of-cnames._acme-challenge.hazmat.jacksonchen666.com. Repeat for all other applicable cases.

re-opening since there's probably a solution to this problem in https://github.com/ndilieto/uacme/pull/68 when i checked