PTR record reports being set wrong
-
claims the ip resolves to nextcloud.domain.nz instead of my.domain.nz
Checking it externally, says its set correctly only the server seems to mismatch it. Running 7.6.4
Had this problem in december intermittantly, now its consistent.
My concern is that it might affect mail delivery, although if the PTR works correctly externally it probably wont be an issue. -
You topic title confuses me
" PTR record reports being set wrong "
Cloudron does not and cannot set PTR aka rDNS (or reverse DNS) records. You have to set it.
Based on what you've written, presumably you actually mean something like "Cloudron reports the PTR record as being incorrect, but it isn't", is that right?
-
G girish marked this topic as a question on
-
the PTR record is correct.
Externally it resolves correctly.
Only the cloudron server says it doesn't. -
the PTR record is correct.
Externally it resolves correctly.
Only the cloudron server says it doesn't.@AartJansen then it may not have propagated if the change is recent. Just refresh the test again tomorrow.
-
You can restart unbound in Services and check if it helps solve the problem? After restart, try
host -t PTR <ip address> 127.0.0.1.@girish said in PTR record reports being set wrong:
host -t PTR <public ip> 127.0.0.1
The result comes back as domain name pointer nextcloud.domain, not my.domain (I had restarted the unbound service first)
I wonder, I recently removed roundcube (my first app) and use sogo instead. (using sogo.domain)
I didn't use a custom prefix for roundcube, so it had my.domain the second app I installed was nextcloud, and I added that custom domain name of nextcloud.domainCould that action have upset its own DNS records?
-
@girish said in PTR record reports being set wrong:
host -t PTR <public ip> 127.0.0.1
The result comes back as domain name pointer nextcloud.domain, not my.domain (I had restarted the unbound service first)
I wonder, I recently removed roundcube (my first app) and use sogo instead. (using sogo.domain)
I didn't use a custom prefix for roundcube, so it had my.domain the second app I installed was nextcloud, and I added that custom domain name of nextcloud.domainCould that action have upset its own DNS records?
@AartJansen PTR records are not set in the DNS. They are set in your VPS Provider. Please see https://docs.cloudron.io/email/#ptr-record . It's not related to adding/removing apps. Cloudron has no automation (and indeed it's impossible) for setting and changing PTR records.
-
Except if I test the PTR record it reports correctly, only the cloudron server itself is misreporting the result.
https://mxtoolbox.com/SuperTool.aspx using PTR tool says the DNS name is my.domain. -
Except if I test the PTR record it reports correctly, only the cloudron server itself is misreporting the result.
https://mxtoolbox.com/SuperTool.aspx using PTR tool says the DNS name is my.domain. -
-
thats also coming back as the wrong result.
@AartJansen you can check in https://dnschecker.org/ if the PTR record has propagated properly . Otherwise, if you can send me IP address to support@cloudron.io, I can check what we see here. Most likely you have to ask your VPS provider why the name is reverse resolving properly.
-
its self hosted, and my ISP set it a long time ago. when I use that site to view my PTR for the IP, all come up as green (and the correct domain) except sitehost in auckland NZ (which is oddly the closest geographically to me). its a red cross.
-
its self hosted, and my ISP set it a long time ago. when I use that site to view my PTR for the IP, all come up as green (and the correct domain) except sitehost in auckland NZ (which is oddly the closest geographically to me). its a red cross.
@AartJansen I can confirm that the PTR looks correct from here. Not sure why your unbound is not resolving it properly. Have you added any additional configs in unbound? If not, can you write to us at support@cloudron.io and we can debug as to why it's not correct.
-
No I don't have anything customized in unbound, have sent an email.
-
G girish has marked this topic as solved on
-
It's kind of odd, that rules been there for many months, I don't remember the exact issue I had that caused me to add it. Which could either be the problem was fixed by it, and will return (I guess that will remind me what it fixed), or it fixed nothing, and I forgot to undo it.
Still pretty strange that it started DNS problems so much later. -
Umm, its happening again.
-
it just went away, i think the router had a DNS cache thats flushed now. It's no longer being set as the DNS server via DHCP, so I think its resolved.
