wrong TXT-DNS entries in seondary mail-domain
-
CLDRN runs on one server IP with 2 domains with email, on SSDnode.
the main domain eb8.org is all green - mostly. since blocklist and outbound SMTP checks are fluctuating.
the secondary domain shows all red since a few weeks.now, having time to dig deeper: in the secondary domain, eb8sys.top:
- the TXT records use the main domain.
- the TXT-records are set, but not found, as is the i.e. cloudron._domainkey
since OVH-DNS is manual, and I din't change anything for the secondary domain for months, suggesting that some changes within CLDR causing that. any hints?
secondary domain
main domain
mostly outbound checks are fails.
Blocklist is a bit stickier, but also toggles within minutes. for both domains.here the relevant DNS entry for the secondary domain, eb8sys.top
$TTL 3600 @ IN SOA dns200.anycast.me. tech.ovh.net. (2023090707 86400 3600 3600000 300) IN NS ns200.anycast.me. IN NS dns200.anycast.me. IN MX 10 my.eb8.org. IN A 63.250.54.195 600 IN TXT "v=spf1 a:my.eb8.org include:mx.ovh.com ~all" 600 IN TXT "1|www.eb8sys.top" _acme-challenge 60 IN TXT "HgwkFqiWgtnHszr8mMSZx9f4JIItKu5XXonwV7TStyo" _acme-challenge 60 IN TXT "HO8bLaHpF3K5jfxqzRaHznVfgRPWwcZum0F2-LJw20o" _autodiscover._tcp IN SRV 0 0 443 my _dmarc IN TXT ( "v=DMARC1; p=reject; pct=100;" ) _imaps._tcp IN SRV 0 0 993 my _submission._tcp IN SRV 0 0 465 my autoconfig IN CNAME my autodiscover IN CNAME my cloudron._domainkey IN TXT ( "v=DKIM1; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD9G9q2uBBEuKKttPjVOD0RE6pU0D32o8/WxViN3olNjgawPQ8qH2g/0bMEvMLjUe5A2isKRnXIrwN5t/qL3UWA5UPYFBU6hwKTUVxKp7gC2gno9P/ff/D9XNhhTnD8wl8RiRfPQSDV8bvPNCOohlkbaLaU6QtBMqLZeeGdv6ZiPwIDAQAB" )
-
For the sake of anyone looking for solutions to a similar problem in the future, just stick with Cloudron, please. CLDRN and CLDR both have unambiguous search results, meaning, anyone looking for "Cloudron + email + DNS + TXT-DNS" will never find this post, etc. It's easier anyway to just type Cloudron. Cloudron.
Also, some more info might help. Are these both new, fresh installations on Ubuntu 22 servers? Or have you upgraded them recently?
Also, are the only "fails" the checks in the Cloudron dashboard? Or are your emails not getting delivered or received?
Checking https://mxtoolbox.com/emailhealth/eb8sys.top/ shows mostly good results, including 100% pass for the mailserver settings. Your domain cert is expired, and the SOA settings have a problem... but everything looks good.
FWIW, every now and then my own Cloudron dashboard will be red, even though everything is working.
-
@scooke ha ha, I feel stupid. It took me a while to grasp what CLDR is!
-
@chymian It looks like DNS resolution is not quite working on the server. Either that or the authoritatize NS of eb8sys.top is not functioning properly.
I can confirm that the DNS entries are actually correct.
host -t TXT eb8sys.top
,host -t MX eb8sys.top
andhost -t TXT cloudron._domainkey.eb8sys.top
are as expected.Can you restart unbound ? Services -> unbound and try again ? You can also try running the above host commands on the server and please paste the output here. Further, also try on the server
host -t TXT eb8sys.top 8.8.8.8
,host -t MX eb8sys.top 8.8.8.8
andhost -t TXT cloudron._domainkey.eb8sys.top 8.8.8.8
and post the value here. -
@scooke thanks for reply. to answer your questions:
Also, some more info might help. Are these both new, fresh installations on Ubuntu 22 servers? Or have you upgraded them recently?
since OVH-DNS is manual, and I din't change anything for the secondary domain for months, suggesting that some changes within CLDR causing that. any hints?
what both installations? one server, one 1 ip, and 2 domains (actually, their is another one, which is more ore less just parked). same setup since years.
as I stated, nothing was changed in the last months/from the time it still worked. the installation is a couple of years old, upgraded to 22.04.mail is working.
and that the cert is expired is a problem which probably has it's cause in the described situation.
the renew of certificates show an error:
Sep 08 19:50:42box:cert/acme2 waitForChallenge: status is "invalid" "{"type":"http-01","status":"invalid","error":{"type":"urn:ietf:params:acme:error:dns","detail":"DNS problem: looking up A for git.eb8sys.top: DNSSEC: DNSKEY Missing; DNS problem: looking up AAAA for git.eb8sys.top: DNSSEC: DNSKEY Missing","status":400},"url":"https://acme-v02.api.letsencrypt.org/acme/chall-v3/262522782736/VWqWnQ","token":"y1q3lTpNjGlrb31X3_iO_-hbwceZmDpj7E0vUQUNH0Q","validated":"2023-09-08T12:45:46Z"}"
which seems to be a pbl. with the chain of trust. how to fix that?@girish I did restart unbound already when I went trough the troubleshooting guide, before I opened this post.
I restarted it again and no curiosities/errors in the log.host -t TXT eb8sys.top 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: Host eb8sys.top not found: 2(SERVFAIL)
host -t MX eb8sys.top 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: Host eb8sys.top not found: 2(SERVFAIL)
host -t TXT cloudron._domainkey.eb8sys.top 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: Host cloudron._domainkey.eb8sys.top not found: 2(SERVFAIL)
FWIW, every now and then my own Cloudron dashboard will be red, even though everything is working.
this and the fluctuating outbound & blocklist checks are really annoying in the sense of usefullness of a check, when it creates so much false positivs. I'd rather be not informed then falsy. but that's another minor thing.
-
@chymian said in wrong TXT-DNS entries in seondary mail-domain:
Host eb8sys.top not found: 2(SERVFAIL)
This is the root of the problem. When the DNS is queried via Google DNS (8.8.8.8) or Cloudflare DNS (1.1.1.1), the DNS resolution fails. It fails here from my laptop as well. Something wrong with the .top TLD . Can you ask your registrar what is going on? It seems the nameservers are set to some anycast.me . What is this? Is it reliable?
-
@girish said in wrong TXT-DNS entries in seondary mail-domain:
anycast.me . What is this? Is it reliable?
clicking the link redirect to OVH Cloud, so I guess it's something to do with them
-
@girish
opps, my last post was never published…anycast.me is their geoloaction-aware DNS system.
I opened a ticket with them and after manual pushing DNS updates after disabling DNSSEC (temporarily), it worked and propagated the right entries.
there are still some false positves on spamhouse, but it's working.
Thanks for your support.
-
-