Re: Performance Issues - PTR Records
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
Re: Outgoing SMTP Servers
On Mon, Oct 31, 2011 at 6:23 AM, Brian Johnson bjohn...@drtel.com wrote: For clarity it's really bad for ISPs to block ports other than 25 for the purposes of mail flow control... correct? Yes, correct. If you're using another mail submission port, you're connecting to a mail service that has the responsibility not to let spam escape, and your ISP has done its job of stopping point-source pollution. BillI've got a strong preference for ISPs to run a BillBlock-25-by-default/Enable-when-asked. [...] This is, of course, exactly why this blocking is done. It looks like you're missing half my point, which is the Enable-when-asked part. There are users who are perfectly legitimately running MTAs at home, whether for reliability or privacy (e.g. so they can run SMTP-over-TLS end-to-end) or just simplicity, and ISPs shouldn't be blocking them (unless they're spammers, of course.) My take on this is that it IS best practice to have users use the submission port (587) for mail submission from the MUA to an MTA. If you're running an MTA service, then yes. If you're running a transport service, then not necessarily. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
