Date: Tue, 22 Oct 2002 14:26:20 -0400 From: Doug Lee <dgl@visi.com> To: freebsd-questions@freebsd.org Subject: ISP DNS blocking?! (was Re: fetchmail protocol error caused by DNS timeout - solution?) Message-ID: <20021022182620.GA16676@kirk.dlee.org> In-Reply-To: <20021021125344.GM586@kirk.dlee.org> References: <20021020215055.GA586@kirk.dlee.org> <20021020215847.GA936@kirk.dlee.org> <20021021111020.GC27016@happy-idiot-talk.infracaninophi> <20021021125344.GM586@kirk.dlee.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Summary of problem: Some emails that show up in my mailbox at my ISP come from addresses for which I can't get DNS, and for which trying to get DNS info causes a long delay and a timeout--but a long enough delay to cause my fetchmail retrievals to die with a protocol error and thus leave all later messages at my ISP, uncollected. I've tried several suggestions from this list but found nothing that works all the time... but just now, I figured out that at least some of my DNS timeouts might be caused by my ISP, which is Verizon (DSL). Example: nslookup m13.shineandsparkle.com causes a delay/timeout on my box but returns DNS data when issued from the two other (non-Verizon-attached) boxes I tried. So my at least temporary solution was to add the ip of an apparently-nonblocked DNS server to the "Forwarders" list in /etc/namedb/named.conf and restart my local named process. Question: Why/how would my ISP limit my DNS queries, or does this signify either a broken ISP DNS server or some form of attempted spam blocking? Thanks much. The rest of this message is a copy of the older messages in this thread, which I summarized above. On Mon, Oct 21, 2002 at 08:53:44AM -0400, Doug Lee wrote: > I already have > > define(`confBIND_OPTS', `WorkAroundBrokenAAAA') > > in my .mc file. Not sure where this leaves me. > > Has anyone else here had this problem? > > On Mon, Oct 21, 2002 at 12:10:20PM +0100, Matthew Seaman wrote: > > On Sun, Oct 20, 2002 at 05:58:47PM -0400, Doug Lee wrote: > > > CORRECTION: It's not an rDNS lookup that's causing my problem; it's a > > > straight DNS lookup of the From: address, I think. Example: I just > > > spotted a message coming in from m7.shineandsparkle.com which plugged > > > up my ``fetchmail'' download (I have to go to the source mailbox and > > > hand-delete the thing to get the rest of them to come in by > > > fetchmail). Pinging m7.shineandsparkle.com causes a long pause > > > followed by > > > > > > ping: cannot resolve m7.shineandsparkle.com.: Host name lookup failure > > > > > > It appears that the same DNS lookup, when initiated by ``fetchmail,'' > > > is taking so long that the remote mail server gives up waiting, so > > > that when DNS finally quits trying, ``fetchmail'' issues a protocol > > > error, only to try again later and go through the same sequence. > > > > > > Also, this problem is not fixed by using my ISP's DNS server instead > > > of my own. > > > > I assume you're using fetchmail(1) to feed the mail into the > > sendmail(8) process on your own machine, which is likely the process > > initiating the DNS lookups that are stalling everything. > > > > One thing that may be biting you is IPv6 support in sendmail. As all > > good Unix programs should nowadays, it uses getaddrinfo(3) rather than > > gethostbyname(3) and it searches first for an AAAA record in the DNS. > > Usually the DNS server will respond very quickly that such a record > > doesn't exist and the next lookup will be for the IPv4 A record, which > > should succeed. Certain broken DNS servers however return the wrong > > code when queried for a resource record type they don't recognise, > > leading to delays similar to what you're seeing. > > > > Check your /etc/mail/`hostname`.mc file --- there's been a workaround > > for this problem in there since May this year, namely: > > > > define(`confBIND_OPTS', `WorkAroundBrokenAAAA') > > > > You can tweak the resolver timeouts used by sendmail(8): grep for > > 'confTO_RESOLVER' in /usr/share/sendmail/cf/README (DANGER Will > > Robinson! -- fiddling with resolver timeouts is not for the faint > > hearted). Other things that may bite you are ident queries, but those > > are set to timeout after 5s by default, so they shouldn't have the > > effect you're seeing. > > > > Cheers, > > > > Matthew > > > > -- > > Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks > > Savill Way > > Marlow > > Tel: +44 1628 476614 Bucks., SL7 1TH UK > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-questions" in the body of the message > > -- > Doug Lee dgl@visi.com http://www.visi.com/~dgl > Bartimaeus Group doug@bartsite.com http://www.bartsite.com > "If you refuse to be made straight when you are green, > you will not be made straight when you are dry." {African} -- Doug Lee dgl@visi.com http://www.visi.com/~dgl Bartimaeus Group doug@bartsite.com http://www.bartsite.com "Our chief want in life is somebody who will make us do what we can. {Ralph Waldo Emerson} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021022182620.GA16676>