From: Matt Chung [mailto:itsmemattchung@gmail.com]
Historically, there was no compelling reason to create PTR records for our CPE however more and more applications seem to be dependent on it. Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose?
As a web host, we frequently find customers who have added Apache rules to their ecommerce sites to block undesirable traffic, such as credit card scammers, etc. Not knowing any better, they often do this by just blocking anything that ends in .in to block Indonesia for example. Well, once you choose to block by resolved name, now that site has to do a dns lookup for every incoming request to see if it resolves to a name that should be blocked. Just one example, but I'm sure there are countless others that also impede performance for IP addresses without a PTR record. David
On Wed, Nov 02, 2011 at 06:12:21PM -0400, David Hubbard wrote:
From: Matt Chung [mailto:itsmemattchung@gmail.com]
Historically, there was no compelling reason to create PTR records for our CPE however more and more applications seem to be dependent on it. Although we will be assigning a record for each address, my question is why is the application (specifically HTTP) dependent on a reverse record ? What is the purpose?
As a web host, we frequently find customers who have added Apache rules to their ecommerce sites to block undesirable traffic, such as credit card scammers, etc. Not knowing any better, they often do this by just blocking anything that ends in .in to block Indonesia for example.
That's even less effective than you'd naively expect, given that Indonesia's TLD is .id... - Matt
As a web host, we frequently find customers who have added Apache rules to their ecommerce sites to block undesirable traffic, such as credit card scammers, etc. Not knowing any better, they often do this by just blocking anything that ends in .in to block Indonesia for example. Well, once you choose to block by resolved name, now that site has to do a dns lookup for every incoming request to see if it resolves to a name that should be blocked.
Another practical problem with this approach is that .IN is India but hey, at least it blocks something :-) -- -Barry Shein, that'd be .ID for Indonesia The World | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo*
On Wed, Nov 2, 2011 at 6:08 PM, Barry Shein <bzs@world.std.com> wrote:
Another practical problem with this approach is that .IN is India but hey, at least it blocks something :-)
There are also some services out there that block connections entirely, if the user doesn't have a PTR record. I'm thinking IRC servers, MUDs, and some other services with strange security policies that check for a port 113 IDENT response and RDNS to make a dark magic security decision to block a user who has no PTR. But in the modern world... more commonly, MTAs such as sendmail are often configured to require a valid PTR record. So as an ISP, you may be breaking your user's local MTA if you don't have the correct PTR for their IP addresses. So I would say following the RFCs and implementing the proper PTRs will help with that performance issue as a side-effect of having a valid zone, and head off other issues with possibly less popular services that are still blocking connections based on lack of proper PTR. :)
-- -Barry Shein, that'd be .ID for Indonesia
-- -JH
participants (4)
-
Barry Shein -
David Hubbard -
Jimmy Hess -
Matthew Palmer