What happens if the ISP never defines a name server with their RIR for their provider-independent address space? Does ARIN point to somewhere which supplies NXDOMAIN? Just a thought -- I don't have a clue.
It is entirely possible they have it pointed to their non-existent or broken DNS. Given current best practices, I see no reason not to assign a generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock. On Wed, Nov 2, 2011 at 5:19 PM, Ben Jencks <b...@bjencks.net> wrote: > On Nov 2, 2011, at 5: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? > > You're returning NXDOMAIN, right? If they're doing a reverse lookup and > you return NXDOMAIN it should fail quickly, or else the application is even > more horribly broken than just doing reverse lookups would imply. On the > other hand, if you're not responding to the PTR request then that could be > causing the timeout. > > -Ben > > >
