Is there a difference between reverse DNS records and PTR records?
"PTR record" is technically specific, unambiguous. The usually
synonomous "reverse DNS" probably has a bunch of different meanings,
most/all of them wrong. :)
I always thought they were the same thing. But some of our users
were having trouble sending to a specific domain and when I spoke
to the other company's techs, they said they were refusing our
emails because we have no PTR record.
But I knew we did have one. I told the tech to go to dnsreport.com
and look down in the MX area.
<http://www.dnsreport.com/tools/dnsreport.ch?domain=rogersbenefit.com>http://www.dnsreport.com/tools/dnsreport.ch?domain=rogersbenefit.com
Shown here:
PASS Reverse DNS entries for MX records OK. The IPs of all of your
mail server(s) have reverse DNS (PTR) entries.
<http://www.DNSstuff.com/pages/rfc1912.htm>RFC1912 2.1 says you
should have a reverse DNS for all your mail servers. It is strongly
urged that you have them, as many mailservers will not accept mail
from mailservers with no reverse DNS entry. Note that this
information is cached, so if you changed it recently, it will not be
reflected here (see the <http://www.dnsstuff.com>www.DNSstuff.com
Reverse DNS Tool for the current data).
... DNSReport's dense, logorrheic fog has caused as much confusion
and as many questions as it answers.
"It is urged" that simpler is always better. :)
The reverse DNS entries are:
203.205.167.68.in-addr.arpa
<http://www.dnsstuff.com/tools/ptr.ch?ip=68.167.205.203>mail.rogersbenefit.com.
[TTL=1470]
the PTR and A records match:
dig -x 68.167.205.203 +short
mail.rogersbenefit.com.
dig mail.rogersbenefit.com +short
68.167.205.203
... end of story. :)
But he told me that they use SurfControl 5.0 SP3 and when he checks
his log files for these transactions where our domain was refused by
theirs - SurfControl came back and said "No PTR Record".
See above, it's correct, now.
Does anyone know if SurfControl looks up PTR records differently
than dnsreport.com? Anyone ever seen this?
A DNS query for PTR record is a DNS query for PTR record. There is
simply no "differently" about such a simple, atomic operation.
Where many mail/DNS admins screw up is in not assuring that an IP's
PTR domain name has matching IP in the domain name's A record.
No PTR + A match = no PTR, for "serious" PTR verification.
Another problem is that querying for existing PTR records not cached
locally can sometimes take many seconds, causing the querier to
timeout and conclude "no PTR". Wrong conclusion.
When a DNS query fails to complete, the SMTP response code for the
reject based on the timeout should be a transient 4xx, not permanent
5xx, since the indeterminate DNS timeout could be caused by a
temporary network/DNS problem. 4xx will cause the sender to retry
and eventually the DNS query will give a definitive positive or
negative answer.
The query for existing records should complete eventually and be
cached so that subsequent PTR/A queries succeed.
Len
_____________________________________________________________________
http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/