Question

4.2.2.2 not responding to DNS queries

  • Posted on September 11, 2014
  • tdierksAsked by tdierks

By default, my droplet (Ubuntu 13.04 x64) was set up with two DNS servers in resolv.conf: 8.8.8.8 and 4.2.2.2. In debugging why my client requests to Twilio were slow or failing, I found out that host resolution was timing out half the time and eventually discovered that 4.2.2.2 is not responding to queries from my droplet:

dierks@sharkodile:~$ host api.twilio.com 4.2.2.2
;; connection timed out; no servers could be reached

It works from my desktop in my office:

~ $ host api.twilio.com 4.2.2.2
Using domain server:
Name: 4.2.2.2
Address: 4.2.2.2#53
Aliases: 
api.twilio.com is an alias for public-vip374d1ca4e.prod.twilio.com.
public-vip374d1ca4e.prod.twilio.com is an alias for ec2-174-129-254-101.compute-1.amazonaws.com.
ec2-174-129-254-101.compute-1.amazonaws.com has address 174.129.254.101

This could be specific to my droplet or to DO. It’s not a big concern for me (I just replaced 4.2.2.2 with 8.8.4.4 in my config; Level3 apparently doesn’t want the public using 4.2.2.2 in the first place), but I thought I’d see if anyone else was seeing this problem and possibly contribute if anyone else is trying to debug similar problems.


Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

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.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

For what it’s worth, we had an issue in PHP where curl was taking ages to do DNS lookups. This turned out to be the culprit.

New droplets should no longer be created with 4.2.2.2 in resolv.conf We encourage users that have an older droplet with it still there to replace it with 8.8.4.4 like you’ve already done.