I’m trying to add a txt record to my domain, I did this before a while ago with the google site verification and it did and still does work but anything new I set does not show up.
Here is the records set on the mailinabox admin
And then when I query my mailserver directly
dig TXT itscode.red @188.8.131.52 I see only the google site verification (I have waited days to check its not a cache but I’m also querying the server directly so there should be none)
;; ANSWER SECTION:
itscode.red. 1800 IN TXT "v=spf1 mx -all"
itscode.red. 1800 IN TXT "google-site-verification=Ds2b6vJwebdGVDwEOoP_ScfaCjGYFKPFMCr_ynEl6v8"
;; AUTHORITY SECTION:
itscode.red. 1800 IN NS ns1.mail.itscode.red.
itscode.red. 1800 IN NS ns2.mail.itscode.red.
My suspicion is the webui has its own internal state which then updates a config file and somehow the config file is not being updated. Is there any way I can check this or any other things I should look in to?
What are the contents of
Looks good to me. Is this the file that powers the dns server or the webui?
So it looks like /etc/nsd/zones/itscode.red.txt is also up to date. I deleted the google site verification key via the web ui and it was removed from the nsd file but it still shows up in the dig query which should be getting the latest data. I assume the issue is whatever uses this nsd file is not reloading properly. I tried
nsd-control reload as suggested on the arch wiki and it prints ok but nothing happens.
Edit 2: Looks like this was the issue
tail -f /var/log/nsd.log
[2020-08-09 15:02:51.218] nsd: error: itscode.red.txt.signed:11: CNAME and other data at the same name
After deleting the cname it updated the txt records correctly. It looks like its impossible to have the root domain be a cname because there are TXT records generated by MIAB there and CNAMEs can not be alongside any other type of record. This suggests its actually impossible to use a cname on a non subdomain since MIAB puts its on records on the root.
This would probably be fine if the MIAB webui prevented you from getting in to this situation and put a warning up explaining the issue.
You know, I totally missed that the CNAME was on the apex of the domain. Yes, that cannot happen. Sorry I missed it.