Reverse DNS Question

James Hess mysidia at gmail.com
Wed Apr 21 04:39:11 UTC 2010


On Tue, Apr 20, 2010 at 3:08 PM, James Martin <jamesmartin at ieee.org> wrote:
> All:
> 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.

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.
http://tools.ietf.org/html/rfc1912
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  http://www.zytrax.com/books/dns/ch3/

The RIRs also have (limited resources)
https://www.arin.net/resources/request/reversedns.html

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.
http://www.apnic.net/__data/assets/pdf_file/0009/9792/Reverse-DNS-manual.pdf


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 in-addr.arpa
domain.


 For example,  if you were allocated the IP block 192.0.0.0/23
then  these would be delegated  to your listed  reverse DNS servers
(by the registry),  it is entirely dependant on your allocation:
0.0.192.in-addr.arpa
1.0.192.in-addr.arpa

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
"
0.0.192.in-addr.arpa.  IN SOA   ns1.example.com.    email.addr.  ( 2037011800
7200 7200
604800  7200 )
                      IN NS  ns1.example.com.
                      IN NS  ns2.example.com.
1                       IN        PTR  ip192-0-0-1.example.com.
2                       IN        PTR  ip192-0-0-2.example.com.
3                       IN        PTR  ip192-0-0-3.example.com.
"

Assuming  "ip192-0-0-1.example.com."  resolved to 192.0.0.1,  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 "ip192-0-0-1.example.com."   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.


--
-J




More information about the NANOG mailing list