Let's Encrypt Error: DNS record for xxxxx.com doesn't exist

Hello everyone.

I just installed a fresh version of Hestia v1.1.2 in Debian 10 and Ubuntu 18.04 and I’m facing a “Error: DNS record for www.XXXX.com doesn’t exist” problem every time I try to use Let’s Encrypt for generating the SSL certificate.

My DNS are like in the attached picture.

I tried with child-ns and default for the BIND9 template, but still the same. I also tried rebuilding the DNS.

Any suggestion?

Hi

First of all, 1.1.2 isnt released yet, you probaly installed from master and not release branch.

About DNS: Are you sure, that your server is providing dns for your domain? It looks more that this runs on another provider.

Thanks for your answer.

That’s odd, I just copied/pasted the instructions from the website.

I’m using vanity nameservers, but yes, I’m controlling the DNS myself (with Hestia). Until this morning I was using a CND. Is it possible that the DNS are not fully propagated?

Which instructions you used? The verification step is a simple nslookup, you can check it on your server, just check what you get for an answer.

I used the instructions available at https://www.hestiacp.com

Checking the history in my server:

wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh
bash hst-install.sh

The DNS lookup answers this:

Server:		XXX.XXX.XXX
Address:	XXX.XXX.XXX#XX

Non-authoritative answer:
Name:	domain.com
Address: XXX.XXX.XXX.XX
;; connection timed out; no servers could be reached

Mmm… Server and Address show a different IP to my machine. So I guess the DNS are not updated yet… Right?

Hmm, install string looks good, are you sure you got 1.1.2?

Looks like you got a dns issue, which need further checks where we can’t help out :slight_smile:.

According to the panel, I have 1.1.2…

I will wait until tomorrow then to see if the DNS propagate correctly…

Thanks @ScIT !

Thanks, going to check why you got 1.1.2 as version number.

Hi @realjumy

Thanks for pointing us indirectly to a version number issue: We had pointed the download script to the wrong branch, so we burned a version number but have fixed the issue: https://github.com/hestiacp/hestiacp/commit/c4734310165c35cc5de81a1978b48869dd27e506

2 Likes

Great. I’m glad at least my issue revealed something to fix ^^

1 Like

I can confirm that the issue is sorted now. Probably it was caused by a DNS that was not updated. Once again thanks for your help!

1 Like

I’m testing the beta Ubuntu 20.04 release now.

I just ran into this same issue.
Version # installed - v1.1.2 (same one that had this issue)

I’m using the same DNS records that worked fine for a year or so on VestaCP. I took that server down and put Hestia up on the same IP the old VestaCP was on, with the same DNS records that worked fine, so it should not be a propagation issue at all. Using things like mxtoolbox shows me “Loop detected” and “Unable to resolve “domain.xxx” to an IP address.”

If I take down the HestiaCP server and put my old VetaCP back up on the same IP address, it works perfectly again. Same DNS records on both. Same IP.

Instead of me trying to diagnose a DNS issue that might not actually exist, what are the chances that the v1.1.2 used for the Ubuntu 20.04 is still suffering from the same issue mentioned in this thread?

First of all: Ubuntu 20.04 is for testing only, do not use them for productive systems, they are not planed to get feature updates.

Your issue sounds like a dns one, I don’t think that we can do much from our side, without more details. How exactly do you run your dns? Do you use cloudflare or a own master master cluster?

WOW! Blazing fast response!

I know 20.04 is not production-ready. I generally assume anything “beta” isn’t production ready. My “production” environment is a home server lab that serves a testbed/playground, so no problems testing out 20.04 on my end. Searching for a way to upgrade VestaCP to Ubuntu 20.04 is THE reason I found Hestia in the first place.

I do have quite a bit of feedback on the 20.04 beta release which I’ll make a separate topic about, but this DNS issue is the one biggie so far, and it seems to match the details mentioned in this thread.

If it is a DNS issue, then I have zero expectation for you to resolve it for me. I’ll dig into it myself.

Just for the record, here’s my DNS setup that has been working just fine on Vesta:

Registar - GoDaddy - vanity ns1 and ns2 nameservers setup pointing to my public IP.

My local pertinent records:
@ NS 14400 ns1.domain.com.
@ NS 14400 ns2.domain.com.
ns1 A x.x.x.x
ns2 A x.x.x.x
@ A 14400 x.x.x.x
www A 14400 x.x.x.x

the rest of the records are things like A records for mail/ftp/etc, MX record for mail, and TXT records for dmarc/dkim and should have no effect on the primary domain resolution.

It all appears to be in good order, but I will keep digging on my end to see if I can find any issue. If these records weren’t working perfectly on another server already, I would seriously question them. But since they are working on another server, I’m leaning towards it being a different issue.

Thanks for the blazing fast response!

JFTR: Pointing your name servers to only one ip multiple time isnt really rfc-conform :slight_smile:. Probaly it would be a good idea, to use cloudflare as nameserver or build up a propper dns cluster over multiple servers :slight_smile:.

You can also check manualy, if the dns server responds properly to requests with nslookup: nslookup domain.tld YourIP

PS: Please remove any domain name and ips, it’s saver to hide them.

That’s not going to happen for me. There’s reasons I do my own stuff instead of using companies/organizations like cloudflare. The determining factor is the soul. I’ll work with people who have souls, but I will not use/work with an “entity” that does not have a soul, wherever possible.

My setup is about as simple and direct as can be. Point nameservers to my IP, which is the one and only public facing server. That server handles the DNS requests and serves the content. If it’s down, it’s completely down, DNS and all. If it’s up, then it’s completely up. I’ve worked this way for many years without issue. Besides, I can power up a different server with the same records on the same IP, and it works again instantly, so good/bad rfc compliance isn’t the issue I’m facing.

I’m looking into bind now to see if there something funny going on there.

Also, I’ve noticed that with VestaCP, the DNS records and primary domain are all setup under the admin account by default, while on Hestia, I have a user account with the domain and DNS records. Is there a conflict of setting up Hestia with my primary domain, and then creating the user account with the same domain? Admin account has zero domains and zero records, but was setup using the primary domain. I have a separate user account with that primary domain and all the DNS records for that domain. Could that be a problem? Do I HAVE TO set it all up under the admin account since Hestia was setup using the primary domain? I’m tempted to try setting up Hestia again, but using a specific subdomain just for the install/admin account. Something’s conflicting somewhere, and this is the most obvious possible culprit. I’ll wait for your feedback on this before I do another fresh install.

Everything I posted in the last post is freely and publicly available already, but I removed my info as you suggested.

Thank you for you patience and responses!

1 Like

We suggest to use a own user, at least for hosting webdomains - the admin user has sudo permission.

So basicly do the install for web01.domain.tld as hostname, then create a new user, in this user create a new web domain with dns support and add all you want to have. Then your server should reply instantly if you try manualy with nslookup above.

About dns cluster you’ll find a lot of useful informations in this thread here: Hestia and DNS management?

1 Like

I’ll reinstall in a little bit and check back in.

Looks like I have some good reading while the install happens :slight_smile:

SUCCESS!

I’ve been looking at Hestia’s backend for a few days. It’s nice to finally see the frontend. Who knew that seeing a yellow hardhat icon could feel like a great accomplishment.

FWIW, the only snag I’ve run into this time around was after Hestia installation, There were originally zero domains and zero records for the admin account, I created my user account and tried to add the primary domain and kept getting “Error: Web domain domain.com exist”. I checked the admin account, and sure enough, the primary domain was magically added there without me doing it. Removed it, Created it on the user account, and BOOM! In business again! Let’s Encrypt and all!

Thank you very much @ ScIT. I’m going to consider future DNS changes based on the other thread you included, but it seems like overkill for now since I don’t setup sites for anyone but myself, and there’s very rarely new domain additions/changes/deletions. I may be forced to do it as they continue to phase out dinosaurs like myself doing things the “old way”.

2 Likes