Host name resolution is controlled by the Name Service Switch (NSS) facility. Check the hosts value in /etc/nsswitch.conf for your configuration.
$ grep ^hosts /etc/nsswitch.conf
hosts: files mymachines dns myhostname
The space-delimited list of services determines the order that services are queried.
-
files queries /etc/hosts
-
mymachines provides hostname resolution for the names of local systemd-machined containers
-
dns queries DNS according to the configuration in /etc/resolv.conf
-
myhostname provides local hostname resolution
-
resolve queries systemd-resolved, a caching DNS stub resolver
Note that there are other services, many of which are used in networks that include non-Linux systems (Unix, Windows, Mac, etc.). The services can be configured using system.nssHosts, but there are various other options that insert services as well.
When using a command like ping, a host is resolved by querying the NSS services in order until one is successful. Name resolution fails if all of the queries fail.
From what you wrote, the delay that you are experiencing does not sound like a DNS issue. This is easy to confirm using the dig utility, available via nixos.dnsutils. This utility queries DNS servers without going through NSS.
For example, here is a query using your configured nameserver:
$ dig +qr @192.168.1.1 A oeis.org
; <<>> DiG 9.14.9 <<>> +qr @192.168.1.1 A oeis.org
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26299
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 781a7ab0f2237616
;; QUESTION SECTION:
;oeis.org. IN A
;; QUERY SIZE: 49
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26299
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;oeis.org. IN A
;; ANSWER SECTION:
oeis.org. 7200 IN A 104.239.138.29
;; Query time: 379 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: 水 3月 04 07:55:31 JST 2020
;; MSG SIZE rcvd: 53
Here is a query using Google’s public nameserver:
$ dig +qr @8.8.8.8 A oeis.org
; <<>> DiG 9.14.9 <<>> +qr @8.8.8.8 A oeis.org
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63253
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 9753e8ab44749369
;; QUESTION SECTION:
;oeis.org. IN A
;; QUERY SIZE: 49
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63253
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;oeis.org. IN A
;; ANSWER SECTION:
oeis.org. 7199 IN A 104.239.138.29
;; Query time: 492 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: 水 3月 04 07:59:03 JST 2020
;; MSG SIZE rcvd: 53
DNS query times are highly dependent on caching. The query may be significantly faster on subsequent queries if the result is cached by the first query.
The getent utility performs name resolution using NSS. Unfortunately, it does not include features useful for debugging. (I wish that it had a --verbose mode that shows each step, with timing information.)
$ time getent hosts oeis.org
104.239.138.29 oeis.org
real 0m0.527s
user 0m0.001s
sys 0m0.003s
If your dig query time is short while your getent query time is long, then it indicates that the delay in name resolution is happening in an NSS service listed before the dns entry.
