On Tue, Apr 20, 2010 at 3:08 PM, James Martin <jamesmartin@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