At 12:35 PM 12/26/01, Chuck Yerkes wrote: >Quoting Daniel Senie ([EMAIL PROTECTED]): > > At 02:20 PM 12/25/01, Chuck Yerkes wrote: > > >30 seconds is almost always a wait for a DNS lookup. > > > > I've found that not to be the case. A 30 second delay will ONLY be DNS the > > first time. The DNS server near (or co-resident) with the server providing > > caching will cache either the positive or negative result. So, you might > > see a 30 second delay once, but if you then check your mail a second time > > and get another 30 second delay, that would point elsewhere. > >Except when that DNS lookup fails. Most DNS servers don't do >negative caching (storing failures).
That's sure news. They are supposed to do negative caching. The timeouts on negatives tend to be short, but if you don't do this, the world tends to go to hell. > When a connection comes >in, a lookup of the connecting IP address is done. Unfortunately, >too much of the Internet is not run by the competent any more, >and those lookups fail. My favorites are that 2.1.220.in-addr.arpa >(e.g.) will have NS servers that are unreachable. This will cause >a 30 second delay each time. > > > I've found the 30 second delay to be a telltale sign of IDENT > processing in > > XINETD. Indeed, in Xinetd, someone hard-coded 30 seconds as a timeout, and > > didn't even provide a way to alter that value. Removing USERID logging in > > your xinetd config will turn this off, give or take bugs in xinetd that > > seem to turn it back on. > >Dunno, don't really use Linux much. When I do, I build from >source (a BSD habit). I happily change the timeouts (it's the >point of using Open Source tools). > >To make this note actually *useful*, I'll suggest that when >facing this sort of problem, a useful tool to debug is to run >tcpdump (or a tool on top of that) on the segment, filtering >for the connecting network or host. You'll see that an IDENT >packet has gone out and, due to misconfigured firewalls, has >been dropped rather than rejected, causing delay. (we found >THAT with sendmail a lot, leading to the current sendmail >default timeout of 2s rather than 30s for ident packets). Another useful tidbit... Careful use of IPCHAINS or similar filtering can allow you to reject the outbound IDENT packet (reject == icmp response). In sendmail, I recofigure the timeout to zero, which results in sendmail NOT doing Ident. Ident is just not useful in the email world at this point. It only hurts, never helps. >Sniff the line, see what's going on. Run in debug mode and >watch. Remove portions of the system (inetd, qpopper, use >different clients) and see where the delay is introduced. ----------------------------------------------------------------- Daniel Senie [EMAIL PROTECTED] Amaranth Networks Inc. http://www.amaranth.com
