Reverse DNS Question
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 -- __________________________________ James Martin jamesmartin@ieee.org
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
I know this is really basic stuff but I don't know it and have never needed to know it until now.
Thanks
-- __________________________________ James Martin jamesmartin@ieee.org
On Tue, 20 Apr 2010, James Martin wrote:
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)?
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
On 4/20/2010 15:26, Antonio Querubin wrote:
On Tue, 20 Apr 2010, James Martin wrote:
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)?
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.
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. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
At 15:37 -0500 4/20/10, Larry Sheldon wrote:
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.
This is as close as the IETF has come to a document. http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-0... 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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same?
On Tue, Apr 20, 2010 at 10:26:17AM -1000, Antonio Querubin wrote:
On Tue, 20 Apr 2010, James Martin wrote:
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)?
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.
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 -- Jim Mercer jim@reptiles.org +92 336 520-4504 "I'm Prime Minister of Canada, I live here and I'm going to take a leak." - Lester Pearson in 1967, during a meeting between himself and President Lyndon Johnson, whose Secret Service detail had taken over Pearson's cottage retreat. At one point, a Johnson guard asked Pearson, "Who are you and where are you going?"
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,
Date: Tue, 20 Apr 2010 16:08:04 -0400 Subject: Reverse DNS Question From: jamesmartin@ieee.org To: nanog@nanog.org
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
-- __________________________________ James Martin jamesmartin@ieee.org
_________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969
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
on Tue, Apr 20, 2010 at 11:39:11PM -0500, James Hess wrote:
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.
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 -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
participants (9)
-
Antonio Querubin -
Edward Lewis -
Jack Carrozzo -
James Hess -
James Martin -
Jim Mercer -
Larry Sheldon -
Steven Champeon -
Tarig Yassin