On 16 Sep 2008, at 22:04, Joe Abley wrote: > but > > [monster:~]% dig @127.0.0.1 nanog.org mx > > ; <<>> DiG 9.4.2 <<>> @127.0.0.1 nanog.org mx > ; (1 server found) > ;; global options: printcmd > ;; connection timed out; no servers could be reached > [monster:~]% > > fails, consistently. And now it's working again: [monster:~]% dig @127.0.0.1 nanog.org mx ; <<>> DiG 9.4.2 <<>> @127.0.0.1 nanog.org mx ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59427 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2 ;; QUESTION SECTION: ;nanog.org. IN MX ;; ANSWER SECTION: nanog.org. 1550 IN MX 0 s0.nanog.org. ;; AUTHORITY SECTION: nanog.org. 13747 IN NS dns1.merit.net. nanog.org. 13747 IN NS dns2.merit.net. nanog.org. 13747 IN NS dns3.merit.net. ;; ADDITIONAL SECTION: s0.nanog.org. 14150 IN A 198.108.95.20 s0.nanog.org. 14150 IN AAAA 2001:48a8:6880:95::20 ;; Query time: 49 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Sep 17 02:10:43 2008 ;; MSG SIZE rcvd: 156 [monster:~]% Arrgh. So, perhaps I should rephrase the question. Since I appear to have intermittent periods during which MX queries are timing out for no apparent reason, what instrumentation can I usefully put in place to try and figure out what is going on? I could easily trigger data collection from a process watching the exim log for lookup failures, for example, but I don't really know what to collect. Joe