Cannot request Lets Encrypt wildcard certificates on CentOS 8 with latest virtualmin

Like said in the title, I can not request a Let’s encrypt wildcard certificate on a CentOS 8 host with freshly installed virtualmin.
This is the error virtualmin gives when I try to request “bluhosting.net” and “*.bluhosting.net

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for bluhosting.net
Running manual-auth-hook command: /etc/webmin/webmin/letsencrypt-dns.pl
Waiting for verification...
Challenge failed for domain bluhosting.net
dns-01 challenge for bluhosting.net
Cleaning up challenges
Running manual-cleanup-hook command: /etc/webmin/webmin/letsencrypt-cleanup.pl
Some challenges have failed.
IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: bluhosting.net
   Type:   dns
   Detail: DNS problem: NXDOMAIN looking up TXT for
   _acme-challenge.bluhosting.net - check that a DNS record exists for
   this domain

This is the output of /var/log/letsencrypt/letsencrypt.log
As this seems to be a dns problem, could it be related to the fact that I use a 3 way dns cluster? I have a main server, with all the websites, ssl certificates, proxies, and handles dns at ns1.bluhosting.net, and I have 2 remote servers (both running the newest version of virtualmin on debian 10) that handle email and dns on ns2.bluhosting.net and ns3.bluhosting.net respectively. I have the secondary dns configured through Webmin > Servers > BIND DNS Server > Cluster Slave Servers.

Any help or insight is greatly appreciated, thanks in advance!
(edited to clarify I use virtualmin for dns)

Possible answer - ‘Virtualmin requires DNS to be hosted on the same system’

That’s the thing though, I am hosting dns on the same system, I just use webmin/virtualmin’s built in dns cluster feature.

I think this may be related to the replication delay among the clustered DNS servers. The LE request process updates the local DNS server, but that may not be the server interrogated for the check process.
If this is, indeed, the problem then there would need to be a delay between updating DNS and requesting the LE certificate.