Performance Issues - PTR Records

Wed Nov 9 22:32:39 UTC 2011

Larry Blunk wrote the following on 11/3/2011 12:47 PM:
> On 11/02/2011 05:57 PM, Matt Chung wrote:
>> I work for a regional ISP and very recently there has been an influx of
>> calls reporting "slowness" when accessing certain websites (i.e
>> google.com/voice/b) via HTTP.  After performing a tcpdump and 
>> analyzing the
>> session, I have been able to pinpoint the latency at the application
>> layer.  After the tcp session has been established, it takes up to 15-20
>> seconds before the application begins sending data.   The root of the
>> problem was that the PTR record for our customer(s) address does not
>> exist.  As soon as the record is created, latency from the 
>> application is
>> eliminated.  This is analogous to latency when accessing a server 
>> over SSH
>> when no PTR is available.
>>
>> A seperate packet capture from another customer exhibiting similar
>> performance behavior showed many TCP retransmissions.  At first 
>> glance, I
>> assumed this was network related however this correlates with the
>> application not responding and inducing retransmissions at the TCP layer
>> (different symptoms, same problem).
>>
>> 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?
>>
>> Hope this is helpful as well
>>
>
>   We recently encountered a similar issue with a customer.
> The sites that had slowness issues were configured to
> use the traditional Google Analytics javascript instead
> of the newer asynchronous code.
>   The problem was not the lack of a PTR record, but rather
> the in-addr delegation was pointing to lame servers that were
> no longer responding (hence the long timeouts as the
> Google servers attempted to perform reverse lookups
> on the client IP's).  As others have pointed out, as long
> as there's a valid nameserver responding, a lack of PTR
> record would not cause issues as an NXDOMAIN record would
> be sent back immediately and the Google Analytics server
> will move on.
>
>
>  -Larry Blunk
>   Merit

Larry, you're absolutely correct. One has to wonder what the continued 
debate is about. The Op likely had a DNS loop, misconfiguration, or lame 
servers. Correcting that issue should resolve any "slowness". The issue 
then is whether the application requires a valid PTR (or subsequent 
matching forward record) such as SMTP.

BTW, ARIN requires valid IN-ADDR.ARPA domain records. The specific 
record may be NXDOMAIN (non-existant), but the server cannot be lame - 
https://www.arin.net/policy/nrpm.html#seven1
I believe just about all of us on this list have agreed to this policy. 
However, my experience tells me that many people choose to ignore it. 
This thread is evidence of such.

--Blake