"Nameserver glue records are incorrect. "

[netsec]

"Nameserver glue records are incorrect. The ns1.xxxxxxxxxx and ns2.xxxxxxxxxxxxnameservers must be configured at your domain name registrar as having the IP address xxxxxxxxxx72. They currently report addresses of [Not Set]/[Not Set]. It may take several hours for public DNS to update after a change."

My Nameserver glue records are in fact correctly set, for over a week now. Yet this issue persists

[Player3324]

This probably means that your system can't reach external dns servers and/or itself via its public ip.

[alento-group]

@netsec So you are using MiaB for DNS of your domain rather than external DNS through your registrar or host (or other DNS provider), correct?

Assuming that your glue records are in fact correctly set and you are not using External DNS, then this error message is absolutely safe to ignore. I have been doing so for years.

However, MAYBE it is time that someone actually looks into why this is such a frequently occurring thing? @JoshData any interest in chasing this down, or is it too low priority?

[netsec]

@alento-group I am using MiaB for DNS - Not DNS through my registrar (correct)
Glue records are set correctly. Thanks for the advice.
However, when the glue records are showing incorrectly set, the Auto Provision button does not populate. Not a huge issue since I can generate the certificates at the command line, however, it was a nice feature that I enjoyed.
I checked and NSD is active and running.

Id like to debug this issue and see what the cause is.

[arthosul]

Hi, I have experienced this issue twice now since I started using MiaB. The solution for me both times was to remove and then add back the DNSSEC entry at Gandi. Here's what happened.

1. I setup MiaB a couple of months ago. Server is a droplet in Digital Ocean and registered the domain name at Gandi.
2. System ran well until today. This morning my email software couldn't find the mail server. I couldn't navigate to the webpages of the server either. Server not found error.
3. I could only access the mail and admin pages on the server by using the IP address. The DNS would not resolve.
4. I checked the DNS records with some webtools and found no issues.
5. I saw the same messages, in the MiaB status page, as indicated earlier in this post. "Nameserver glue records are incorrect. The ns1.xxxxxxxxxx and ns2.xxxxxxxxxxxxnameservers must be configured at your domain name registrar as having the IP address xxxxxxxxxx72. They currently report addresses of [Not Set]/[Not Set]. It may take several hours for public DNS to update after a change."
6. Mail was still being delivered successfully to the mail server. I could see mail coming into my inbox via Roundcube Webmail using the IP server IP in my browser to log in.
7. I read several posts on the discussion forum that pointed me to removing the DNSSEC entry at Gandi.
8. As soon as I did that the system worked again. The result was immediate.
9. I recreated a new DNSSEC entry at Gandi using the same DNSSEC record data and the systems continues to run normally.
10. As I am typing this message the system stopped working again. Removed DNSSEC and it was back up and running.

Is there something I need to do or is this a bug? I don't know but when I read this issue I thought I'd add my information.

Hope this is helpful. MiaB is a great solution and I want to use this as my permeant mail solution. Thanks for MiaB!

[m-e-st]

Lately I have the same problem. After running flawlessly for more than a week, I've getting the message "Nameserver glue records are incorrect. The ns1.box.xxxx.xx and ns2.box.xxxx.xx nameservers must be configured at your domain name registrar as having the IP address 999.999.999.999. They currently report addresses of [timeout]/[timeout]. It may take several hours for public DNS to update after a change.".

Rest is the same. Mail works flawlessly. All served domains are recognized everywhere (e.g. by nslookup) except on the MiaB server itself. Updated form 0.54 to 0.55, but no success. Glue records also checked, they are correct.Unfortunately I did not set a DNSSEC entry at my domain providers (my MiaB Instances servers domains from two providers), so I cannot solve the problem like @arthosul did.

Has anybody an idea, how to solve this?. Unfortunately, I am running out of time, this the first (let's encrypt) certificates will become invalid in five days and MiaB rejects to renew them due to the domain problem. (Certificate has a problem: The certificate is expiring soon: The certificate expires in 5 days on 2021-10-31. The domain name does not resolve to this machine: [Not Set] (A).

[alento-group]

@m-e-st Would you be kind enough to share your box's hostname via PM (either on Slack or the discourse forum as I do not believe it is possible on GitHub) so I can take a look ....
As for the certificates, it should be possible to renew them from the command line based on other comments in this thread.
Thanks!

[m-e-st]

@alento-group Seems to be to complicated for me to send PM. The hostname is not secret, it is box.stumpp.tk. I'd really appreciate, if you take the time to take a look. Some further information on that issue. Even the box server itself wasn't able to resolve box.stumpp.tk on the command line. Each sudo call run into a timeout. Solved this by expanding /etc/hosts. In the meantime I've checked the domains with various tools (intodns.com, dnsspy.io) - looks fine everywhere.

Since up to now, I used MiaB as a real black box, i'd appreciate any hint, which command would renew the certificates without breaking something.

Thank you in advance.

[alento-group]

@m-e-st

Can you confirm that bind is running on your VPS?

sudo service bind9 status

[m-e-st]

Yes ist does. But the status shows some interesting log entries (which were not there about six hours ago)

bind9.service - BIND Domain Name Server
   Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-10-25 12:54:18 CEST; 6h ago
     Docs: man:named(8)
 Main PID: 788 (named)
    Tasks: 5 (limit: 2306)
   CGroup: /system.slice/bind9.service
           └─788 /usr/sbin/named -f -u bind -4

Oct 25 17:08:38 box.stumpp.tk named[788]: validating pp-epsilon1._domainkey.mail.paypal.de/TXT: no valid signature found
Oct 25 17:33:34 box.stumpp.tk named[788]: connection refused resolving '70.28.201.74.in-addr.arpa/PTR/IN': 94.228.210.122#53
Oct 25 17:33:34 box.stumpp.tk named[788]: connection refused resolving 'ns1.serverion.nl/A/IN': 94.228.210.122#53
Oct 25 18:37:40 box.stumpp.tk named[788]: connection refused resolving '70.28.201.74.in-addr.arpa/PTR/IN': 94.228.210.122#53
Oct 25 18:56:05 box.stumpp.tk named[788]: REFUSED unexpected RCODE resolving '218.184.106.182.in-addr.arpa/PTR/IN': 117.45.170.33#53
Oct 25 18:56:05 box.stumpp.tk named[788]: REFUSED unexpected RCODE resolving '218.184.106.182.in-addr.arpa/PTR/IN': 182.98.160.80#53
Oct 25 19:04:41 box.stumpp.tk named[788]: received control channel command 'flush'
Oct 25 19:04:41 box.stumpp.tk named[788]: flushing caches in all views succeeded
Oct 25 19:04:41 box.stumpp.tk named[788]: resolver priming query complete
Oct 25 19:09:37 box.stumpp.tk named[788]: connection refused resolving 'ns2.serverion.eu/A/IN': 94.228.210.122#53