• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question PTR lookups fail

BjornO

New Pleskian
Hello all,

I am having an issue with PTR lookups for any IP addresses (it doesn't have to be ours) fail. This is causing inbound mail to be rejected.

E.g.: Doing "dig -x IP" for IP-addresses that are known to have a PTR record will return no results.

Being new to Plesk I am not quite sure where to look to correct this issue. Advise would be appreciated.
 
The problem may be in bad nameservers specified in /etc/resolv.conf of your Plesk server. Have you tried to change it?
 
Hi Igor,

Thanks. I don't think the issue is related to bad name servers n /etc/resolv.conf. I've tried both our own pair of name servers (which we use across a number of other linux servers) as well as 8.8.8.8, but they all return the same result.

However, I should rephrase the initial problem. It turns out I must have typed in an incorrect IP when doing a PTR lookup for IP-addresses outside of our own subnet, as I do get a result if I e.g. do "dig -x 8.8.8.8". But I fail to get a result if I lookup any of the IP addresses in our own subnet "dig -X our-own-subnet-ips". In Plesk, I see the following, which I suppose is fetched from icfg-eth0:

IP: 123.123.123.123/255.255.255.0

Now, could the issue be caused by the fact that the network mask is not listed as 255.255.255.255? In any case, the reason it's not, is because the gateway resides as 123.123.123.1, so if I am not mistaken, netmask needs to be 255.255.255.0 also in the network config file.
 
I figured this one out. It appears as if Plesk for some reason has created a zone for the /24 subnet we're using on this server, which took me by surprise, as I cannot recall telling Plesk to do so. The solution was to comment out the reference to the zone from /etc/named.conf. However this file will be overwritten by Plesk in time.

So I guess the question now is: How can I - on a permanent basis - tell Plesk's named service to not act as authorative for our subnet?
 
Back
Top