Reverse DNS Question


In the process of requesting a block of IP's for a client, ARIN requested
that we list Reverse DNS Servers for the block. I've never done this
before, nor have I ever thought it through.

What is the purpose for this besides resolving name-based reverse lookups?
Are there any definitive guides out there on how this works (besides the
ARIN site)?

I know this is really basic stuff but I don't know it and have never needed
to know it until now.


What is the purpose for this besides resolving name-based reverse lookups?

Resolving the reverse lookups IS the reason they need the nameservers
- how else do you reckon queries on one of your IPs would end up
finding the correct answer? In the same manner that you tell your
domain registrar where to find nameservers for that domain, you're
telling ARIN what servers can handle a query for

Are there any definitive guides out there on how this works (besides the
ARIN site)?

On setting up nameservers? Googling 'configuring BIND' will lead you
on your way, unless you're already using a different nameserver
daemon. As far as I know there are no ARIN-specific requirements to


-Jack Carrozzo

It's for resolving address-based lookups. When ARIN allocates address space to you, you now become responsible for the reverse-lookups for that allocated address range.

Antonio Querubin
808-545-5282 x3003

Some email blacklist operators have draconian requirements for PTR
values for IP addresses that (attempt to) send email.

To minimize unwarranted hassle, if you will have email senders, spend
some time looking into the "requirements". I don't think there are any
RFC or other authoritative standards in the matter.

Dear janes

as I know many services use reverse lookup as a sender authentication technique.
e.g. Email server using this technique to reduce spams.( if the ip adress of sending smtp server has no reverse lookup it's messages will be considered spam).


The Reverse DNS zone is for mapping internet address to hostname. It
is a basic requirement for proper DNS functionality that the Internet
address of every host maps back to the host's authoritative name.
It is important, and cannot be fully explained here, but you should
see the relevant RFCs to research the requirements to properly
implement Reverse DNS. See, RFC 1912.
for some usage information (Forward-confirmed Reverse DNS)

Any good DNS book should contain relevant details about how reverse
mapping is implemented in the DNS protocol. Zytrax is one of the
well-known online guides

The RIRs also have (limited resources)

APNIC's manual is OK and provides instructions for reverse zone
creation, if you ignore APNIC-specific policy details, such as their
delegation objects/delegation templates.

This is not necessarily just about sending e-mail, RDNS verification
and use of forward-confirmed RDNS may have fallen into some disuse in
recent years, with SSH replacing RSH and all, and "hosts.equiv"
going away, but, various internet services have been known to reject
connections intentionally (or accidentally) if reverse DNS is not
setup for an IP address of the peer/requestor, or is not present at
all, e.g. many IRC, NNTP, WHOIS, Finger servers.

It is a default behavior of TCP Wrappers (#define PARANOID), commonly
used to protect programs run by inetd on *ix systems.
Authentication/login protocols such as Kerberos also rely on proper RDNS.

When IP addresses are allocated to you by a regional registry such as
ARIN, or if another provider officially re-assigns and delegates
reverse to your IPs, the reverse DNS authority for those IPs becomes
your org's responsibility to either manage (or delegate further
downstream, using NS records, when appropriate).


See RFC1035, "Section 3.5. IN-ADDR.ARPA domain " What you supply
to ARIN are hostnames of some DNS servers that ARIN will delegate
your portions of the reverse DNS space to, from the

For example, if you were allocated the IP block
then these would be delegated to your listed reverse DNS servers
(by the registry), it is entirely dependant on your allocation:

The expectation is that your DNS servers will serve a PTR record in
the proper zone for each IP address you have assigned to a host

e.g. for that example, your first BIND zone might look like
" IN SOA email.addr. ( 2037011800
7200 7200
604800 7200 )
                      IN NS
                      IN NS

Assuming "" resolved to, etc, etc...

And you would have a second zone for the 192.0.1.* IPs

EXCEPT.... that is just an example, don't actually use a hostname
like "" in real life.

[*] Certain overly aggressive blacklists assume that the host must be
a dynamic / dial-up user due to the presence of "192-0-0-1", which
is recognized to be an IP address, so be careful.

with forward DNS, anyone can map a domain to any arbitrary IP address, such
as mapping to the same IP address as

there is nothing to prevent this, and in some cases it is acceptable, and in
some cases, possibly nefarious.

when the registeries (ARIN/RIPE/APNIC/etc) require the "owner" of an ip block
to define name servers for reverse maps, it provides a mechanism to double
check if a domain/ip-addr map is valid.

it isn't 100%, for sure, but, it is substantially better than nothing.

in this sense, can have an A record of

and, through the reverse map, will have a PTR record
of ""

in fact, there can be multiple PTR records, in case you have multiple
domains pointing at the same IP address.

on many unix(-ish) systems, the "host" command will show you the reverse PTR
record, if you run: host , it might show:

user@hostname% host domain name pointer

keep in mind, this will only work if the name servers registered for the ip
block actually contain data.

check out:

and, go to "Guide to reverse zones" in:

hope this is helpful

This is as close as the IETF has come to a document.

That document has been expired for 3 years, meaning, no one has updated it, no one has tried to get a steering committee broad review (IESG approval), etc.

While I don't consider my project to be "over-aggressive", you should be
aware that many antispam filtering systems do classify hostnames as a
class by their naming convention (in my case, I have ~52K patterns for
naming conventions in around 27K domains, classified by assignment and
other types and where possible by the technology in use eg static/dsl,
dynamic/dialup) and use those classifications to determine policy.

So, if you're intending to do the right thing here WRT your PTR naming,
it'd behoove you to indicate at the very least whether these are to be
used by end users (who are more likely to be infected with bots),
whether they're dynamically or statically assigned, whether they're
legit sources of mail, etc. Best current practice is to allow customers
running mail servers to assign custom and appropriate names to said
hosts (including PTR, not just A).

Also, to make it easier for folks running older MTAs without decent
regex support to block unwanted bot mail try to keep the most
significant token to the right hand side, a la

instead of

So they can block all mail from dynamics with a simple ''
instead of having to collect access.db entries for every city you happen
to provide access to. The rest of the Internet thanks you in advance :wink:

Having some comment or memo in your SWIP for the block that indicates
what the block's IPs are to be used for is also helpful, as when the PTR
is obscure and unhelpful rwhois is the next obvious place to turn for

I've written up some tips and hints here:

Comments welcome.

As for those supposed blacklists that treat n-n-n-n as an obvious
dialup, they're going to run into a lot of trouble if they try to
classify any of these hosts that way (they are in all likelihood MXen
or outbounds):