Egads!  Don't use microsoft.com for the queries without the option.

Use one or more sites with high availability.  yahoo.com comes to mind.

Every public site is down from time to time. What about checking more than 
one? Takes longer if DNS is really down but makes shure it's not only one site 
which failed. I'll attach a patch which tries three random domains from a 
larger list of sites with high availability. 

Created attachment 187 [details]
Patch against Dns.pm

Subject: Re: [SAdev]  is Net::DNS::Resolver unavailable? -> unreliable

bugzilla-daemon@hughes-family.org writes:

> Every public site is down from time to time. What about checking
> more than one? Takes longer if DNS is really down but makes shure
> it's not only one site which failed. I'll attach a patch which tries
> three random domains from a larger list of sites with high
> availability.

I like the idea someone had to have a configuration option that can
eliminate the need for the test.  Something like:

  # set to "yes" or "no" to avoid testing for DNS
  dns_available test

I haven't looked at the patch yet, but we only need one positive result
before moving on, and I think it's desireable for the testing be
non-random.  Try yahoo.com, then slashdot.org, then google.com, then
amazon.com, then ebay.com (or something like that, but always in the
same order so we can debug problems).

> I haven't looked at the patch yet, but we only need one positive result 
> before moving on, and I think it's desireable for the testing be 
> non-random.  Try yahoo.com, then slashdot.org, then google.com, then 
> amazon.com, then ebay.com (or something like that, but always in the 
> same order so we can debug problems). 
 
Have a look at the patch ;-) It stops if there is a positive result. So in 
most cases there will be only one test if DNS is available. 
 
It tries only three hosts because else it will take too long and if three well 
known sites aren't available it's very probably DNS being down. By picking 
random sites we assure that we have a pretty large test pool from which we 
choose and just in the case some day all three test sites are down (think 
DDoS) it fails only once and the next run is very likely to go without 
problems. The sites tested are printed when debugging. 

Ok, here comes a script to test all the domains for availability. 
 
I'll have a look how to implement Daniel's config setting tomorrow or the day 
after. Marc, does your proposed patch already contain something like this? 

Created attachment 188 [details]
tools/check_dnstestdomains

Malte, I like the idea of picking 3 sites out of 10 or so, but I also agree with
Dan that we should be able to override with an option.
I can take your patch and add a dns_available override, or you can add that
yourself. Your call (I should be able to work on it tonight)

I did not want to denigrate the config option. To be honest I really like it 
and think I'll set it to 'yes' when it's available :o) Please implement the 
option. Dan suggested a tristate option (I think):  
 
dns_available no   # don't do any DNS tests 
dns_available yes  # assume DNS to be available/don't test for it 
dns_available test # test if DNS is available (default) 
 
It could be extended (just an idea) to 
dns_available test:servername # test against server 'servername' 

Ok, I have a patch that should please everyone:

+=item dns_available { yes | test[: name1 name2...] | no }   (default: test)    
+                                                                               
+By default, SpamAssassin will query some default hosts on the internet to      
+attempt to check if DNS is working on not. The problem is that it can introduce
+some delay if your network connection is down, and in some cases it can wrongly
+guess that DNS is unavailable because the test connections failed.             
+SpamAssassin does have a set of 13 servers, among which 3 are picked randomly. 
+You can however specify your own list by specifying                            
+dns_available test: server1.tld server2.tld server3.tld 

Created attachment 194 [details]
Configuration option to decide if DNS is available or not, or should be autodetected

Nice one. Looks good. I already love it ;-) 

Note to CVS commiters:
The patch includes a looks like a null change to BEGIN import Hires, but it
actually removes a *lot* of whitespace that ended up there due to a copy and paste.

Spurious whitespace at line ends is my fault probably, due to the lame way copy/paste works in 
OSX Terminal windows.

I haven't been able to check CVS in a while. Was this applied (and should we
close the bug)?

looks like it never got in.  I've just committed it now, although I had
to make some fixes, as the "done" label had been deleted!  still, the rest
of the code looks OK ;)

fixed