What do you guys like for your /etc/resolv.conf?

Not_Oles

D-Existential and N-phenomenological S-investigations:

Who should Darkstar use to resolve DNA DNS requests? Why!?

Eeeks! We can get IPv6 addresses via DNS requests sent over IPv4, but don't we need an IPv6 address or two in our /etc/resolv.conf?

If the DNS system experienced "trouble," would we be better with a longer list of resolvers than two each IPv4 and IPv6? Back in the old days I remember seeing a long list which included, among other things, all of the DNS root servers. Perhaps sending DNS requests to the root servers might not work nowadays.

D-Mumbles, N-rumbles, S-tumbles

tom@darkstar:~$ cat /etc/resolv.conf
options single-request
search metalvps.com
nameserver 1.1.1.1
nameserver 1.0.0.1

tom@darkstar:~$ 

## Perhaps 20 times as long to ping 1.1.1.1 as 8.8.8.8? Really!!??

tom@darkstar:~$ date; time ping -c 2 1.1.1.1
Sat Dec 18 21:17:41 UTC 2021
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=21.2 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=21.2 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 21.221/21.226/21.231/0.005 ms

real    0m1.030s
user    0m0.004s
sys     0m0.001s
tom@darkstar:~$ date; time ping -c 2 8.8.8.8
Sat Dec 18 21:17:55 UTC 2021
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=0.952 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=0.872 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.872/0.912/0.952/0.040 ms

real    0m1.008s
user    0m0.003s
sys     0m0.001s
tom@darkstar:~$ 

References:

"Up to MAXNS (currently 3, see <resolv.h>) name servers may be listed, one per keyword. "
-- https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html

"DNS NSS improvement" "Add “single-request” to the options in /etc/resolv.conf. "
-- http://udrepper.livejournal.com/20948.html

yoursunny

Typically, I configure two resolvers.

• one IPv4 and one IPv6, unless the server is single stack and the other protocol is tunneled
• different providers, typically Google and Cloudflare; in case one of these has high latency, Quad9 or HE or Neustar may be substituted

dahartigan

I use 1.1.1.1 and 8.8.8.8 plus Google's ipv6 resolver.

No other fancy stuff he he

terrorgen

I use quad9 as well.

Google DNS might be in the same DC as your machine and Cloudflare somewhere further, therefore the difference between them.

cybertech

@dahartigan said:
I use 1.1.1.1 and 8.8.8.8 plus Google's ipv6 resolver.

No other fancy stuff he he

same here

vyas

@dahartigan said:
I use 1.1.1.1 and 8.8.8.8 plus Google's ipv6 resolver.

No other fancy stuff he he

You bring shame to the MJJ family.
No Ali/Tencent/Baidu resolvers.

bdl

@dahartigan said:
I use 1.1.1.1 and 8.8.8.8 plus Google's ipv6 resolver.

No other fancy stuff he he

dns.he.net?

Not_Oles

@bdl said:

@dahartigan said:
I use 1.1.1.1 and 8.8.8.8 plus Google's ipv6 resolver.

No other fancy stuff he he

dns.he.net?

This one I have to quote in full because of what he he he HE @bdl said. Hehe!

how

nameserver 8.8.8.8
nameserver 8.8.4.4

And disable IPv6

johnk

If the DNS system experienced "trouble," would we be better with a longer list of resolvers than two each IPv4 and IPv6?

Not really. Typically, 2, maybe 3 "large" providers are more than enough. Seems Google is fastest for your case, so I'd use that first, with Cloudflare/Q9, Cisco, as backup.

Perhaps sending DNS requests to the root servers might not work nowadays.

Not a good idea.

budi1413

1.1.1.1
9.9.9.9

bruh21

1.1.1.1 is good enough

mfs

If we are talking about servers (virtual or not), my resolv.conf usually includes just a
nameserver 127.0.0.1
which leads to a dnsdist service.
dnsdist may be configured to fetch results from your poison of choice (including 1.1.1.1, 9.9.9.9, 8.8.8.8 or whatever) or your local resolver; in the latter case your local named-chroot (or w/e) should pick a different privileged port on the listen-on port directive (if your resolver isn't on a remote box)(possibly not an open resolver)
For a while I played with alternative roots (it's quite sad to see that the ORSN domain has been squatted by someone else), some boxes still rely on OpenNIC Tier 1 servers for their main resolver
On my to-do list there's handshake DNS (maybe during holidays I'll give a more serious look); the famous public resolver nextdns.io is "Handshake domain"-compatible already

zxrlha

Usually I do not change DNS myself.
However, some VPS use cloudflare DNS which failed occasionally, so I changed them into 8.8.8.8

lukgth

8.8.8.8 and 9.9.9.9

CamoYoshi

I use DNSBench from GRC to test what are the fastest DNS servers on a given internet connection and use those. https://www.grc.com/dns/benchmark.htm

(Runs both on Windows and in WINE)

I also put into consideration the privacy policy for the DNS servers I will be using, as well.

My personal go-to favorite is Hurricane Electric's (74.82.42.42).

Not_Oles

@CamoYoshi said:
I use DNSBench from GRC to test what are the fastest DNS servers on a given internet connection and use those. https://www.grc.com/dns/benchmark.htm

(Runs both on Windows and in WINE)

I also put into consideration the privacy policy for the DNS servers I will be using, as well.

My personal go-to favorite is Hurricane Electric's (74.82.42.42).

Hi @CamoYoshi ! Nice to see you! Just for fun:

tom@darkstar:~$ ping -c 2 74.82.42.42
PING 74.82.42.42 (74.82.42.42) 56(84) bytes of data.
64 bytes from 74.82.42.42: icmp_seq=1 ttl=56 time=0.723 ms
64 bytes from 74.82.42.42: icmp_seq=2 ttl=56 time=0.735 ms

--- 74.82.42.42 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1018ms
rtt min/avg/max/mdev = 0.723/0.729/0.735/0.006 ms
tom@darkstar:~$ ping -c 2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=21.1 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=21.5 ms

--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 21.094/21.306/21.518/0.212 ms
tom@darkstar:~$ ping -c 2 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_seq=1 ttl=115 time=37.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=37.2 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 37.200/37.392/37.584/0.192 ms
tom@darkstar:~$ 

Friendly greetings from NYC and Sonora, MX! 🗽🇺🇸🇲🇽🏜️

Daniel

@Not_Oles said:

Perhaps 20 times as long to ping 1.1.1.1 as 8.8.8.8? Really!!??

Google likely colo some servers in the same data center.

In reality, you're really not going to notice the difference between 1ms and 21ms. The difference is only slightly longer than the time taken to render a single frame at 60fps (~16.6667ms). Generally humans don't notice anything less than ~40ms. Plus, any commonly accessed hosts will be in the local cache anyways.

jon617

For the first nameserver in /etc/resolv.conf, I typically use the provider's dns if they have one (most do not, these days). Then I ping each of the following and list them in order of quickest to slowest, up to 3.

google public dns - 8.8.8.8 or 2001:4860:4860::8888 with ipv6 support
cloudflare - 1.1.1.1
he - 74.82.42.42 or 2001:470:20::2

On rare occasions, I've had to use another from this list https://gist.github.com/mutin-sa/5dcbd35ee436eb629db7872581093bc5

angstrom

I usually add options rotate so that load balancing is done among the three nameservers

vpsgeek3333

8.8.8.8
Provider's DNS or (if provider's DNS is not available) 1.1.1.1
2001:4860:4860::8888

FreeBSD

Provider HDNS: 103.196.38.38, 103.196.38.39

Janevski

DNS resolvers are overrated.
I use pure non-GMO p2p internet.

PS: Via telepathic layer 2.

uptime

I've recently been stumbling around @Not_Oles Darkstar server in a semi-demented haze, probulating the relative responsiveness of 1.1.1.1 vs 8.8.8.8 vs 74.82.42.42 ...

(Trying to figure out source of occasional 5-second delays in DNS lookups, under the possibly dubious assumption that it may relate to how ipv6 lookups are handled as per https://udrepper.livejournal.com/20948.html - or could it be something else ...?)

Whatever's going on is not at all clear to me (nor would it be, I'm a noob when it comes to networks) - but so far it seems like the HE dns is doing a lot better than 1.1.1.1 and 8.8.8.8 - at least when testing on the Darkstar server (levelone network in Dallas routing through path ddos then hivelocity)

uptime@darkstar:~/notes$ for x in $f $g $h; do echo $x; n=$(grep -- -- $x | wc -l); m=$(grep -- '--.*0:' $x | wc -l); echo $n samples / $m delays; grep -- '--.*0:' $x; done
/home/uptime/notes/20211223_shock_http_1.1.1.1_dns
72 samples / 10 delays
100   612  100   612    0     0    121      0  0:00:05  0:00:05 --:--:--   152
100   612  100   612    0     0    121      0  0:00:05  0:00:05 --:--:--   175
100   612  100   612    0     0    119      0  0:00:05  0:00:05 --:--:--   152
100   612  100   612    0     0    121      0  0:00:05  0:00:05 --:--:--   152
100   612  100   612    0     0    121      0  0:00:05  0:00:05 --:--:--   154
100   612  100   612    0     0    117      0  0:00:05  0:00:05 --:--:--   146
100   612  100   612    0     0    121      0  0:00:05  0:00:05 --:--:--   152
100   612  100   612    0     0    121      0  0:00:05  0:00:05 --:--:--   152
100   612  100   612    0     0    121      0  0:00:05  0:00:05 --:--:--   152
100   612  100   612    0     0    121      0  0:00:05  0:00:05 --:--:--   154
/home/uptime/notes/20211223_shock_http_8.8.8.8_dns
69 samples / 7 delays
100   612  100   612    0     0    121      0  0:00:05  0:00:05 --:--:--   155
100   612  100   612    0     0    119      0  0:00:05  0:00:05 --:--:--   152
100   612  100   612    0     0    549      0  0:00:01  0:00:01 --:--:--   550
100   612  100   612    0     0    559      0  0:00:01  0:00:01 --:--:--   560
100   612  100   612    0     0    582      0  0:00:01  0:00:01 --:--:--   582
100   612  100   612    0     0    585      0  0:00:01  0:00:01 --:--:--   585
100   612  100   612    0     0    584      0  0:00:01  0:00:01 --:--:--   585
/home/uptime/notes/20211223_shock_http_74.82.42.42_dns
64 samples / 0 delays

some more notes here, doing similar tests from various providers in Dallas https://wiki.metalvps.com/chat/20211223/?updated

no idea what's going on, so it's kind of "interesting" .... Hoping to eventually understand some of this a bit better!

Not_Oles

Hi @uptime! Is it unambiguous in the above results whether the http transfer being timed took place over IPv4 or IPv6?

Even though the DNS inquiries apparently took place only over IPv4 the results presumably were returned in both IPv4 and IPv6. I believe both ends of the http transfer are IPv4 and IPv6 enabled.

How might we know whether the specific http transfer delay being logged was due to DNS delay or perhaps was due to some delay related to the sender's or the receiver's IPv4 or IPv6 use or switching between the two? Maybe something like what Drepper was talking about on the page to which you linked?

Hope this is helpful! Friendly greetings from Sonora! 🏜️

uptime

@Not_Oles said: Is it unambiguous in the above results whether the http transfer being timed took place over IPv4 or IPv6?

I think so, if the --ipv4 parameter to curl does what it says on the tin:

uptime@darkstar:~/notes$ man curl | grep -A 7 -- --ipv4
       -4, --ipv4
              This  option tells curl to resolve names to IPv4 addresses only,
              and not for example try IPv6.

              Example:
               curl --ipv4 https://example.com

              See also  --http1.1  and  --http2.  This  option  overrides  -6,
              --ipv6.
[...]
uptime@darkstar:~/notes$ typeset -f jankycurl
jankycurl () 
{ 
    ip=${1:-74.82.42.42};
    date;
    curl -4 --dns-servers ${ip} http://shock.metalvps.com 2>&1 > /dev/null;
    date
}
uptime@darkstar:~/notes$ jobs
[1]   Running                 while :; do
    jankycurl 1.1.1.1; zzz;
done > $f &
[2]-  Running                 while :; do
    jankycurl 8.8.8.8; zzz;
done > $g &
[3]+  Running                 while :; do
    jankycurl 74.82.42.42; zzz;
done > $h &
uptime@darkstar:~/notes$ printf '%s\n%s\n%s\n' $f $g $h
/home/uptime/notes/20211223_shock_http_1.1.1.1_dns
/home/uptime/notes/20211223_shock_http_8.8.8.8_dns
/home/uptime/notes/20211223_shock_http_74.82.42.42_dns
uptime@darkstar:~/notes$ for x in $f $g $h; do echo $x; n=$(grep -- -- $x | wc -l); m=$(grep -- '--.*0:' $x | wc -l); echo $n samples / $m delays; done
/home/uptime/notes/20211223_shock_http_1.1.1.1_dns
269 samples / 52 delays
/home/uptime/notes/20211223_shock_http_8.8.8.8_dns
260 samples / 17 delays
/home/uptime/notes/20211223_shock_http_74.82.42.42_dns
269 samples / 2 delays
uptime@darkstar:~/notes$ grep -- '--.*0:' /home/uptime/notes/20211223_shock_http_74.82.42.42_dns 
100   612  100   612    0     0    198      0  0:00:03  0:00:03 --:--:--   198
100   612  100   612    0     0    390      0  0:00:01  0:00:01 --:--:--   390

that's my story, and I'm sticking to it!

Not_Oles

@uptime Thanks! Maybe there might remain nevertheless a bit of IPv4/IPv6 ambiguity.

Suppose curl wants IPv4 because it saw the -ipv4 parameter, but DNS wants to hand curl an IPv6 address, and the result is a delay. Is this too crazy?

Suppose we put the IPv4 address for the target http server into /etc/hosts and tried the test that way. . . . Presumably the IPv4 address might be consistently taken from /etc/hosts. The five second delays might or might not remain, and we could try to figure out why.

Maybe some kind of verbose logging of the DNS requests might be possible and helpful?

Friendly greetings!

uptime

Suppose curl wants IPv4 because it saw the -ipv4 parameter, but DNS wants to hand curl an IPv6 address, and the result is a delay. Is this too crazy?

seems like a long shot ...? but here we are. Lol!

I think some judicious packet captures (using tcpdump ) could be helpful to take a closer look.

Might could go through the curl code (just a few tens of thousands of possibly relevant lines of c)

I've seen mention of an "ipv4-only" build for curl (from a quick peek at the source) ...

uptime@darkstar:~/curl/curl/lib$ wc -l $(grep -l -i -e 'ipv[46]' -e dns *.c)
    936 asyn-ares.c
    760 asyn-thread.c
    603 conncache.c
   1677 connect.c
   1766 cookie.c
    595 curl_addrinfo.c
    993 doh.c
   1259 easy.c
    365 easyoptions.c
   4402 ftp.c
    125 hostasyn.c
   1306 hostip.c
    298 hostip4.c
    160 hostip6.c
    106 hostsyn.c
   4375 http.c
   1067 http_proxy.c
    246 if2ip.c
    197 inet_ntop.c
    237 inet_pton.c
   3680 multi.c
   3077 setopt.c
    260 share.c
   1033 socks.c
   1122 strerror.c
   1409 tftp.c
   4194 url.c
   1707 urlapi.c
    612 version.c
   1329 x509asn1.c
  39896 total

hmmm ...

uptime@darkstar:~/curl/curl/lib$ grep -A 20 -i -e 'ipv4' -e dns asyn-ares.c | head -20
  struct curltime happy_eyeballs_dns_time; /* when this timer started, or 0 */
#endif
};

/* How long we are willing to wait for additional parallel responses after
   obtaining a "definitive" one.

   This is intended to equal the c-ares default timeout.  cURL always uses that
   default value.  Unfortunately, c-ares doesn't expose its default timeout in
   its API, but it is officially documented as 5 seconds.

   See query_completed_cb() for an explanation of how this is used.
 */
#define HAPPY_EYEBALLS_DNS_TIMEOUT 5000

/*
 * Curl_resolver_global_init() - the generic low-level asynchronous name
 * resolve API.  Called from curl_global_init() to initialize global resolver
 * environment.  Initializes ares library.
 */

something something HAPPY_EYEBALLS_DNS_TIMEOUT ftw ...?

Not_Oles

from https://man7.org/linux/man-pages/man3/resolver.3.html

   RES_DEBUG
          Print debugging messages.  This option is available only
          if glibc was built with debugging enabled, which is not
          the default.

Just wondering if something like setting a resolver debug option might be helpful? Dunno. Have to see if the debug code includes timestamps? Or maybe add them?

¡Saludos!

uptime

All options are on the table.

Shave every yak, I say!

And let root sort them out.

Anyhoo. Here's a fun read:

IPv6, Large UDP Packets and the DNS

[...] the underlying host of this name server is configured with a local maximum packet size of 1,280 octets. This means that in the first case the response being sent to the Google resolver is a single unfragmented IPv6 UDP packet, and the second case the response is broken into two fragmented IPv6 UDP packets. And it is this single change that triggers the Google Public DNS Server to provide the intended answer in the first case, but to return a SERVFAIL failure notice in response to the fragmented IPv6 response. When the local MTU on the server is lifted from 1,280 octets to 1,500 octets the Google resolver returns the server’s DNS response in both cases.

Edit2: Moar, better, from June 2020, explains Happy Eyeballs and more -> https://www.potaroo.net/ispcol/2020-07/dns6.html

Today the dual-stack Internet comes to the rescue and what does not or cannot happen in IPv6 is seamlessly fixed using IPv4, but that's not a course of action that will be sustainable forever. We really need to address this appalling packet drop rate for fragmented IPv6 packets in the DNS, and on all end-to-end IPv6 paths in the Internet. Our choices are to either try and fix this problem in the switches in the network, or we can alter end systems and applications to simply work around the problem.

vyas

4.4.4.4 if you are MjJ

@dahartigan