Re: DNS timeout problem
Tony Houghton wrote: > Bob Proulx wrote: > > Check /etc/resolv.conf for nameserver entries and modify or > > change the file as needed to say 'nameserver 0.0.0.0' (okay to use > > 'nameserver 127.0.0.1' with modern software too). See the wiki page > > for general information. > > I hadn't heard of 0.0.0.0 being used instead of 127.0.0.1. Is that > specific to resolv.conf? The 0.0.0.0 address is interpreted by most TCP/IP OS implementations to mean the local host and will do the right thing. It can mostly be used interchangeably with 127.0.0.1 or any 127/8 address. The reason it became useful with the nameserver directive was that there was a bug in some Berkeley derived TCP/IP implementations that BIND would tickle. The resolver's connected datagram socket wouldn't rebind to a new local address and would "drag along" the previous 127.0.0.1 source address when switching to a new connection to the remote host. If the local name server was down the libc resolver would cycle to the next listed nameserver but end up sending a query with the bug of using the previous 127.0.0.1 address as the source address instead of the external IP address. In that case the remote nameserver would send a response back to themselves on the 127.0.0.1 address. Using 0.0.0.0 as the nameserver address avoided this bug when it was present on systems and also worked correctly on systems without the bug. Since it always worked everywhere the use of 0.0.0.0 was very common. This bug has probably been fixed for years now and so is unlikely to matter these days. But 0.0.0.0 always works and so why not use it? Bob
Re: DNS timeout problem
Nigel Kendrick wrote: Strangely enough I have been looking at why SA has suddenly started to act up and I also seem to be having DNS timeout issues after years of faultless operation. I am running a local caching nameserver, but spamassassin -D just stops dead as follows: Unless you hit ctrl+D to end the input its expecting from STDIN you'll be waiting forever. Daryl
Re: DNS timeout problem
Hm, it really is that easy. I've got used to this culture that complex packages won't do anything useful until configured so that's why I was reluctant to install bind, thinking it would take up a lot of time and effort. Anyway, it's helped. It seems to take about 5 seconds per message instead of over 10. It probably would have helped more if I didn't decide I might as well install pyzor, razor and dcc :-/. -- TH * http://www.realh.co.uk If you install pyzor, don't use the main server, use the mirror: http://marc.info/?l=spamassassin-users&m=117907371211470 _ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507
Re: DNS timeout problem
In <[EMAIL PROTECTED]>, Bob Proulx wrote: > For your Debian machine it is very easy with the following commands. > > $ sudo apt-get update > $ sudo apt-get install bind9 > > The default package configuration is a caching nameserver and the > above commands should be all that is needed to set up and configure it > this way. Hm, it really is that easy. I've got used to this culture that complex packages won't do anything useful until configured so that's why I was reluctant to install bind, thinking it would take up a lot of time and effort. > Check /etc/resolv.conf for nameserver entries and modify or > change the file as needed to say 'nameserver 0.0.0.0' (okay to use > 'nameserver 127.0.0.1' with modern software too). See the wiki page > for general information. I hadn't heard of 0.0.0.0 being used instead of 127.0.0.1. Is that specific to resolv.conf? > I highly recommend the 'resolvconf' package to coordinate the > automated editing of the /etc/resolv.conf file by the various > subsystems such as dhcp, dns, udev scripts, etc. I use static addresses and consider my connection permanent, so I'm probably better off without that. Anyway, it's helped. It seems to take about 5 seconds per message instead of over 10. It probably would have helped more if I didn't decide I might as well install pyzor, razor and dcc :-/. -- TH * http://www.realh.co.uk
RE: DNS timeout problem
Strangely enough I have been looking at why SA has suddenly started to act up and I also seem to be having DNS timeout issues after years of faultless operation. I am running a local caching nameserver, but spamassassin -D just stops dead as follows: [8808] dbg: logger: adding facilities: all [8808] dbg: logger: logging level is DBG [8808] dbg: generic: SpamAssassin version 3.2.1 [8808] dbg: config: score set 0 chosen. [8808] dbg: util: running in taint mode? yes [8808] dbg: util: taint mode: deleting unsafe environment variables, resetting PATH [8808] dbg: util: PATH included '/usr/kerberos/sbin', keeping [8808] dbg: util: PATH included '/usr/kerberos/bin', keeping [8808] dbg: util: PATH included '/usr/local/sbin', keeping [8808] dbg: util: PATH included '/usr/local/bin', keeping [8808] dbg: util: PATH included '/sbin', keeping [8808] dbg: util: PATH included '/bin', keeping [8808] dbg: util: PATH included '/usr/sbin', keeping [8808] dbg: util: PATH included '/usr/bin', keeping [8808] dbg: util: PATH included '/usr/X11R6/bin', keeping [8808] dbg: util: PATH included '/root/bin', which doesn't exist, dropping [8808] dbg: util: final PATH set to: /usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/b in:/usr/sbin:/usr/bin:/usr/X11R6/bin [8808] dbg: dns: no ipv6 [8808] dbg: dns: is Net::DNS::Resolver available? yes [8808] dbg: dns: Net::DNS version: 0.48 I have checked the version of Net::DNS installed and according to cpan I am up to date with version 0.6 so is there any relevance in the fact that the above output says it's using 0.48? That's it - I don't know if it's related to the OP's problem but any advice is welcomed. Thanks
Re: DNS timeout problem
Tony Houghton wrote: > Gary V wrote: > > Tony Houghton wrote: > > > Gary V wrote: > > > > What OS are you running? > > > > > > Linux. Sigh. > > Exactly which distrubution and version of that distribution? > > Sorry, Debian unstable amd64. Setting up a caching nameserver is documented for various operating systems on the SA wiki page. I also run Debian amd64. http://wiki.apache.org/spamassassin/CachingNameserver For your Debian machine it is very easy with the following commands. $ sudo apt-get update $ sudo apt-get install bind9 The default package configuration is a caching nameserver and the above commands should be all that is needed to set up and configure it this way. Check /etc/resolv.conf for nameserver entries and modify or change the file as needed to say 'nameserver 0.0.0.0' (okay to use 'nameserver 127.0.0.1' with modern software too). See the wiki page for general information. I highly recommend the 'resolvconf' package to coordinate the automated editing of the /etc/resolv.conf file by the various subsystems such as dhcp, dns, udev scripts, etc. $ sudo apt-get install resolvconf The resolvconf scripts run when the interface is brought online. Since the network will already be online when resolvconf is installed it won't do anything with /etc/resolv.conf at that moment but will rewrite that file the next time the networking for an interface is restarted. Especially for dhcp interfaces this nicely coordinates and wraps up the configuration so that the nameserver entries are updated automatically. > SA has been slow on it for ages; it's only recently I got fed that > up with it, mainly due to coming back from a holiday. It "works for me" on my Debian amd64 machine. (shrug) Bob
Re: DNS timeout problem
In <[EMAIL PROTECTED]>, Gary V wrote: > >Gary V wrote: > > > >> As mentioned twice, use a local caching DNS server (like bind for > >> example). Even if configured to forward requests to your ISP's DNS > >> server it may make a big difference. What OS are you running? > > > >Linux. > > Exactly which distrubution and version of that distribution? Sorry, Debian unstable amd64. SA has been slow on it for ages; it's only recently I got fed that up with it, mainly due to coming back from a holiday. -- TH * http://www.realh.co.uk
Re: DNS timeout problem
Gary V wrote: > As mentioned twice, use a local caching DNS server (like bind for example). > Even if configured to forward requests to your ISP's DNS server it may make > a big difference. What OS are you running? Linux. -- TH * http://www.realh.co.uk Exactly which distrubution and version of that distribution? _ Local listings, incredible imagery, and driving directions - all in one place! http://maps.live.com/?wip=69&FORM=MGAC01
Re: DNS timeout problem
In <[EMAIL PROTECTED]>, SM wrote: > At 06:10 07-07-2007, Tony Houghton wrote: > >SA used to kill a different router I used to have, but I don't think > >that's the problem here. I temporarily pointed /etc/resolv.conf to my > >ISP's servers and restarted spamd, which you'd expect to make at least > >some difference, but it didn't really. Besides, I can still freely > > Only if you expect the ISP's resolver to be better which isn't always the > case. I use a small reseller (ukfsn.org) of a large ISP (enta.net). Enta's support is better than average, and ukfsn also has its own servers for several critical services, including DNS, and you can actually get in contact with the person who runs them. I'm quite sure he's more capable of configuring bind than I am! -- TH * http://www.realh.co.uk
Re: DNS timeout problem
In <[EMAIL PROTECTED]>, Gary V wrote: > As mentioned twice, use a local caching DNS server (like bind for example). > Even if configured to forward requests to your ISP's DNS server it may make > a big difference. What OS are you running? Linux. -- TH * http://www.realh.co.uk
Re: DNS timeout problem
At 06:10 07-07-2007, Tony Houghton wrote: SA used to kill a different router I used to have, but I don't think that's the problem here. I temporarily pointed /etc/resolv.conf to my ISP's servers and restarted spamd, which you'd expect to make at least some difference, but it didn't really. Besides, I can still freely Only if you expect the ISP's resolver to be better which isn't always the case. Regards, -sm As mentioned twice, use a local caching DNS server (like bind for example). Even if configured to forward requests to your ISP's DNS server it may make a big difference. What OS are you running? Gary V _ http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507
Re: DNS timeout problem
At 06:10 07-07-2007, Tony Houghton wrote: SA used to kill a different router I used to have, but I don't think that's the problem here. I temporarily pointed /etc/resolv.conf to my ISP's servers and restarted spamd, which you'd expect to make at least some difference, but it didn't really. Besides, I can still freely Only if you expect the ISP's resolver to be better which isn't always the case. Regards, -sm
Re: DNS timeout problem
Tony Houghton wrote: > I switch my PC off overnight and I noticed the router would crash > shortly after switching it back on and deduced it was because of the > large volume of mail being fetched in one go. It was OK if I got my > PC to use my ISP's DNS instead. Strange. Frankly that just seems like buggy firmware in general. :-( > That seems to take about 5 seconds when given a new address, under 1.5s > when repeating one. Something is caching the answer then. Which is good in general. > spamassassin always takes over 10 secs. The debug output I posted > seems to say it is DNS timeouts. There's a whole load of activity to > start with, then it prints several messages which look like it's > waiting for the DNS queries to complete, then a load of messages > saying "dns: timeout", usually after 11 seconds. Maybe this is related to a quirk of perl's Net::DNS module? Theo Van Dinter recently wrote: > Net::DNS, which is what SA uses to call DNS, has been well known to > only use the first [nameserver] entry in resolv.conf, unfortunately. fyi. ?? Maybe... Bob
Re: DNS timeout problem
In <[EMAIL PROTECTED]>, Bob Proulx wrote: > Tony Houghton wrote: > > SA used to kill a different router I used to have, but I don't think > > that's the problem here. > > I don't see how even a low end router would have a problem with the > amount of data from DNS lookups that could be generated. It must have > been something else. I'm pretty sure it was that. I switch my PC off overnight and I noticed the router would crash shortly after switching it back on and deduced it was because of the large volume of mail being fetched in one go. It was OK if I got my PC to use my ISP's DNS instead. > > I temporarily pointed /etc/resolv.conf to my ISP's servers and > > restarted spamd, which you'd expect to make at least some > > difference, but it didn't really. Besides, I can still freely browse > > the web etc while SA is stalled on these lookups. > > You might want to try out one of the RBL check tools. > > http://rblcheck.wiki.sourceforge.net/ > > Basically 'rblcheck 208.77.188.166' and see how long that takes. It > is very similar to what SA would be doing internally. If that is slow > then you have a smaller problem to debug. If that is fast then SA's > dsn lookup is probably not your problem and you can look at other > things that might be running slowly. That seems to take about 5 seconds when given a new address, under 1.5s when repeating one. spamassassin always takes over 10 secs. The debug output I posted seems to say it is DNS timeouts. There's a whole load of activity to start with, then it prints several messages which look like it's waiting for the DNS queries to complete, then a load of messages saying "dns: timeout", usually after 11 seconds. -- TH * http://www.realh.co.uk
Re: DNS timeout problem
Tony Houghton wrote: > SA used to kill a different router I used to have, but I don't think > that's the problem here. I don't see how even a low end router would have a problem with the amount of data from DNS lookups that could be generated. It must have been something else. > I temporarily pointed /etc/resolv.conf to my ISP's servers and > restarted spamd, which you'd expect to make at least some > difference, but it didn't really. Besides, I can still freely browse > the web etc while SA is stalled on these lookups. You might want to try out one of the RBL check tools. http://rblcheck.wiki.sourceforge.net/ Basically 'rblcheck 208.77.188.166' and see how long that takes. It is very similar to what SA would be doing internally. If that is slow then you have a smaller problem to debug. If that is fast then SA's dsn lookup is probably not your problem and you can look at other things that might be running slowly. Bob
Re: DNS timeout problem
In <[EMAIL PROTECTED]>, SM wrote: > Hi Tony, > At 15:01 06-07-2007, Tony Houghton wrote: > >I just use the one built in to my ADSL router; I don't know whether it > >caches. The one it forwards to at my ISP is probably bind. > > The DNS server on your ADSL router is built for residential > usage. If you are going to do a lot of DNS queries, for example with > SpamAssassin, it is better to run a DNS server on the same computer > as SpamAssassin. SA used to kill a different router I used to have, but I don't think that's the problem here. I temporarily pointed /etc/resolv.conf to my ISP's servers and restarted spamd, which you'd expect to make at least some difference, but it didn't really. Besides, I can still freely browse the web etc while SA is stalled on these lookups. I think I'll just have to stop using SA on my own machine :-(. It's available at my ISP anyway; the only difference is I can't train it or fine-tune it (which I didn't really do anyway) there. -- TH * http://www.realh.co.uk
Re: DNS timeout problem
Hi Tony, At 15:01 06-07-2007, Tony Houghton wrote: I just use the one built in to my ADSL router; I don't know whether it caches. The one it forwards to at my ISP is probably bind. The DNS server on your ADSL router is built for residential usage. If you are going to do a lot of DNS queries, for example with SpamAssassin, it is better to run a DNS server on the same computer as SpamAssassin. Regards, -sm
Re: DNS timeout problem
In <[EMAIL PROTECTED]>, James D. Rallo wrote: > Are you running a local dns caching server? I just use the one built in to my ADSL router; I don't know whether it caches. The one it forwards to at my ISP is probably bind. > Do manual queries to rbls take a long time? (Hint: Don't run the query > again, as it may be cached up stream and may give a fast result.) I don't actually know how to do a manual query. I don't think there is any caching as far as SA is concerned because the timeouts are completely consistent. > You didn't attach your conf, but you may also want to set > dns_available yes > in your local.cf to save the dns check. That seemed to whizz past quite quickly compared to these timeouts. And I was only using the main spamassassin program to get the debugging; I usually use spamc and spamd so I doubt that runs the check for every message. -- TH * http://www.realh.co.uk
RE: DNS timeout problem
Are you running a local dns caching server? Do manual queries to rbls take a long time? (Hint: Don't run the query again, as it may be cached up stream and may give a fast result.) You didn't attach your conf, but you may also want to set dns_available yes in your local.cf to save the dns check. Thanks, James > -Original Message- > From: Tony Houghton [mailto:[EMAIL PROTECTED] > Sent: Friday, July 06, 2007 4:12 PM > To: users@spamassassin.apache.org > Subject: DNS timeout problem > > I'm having a problem with spamassassin taking ages due to DNS lookups > timing out. I could make the timeout shorter, but I'd rather try to find > out what it's failing on and stop it trying to do those lookups. I've > made a log of its debugging output (attached) but I don't understand it > well enough to be able to identify the problem correctly. I hope someone > here can help me. TIA. > > -- > TH * http://www.realh.co.uk
