Get APLawrence.com by RSSBasic DNS: PTR records and why you care
Fri Jul 2 15:56:02 2004 Basic DNS: PTR records and why you care
Posted by Tony Lawrence
Search Keys: DNS, PTR record mail
A PTR record is what lets someone do a "reverse" DNS lookup - that is, they have your IP address and want to know what your host/domain is. At any Unix/Linux command line, you can use "dig -x" to do a reverse lookup:
bash-2.05a$ dig -x 64.226.42.29
; <<>> DiG 9.2.1 <<>> -x 64.226.42.29
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38101
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;29.42.226.64.in-addr.arpa. IN PTR
;; ANSWER SECTION:
29.42.226.64.in-addr.arpa. 1762 IN PTR pcunix.com.
;; Query time: 49 msec
;; SERVER: 10.1.36.238#53(10.1.36.238)
;; WHEN: Fri Jul 2 11:03:29 2004
;; MSG SIZE rcvd: 67
Not every IP address has a corresponding PTR record. In fact, if you took a random sampling of addresses your firewall blocked because they were up to no good, you'd probably find most have no PTR record - a dig -x gets you no information. That's also apt to be true for mail spammers, or their PTR doesn't match up: if you do a dig -x on their IP you get a result, but if you look up that result you might not get the same IP you started with.
That's why PTR records have become important. Originally, PTR records were just intended as a convenience, and perhaps as a way to be neat and complete. There still are no requirements that you have a PTR record or that it be accurate, but because of the abuse of the internet by spammers, certain conventions have grown up. For example, you may not be able to send email to some sites if you don't have a valid PTR record, or if your pointer is "generic":
dig -x 65.96.9.234
; <<>> DiG 9.2.1 <<>> -x 65.96.9.234
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55565
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;234.9.96.65.in-addr.arpa. IN PTR
;; ANSWER SECTION:
234.9.96.65.in-addr.arpa. 3570 IN PTR h00c0f06bacf1.ne.client2.attbi.com.
;; Query time: 2 msec
;; SERVER: 10.1.36.238#53(10.1.36.238)
;; WHEN: Fri Jul 2 11:12:45 2004
;; MSG SIZE rcvd: 90
Typically, the reason you get refused is because the "generic" pointer doesn't have an MX (mail exchange record):
dig h00c0f06bacf1.ne.client2.attbi.com MX
; <<>> DiG 9.2.1 <<>> h00c0f06bacf1.ne.client2.attbi.com MX
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32826
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;h00c0f06bacf1.ne.client2.attbi.com. IN MX
;; Query time: 292 msec
;; SERVER: 10.1.36.238#53(10.1.36.238)
;; WHEN: Fri Jul 2 11:14:01 2004
;; MSG SIZE rcvd: 52
How do you get a PTR record? You might think that this is done by your domain registrar - after all, they point your domain to an IP address. Or you might think whoever handles your DNS would do this. But the PTR record isn't up to them, it's up to the ISP that "owns" the IP block it came from. They are the ones who need to create the PTR record. In some cases, that may be the same folks who handle your DNS, but the point is that it is not necessarily so: you may have no control over this whatsoever. See RFC 2317 and Avoid RFC 2317 style delegation of 'in-addr.arpa.' also.
If you don't have a PTR record, and can't get one (for example because you have a dynamic address), you will want to send outgoing email through a server that does. Your INCOMING server doesn't need a PTR record - you can use a dynamically assigned IP address for a mail server as long as you have some way of updating your MX record when your IP changes. And it isn't that you can't send SMTP mail out from such a server (although some ISP's do block outgoing SMTP to any but their own server); it's just that some recipients may block you because you don't have that PTR record or because it doesn't match up wth an MX record for you.
Usually, you'll use your ISP's SMTP server as your "delegate" server - that can be done at your internal mail server or at the client machines ("Outgoing SMTP Server"). However, assuming that you aren't blocked for outgoing SMTP, you can use any server that "likes" you - that is, any server that will allow your IP address to relay mail through it. That's probably going to be another server under your control, or someone who knows you - there are few servers left that will let just anyone use them as a mail relay.
Swedish Translation by Thor Kottelin available.
Finnish Translation by Thor Kottelin available.
Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)
| Views for this page | ||||
|---|---|---|---|---|
| Today | This Week | This Month | This Year | Overall |
| 4 | 935 | 3,281 | 53,510 | 125,205 |
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Your ad here - $24.00 yearly!
http://www.schewanick.com SCO Unix, Solaris, Linx (various), PHP, MySQL, Apache, uniBasic, dL4, Perl, System Administration and more....
UBB Computer Services Support for Openserver, Unixware and Linux. Windows integration with Unix/Linux servers. Hardware, Backup and Networking issues. Located near Sacramento CA, we provide onsite support throughout Northern CA and Nationwide via remote access. We are a SCO Authorized Partner and a Microlite BackupEdge Certified Reseller.
http://www.breakthru.com.au SCO (Openserver and Unixware), Unix, Solaris and Linux Consulting services including: Secure Networking Solutions; Linux based Firewalls; Backup Solutions; Secure Home to Office Network Setup; Phone, Remote and On-Site Support available - Satisfaction Guaranteed!
Related Posts
Thu Sep 8 15:28:47 2005: Subject: TonyLawrence
Thanks for the correction on the link; I wish people were smart enough to add redirects when the decide they need to shuffle things around, but it seems like nobody cares..
Thu Oct 9 03:55:55 2008: Subject: anonymous
"Typically, the reason you get refused is because the "generic" pointer doesn't have an MX (mail exchange record):"
This statement is incorrect. It's a very common practice to use separate inbound and outbound servers in an email environment. Verifying a PTR record against an MX record would result in a large amount of false positives. Whether this was a common practice or not in 2004 is questionable; however, having been in the spam filtering industry for the past 3 years, I have NEVER come across a case where the MX record was in fact being compared to the PTR record. This is a very common misconception (hence, the reason for my comment today).
AOL's website states the following:
* AOL does require that all connecting Mail Transfer Agents have established reverse DNS, regardless of whether it matches the domain.
* Reverse DNS must be in the form of a fully-qualified domain name. Reverse DNS containing in-addr.arpa are not acceptable, as these are merely placeholders for a valid PTR record. Reverse DNS consisting of IP addresses are also not acceptable, as they do not correctly establish the relationship between domain and IP address.
* Reverse DNS that may be similar to dynamic IP space (containing pool, dhcp, dyn, etc.) may be treated as suspect. Therefore should be changed to reflect a fully-qualified domain name with standard MTA reverse DNS.
Source: http://postmaster.info.aol.com/info/rdns.html
Hope this helps someone in the future. :)
Thu Oct 9 11:47:33 2008: Subject: TonyLawrence
OK, I see your point. Most of the people that have this problem are small, and run ONE server, so for them it's simpler to explain it this way. Your comment will serve to correct for the few cases where separate servers are used.
Add your comments