It takes 10+ seconds for an HTTP request from my Droplet to another server to complete. I can confirm that it’s not an issue with poor application code, but something deeper at the networking level. Just running basic curl and outputting timings produces:
$ curl -w "@curl-timings" -o /dev/null -s google.com
time_namelookup: 10.044
time_connect: 10.045
time_appconnect: 0.000
time_pretransfer: 10.045
time_redirect: 0.000
time_starttransfer: 10.065
----------
time_total: 10.065
But as soon as you replace the domain name:
$ curl -w "@curl-timings" -o /dev/null -s 173.194.123.70
time_namelookup: 0.000
time_connect: 0.001
time_appconnect: 0.000
time_pretransfer: 0.001
time_redirect: 0.000
time_starttransfer: 0.039
----------
time_total: 0.039
This smells like something to do with how my Droplet is performing DNS lookup/resolution, but I don’t really know where to start looking or what to poke around at. Any help?
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Seems like the problem is that you are listing a resolver 4.2.2.2, which doesn’t want anything to do with your droplet. The delay you suffered were from every lookup first timing out on the first entry before moving on to the second.
Unless you have any particular reason for wanting to use 4.2.2.2, you might instead want to use both the Google resolvers in your resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
This comment has been deleted
Modified the file and moved Google’s DNS to the top and things are working better! I wonder what actually happened here though?
resolv.conf below, also a little weird that I can’t reach 4.2.2.2. 8.8.8.8 works fine and seems to be what’s actually being used.
What does your /etc/resolv.conf look like? If you run a
dig google.com
, from where does it say the response come? At the bottom, look for a line starting with;; SERVER:
.