Thinking about binding two Vmin servers to work with each other as master and slave DNS. Got couple of questions about the zone Server Templates set up and generally the DNS zones itself.
So let’s say I have two Vmin servers with the following IP addresses:
1.1.1.1
2.2.2.2
I also have two domains that will be parked on each of these:
I want them to be separately configured. The only thing to be in common is the DNS Master-Slave bondage.
The main domains will have the config I mentioned. And these will not be synced. These will be like main domains for each server. And every domain that will be hosted/parked on each will use the settings of these domains.
Domain fubar.com and foo.com will be added to each server as main domain that will also server as server’s hostname. Once that is done - THEN I will park domains that will host some websites and services
Let me rephrase and explain you once more cause I think I haven’t explained it fully.
My use case is to:
Have two independent servers. Each of them is capable to run different websites, different services etc.
I need two DNS servers. All hosted, managed by me.
I already did use some of the Slave servers such as FreeDNS.42.pl and other Vmin server where I had Bind module set up as a slave server without Vmin Auto-Slave Config feature.
Now I want to set it up and basically use the Webmin Servers Index feature but I don’t want to cluster them together per se, except that DNS functionality.
And now I know that I cannot cause being busy I’ve tried to point like that in OVH but OVH doesn’t know where foo.com’s DNS servers are ponting to and it’s impossible to point at IP address only.
I’m searching for a good solution where:
I have two Vmin servers
I have two domains that would act like primary domain for each server
Every Vmin would be a master/slave to each other thanks to cluster function
I wanted to avoid records management on OVH panel and have that everything in my Virtualmin(s) servers. But without being able to use IPs as DNS servers it seems I cannot. Cause stupid OVH expects domain names in DNS entries which are not existing cause… They are IPs to the world.
The bind here is not a problem actually. The problem is how to “make” domain see server’s IP instead of hostname.
You ever used OVH or any other registrars? They expect domain names as DNS. I only have server’s IP address on which I have Bind9 to manage the domain I want to park in
In cases where your registrar doesn’t automatically handle the chicken/egg problem of springing a new zone into existence, you have to create the A records for your name servers in the registrars DNS services first, and then switch name servers once they resolve.
It’s not about something being obvious. It’s about helping each other and leave the trace of solution for people that would deal with similar issue. From the beginning you’ve been focused on educating me about Cluster/Slave DNS Servers instead of looking into a matter of spinning up two servers that would handle DNS management from scratch and ion Virtualmin exllusively.
In cases where your registrar doesn’t automatically handle the chicken/egg problem of springing a new zone into existence, you have to create the A records for your name servers in the registrars DNS services first, and then switch name servers once they resolve.
Virtualmin server1 and server2 are set up as master/slave DNS to each other. Creating DNS zones on each works like a charm.
Server1 IP: 1.1.1.1
Server2 IP: 2.2.2.2
I’ve added/pointed my foo.com to dns.hetzner.com which is free DNS service. On Hetzner’s DNS I have following records:
SOA @ hydrogen.ns.hetzner.com. dns.hetzner.com. 2023122500 86400 10800 3600000 3600
NS @ helium.ns.hetzner.de.
NS @ oxygen.ns.hetzner.com.
NS @ helium.ns.hetzner.de.
A @ 1.1.1.1
A www.foo.com 1.1.1.1
A mail.foo.com 1.1.1.1
A dns1.foo.com 1.1.1.1
A dns2.foo.com 2.2.2.2
On Server1 I’ve added Virtual Server foo.com.
The zone file there looks like this:
$ttl 3600
@ IN SOA dns1.foo.com. root.dns1.foo.com. (
2023122502
3600
600
1209600
3600 )
@ IN NS dns1.foo.com.
@ IN NS dns2.foo.com.
foo.com. IN A 1.1.1.1
www.foo.com. IN A 1.1.1.1
ftp.foo.com. IN A 1.1.1.1
dns1.foo.com. IN A 1.1.1.1
dns2.foo.com. IN A 2.2.2.2
foo.com. IN TXT "v=spf1 a mx a:foo.com ip4:1.1.1.1 ip4:1.1.1.1 ?all"
@ IN CAA 0 issuewild letsencrypt.org
Do you think that is enough? What’s is the procedure to be able to add additional domain mydomain.com to Server1 so I could use following DNS servers:
Do your name server A records work and do they point to the correct IPs for your Webmin/Virtualmin servers? The records at hetzner, I mean. We need to go one step at a time, to narrow down the actual point of the trouble. If you can’t resolve those names, they can’t become DNS servers.
#### The domain must have at least one working name server
BASIC02
* CRITICAL
There is no working name server for "mydomain.com" so it is unreachable.
* ERROR
Name server "dns1.foo.com" cannot be resolved into an IP address.
* ERROR
Name server "dns2.foo.com" cannot be resolved into an IP address.
I could tell you more with actual names and IP addresses.
You need to verify that your DNS server is resolving correctly, as well. Though I think this is just indicating the glue records are wrong (which is a registrar problem, not something you can solve in Virtualmin). It may just be propagation delay. While most stuff is much faster these days (only needing minutes or roughly the record TTL time to propagate), it can take several hours for glue records to propagate as the global servers have to update and that’s never instant.
But, you can/should confirm your DNS servers are doing something useful:
host dns1.foo.com 1.1.1.1
Will prove your server can resolve that name.
host -t NS foo.com 1.1.1.1
Will confirm you have an NS record for the zone.
If those are true, then the registrar glue records is the only problem to solve and where you should focus your attention. You may need to reach out to their support folks if it continues to not work. I have no experience with OVH for domain name registration.
$ host dns1.foo.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
Host dns1.foo.com not found: 5(REFUSED)
$ host -t NS foo.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:
Host foo.com not found: 5(REFUSED)
These were done both locally from my PC and from the 1.1.1.1 server itself
I’ve browsed a couple of registrars yesterday and there’s literally none on the market providing Name Servers by IP. All require FQDN.
So I’m guessing it’s kind if impossible to delegate full domain management to Virtualmin.
What I am thinking right now is:
Have the domain DNS manaqed by the Domain Registrar with following minimum records
foo.com in NS firstdns.ofdomainregistrar.com
foo.com in NS seconddns.ofdomainregistrar.com
foo.com in A 1.1.1.1
*.foo.com in A 1.1.1.1
mail.foo.com in MX 1.1.1.1
On Virtualmin simply add your domain which is going to create following records:
foo.com in NS dns1.foo.com
foo.com in NS dns2.foo.com
admin.foo.com in A 1.1.1.1
webmail.foo.com in A 1.1.1.1
www.foo.com in A 1.1.1.1
custom-record.foo.com in A 1.1.1.1
*.foo.com in A 1.1.1.1
dns1.foo.com in A 1.1.1.1
dns2.foo.com in A 2.2.2.2 # my second VPS with Vmin
mail.foo.com in MX 1.1.1.1
Thanks to this my Registrar’s DNS zone will redirect MX and * records to my server where my server would handle this on my own.
Name server "dns1.foo.com/1.1.1.1" responds with an unexpected RCODE name ("REFUSED") on an SOA query.
So… Partially it works but only using Nameservers that are provided by registrar (or any free DNS service such as dns.Hetzner.com or FreeDNS.42.pl)
What do you think about this, Joe?
I miss the old days where you could simply point the domain at two IPs of which both were my servers’ and the whole DNS management was happening on Virtualmin not using domain user panel at registrar’s place. Now you have to deal with this FQDN sh*t. Now you need to handle SPF/TXT records on both your Virtualmin and on domain management panel cause when you’re going to send any email to let’s say GMail it will reject your mail because of lack of SPF records (minimum zone setup mentioned in point 1 above.)
To be clear you have replaced 1.1.1.1 with your actual DNS server IP, right? (this is why I’d rather we were talking about real IPs, here).
If so, then this is a problem you need to solve, even if your glue records are right, your DNS server isn’t (it isn’t a DNS server for your zone, I mean).
There are some, but it doesn’t matter. It’s not difficult to make it work without it.