dns: make always 8.8.8.8 in name servers

[yorkie]

This fixes #1644 by always using 8.8.8.8 as one of name servers.

/cc @johnthedebs @bnoordhuis @silverwind

[ChALkeR]

To me, this fix looks worse than the problem it tries to solve.

1. This is clearly not expected by the user. Expected would be to use system-wide dns servers by default and only those.
2. You could be on a network where 8.8.8.8 (or any other fixed dns server) is unreachable and this would produce unwanted queries to that server.
3. 8.8.8.8 (or any other fixed dns server) might be slow in some regions, far slower than the local dns.

[jbergstroem]

Not a fan of this approach. After reading #1644 this looks more like hiding the real issue.

[yorkie]

This is clearly not expected by the user. Expected would be to use system-wide dns servers by default and only those.

This patch just appends an optional 8.8.8.8 to servers, so there are no side-effects for any users, plus the c-ares also added 127.0.0.1. And yes, the 8.8.8.8 is not a system-wide dns, it doesn't work in all cases but only most.

You could be on a network where 8.8.8.8 (or any other fixed dns server) is unreachable and this would produce unwanted queries to that server.

This seems to be another problem IMO. in this patch, I fixed the issue, the name servers can't be updated when the instance is online from offline.

But I think when someone is going to deploy the app on the specific machine, he or she can make sure if 8.8.8.8 is working there.

The bug #1644 is caused by the default name servers set by c-ares is 127.0.0.1, as I have known so far, this address doesn't help anything.

8.8.8.8 (or any other fixed dns server) might be slow in some regions, far slower than the local dns.

This is actually a edge case, if you have own /etc/resove.conf then you will get the following servers:

> dns.getServers()
> ['192.168.1.1', '8.8.8.8']

That's why I use push function, c-ares will use the resolve.conf servers at first.

By the way, I thought fix this bug by syncing /etc/resolve.conf, but it consumes so many I/O resources in common cases, except we have a network trigger.

---

update: Okay, I see, then closing, thank you @ChALkeR @jbergstroem