Unable to get reverse DNS for MX record configured

My virtual domains cannot send to AOL.

I’ve tried to use the interface to correct the reverse lookup failure, at this point, I’m not sure what to do next.

Can someone please post an example of the DNS file for a working domain, feel free to change the address/name.

After initial domain creation bind showed no reverse records.
I have made many attempts but all fail. I am running my own DNS server on the same box as virtualmin and websites.

Any help is appreciated.

Thanks in Advance

Thanks and I do know how to setup the records manually, This new server, I had thought my address where completely delegated to me but after your post, I checked with them and found out you were correct. This is getting addressed by my isp now.
Thanks Again, I prob would have kept beating my head against the wall without your post.

I’ve been banging my head against the wall on this one for the past month here.

Last week, my ISP told me that they are doing what is called a "CNAME Hack" to delegate reverse DNS zones to our servers. Before they clarified that they had set up the "CNAME Hack" the error message I got for reverse DNS resolution was "NXDOMAIN" from sites like this one:

http://www.infoblox.com/services/dns_advisor_tool.cfm

Now I am getting "SERVERFAIL" - neither these error messages tell me much.

Does someone have a reverse zone file and master zone entry they can post here that works with virtualmin?

My situation is that we are using live/exposed IP addresses (none of our servers are on an internal network, per se.)

Thanks for any help you can offer,
-J

Reverse zones are outside of the scope of what Virtualmin cares about…so you don’t need a special configuration that “works with Virtualmin”. Virtualmin won’t care, no matter what you have in your reverse zone.

Luckily, reverse zones are stupidly simple. You almost can’t possibly go wrong in creating them. And, you only need one record for each IP address on your server.

Here’s the docs for creating a new zone in Webmin’s BIND module (it covers both forward and reverse simultaneously, as they are very similar):

http://doxfer.com/Webmin/BINDDNSServer#Creating_a_new_master_zone

In short, just create a new master zone, select Reverse, and fill out the form (punch in the network in the form 192.168.1. ). Holler if you run into specific problems, while creating the zone, or after you’ve created it, with what problem you’re seeing, and we’ll help you get it straightened out. But, don’t be afraid to dive in and try creating it–you’ll find it’s less intimidating than it seems once you’ve poked at it a bit.

Joe,

I’ve tried to set this up from virtualmin - used the docs and so on. From virtualmin, adding the reverse master zone was/is totally cake.

However - it’s not worked. I just emailed the ISP to ask them to check the reverse DNS zone setup (since we don’t have the entire address block, just 12 addresses of our class “C” block.)

I’m trying to make sure that I have exhausted all avenues on my end before going to my ISP again.

I’ll send you an email and if you can help out, great - I really, really would appreciate it.

Whatever the outcome, we can post it here for other folks with similar issues.

thanks,
-J

Note that you can use the same techniques to troubleshoot reverse records as you’d use to troubleshoot forward records.

So, ask your name server if it knows how to resolve your address…run this on the command line of your Virtualmin box:

host 192.168.1.1 localhost

Obviously, replacing 192.168.1.1 with your actual IP address.

What does it say? If it responds correctly, then the problem is probably on your ISPs end–they really haven’t delegated to you. Maybe the only reload zones every four hours or something and that reload hasn’t happened yet, or similar.

Reverse zones are really a lot easier than forward zones, though delegation can be intimidating.

Finally, I was able to get this resolved.

Our virtualmin server is on a subnet of a full class "C" network. Our ISP has allotted to us 10 addresses and registered these addresses with ARIN to officially allocate them to our organization.

A big clue to decipher how to do this:
http://doxfer.com/Webmin/BINDDNSServer#Setting_up_partial_reverse_deleg

-In particular, steps 6 and 7 below: (1-5 are for the ISP)
6 On the DNS server for the sub-network, create a new master zone for the reverse network 192.168.1.100-110. Webmin will automatically convert this to the correct in-addr.arpa format for you.
7 Add Reverse Address records to the new zone as normal for IP addresses like 192.168.1.100-110.101. Adding a record for the IP 192.168.1.101 will not work.

Another big clue was using DNSstuff’s tools to do an “advanced” reverse IP trace - which walked through each of the DNS queries for our the allotted IP address we checked.

Parsing through the queries and responses explained the issue plainly.

[code:1]Asking e.root-servers.net for 232.214.162.207.in-addr.arpa PTR record:
e.root-servers.net says to go to henna.arin.net. (zone: 207.in-addr.arpa.)

Asking henna.arin.net. for 232.214.162.207.in-addr.arpa PTR record:
henna.arin.net [192.26.92.32] says to go to ns1.lightpointcommunications.net. (zone: 214.162.207.in-addr.arpa.)

Asking ns1.lightpointcommunications.net. for 232.214.162.207.in-addr.arpa PTR record: Got CNAME referral (with no NS) to d.root-servers.net (zone 232.224/28.214.162.207.in-addr.arpa.) [from 207.162.208.55]

Asking d.root-servers.net for 232.224/28.214.162.207.in-addr.arpa. PTR record:
d.root-servers.net [128.8.10.90] says to go to figwort.ARIN.NET. (zone: 207.in-addr.arpa.)

Asking figwort.ARIN.NET. for 232.224/28.214.162.207.in-addr.arpa. PTR record:
figwort.arin.net [192.42.93.32] says to go to ns.lightpointcommunications.com. (zone: 214.162.207.in-addr.arpa.)

Asking ns.lightpointcommunications.com. for 232.224/28.214.162.207.in-addr.arpa. PTR record:
ns.lightpointcommunications.com [207.162.208.2] says to go to ns1.lightonthenet.org. (zone: 224/28.214.162.207.in-addr.arpa.)

Asking ns1.lightonthenet.org. for 232.224/28.214.162.207.in-addr.arpa. PTR record: Reports that no PTR records exist [from 207.162.214.232].[/code:1]

So that means our ISP is forwarding the 224/28.214.162.207 zone request to our server and then the specific IP is queried (looking for a PTR for the IP in our allocated block that ends in .232).

In order to fix this - I had to know what zone query our ISP was forwarding - in this case : “224/28.214.162.207.in-addr.arpa.” AND I had to have a PTR in the correct format to delineate specific IP’s on our allocated block - again, the hint was in good ol’ DNSstuff tools: “232.224/28.214.162.207.in-addr.arpa.”

In the webmin interface for BIND this is easy to do whence you know the way to accomplish it.

create a master zone, select it to be “reverse” and then enter the zone that your ISP is querying - you don’t have to enter it “backwards” just the 207.162.214.224/28 or similar will work - webmin will convert it for you.

Add reverse records to this master zone - again you don’t need to enter them in reverse - just 207.162.214.224/28.232 will do the trick.

For posterities sake, I also added another reverse master zone for the whole class “C” network - 207.214.162 And added all the reverse records in this address as well. This was significant for host xxx.xxx.xxx.xxx queries to resolve correctly. Seeing as everything is working as expected at this point, I don’t plan on seeing the impact of removing this zone will have at this point.

It’s great to finally put this to rest and I hope this thread will help others find answers to similar problems…

-J

Sweet! Awesome troubleshooting!

Thanks for the update…this one had me rather stumped, too.

Reverse lookups are rarely in your power to control, unless you are a hosting provider or ISP (in which case, you’d know how to set them up). Generally, you’d need to talk to your ISP/host to get them to either delegate reverse for your IP(s) to your server, or to simply provide sane reverse records. The actual record served doesn’t matter–it just has to resolve. For example, Virtualmin.com IPs reverse resolve to something like: ee.4.5646.static.theplanet.com. And this works just fine.

So, talk to your provider and ask them if they have delegated the IP to your server, and if they haven’t ask them to setup correct reverse resolution (again, the name doesn’t matter–it just has to resolve to something). If they’ve delegated it to you, then you need to setup a reverse zone for your IP address(es).

To do that use the BIND module and click “Create master zone”, then fill out the form setting Zone type to “Reverse”. But, since you say you’ve tried that, it’s pretty likely that your server isn’t even authoritative for the IP in question, and no amount of poking at it is going to do anything. (In all honesty, you probably don’t even want to be authoritative for reverse resolution–it’s just a needless hassle.)