TXT records set for DNS do not show up in queries

1

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

Screenshot%20from%202020-08-09%2011-01-03
Screenshot from 2020-08-09 11-01-03.png1990×236 38.9 KB

And then when I query my mailserver directly dig TXT itscode.red @207.246.65.173 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?

2

What are the contents of /home/user-data/dns/custom.yaml? @fiberglass

3 
itscode.red:
  TXT:
  - google-site-verification=Ds2b6vJwebdGVDwEOoP_ScfaCjGYFKPFMCr_ynEl6v8
  - gitlab-pages-verification-code=acbf2304a9adf1acac05b40c1547e97f
  CNAME: Qwertie.gitlab.io.

Looks good to me. Is this the file that powers the dns server or the webui?

Edit:
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[3409]: 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.

1 Like
4

You know, I totally missed that the CNAME was on the apex of the domain. Yes, that cannot happen. Sorry I missed it.