Basic DNS: PTR Records And Why You Care

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 desn'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.


By A.P. Lawrence  http://aplawrence.com


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Submitted by Guest on Tue, 03/06/2007 - 16:45.

Nice article... helped a lot.

Thank you.

elhoyos.co