Custom DNS silently fails when creating a CNAME record on the same key as a TXT record

[chr-1x]

Context: I let Protonmail manage some of my email domains (and just use MIAB for DNS for those domains).

Protonmail recently changed the way they do DKIM setup for custom domains. Previously they had you create a TXT record with a particular key. Now they recommend you set up three CNAME records that point to their servers instead (presumably so they can do key rotation). Now, when I went to switch my protonmail-managed domains over the new system, I wanted to make sure my mail kept working the whole time, so I was going to create the new CNAME records and then delete the old TXT record. MIAB appeared to create the CNAME records successfully. However, when I went to check, protonmail didnt seem to see the new DNS key, nor could I see it with dig.

After some more digging and looking around the nsd logs, I noticed the following error message:

[2021-02-04 20:32:27.262] nsd[6818]: error: <my domain>.txt.signed:38: CNAME and other data at the same name

Turns out that one of the new CNAMEs they had you create had the same name as the previous TXT record. Deleting the TXT record resolved the issue and made the new CNAME records visible.

This seems like a MIAB UI issue more than anything. If NSD did not successfully load the config file, MIAB should indicate that in the UI (maybe in the system status page?). This may be kind of a niche need but it was a real pain in the tail to track down!

[ddavness]

For the reader's context - in DNS, you're not allowed to have a CNAME for a domain and any other record for that domain.

However, it seems that it's hard to search for an edge case like that one, because NSD apparently can serve files with errors (?), and from MIAB's perspective there would be nothing wrong with NSD.

Could be regarded more as both an UI issue and daemon issue, because they both don't catch the error - I think this situation (more than one record and one of them is a CNAME) could be verified by the daemon and if so, do not update the files and send back an error 400.

[cmasterdelphi]

How do you resolve this issue? Where should I delete what?
I might have a similar/same issue with CNAME records and TXT records due to DNS-01 challenge from letsencrypt.

#1973