I noticed a noticeable degrade in network performance in my droplets. It took forever to open a connection. It happened from last week I guess. Restart server does not help. I though it’s just temporary. However today I noticed that, DigitalOcean by default assign 2 DNS servers for every droplet in NYC2 region:

nameserver 4.2.2.2
nameserver 8.8.8.8

Here is the result for ping from my droplet to both servers:

tuananh@codepie:~$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=46 time=13.7 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=46 time=13.8 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=46 time=13.8 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=46 time=13.8 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=46 time=13.7 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=46 time=13.7 ms
64 bytes from 8.8.8.8: icmp_req=7 ttl=46 time=13.7 ms
64 bytes from 8.8.8.8: icmp_req=8 ttl=46 time=13.7 ms
64 bytes from 8.8.8.8: icmp_req=9 ttl=46 time=13.7 ms
64 bytes from 8.8.8.8: icmp_req=10 ttl=46 time=13.7 ms
^C
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9014ms
rtt min/avg/max/mdev = 13.705/13.774/13.883/0.147 ms
tuananh@codepie:~$ ping 4.2.2.2
PING 4.2.2.2 (4.2.2.2) 56(84) bytes of data.
^C
--- 4.2.2.2 ping statistics ---
167 packets transmitted, 0 received, 100% packet loss, time 167318ms

Performing dig returns similar problem:

tuananh@codepie:~$ dig google.com @4.2.2.2

; < <>> DiG 9.8.1-P1 < <>> google.com @4.2.2.2
;; global options: +cmd
;; connection timed out; no servers could be reached

As you can see, somehow my droplet won’t be able to connect to 4.2.2.2. A simple switch to 8.8.8.8 as main DNS resolver and thing’s back to normal.

DigitalOcean droplets (at least for NYC2 region) are having trouble connecting to 4.2.2.2
Tagged on:         

2 thoughts on “DigitalOcean droplets (at least for NYC2 region) are having trouble connecting to 4.2.2.2

Leave a Reply