I’m just documenting a bunch of problems with a setup, which has things I need to fix and hopefully for people to build/learn better ways to not have problems if they encounter them.
This is on a 2nd box I’m testing MIAB for a different use. Note i am testing, so customer-domain.com is not causing stress
System status did not respond after new domains were added:
SERVFAIL unexpected RCODE resolving 'customer-domain.com/NS/IN': xxx.xxx.xxx.xxx#53
SERVFAIL unexpected RCODE resolving 'customer-domain.com/A/IN': xxx.xxx.xxx.xxx#53
Jan 29 05:50:02 box named[901]: validating miab-domain.com/NS: got insecure response; parent indicates it should be secure
Jan 29 05:50:02 box named[901]: insecurity proof failed resolving 'miab-domain.com/NS/IN': yy.yy.yy.yy#53
So I removed customer-domain.com from the miab setup and system status responds.
It then reports:
Nameserver glue records are incorrect. The ns1.box.miab-domain.com and ns2.box.miab-domain.com nameservers must be configured at your domain name registrar as having the IP address xxx.xxx.xxx.xxx.
They currently report addresses of [Not Set]/[Not Set]. It may take several hours for public DNS to update after a change.
The weird thing is glue records were set a couple of days ago, before I started using secondary DNS - which I think I may have gone against the workflow of the registrar, by totally resetting nameservers (and therefore glue records in their way of setting things up in the backend).
How does this part relate to the other part? You are NOW using secondary DNS but we not when you set the glue records? If that is the case, what IP('s) have you set as the glue records with the registrar?
If you are just doing testing, you could grab a domain name (or two) from freenom … by doing so you could list the domain names publicly so others can do DNS checks to help troubleshoot. That said, if you wish send me a PM with your hostname so I can look at the DNS if you’d like.
Turn it off at the registrar before you install MiaB. You can re-enable it afterward if you wish. What is happening is that DNSSEC is failing because the registrar says that the info should be x but the new DNS system saying that the info should be y.
My apologies … I was quite sleep deprived when I wrote that initially, so it would have been barely comprehensible for a native English speaker - if English is your second language it would have made zero sense.
Translation: You need to turn off DNSSEC at the registrar before installing MiaB as the registrar says that a specific key must be present, and it is not as MiaB is a different server with a different key, so name resolution fails.
Set the secondary DNS in miab to X.ns.buddyns.com Y.ns.buddyns.com Z.ns.buddyns.com xfr:88.198.106.11 xfr:185.136.176.247 xfr:103.6.87.125 xfr:108.61.224.67 xfr:173.244.206.26
Sync at buddyns, one error. Registrar lists 5 nameservers but authoritative nameserver lists only 4. One of the miab FQDN is missing.
At this stage, things were resolving so I didn’t look into fixing it to continue progress.
Then I don’t really remember what I did, but syncing between buddyns and box.domain.org didn’t work. The serial didn’t update as I set an A record for domain.org and I guess I was doing a bit of pseudo rage-config.
I suspect that something has gone awry with the registrar config although the glue records and whois are set for only ns1.box.domain.org and ns2.box.domain.org but neither of those nor box.domain.org resolve with nslookup from my localhost.
I have steered away from dns and mail management in place for plesk, dnsimple, route53, mailgun, gsuite over the years but would like to take control of this aspect of it and perhaps integrate with other decentralized tech over the next 12 months (despite pseudo rage-config)
Ok, in my experiments I have discovered that when a secondary name server is used, MiaB replaces ns2.box.domain.org. This explains the results that you are getting.
I recommend updating all domains to show the 4 NS’s and do not mention ns2.box.
When we get to vanity NS with BuddyNS there are some unknowns still for me. I will talk about them in another comment.
Which A records and which CNAME records and where are they pointing? Do you have a website on a different server or intend for them to resolve to the MiaB server? One thing often missed even by the most experienced is the trailing dot in the CNAME record which could cause the issue you experienced. Now that the domain is removed it is not possible to go back to check the syntax, so if you want to try again with customer-domain.com but instead use just A records … we can see if the issue repeats.
I have also noticed that when changing DNSSEC and Glue records that sometimes things really do not catch up for hours.
tl;dr; re-run setup with new domain on new registrar, working - I’ll continue doing the rest of the secondary testing.
I suspected my problem was glue records with the registrar, and used another domain on the same registrar. It has been about 8 hours, no update to glue records. Not Set responses in the system status. I’ll email support after another 40 hours with this domain to see what limitations are on their backend. It is an Australian registrar which I had trouble with 6+ years ago with updating whois records, so I can’t be confident with their backend integrations.
However!
I’ve used a .pro domain from namecheap. Setup custom nameservers (glue records) and changed the reverse DNS. No problems so far.
I understand the point of using the test domains you mentioned earlier in the thread - I’d like to find a combination of automated convenience with a real world registrar etc. so I can re-use reliably rather than try with different registrars with unknown stuff. Hope this part makes sense.
Re-running the setup.sh was great/easy for re-provisioning/re-purposing the hostname. Only had to create a new admin account, log out and disable the old one - remove mail aliases then the DNS of the old domain. I did have to create an alias for the new administrator@box.newdomain.tld to go to the new admin user though.
I’ll continue doing the rest of the secondary testing.
