Bottom line: The wrong domain is being returned to rDNS queries. I know PTR records aren't required and are somewhat controversial. The decision to have one or not is subjective. But when we do want one, I think it's important to be able to get the one we want. And I know this is a very common topic. But looking at my configuration, I still can't figure out what the problem is. I now have several domains in my ISPConfig environment. At this point, ISPConfig doesn't seem relevant to this question, I'm just saying this is what I'm using for management. The primary domain for this environment is primary.tld. Each of the domain zones has two NS records for "domain.tld.", with values ns1.primary.tld and ns2.primary.tld, respectively. In the primary domain zone these are the relevant records: Code: A primary.tld. 1.2.3.4 A mail 1.2.3.4 MX primary.tld. mail.primary.tld. 10 NS primary.tld. ns1.primary.tld. < this is .4 NS primary.t ns2.primary.tld. < this is .5 PTR 4.3.2.1.in-addr.arpa. mail.primary.tld. PTR 5.3.2.1.in-addr.arpa. mail.primary.tld. The secondary server is configured for mail but I have not created a secondary MX record for it yet. With "dig -x 1.2.3.4" on the localhost, the Answer section shows the actual server hostname: "myserver.primary.tld." and "myserver.". With "dig -x 1.2.3.5" (ns2) my ISPs node name for this IP is displayed, so that second PTR record is ignored/invalid. But the PTR record for 1.2.3.4 refers to the "mail" name anyway. So I'm confused about that. I'm thinking the only service that seems to care about RDNS is email. Postfix is set to display mail.primary.tld in the banner, so RDNS should return the same FQDN to make other email servers happy. Unfortunately on a rDNS query, one of the other zones is being returned, so the response is "other.tld", not "primary.tld" and not "mail.primary.tld". I'll certainly post more info as required. At this point I don't know what other info would help. Thanks!
My signature has link to DNS tutorial, it explains also PTR records and how to set them up. PTR records are not added to your primary zone, they go to the reverse zone.
I've seen that tutorial and it seemed to be for larger installations. Apparently I was wrong. I will implement it today and post back here later. Thanks.
The DNS tutorial is for ISPConfig multiserver setup with two hosts running name service. Not that big, since two name servers is the minimum. Tutorial also tries to explain what name service is about and how to test it is working properly, this part applies quite well even for other kinds of name service setups.
I created a reverse zone and it's not being used. This seems to be ISP-specific but this may help others... I use DreamHost, their DreamCompute services. I have a subnet of servers with a pool of floating IPs that they provide, which I can dynamically allocate to servers as required. They control the rDNS for these IPs. When I use dig from my own servers, it uses my own DNS, and I get the right hostnames. But from outside of the network, the rDNS goes through DreamHost and it seems that cannot be overridden. So coming back to the original goal - where we have a multi-server ISPConfig setup, NS1=master and NS2=slave, MX/alias on master is "mail.domain.tld" - should the rDNS for the secondary sytem also return the same "mail.domain.tld" name? If that is correct, I need to tell DreamHost to set their own PTR records to point back to my "mail.domain.tld". Then I guess I can remove my PTR records and zone - unless you know a reason to keep it? Thanks!
It may be that you do not understand the concept of the PTR records. https://en.wikipedia.org/wiki/Reverse_DNS_lookup You wrote How is it not being used? How do you determine it is not being used? If you created the reverse zone on your ISPConfig name service, then it indeed is not used, since your name server is not authoritative for the reverse zone. If Dreamhost gave you these IP-numbers for running servers on with those addresses, they should provide reverse name service you can configure so it returns the FQDN you want. You need this at least for e-mail server to work properly.
