This is a refinement of the thread I started here:
There appears to be an issue with the Let's Encrypt script for the DA server hostname, when the same server is also hosting the domain as well. For example:
domain: example.com
server: host.example.com
The result is that DA creates the host.example.com DNS zone when installation is complete. After logging in to the DA server, enter the User mode, and create the domain for example.com. The result is that example.com exists along side host.example.com. However, host.example.com refers to ns1.example.com and ns2.example.com, which are the DA server itself. But the problem is that the base domain example.com doesn't have any records for host.example.com, and so that zone is dead except for local resolution. If I try to use the Let's Encrypt script mentioned here:
It will quit with either the message:
Setting up certificate for a hostname: host.example.com
Error: http://host.example.com/.well-known/acme-challenge/letsencrypt_1575657746 is not reachable. Aborting the script.
or:
Unable to determine domain name for authorization. Exiting...
Looking at the script here https://files.directadmin.com/services/all/letsencrypt.sh I can see that these are both error messages of the script itself, not a response from Let's Encrypt. If I now create the A and NS records in example.com for host.example.com such that the host.example.com zone now can be resolved, the problem still exists. I manually checked that files under .well-known are accessible from a browser and indeed they are, though they are of 0 size. Other files are also available under this folder.
I have waited a long time with a TTL of 60 seconds long after the default 14400 would have expired and the issue persists.
As proof I'm not crazy, I created host.example.net at a different DNS provider, and pointed it to my IP address, and the script completed just fine. Other domains on this host also resolve and get certificates fine as well.
Is the scenario where the server hostname is hosted by it's own server not supported? Perhaps just not tested? I tried to document my entire issue above, but perhaps I missed something. My use case is that I would like to manage all my domains with DA, and not have to rely on an external DNS provider and domain.
Ideas?
Default zone record for server hostname
If I install DA on server.example.com , a default zone for server.example.com will be created. Can I delete this zone, and/or move it under my example.com domain since that is hosted on this DA server? Is it enough to recreate the A/MX/TXT records under the example.com zone?
forum.directadmin.com
There appears to be an issue with the Let's Encrypt script for the DA server hostname, when the same server is also hosting the domain as well. For example:
domain: example.com
server: host.example.com
The result is that DA creates the host.example.com DNS zone when installation is complete. After logging in to the DA server, enter the User mode, and create the domain for example.com. The result is that example.com exists along side host.example.com. However, host.example.com refers to ns1.example.com and ns2.example.com, which are the DA server itself. But the problem is that the base domain example.com doesn't have any records for host.example.com, and so that zone is dead except for local resolution. If I try to use the Let's Encrypt script mentioned here:
It will quit with either the message:
Setting up certificate for a hostname: host.example.com
Error: http://host.example.com/.well-known/acme-challenge/letsencrypt_1575657746 is not reachable. Aborting the script.
or:
Unable to determine domain name for authorization. Exiting...
Looking at the script here https://files.directadmin.com/services/all/letsencrypt.sh I can see that these are both error messages of the script itself, not a response from Let's Encrypt. If I now create the A and NS records in example.com for host.example.com such that the host.example.com zone now can be resolved, the problem still exists. I manually checked that files under .well-known are accessible from a browser and indeed they are, though they are of 0 size. Other files are also available under this folder.
I have waited a long time with a TTL of 60 seconds long after the default 14400 would have expired and the issue persists.
As proof I'm not crazy, I created host.example.net at a different DNS provider, and pointed it to my IP address, and the script completed just fine. Other domains on this host also resolve and get certificates fine as well.
Is the scenario where the server hostname is hosted by it's own server not supported? Perhaps just not tested? I tried to document my entire issue above, but perhaps I missed something. My use case is that I would like to manage all my domains with DA, and not have to rely on an external DNS provider and domain.
Ideas?
Last edited: