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.
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.
Thanks
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
[your-ips].IN-ADDR.ARPA
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
it.
Cheers,
-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
e-mail/xmpp: tony@lava.net
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).
regards,
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.
with forward DNS, anyone can map a domain to any arbitrary IP address, such
as mapping www.example.com to the same IP address as big-popular-bank.com.
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, www.example.com can have an A record of 192.168.1.1
and, through the reverse map, 1.1.168.192.in-addr.arpa will have a PTR record
of "www.example.com"
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 192.168.1.1 , it might show:
user@hostname% host 192.168.1.1
1.1.168.192.in-addr.arpa domain name pointer www.example.com.
keep in mind, this will only work if the name servers registered for the ip
block actually contain data.
check out:
http://en.wikipedia.org/wiki/Reverse_DNS_lookup
and, go to "Guide to reverse zones" in:
http://www.apnic.net/__data/assets/pdf_file/0009/9792/Reverse-DNS-manual.pdf
hope this is helpful
This is as close as the IETF has come to a document.
http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06
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
1-2-3-4.raleigh.nc.dsl.dyn.example.net
instead of
dsl-1-2-3-4-dynamic.nc.raleigh.example.net
So they can block all mail from dynamics with a simple 'dyn.example.net'
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 
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
enlightenment.
I've written up some tips and hints here:
http://enemieslist.com/news/archives/2009/06/principles.html
http://enemieslist.com/news/archives/2009/06/basic_principle.html
http://enemieslist.com/news/archives/2009/06/basic_principle_1.html
http://enemieslist.com/news/archives/2009/06/basic_principle_2.html
http://enemieslist.com/news/archives/2009/07/a_passionate_cr.html
http://enemieslist.com/news/archives/2009/07/why_we_suspect.html
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):
203-214-65-42.mail2.fft.com.au
189-17-23-133.alpinet.com.br
mx-189-108-118-122.compertratores.com.br
200-206-157-155.mail.eletti.com.br
200-148-137-195.fundecitrus.com.br
200-206-216-150.corpmail.panini.com.br
200-204-147-132.smtp-gw.scanbrasil.com.br
gate-193-85-144-1.e-one.cz
63-145-232-66.accessintel.com
24-43-168-100.biz.aceweb.com
mm-notify-out-72-21-209-53.amazon.com
69-20-71-3.clearrequest.com
mx-82-102-77-85.infocreditgroup.com
84-45-12-85.interparcel.com
64-128-133-217.static.ithikon.com
s199-126-14-180.local1111.com
adsl-66-139-110-100.midwestrug.com
sm-70-42-226-219.quepasa.com
so-63-131-152-52.serviceobjects.com
216-139-224-52.aus.us.siteprotect.com
151-204-36-17.smtpusa.com
mx-119-92-80-10.theorchardgolf.com
203-214-65-56.mail.thomsettinternational.com
antispam-213-183-191-209.ewe-ip-backbone.de
11-176-40-206-reverse.brazosport.edu
209-184-246-217.labette.edu
124-247-238-41.mail.ashwath.in
186-227-63-74.reverse.wirepressnewsalerts.info
77-49-165-194.celeo.net
mail-36-244-187-78.imzahost.net
66-50-173-37.masso.net
35-225-63-74.reverse.wirepresswirenewsalerts.net
mx-213-48-133-164.aclt.org
host84-233-131-230.19.co.uk
207-193-177-11.crowley.k12.tx.us
HTH,
Steve