------------ Original Message ------------
> Date: Tuesday, July 15, 2014 15:04:22 -0700
> From: Quanah Gibson-Mount <qua...@zimbra.com>
> To: Dave Warren <da...@hireahit.com>, users@spamassassin.apache.org
> Subject: Re: Dealing with a bad network device affecting DNS
lookups
>
> --On Tuesday, July 15, 2014 3:52 PM -0700 Dave Warren
> <da...@hireahit.com> 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 still pay for this service?
>> Or is there more going on than is immediately obvious here?
>
> I honestly don't blame Rackspace for this specific problem. It
> has more to do with the environment as ordered by our IT
> department, and getting them to understand why the environment
> as-is is a problem, has been the difficulty. That has finally
> been done.
>
> --Quanah
>
> --On Tuesday, July 15, 2014 3:52 PM -0700 Dave Warren
> <da...@hireahit.com> 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 still pay for this service?
>> Or is there more going on than is immediately obvious here?
>
> I honestly don't blame Rackspace for this specific problem. It
> has more to do with the environment as ordered by our IT
> department, and getting them to understand why the environment
> as-is is a problem, has been the difficulty. That has finally
> been done.
>
> --Quanah
>
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.
By the way, unless there's a serious lookup failure, a second query
(within the TTLs) will almost always give a quick reply since the
responses get cached -- just not in enough time to be displayed to
you.
- Richard
