------------ Original Message ------------ > Date: Tuesday, July 15, 2014 18:39:58 -0700 > From: Quanah Gibson-Mount <qua...@zimbra.com> > To: users@spamassassin.apache.org > Subject: Re: Dealing with a bad network device affecting DNS lookups > > --On Wednesday, July 16, 2014 2:26 AM +0000 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 you use "dig" (which includes >> the query time by default) with options like "+trace" so that you >> can see what's really going on and how long it's taking at each >> stage of the lookup. >> >> You may have done this in the past, but the results output you >> included in this thread didn't do much to convince me that this >> was a Rackspace issue, rather than simply slow remote-end (e.g., >> yahoo) dns servers. > > It happens with *every* remote lookup the first time a domain is > queried. It won't occur again for that domain until the cache > expires on our local DNS. That was simply AN example of a domain > I knew was likely to not be cached, since no one uses > www.alltheweb.com anymore. ;) dig also returns NXDOMAIN on the > first lookup. > > Here's a totally different domain, with dig: > > [quanah@mbs01 ~]$ time dig git-master.openldap.org +trace > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> > git-master.openldap.org +trace > ;; global options: +cmd > . 339646 IN NS g.root-servers.net. > . 339646 IN NS l.root-servers.net. > . 339646 IN NS b.root-servers.net. > . 339646 IN NS a.root-servers.net. > . 339646 IN NS f.root-servers.net. > . 339646 IN NS h.root-servers.net. > . 339646 IN NS c.root-servers.net. > . 339646 IN NS i.root-servers.net. > . 339646 IN NS j.root-servers.net. > . 339646 IN NS e.root-servers.net. > . 339646 IN NS m.root-servers.net. > . 339646 IN NS k.root-servers.net. > . 339646 IN NS d.root-servers.net. > ;; Received 508 bytes from 10.110.0.108#53(10.110.0.108) in 15 ms > > org. 172800 IN NS a2.org.afilias-nst.info. > org. 172800 IN NS b0.org.afilias-nst.org. > org. 172800 IN NS b2.org.afilias-nst.org. > org. 172800 IN NS c0.org.afilias-nst.info. > org. 172800 IN NS a0.org.afilias-nst.info. > org. 172800 IN NS d0.org.afilias-nst.org. > ;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 15071 ms > > openldap.org. 86400 IN NS ns5.he.net. > openldap.org. 86400 IN NS ns4.he.net. > openldap.org. 86400 IN NS ns1.he.net. > openldap.org. 86400 IN NS ns3.he.net. > openldap.org. 86400 IN NS ns2.he.net. > ;; Received 137 bytes from 199.19.53.1#53(199.19.53.1) in 10040 ms > > git-master.openldap.org. 300 IN CNAME euler.openldap.org. > euler.openldap.org. 300 IN A 23.92.27.229 > ;; Received 77 bytes from 216.218.130.2#53(216.218.130.2) in 10 ms >
The timing on the final lookup: git-master.openldap.org. 300 IN CNAME euler.openldap.org. euler.openldap.org. 300 IN A 23.92.27.229 ;; Received 77 bytes from 216.218.130.2#53(216.218.130.2) in 10 ms doesn't really seem to support your overall theory that there is something blocking/slowing your queries. The timing on the two intermediate ones are rather high (the answers for the first/root-servers query should be stapled into your dns server) so I would look into this a bit further to see if it's generally the intermediate lookups that are slow, and why. Is your dns server configured to think it is IPv6 capable, but isn't really -- hence causing timeouts when trying to use IPv6 addresses? - Richard [I am on the list, so please do not include my address in replies.]
