DNS & DKIM Questions : Pre-Install Prep

I am getting my ducks in a row to set up a Hestia host for managing some personal domains. Here is what I wish to accomplish with Hestia with a few questions.

  1. Install on fresh Debian 10 VPS with static IP. I have the new VPS ready and waiting.

  2. [IMPORTANT, not optional] Set Hestia to manage ALL DNS for the install domain and all subsequent future domains, subdomains, mail domains added via the web panel. I do not want to use Cloudflare or any third party DNS. I want name resolution and mail records self-contained on this single host.

  3. Add the minimum number of A-AAAA-CNAME records possible with my domain registrar to point to my own DNS server as the resolver for everything on my host. I don’t want my registrar (namecheap) to manage any DNS records that bind9/named can automatically and canonically correctly handle on the VPS Hestia host.

  4. Set up DKIM on the Hestia host so that gmail and others won’t reject mails for lack of authentication. The tiniest mismatch or misconfig will prevent all outgoing email. Since I don’t know how Hestia will configure it (Hestia is new to me) troubleshooting it could be a knight’s errand.

For the registrar I think I only need to add an ‘@’ A record for the root domain and then the personal DNS servers in their personal DNS settings, but I’m not sure if I need to add anything for DKIM / MX authentication on the registrar account. If so, which records should I keep with the registrar?

How do I proceed without shooting myself in the foot? Ideal end result: Hestia web panel will set up proper DKIM and MX records to prevent google and other mail hosts from rejecting for MX authentication failure.

Another question: during Hestia setup, should I explicitly use the hostname in the FQDN that the setup script requests, i.e. ‘buster.domain.tld’ or can I use just the domain name ‘domain.tld’ and what would be the divergent consequences for the way Hestia configures the setup?

In HESTIA you have to:

  • create NS records
    ** ns1.domain.tld
    ** ns2.domain.tld
  • also create A records
    ** ns1.domain.tld A (IP of your server)
    ** ns2.domain.tld A (IP of your ns or a different dns server if configured)

Then, go to the domain registrar and set:
ns1.domain.tld and ns2.domain.tld as the DNS servers for every domain that you use.

After that, the world will recognize and use your DNS servers as the true ones.

You may check https://dnschecker.org/ to see if there is any problem.

In HESTIA you have to:

  • Create client
  • Assign them to a hosting plan
  • Assign domains to DNS, EMAIL, WEB, DATABASE, etc.

You may select a DNS template OR edit your own DNS template

After creating a DNS domain under an user you may customize the zones and choose DKIM and so on.
just bear in mind that you set a valid MX record.

To create a valid MX record you can:

  • In domain.tld DNS configuration create: hostname.domain.tld A (the IP of the VPS)
  • In customerdomain.tld create: @ MX hostname.domain.tld
  • In customerdomain.tld create: @ TXT “v=spf1 +a +mx +a:smtp.customerdomain.tld include:own-spf.domain.tld include:ext-spf.domain.tld -all” (or anything that suits your needs)

The include:own-spf.domain.tld include:ext-spf.domain.tld part consists of two lists. The first one with all my servers so I can send from any of my servers and the second one has google, mailchimp and so on. You can delete the includes if you want and leave: “v=spf1 +a +mx +a:smtp.customerdomain.tld -all” or even leave: “v=spf1 +a +mx”

The +mx part is the one that authorizes hostname.domain.tld to send emails on behalf of customerdomain.tld
The +a part authorizes the web server (if it were a different one) to send emails on behalf of customerdomain.tld

  • Use subdomain.domain.tld Don’t use domain.tld
  • subdomain.domain.tld will be under the admin account and hosts only WEB in order to provide you with a valid SSL certificate.
  • domain.tld will be under a normal user’s account and under that user’s DNS settings you will configure.

I hope this helps.

1 Like

jlguerrero has explained everything pretty well above, and it will give you almost bulletproof cheatsheet for DNS setup with Hestia CP. Just wanted to add that you will need to perform 1 extra step: you will need to associate IP of your server with installed Bind9 with custom nameserver in domain registrar panel, which will be IP of let’s say ns1.domain.tld. And also, usually it requires at least 2 ns* records, and more of that - in most cases it shouldn’t be same IP address used for both nameservers…

1 Like

Thank you @jlguerrero and @Vadym for your help. It did help me to avoid a lot of trial and error that I’m sure would have felt like a forever project.

I did a test install and used the Hestia panel to set up DNS zones after pointing my registrar’s A record and DNS servers to ns1.domain.url and ns2.domain.url. It started resolving within seconds. The DKIM records all set up correctly and test mails were able to get through.

In my recent test run I decided not to put hostname in the FQDN just to see how it would set up and resolve from the very root of the domain. I used domain.tld instead when asked by the installer. It works this way, but I suppose it might have some hidden problem waiting to manifest itself. I like having my networking set up right at the root of the domain so that all my remote and local scripts just show the domain name, which is easier to work with if I end up changing the hostname or adding hostnames.

Are there security implications I need to be aware of and mitigate if I continue using the .domain.tld name without hostname.domain.tld on the setup? Should I just scratch it and do it with hostname (a minor inconvenience for redoing some scripts) or can I chug ahead?

Once again thank you for releasing such a useful and time-saving product. I hope you will keep the banner flying.

I can understand that. There is no real problem.

You are just sacrificing the ability to move your web to a different host. In case of emergency or upon new system configuration you will have to work a bit harder.

I don’t think that there will be any additional security risks associated with the name.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.