<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:blogChannel="http://backend.userland.com/blogChannelModule">

<channel>
<title>Topic &#x27;[Servers] Issues with Bad Reverse DNS&#x27; in forum &#x27;Networking&#x27; - dslreports.com</title>
<link>http://www.dslreports.com/forum/Servers-Issues-with-Bad-Reverse-DNS-22673329</link>
<description></description>
<language>en</language>
<pubDate>Fri, 10 Feb 2012 02:45:56 EDT</pubDate>
<lastBuildDate>Fri, 10 Feb 2012 02:45:56 EDT</lastBuildDate>

<item>
<title>Re: [Servers] Issues with Bad Reverse DNS</title>
<link>http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22675011</link>
<description><![CDATA[IT Guy posted : <div class="bquote"><small>said by <a href="/profile/652969" onClick="this.blur(); return popup(event,'/uidpop?ajh=1&uid=652969');">LinkTech</a>:</small><br><br>I would contact Apollo in this case. Reverse DNS is handled by the company that issues the IP.  They can make another server authoritative for you IP range, however saying its hosted they probably won't do that.  They will probably need to do it on their end.  But its definately an Apollo problem, not Bluehost.  If it was the SPF record, then yes Bluehost, not reverse DNS.<br> </div>I stand corrected, you were right.  I called Apollo back a second time and had them create the PTR on their end. Performing the test through MXtoolbox.com is showing the RDNS passed.  Thanks for your help, all of you.  This information will be dually noted for any future email calamity.<br><small>--<br>My time is a piece of wax, falling on a termite, that's choking on a splinter.  --Beck</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22675011</guid>
<pubDate>Wed, 08 Jul 2009 16:47:40 EDT</pubDate>
</item>

<item>
<title>Re: [Servers] Issues with Bad Reverse DNS</title>
<link>http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22674677</link>
<description><![CDATA[IT Guy posted : I just got off the phone with the mail host, and they stated that it would have to be Bluehost (finger-pointing is the story of my life).  <br><br>When looking through the FAQ at Bluehost, they say they do not currently allow custom PTR records and if one is needed, we would need a 3rd party DNS provider. The PTR record, from my understanding is where RDNS pulls from.  Out of curiosity, I've entered the DNS Zone settings for our mail server and enabled PTR with the IP for our server and domain name for our mail server. I'm very skeptical if this will work.  I can't remember for the life of me how our DNS zone was set up or if it was even active at all through our mail server.  Since our mail server is dedicated, can't it just act as the "3rd party" DNS provider?  I'm just not sure if I can activate only the PTR record or if it will have to activate all DNS zone records and if it will interfere with the DNS, A records, etc... that are being handled by Bluehost.  I'm very confused.<br><small>--<br>My time is a piece of wax, falling on a termite, that's choking on a splinter.  --Beck</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22674677</guid>
<pubDate>Wed, 08 Jul 2009 15:50:38 EDT</pubDate>
</item>

<item>
<title>Re: [Servers] Issues with Bad Reverse DNS</title>
<link>http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22674514</link>
<description><![CDATA[Jahntassa posted : <div class="bquote"><small>said by <a href="/profile/1049469" onClick="this.blur(); return popup(event,'/uidpop?ajh=1&uid=1049469');">IT Guy</a>:</small><br><br>Where exactly should the RDNS info. be pulling from? The A record, MX record or the DNS or is it its own record?<br> </div>The provider of the IP address in question.<br><br>Our T1 is hosted by telepacific, and they hold the DNS Zone for those IP addresses. When I need an RDNS entry updated I have to contact them.<br><br>When we had AT&T, they pointed the IP DNS Zone to our DNS servers, and we could control our own RDNS entries.<br><br>So it sounds like your mail hosting company, that assigned you the IP address, needs to do the change.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22674514</guid>
<pubDate>Wed, 08 Jul 2009 15:20:54 EDT</pubDate>
</item>

<item>
<title>Re: [Servers] Issues with Bad Reverse DNS</title>
<link>http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22674384</link>
<description><![CDATA[IT Guy posted : <div class="bquote"><small>said by <a href="/profile/652969" onClick="this.blur(); return popup(event,'/uidpop?ajh=1&uid=652969');">LinkTech</a>:</small><br><br>I would contact Apollo in this case. Reverse DNS is handled by the company that issues the IP.  They can make another server authoritative for you IP range, however saying its hosted they probably won't do that.  They will probably need to do it on their end.  But its definately an Apollo problem, not Bluehost.  If it was the SPF record, then yes Bluehost, not reverse DNS.<br> </div>This is what is confusing me so much about this RDNS.  DNS is solely being handled by Bluehost and all DNS Zones are disabled through Apollo.  My limited understanding is that it has to be set up in this fashion.  While it is true that the RDNS should be reflecting the IP address for our mail server through Apollo, shouldn't the actual record reside with Bluehost? Where exactly should the RDNS info. be pulling from? The A record, MX record or the DNS or is it its own record?<br><small>--<br>My time is a piece of wax, falling on a termite, that's choking on a splinter.  --Beck</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22674384</guid>
<pubDate>Wed, 08 Jul 2009 14:56:56 EDT</pubDate>
</item>

<item>
<title>Re: [Servers] Issues with Bad Reverse DNS</title>
<link>http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22673607</link>
<description><![CDATA[LinkTech posted : I would contact Apollo in this case. Reverse DNS is handled by the company that issues the IP.  They can make another server authoritative for you IP range, however saying its hosted they probably won't do that.  They will probably need to do it on their end.  But its definately an Apollo problem, not Bluehost.  If it was the SPF record, then yes Bluehost, not reverse DNS.]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/Re-Servers-Issues-with-Bad-Reverse-DNS-22673607</guid>
<pubDate>Wed, 08 Jul 2009 12:55:31 EDT</pubDate>
</item>

<item>
<title>[Servers] Issues with Bad Reverse DNS</title>
<link>http://www.dslreports.com/forum/Servers-Issues-with-Bad-Reverse-DNS-22673329</link>
<description><![CDATA[IT Guy posted : Ok, here's the background.  Bluehost is Web hosting company (via our 3rd party Web developers), we have another company, Apollo Hosting, hosting our email server (for reasons I won't go into here, we have them separated).  We also use Postini as our spam gateway, but they aren't handling any DNS/RDNS for us, we only have Postini set up for inbound traffic.  We just have the MX records at Bluehost pointing to Postini, and Postini pointing to our new mail server IP.<br><br>Recently our email hosting company changed our IP address and I had to make a mad rush to coordinate the effort to get Bluehost to update the IP addresses in various authoritative records which they are responsible for, primarily the NS and A records specific to our mail (they provide DNS, A record, CNAME, MX, etc. for our entire domain and have control of routing to the correct servers).  All of that is now straightened out, but I have one remaining problem.  When running tests on our mail.domain.com using MXtoolbox.com and some others, it is reporting that there is no reverse DNS or otherwise it has failed.  I have run these tests in the past before the IP address change and I have assured Bluehost tech. support that these tools were finding the RDNS right up to the point Apollo changed our IP.  <br><br>Bluehost support is telling me that the shared nature of our hosting package negates the use of RDNS, meanwhile I have 130 + people who are getting failure notices from some domains such as att.net and yahoo.com stating bad reverse DNS errors.  Bluehost insists that all is needed is an updated SPF record (which they have done), but I'm not convinced.  <br><br>Can anyone shed any light on this subject for me? I'm not the MOST knowledgeable person on this subject, but these inconsistencies make me wonder how much knowledge Bluehost has on the subject. I don't understand how they can claim that RDNS isn't an option available for us when it clearly (to me and mxtoolbox.com anyway) was active right up to the point our mail server IP address changed.  I've been getting conflicting stories from each tech. I've had to deal with and this is really frustrating.<br><small>--<br>My time is a piece of wax, falling on a termite, that's choking on a splinter.  --Beck</small>]]></description>
<guid isPermaLink="true">http://www.dslreports.com/forum/Servers-Issues-with-Bad-Reverse-DNS-22673329</guid>
<pubDate>Wed, 08 Jul 2009 12:20:33 EDT</pubDate>
</item>

</channel>
</rss>

