trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Carroll <solidwallofc...@yahoo-inc.com>
Subject Re: Weird DNS issue "failover" issue
Date Tue, 24 Mar 2015 19:01:15 GMT
You could also turn on the "dns" debug tag.
 


     On Tuesday, March 24, 2015 1:31 PM, Jason Strongman <jasonstrongman2016@gmail.com>
wrote:
   

 the system trace will tell you where ATS is grabbing the name servers
in question. its brute force in that you are capturing all the open
and read calls.. then parsing those calls for the name servers seen in
the error log. once you find where the name servers are coming from,
you can work on resolution from that point.



On Tue, Mar 24, 2015 at 12:09 PM, Jason J. W. Williams
<jasonjwwilliams@gmail.com> wrote:
> Thanks Jason. Is there anyway to query ATS to dump which resolvers it thinks it's using?
>
> Also does that error only apply to queries to the resolvers?
>
> -J
>
> Sent via iPhone
>
>> On Mar 24, 2015, at 9:45, Jason Strongman <jasonstrongman2016@gmail.com> wrote:
>>
>> if you can reproduce this on the fly, maybe try fleshing it out via a
>> system call tracer.
>> so stop ATS, then start ATS accompanied by a system call tracer..
>> something like strace..
>>
>> make sure to pass the -f and '-s 10000' arguments to strace. -f
>> follows child processes and -s defines the max string size to capture.
>>
>> once ATS starts reporting this DNS error, stop the trace, then run
>> through the output file. you will then see where the DNS servers are
>> defined.  thats my brute force way of approaching things.
>>
>>
>> On Sun, Mar 22, 2015 at 2:34 AM, Jason J. W. Williams
>> <jasonjwwilliams@gmail.com> wrote:
>>> We just saw a bunch of "connection to DNS server 72.14.179.5 lost,
>>> move to 72.14.188.5" on one of our ATS instances:
>>>
>>> https://gist.github.com/williamsjj/f99e2a33d0beb27e63d8
>>>
>>> What confuses me is the server's resolv.conf is:
>>> nameserver 127.0.0.1
>>> nameserver 8.8.8.8
>>>
>>> So neither 72.14.179.5 nor 72.14.188.5 should be involved. Any advice
>>> is greatly appreciated.
>>>
>>> (I checked the records.config and proxy.config.dns.resolv_conf is set
>>> to the expected resolv.conf above)
>>>
>>> Any advice is appreciated.
>>>
>>> -J


  
Mime
View raw message