Count of DNS lookups

Hello, Is there a way to count and log the number of individual DNS lookups that Spamassassin does whilst processing an email? I'm really after just a number of the lookups requested, but a list of all the individual lookups types would be nice. Thanks. Skeffling.

Re: DNS lookups - bug with recursive lookups, or shoddy bind config?

On 04/01/2016 20:48, Joe Quinn wrote: By the way, have you considered subscribing to the dev@ list and contributing to SA? You ran through this issue pretty much perfectly, other than the bad luck with our Bugzilla's results on Google. Time is my main issue (that and being a rather rusty with p

Re: DNS lookups - bug with recursive lookups, or shoddy bind config?

On 1/4/2016 3:39 PM, Quanah Gibson-Mount wrote: --On Monday, January 04, 2016 8:28 PM + Chris J wrote: Before I raise this on Bugzilla, I just want to run this past people as I'm quite happy that I've failed to configure something, but can't see what. In short, RBL blacklists haven't bee

Re: DNS lookups - bug with recursive lookups, or shoddy bind config?

On 04/01/2016 20:39, Quanah Gibson-Mount wrote: If you're using Net::DNS 1.01 or later, you must patch SA. There is an entire thread dedicated to this issue.

Re: DNS lookups - bug with recursive lookups, or shoddy bind config?

--On Monday, January 04, 2016 8:28 PM + Chris J wrote: Before I raise this on Bugzilla, I just want to run this past people as I'm quite happy that I've failed to configure something, but can't see what. In short, RBL blacklists haven't been working and I've finally, with tcpdump, traced

DNS lookups - bug with recursive lookups, or shoddy bind config?

Before I raise this on Bugzilla, I just want to run this past people as I'm quite happy that I've failed to configure something, but can't see what. In short, RBL blacklists haven't been working and I've finally, with tcpdump, traced it to SpamAssassin not requesting recursive queries. The se

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

--On Wednesday, December 16, 2015 6:28 PM +0100 Mark Martinec wrote: Tried it now with 3.4.1 and Net::DNS 1.04. You still need to apply the patch from Bug 7223 (in addition to a patch from Bug 7231), then it passes all tests with Net::DNS 1.04 (even without patches from Bug 7265). Seems easi

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

Not sure about SPF. It's supposed to be fixed in the current 3.4 branch and in trunk, which is why I'm not seeing a problem with Net::DNS 1.03 or Net::DNS 1.04. Will check how the released version of 3.4.1 fares with Net::DNS 1.04 regarding SPF. The emergency patches were applied to FreeBSD ports,

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

--On Wednesday, December 16, 2015 4:13 PM + Ian Eiloart wrote: On 16 Dec 2015, at 16:09, Reindl Harald wrote: Am 16.12.2015 um 17:00 schrieb Ian Eiloart: On 16 Dec 2015, at 15:30, Kevin A. McGrail wrote: Downgrade tour netdns. There were changes in 1.03 that are fixed in trunk.

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

Ian Eiloart wrote: I had this problem after upgrading from a rather old version of SA. After upgrading to Net::DNS 1.04, the errors aren’t logged, but SpamAssassin isn’t finding SPF records. I wonder whether anyone can offer any suggestions. [...] Yesterday, I upgraded Net::DNS 1.03 to Net::D

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

On 12/16/2015 11:00 AM, Ian Eiloart wrote: On 16 Dec 2015, at 15:30, Kevin A. McGrail wrote: Downgrade tour netdns. There were changes in 1.03 that are fixed in trunk. Regards, KAM Downgrade? I upgraded to 1.04: does that not fix the problem? Are you running 3.4.1 or trunk? If trunk, 1.04 mig

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

On Wed, 16 Dec 2015 16:13:03 -, Ian Eiloart wrote: On 16 Dec 2015, at 16:09, Reindl Harald wrote: Am 16.12.2015 um 17:00 schrieb Ian Eiloart: On 16 Dec 2015, at 15:30, Kevin A. McGrail wrote: Downgrade tour netdns. There were changes in 1.03 that are fixed in trunk. Regards, K

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

> On 16 Dec 2015, at 16:09, Reindl Harald wrote: > > > > Am 16.12.2015 um 17:00 schrieb Ian Eiloart: >> >>> On 16 Dec 2015, at 15:30, Kevin A. McGrail wrote: >>> >>> Downgrade tour netdns. There were changes in 1.03 that are fixed in trunk. >>> Regards, >>> KAM >> >> Downgrade? I upgraded

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

only get SPF_NONE Weitergeleitete Nachricht Betreff: Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03 Datum: Wed, 16 Dec 2015 14:49:38 + Von: Ian Eiloart An: users@spamassassin.apache.org Hi, I had this problem after upgrading from a rather old version of SA

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

> On 16 Dec 2015, at 15:30, Kevin A. McGrail wrote: > > Downgrade tour netdns. There were changes in 1.03 that are fixed in trunk. > Regards, > KAM Downgrade? I upgraded to 1.04: does that not fix the problem? -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

gt; >got hit (1) > >And this is the relevant received header: > >Received: from mail-wm0-f53.google.com ([74.125.82.53]) by >karpinski.uscs.susx.ac.uk with esmtps (TLSv1:RC4-SHA:128) (Exim >4.76) >(envelope-from ) id NZEYTP-00019V-NS for >i...@sussex.ac.uk; &g

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

em there. Elsewhere, I see successful DNS lookups, eg: Dec 16 14:34:59.179 [4218] dbg: async: calling callback on key dns:MX:eiloart.com Dec 16 14:34:59.194 [4218] dbg: dns: hit 50 aspmx3.googlemail.com. Dec 16 14:34:59.195 [4218] dbg: dns: hit 10 aspmx.l.google.com. Dec 16 14:34

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

--On Tuesday, December 08, 2015 4:55 PM -0800 Quanah Gibson-Mount wrote: --On Friday, November 13, 2015 2:01 PM -0500 "Kevin A. McGrail" wrote: On 11/13/2015 2:00 PM, Mark Martinec wrote: To me, this is an incompatible documented change - not something one would expect in an 1.02 -> 1.03

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

--On Friday, November 13, 2015 2:01 PM -0500 "Kevin A. McGrail" wrote: On 11/13/2015 2:00 PM, Mark Martinec wrote: To me, this is an incompatible documented change - not something one would expect in an 1.02 -> 1.03 update. +1. An API change in a minor rev is not acceptable. Net::DNS 1.0

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

On 11/13/2015 2:00 PM, Mark Martinec wrote: To me, this is an incompatible documented change - not something one would expect in an 1.02 -> 1.03 update. +1. An API change in a minor rev is not acceptable. -- *Kevin A. McGrail* CEO Peregrine Computer Consultants Corporation 3927 Old Lee Highw

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

Net::DNS 1.03 breaks compatibility with SpamAssassin: DNS lookups no longer work, and warnings like the following pop up: On 2015-11-13 19:22, Quanah Gibson-Mount wrote: Well, IO::Socket::IP support is new in Net::DNS 1.03, but it is only used if IO::Socket::INET6 is not present. I would

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

--On Friday, November 13, 2015 10:22 AM -0800 Quanah Gibson-Mount wrote: Well, IO::Socket::IP support is new in Net::DNS 1.03, but it is only used if IO::Socket::INET6 is not present. I would assume you can use it as long as you have IO::Socket::INET6 installed, but I haven't tested that assu

Re: DNS lookups fail with SpamAssassin since Net::DNS 1.03

--On Friday, November 13, 2015 1:20 AM +0100 Mark Martinec wrote: Net::DNS 1.03 breaks compatibility with SpamAssassin: DNS lookups no longer work, and warnings like the following pop up: lookup failed: Can't locate object method "handles" via package "IO::Socket::IP

DNS lookups fail with SpamAssassin since Net::DNS 1.03

Net::DNS 1.03 breaks compatibility with SpamAssassin: DNS lookups no longer work, and warnings like the following pop up: lookup failed: Can't locate object method "handles" via package "IO::Socket::IP" at /usr/local/lib/perl5/site_perl/Net/DNS/Resolver/Base.pm l

Re: Dealing with a bad network device affecting DNS lookups

--On Wednesday, July 16, 2014 1:44 PM +0100 Martin Hepworth wrote: So whats the forwarder as it leaves your machine, a local DNS server, the appliance you think is in the way or Rackspace's DNS. If you can alter the overall forwarding so as it leaves your network can you make this google'

Re: Dealing with a bad network device affecting DNS lookups

ers@spamassassin.apache.org > > Subject: Re: Dealing with a bad network device affecting DNS > lookups > > > > --On Wednesday, July 16, 2014 2:26 AM + lists-spamassassin > > wrote: > > > >> I'm really not certain that using "time" and &

Re: Dealing with a bad network device affecting DNS lookups

Original Message > Date: Tuesday, July 15, 2014 18:39:58 -0700 > From: Quanah Gibson-Mount > To: users@spamassassin.apache.org > Subject: Re: Dealing with a bad network device affecting DNS lookups > > --On Wednesday, July 16, 2014 2:26 AM +

Re: Dealing with a bad network device affecting DNS lookups

On 16. jul. 2014 00.27.08 CEST, "Kevin A. McGrail" wrote: >> One manual lookup might work, but when a msg comes in, there's a >> little flood and your friends don't like it . >Or one of the recursion rate limiting patches... does not makes sense, this limit is not forceing interceptions, whatev

Re: Dealing with a bad network device affecting DNS lookups

On 15. jul. 2014 23.15.30 CEST, Quanah Gibson-Mount wrote: >*sigh* I DO already. That still does not prevent FIRST TIME LOOKUPS >from failing. if thats correct postfix would try one more time since dns on the sender dns server domain reject dns resolving on there sender domain dont shut the po

Re: Dealing with a bad network device affecting DNS lookups

On 15. jul. 2014 23.09.55 CEST, Quanah Gibson-Mount wrote: >> DNS requests should takes less that 1 sec. 1 sec is slow imho :) >The problem isn't the DNS requests. The problem is the appliance that >is INTERCEPTING THE REQUESTS ON THE WAY OUT. ask them about dnssec dig +trace debian.org foll

Re: Dealing with a bad network device affecting DNS lookups

--On Wednesday, July 16, 2014 2:26 AM + lists-spamassassin wrote: I'm really not certain that using "time" and "nslookup" (which is a somewhat depreciated tool at this point) gives you results that show where the problem might be. I would suggest that for debugging/proof of issue purposes

Re: Dealing with a bad network device affecting DNS lookups

Original Message > Date: Tuesday, July 15, 2014 15:04:22 -0700 > From: Quanah Gibson-Mount > To: Dave Warren , users@spamassassin.apache.org > Subject: Re: Dealing with a bad network device affecting DNS lookups > > --On Tuesday, July 15, 2014 3:52 PM

Re: Dealing with a bad network device affecting DNS lookups

On 7/15/2014 6:18 PM, Axb wrote: On 07/16/2014 12:04 AM, Quanah Gibson-Mount wrote: --On Tuesday, July 15, 2014 3:52 PM -0700 Dave Warren wrote: Are you saying that if you perform something like "dig @8.8.8.8 asdfalksdflk.example.com a", Rackspace intercepts the packet on port 53 and does som

Re: Dealing with a bad network device affecting DNS lookups

On 07/16/2014 12:04 AM, Quanah Gibson-Mount wrote: --On Tuesday, July 15, 2014 3:52 PM -0700 Dave Warren wrote: Are you saying that if you perform something like "dig @8.8.8.8 asdfalksdflk.example.com a", Rackspace intercepts the packet on port 53 and does something with it? Right And it's

Fwd: Dealing with a bad network device affecting DNS lookups

(Accidentally off list, sorry) Begin forwarded message: > From: Dominic Benson > Date: 15 July 2014 22:59:14 BST > To: Quanah Gibson-Mount > Subject: Re: Dealing with a bad network device affecting DNS lookups > > >> On 15 Jul 2014, at 22:46, Quanah Gibson-Mount wr

Re: Dealing with a bad network device affecting DNS lookups

--On Tuesday, July 15, 2014 3:52 PM -0700 Dave Warren wrote: Are you saying that if you perform something like "dig @8.8.8.8 asdfalksdflk.example.com a", Rackspace intercepts the packet on port 53 and does something with it? Right And it's taken them since October to resolve it? And you st

Re: Dealing with a bad network device affecting DNS lookups

On 2014-07-15 14:46, Quanah Gibson-Mount wrote: I've been complaining about it since last October. Supposedly it will be fixed by the end of this month. In the meantime, I still have floods of spam coming in that I'd like scored correctly. Are you saying that if you perform something like "d

Re: Dealing with a bad network device affecting DNS lookups

On 2014-07-15 14:40, John Hardin wrote: On Tue, 15 Jul 2014, Martin Hepworth wrote: On Tuesday, 15 July 2014, Quanah Gibson-Mount wrote: --On Wednesday, July 16, 2014 12:08 AM +0200 Axb wrote: and what's prevents you from running a recursor on those servers? In a halfway well connected n

Re: Dealing with a bad network device affecting DNS lookups

--On Tuesday, July 15, 2014 3:41 PM -0700 John Hardin wrote: On Tue, 15 Jul 2014, Quanah Gibson-Mount wrote: --On Wednesday, July 16, 2014 12:12 AM +0200 Axb wrote: And what appliance is that? No idea. Again, I don't run the network and what's on it. Whatever it is, if it breaks yo

Re: Dealing with a bad network device affecting DNS lookups

On Tue, 15 Jul 2014, Quanah Gibson-Mount wrote: --On Wednesday, July 16, 2014 12:12 AM +0200 Axb wrote: And what appliance is that? No idea. Again, I don't run the network and what's on it. Whatever it is, if it breaks your DNS traffic, trash it. I have no control over it or its usag

Re: Dealing with a bad network device affecting DNS lookups

On Tue, 15 Jul 2014, Martin Hepworth wrote: On Tuesday, 15 July 2014, Quanah Gibson-Mount wrote: --On Wednesday, July 16, 2014 12:08 AM +0200 Axb wrote: and what's prevents you from running a recursor on those servers? In a halfway well connected network, and Rackpace is VERY well connec

Re: Dealing with a bad network device affecting DNS lookups

Then I think we can all agree that just extending the timeout is not a fix. You have network issues that should be resolved. -- Jeremy McSpadden Flux Labs | http://www.fluxlabs.net | Endless Solutions Office : 850-250-5590x501 | Cell : 850-890-2543 | Fax : 850-254-2955

Re: Dealing with a bad network device affecting DNS lookups

--On Wednesday, July 16, 2014 12:12 AM +0200 Axb wrote: And what appliance is that? No idea. Again, I don't run the network and what's on it. Whatever it is, if it breaks your DNS traffic, trash it. I have no control over it or its usage or presence. --Quanah -- Quanah Gibson-Mount S

Re: Dealing with a bad network device affecting DNS lookups

--On Tuesday, July 15, 2014 11:13 PM +0100 Martin Hepworth wrote: Run your own caching server on the sa box itself, makes a surprising difference and something I always reconmend  *sigh* I DO already. That still does not prevent FIRST TIME LOOKUPS from failing. --Quanah -- Quanah Gibso

Re: Dealing with a bad network device affecting DNS lookups

On Tuesday, 15 July 2014, Quanah Gibson-Mount wrote: > --On Wednesday, July 16, 2014 12:08 AM +0200 Axb > wrote: > > > and what's prevents you from running a recursor on those servers? >> >> In a halfway well connected network, and Rackpace is VERY well connected, >> DNS requests should takes l

Re: Dealing with a bad network device affecting DNS lookups

On 07/15/2014 11:09 PM, Quanah Gibson-Mount wrote: --On Wednesday, July 16, 2014 12:08 AM +0200 Axb wrote: and what's prevents you from running a recursor on those servers? In a halfway well connected network, and Rackpace is VERY well connected, DNS requests should takes less that 1 sec.

Re: Dealing with a bad network device affecting DNS lookups

--On Wednesday, July 16, 2014 12:08 AM +0200 Axb wrote: and what's prevents you from running a recursor on those servers? In a halfway well connected network, and Rackpace is VERY well connected, DNS requests should takes less that 1 sec. The problem isn't the DNS requests. The problem is

Re: Dealing with a bad network device affecting DNS lookups

On 07/15/2014 10:58 PM, Quanah Gibson-Mount wrote: --On Tuesday, July 15, 2014 9:51 PM + Jeremy McSpadden wrote: Have you considered running your own DNS server locally ? I do. ;) But I don't run the network (our servers are hosted @ Rackspace), and any outbound DNS request hits the ne

Re: Dealing with a bad network device affecting DNS lookups

--On Tuesday, July 15, 2014 10:00 PM + Jeremy McSpadden wrote: Run a DNS server on your rack space servers. If your using rack space DNS your rbl queries are more than likely going to cause quite a few FPs. Never good to use ISP or hosting DNS servers. As I said... I *already* run my ow

Re: Dealing with a bad network device affecting DNS lookups

--On Tuesday, July 15, 2014 9:51 PM + Jeremy McSpadden wrote: Have you considered running your own DNS server locally ? I do. ;) But I don't run the network (our servers are hosted @ Rackspace), and any outbound DNS request hits the network appliance, so my own DNS doesn't help with

Re: Dealing with a bad network device affecting DNS lookups

uot; mailto:qua...@zimbra.com>> wrote: Hi, Apparently there is a network device somewhere on the network my production servers use that is causing very long delays with first time DNS lookups. This is having a significant impact on SA's ability to score spam, as the various RBL lookups

Dealing with a bad network device affecting DNS lookups

Hi, Apparently there is a network device somewhere on the network my production servers use that is causing very long delays with first time DNS lookups. This is having a significant impact on SA's ability to score spam, as the various RBL lookups time out, as well as Razor and Pyzor.

OT: RBL for dynamic "no reverse DNS" lookups

OT: RBL for dynamic "no reverse DNS" lookups I'm trying to find an RBL which will return a standard RBL return code (like "127.0.0.2") if/when the IP passed to the RBL doesn't have a reverse DNS entry. (1) I know that SA doesn't have a need for this as another

Re: DNS lookups

On Thursday, June 9, 2005, 11:00:50 PM, Bob Proulx wrote: > Kenneth Porter wrote: >> Bob Proulx wrote: >> > In both cases you would need to modify /etc/resolv.conf to use the >> > local nameserver instead of the current one. >> >> Wiki fodder? > Good point. Okay, here is the initial page with th

Re: DNS lookups

Kenneth Porter wrote: > Bob Proulx wrote: > > In both cases you would need to modify /etc/resolv.conf to use the > > local nameserver instead of the current one. > > Wiki fodder? Good point. Okay, here is the initial page with the above information. http://wiki.apache.org/spamassassin/Caching

Re: DNS lookups

* Jon Dossey <[EMAIL PROTECTED]>: > You'd "hack" SA instead of just installing bind, and letting it just > cache the response? Or djbdns... > Talk about wagging the dog ... Indeed -- Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED] Charite - Universitätsmedizin Berlin

Re: DNS lookups

From: "Ronan McGlue" <[EMAIL PROTECTED]> > Matt Kettler wrote: > > At 08:32 AM 6/9/2005, Ronan McGlue wrote: > > > >> anyclues as to why SA isnt 'apparently' using the hosts file?? > > > > > > This is because SA doesn't use the system resolver, it uses Net::DNS's > > resolver. This gives SA a lot

Re: DNS lookups

From: "Jeff Chan" <[EMAIL PROTECTED]> > On Thursday, June 9, 2005, 5:32:23 AM, Ronan McGlue wrote: > > Niek wrote: > >> On 6/9/2005 2:19 PM +0200, Ronan McGlue wrote: > >> > >>> sry should have added that the DNS order in /etc/resolv.conf is also > >>> correct... > >> > >> > >> What order ? Th

Re: DNS lookups

>... >On Thursday, June 9, 2005, 5:32:23 AM, Ronan McGlue wrote: >> Niek wrote: >>> On 6/9/2005 2:19 PM +0200, Ronan McGlue wrote: >>> sry should have added that the DNS order in /etc/resolv.conf is also correct... >>> >>> >>> What order ? The nameservers are used randomly... >> again

Re: DNS lookups

--On Thursday, June 09, 2005 10:25 AM -0600 Bob Proulx <[EMAIL PROTECTED]> wrote: Kenneth Porter wrote: If it's a Red Hat system (including Fedora), just install the caching-nameserver RPM. It pulls in BIND and installs appropriate config files. Then edit resolv.conf to point to localhost. I

Re: DNS lookups

Kenneth Porter wrote: > If it's a Red Hat system (including Fedora), just install the > caching-nameserver RPM. It pulls in BIND and installs appropriate config > files. Then edit resolv.conf to point to localhost. If it is a Debian system just install bind9 and the default configuration is a ca

Re: DNS lookups

Jon Dossey wrote: > > You'd "hack" SA instead of just installing bind, and letting it just > cache the response? Yes, although that would be rather ugly, and probably much harder to implement than installing a caching nameserver. You also wouldn't reap all the benefits that a local caching names

Re: DNS lookups

--On Thursday, June 09, 2005 11:03 AM -0400 Steven Dickenson <[EMAIL PROTECTED]> wrote: We run bind with no zones on our SA gateway to serve as a DNS cache. Helps take a load off DNS lookups for common hosts. You can easily do this with any other DNS daemon as well. Google for c

Re: DNS lookups

y i can hack it?? *goes off to read CPAN*... We run bind with no zones on our SA gateway to serve as a DNS cache. Helps take a load off DNS lookups for common hosts. You can easily do this with any other DNS daemon as well. Google for caching nameserver. - S

RE: DNS lookups

> Matt Kettler wrote: > > At 08:32 AM 6/9/2005, Ronan McGlue wrote: > > > >> anyclues as to why SA isnt 'apparently' using the hosts file?? > > > > > > This is because SA doesn't use the system resolver, it uses Net::DNS's > > resolver. This gives SA a lot of control over queries, but doesn't take

Re: DNS lookups

Matt Kettler wrote: At 08:32 AM 6/9/2005, Ronan McGlue wrote: anyclues as to why SA isnt 'apparently' using the hosts file?? This is because SA doesn't use the system resolver, it uses Net::DNS's resolver. This gives SA a lot of control over queries, but doesn't take advantage of things li

Re: DNS lookups

At 08:32 AM 6/9/2005, Ronan McGlue wrote: anyclues as to why SA isnt 'apparently' using the hosts file?? This is because SA doesn't use the system resolver, it uses Net::DNS's resolver. This gives SA a lot of control over queries, but doesn't take advantage of things like /etc/hosts, and onl

Re: DNS lookups

Victor Brilon wrote: --- Ronan McGlue <[EMAIL PROTECTED]> wrote: yes, but BIND isnt running on the machine in question... (atm) The nets guys here are seeing a lot of lookups from this SPAMD machine for our mailhubs to the Local dns... which is an extra couple of miliseconds i want to avoid

Re: DNS lookups

Jeff Chan wrote: On Thursday, June 9, 2005, 5:32:23 AM, Ronan McGlue wrote: Niek wrote: On 6/9/2005 2:19 PM +0200, Ronan McGlue wrote: sry should have added that the DNS order in /etc/resolv.conf is also correct... What order ? The nameservers are used randomly... again, my semantics

Re: DNS lookups

On Thursday, June 9, 2005, 5:32:23 AM, Ronan McGlue wrote: > Niek wrote: >> On 6/9/2005 2:19 PM +0200, Ronan McGlue wrote: >> >>> sry should have added that the DNS order in /etc/resolv.conf is also >>> correct... >> >> >> What order ? The nameservers are used randomly... > again, my semantics

Re: DNS lookups

Niek wrote: On 6/9/2005 2:19 PM +0200, Ronan McGlue wrote: sry should have added that the DNS order in /etc/resolv.conf is also correct... What order ? The nameservers are used randomly... again, my semantics need work... :S the DNS *is in* order in /etc/resolv.conf... anyclues as to why

Re: DNS lookups

On 6/9/2005 2:19 PM +0200, Ronan McGlue wrote: sry should have added that the DNS order in /etc/resolv.conf is also correct... What order ? The nameservers are used randomly... Niek Baakman

Re: DNS lookups

Niek wrote: On 6/9/2005 2:15 PM +0200, Ronan McGlue wrote: hi SA is continually looking up my 3 mailhubs to our local DNS even though i have them hardcoded into /etc/hosts and /etc/nsswitch.conf is configured properly etc etc... How can I make SA use the hosts file if such an option exists

Re: DNS lookups

On 6/9/2005 2:15 PM +0200, Ronan McGlue wrote: hi SA is continually looking up my 3 mailhubs to our local DNS even though i have them hardcoded into /etc/hosts and /etc/nsswitch.conf is configured properly etc etc... How can I make SA use the hosts file if such an option exists... anyone el

DNS lookups

hi SA is continually looking up my 3 mailhubs to our local DNS even though i have them hardcoded into /etc/hosts and /etc/nsswitch.conf is configured properly etc etc... How can I make SA use the hosts file if such an option exists... anyone else notice this behaviour?? ronan --