0

I had some failing API calls in a mobile client. In order to investigate, I followed Joseph Scott's advice and executed curl with a few debugging parameters:

The results from the Amazon EC2 server:

        time_namelookup:  0.011
           time_connect:  0.011
        time_appconnect:  0.016
       time_pretransfer:  0.027
          time_redirect:  0.000
     time_starttransfer:  0.049
                        ----------
             time_total:  0.049

The results from a laptop (in Israel):

        time_namelookup:  5.004
           time_connect:  5.264
        time_appconnect:  5.851
       time_pretransfer:  5.851
          time_redirect:  0.000
     time_starttransfer:  6.188
                        ----------
             time_total:  6.188

My resolv.conf:

#
# Mac OS X Notice
#
# This file is not used by the host name and address resolution
# or the DNS query routing mechanisms used by most processes on
# this Mac OS X system.
#
# This file is automatically generated.
#
nameserver 192.168.0.1

Other details:

  1. The TTL is 300.
  2. The high time_namelookup does not change after a few consecutive calls, so it's not a local cache issue.
  3. The problem happens both with CNAME and A records.
  4. dig returns instantly.

Any idea why the time_namelookup takes so long?

Update

When I execute the same command in a different wireless network, I get the following:

        time_namelookup:  0.003
           time_connect:  0.273
        time_appconnect:  2.189
       time_pretransfer:  2.189
          time_redirect:  0.000
     time_starttransfer:  3.200
                        ----------
             time_total:  3.201

This probably means that the long time_namelookup was indeed a firewall issue. Thanks to everybody who helped!

Adam Matan
  • 13,194
  • 19
  • 55
  • 75

2 Answers2

3

The fact that the timeout is five seconds long could be significant. Some applications (but notably not dig) use getaddrinfo() instead of gethostbyname(); the former, if called with certain arguments, will wait for both IPv4 and IPv6 responses, while the latter will return immediately an IPv4 reply is received. The default timeout for getaddrinfo() in this case is five seconds.

We really need a tcpdump trace of port 53 traffic from the errant client's point of view to see what's going on. I recently tackled a problem like this, and it turned out that a firewall was blocking one of the reply packets.

Community
  • 1
Flup
  • 7,978
  • 2
  • 32
  • 43
  • A search here on SF could have [saved you some trouble](http://serverfault.com/a/411178/126632) :) – Michael Hampton Jul 10 '14 at 12:42
  • Heh, if I'd have known about the Juniper from the outset then yes, probably, but I doubt I would have found that question with what I had to go on at the start. There really are no new problems :) – Flup Jul 10 '14 at 13:09
1

This is macosx, i see this in your resolv.conf dump. this file is used for compatibility. does nameserver 192.168.0.1 work properly? behavior points me, it is not working and proces timeouts with dns contact. other, 192.168.0.1 is local ip in unroutable ip class (not routed over Internet). this should be any local cache dns server. this is working? Have you tested it by nslookup ?

another point, on macosx you have /etc/resolver/* files. maybe one tool gets config from resolv.conf and waits for timeout, and another tool gets it from /etc/resolver/* file. look what is configured in that file. maybe you should update configuration, specially inside resolv.conf . don't edit this manually (as described inside comment), do any macosx tool.

I found some recipe with dns resolving, but i'm not sure it suits to you: http://www.justincarmony.com/blog/2011/07/27/mac-os-x-lion-etc-hosts-bugs-and-dns-resolution/ but maybe this helps you.

Znik
  • 348
  • 1
  • 3
  • 12