컬 조회 명령을 사용하는 데 시간이 오래 걸리고(때때로) 빠르기도 하는 문제를 해결하려고 노력해 왔습니다.
TL;DR 질문: 추가로 문제를 해결하려면 어떻게 해야 합니까?
IP 주소에 직접 연결하는 데에는 문제가 없습니다.
저는 두 개의 서로 다른 위치, 여러 컴퓨터(RPi, debian vm, Windows10)를 시도했습니다.
동일한 결과로 네임서버를 1.1.1.1과 8.8.8.8로 설정하려고 했습니다.
나는 /etc/resolv.conf를 변경하여 그것이 포함되도록 했습니다(그리고 그렇습니다. 쓰기 방지했습니다)
options timeout:1
이제 dns_solution에 성공하기까지 더 이상 5초가 걸리지 않습니다. 하지만 1.00xx초(때로는), 때로는 0.00xxx초가 걸립니다.
나에게 그것은 처음에는 방화벽 삭제 패킷 문제 또는 ipv6-try 문제처럼 보였습니다. 그러나 나는 운이 좋게도 기계에서 ipv6을 비활성화했습니다.
조회를 수행하기 위해 다음 명령을 사용했습니다.
while :; do curl --max-time 10 -w "time_namelookup: %{time_namelookup}, time_connect: %{time_connect}, time_appconnect: %{time_appconnect}, time_pretransfer: %{time_pretransfer}, time_redirect: %{time_redirect}, time_starttransfer: %{time_starttransfer}, time_total: %{time_total}\n" -o /dev/null -s "https://www.google.com"; sleep 1; done
다음은 몇 가지 샘플 결과입니다.
time_namelookup: 1.059151, time_connect: 1.083971, time_appconnect: 1.129219, time_pretransfer: 1.129803, time_redirect: 0.000000, time_starttransfer: 1.191138, time_total: 1.198772
time_namelookup: 1.058956, time_connect: 1.084363, time_appconnect: 1.130112, time_pretransfer: 1.131392, time_redirect: 0.000000, time_starttransfer: 1.291702, time_total: 1.300107
time_namelookup: 1.057719, time_connect: 1.083355, time_appconnect: 1.128083, time_pretransfer: 1.128726, time_redirect: 0.000000, time_starttransfer: 1.190859, time_total: 1.198635
time_namelookup: 0.018382, time_connect: 0.043042, time_appconnect: 0.077228, time_pretransfer: 0.077517, time_redirect: 0.000000, time_starttransfer: 0.142618, time_total: 0.150624
time_namelookup: 1.058276, time_connect: 1.082821, time_appconnect: 1.127496, time_pretransfer: 1.128083, time_redirect: 0.000000, time_starttransfer: 1.188930, time_total: 1.197614
time_namelookup: 0.023630, time_connect: 0.047877, time_appconnect: 0.079810, time_pretransfer: 0.080053, time_redirect: 0.000000, time_starttransfer: 0.136007, time_total: 0.141614
time_namelookup: 0.018607, time_connect: 0.043160, time_appconnect: 0.079620, time_pretransfer: 0.079966, time_redirect: 0.000000, time_starttransfer: 0.139617, time_total: 0.145728
time_namelookup: 1.059191, time_connect: 1.084436, time_appconnect: 1.127247, time_pretransfer: 1.127825, time_redirect: 0.000000, time_starttransfer: 1.189962, time_total: 1.199934
time_namelookup: 1.058040, time_connect: 1.083303, time_appconnect: 1.127172, time_pretransfer: 1.128314, time_redirect: 0.000000, time_starttransfer: 1.194481, time_total: 1.202276
time_namelookup: 0.018539, time_connect: 0.043664, time_appconnect: 0.079772, time_pretransfer: 0.080074, time_redirect: 0.000000, time_starttransfer: 0.141406, time_total: 0.147358
time_namelookup: 1.060180, time_connect: 1.084996, time_appconnect: 1.130302, time_pretransfer: 1.131054, time_redirect: 0.000000, time_starttransfer: 1.197778, time_total: 1.205363
time_namelookup: 0.031891, time_connect: 0.058458, time_appconnect: 0.097752, time_pretransfer: 0.098055, time_redirect: 0.000000, time_starttransfer: 0.157533, time_total: 0.188634
time_namelookup: 1.059059, time_connect: 1.083472, time_appconnect: 1.126565, time_pretransfer: 1.127196, time_redirect: 0.000000, time_starttransfer: 1.189149, time_total: 1.195730
time_namelookup: 0.023647, time_connect: 0.048197, time_appconnect: 0.082277, time_pretransfer: 0.082772, time_redirect: 0.000000, time_starttransfer: 0.143120, time_total: 0.149757
time_namelookup: 0.017073, time_connect: 0.041658, time_appconnect: 0.081927, time_pretransfer: 0.082310, time_redirect: 0.000000, time_starttransfer: 0.144873, time_total: 0.152739
time_namelookup: 0.017251, time_connect: 0.042056, time_appconnect: 0.079905, time_pretransfer: 0.080475, time_redirect: 0.000000, time_starttransfer: 0.141332, time_total: 0.147886
그러나 dig 명령을 수행하는 것은 매우 빠릅니다.
$ dig @dns.google google.com
; <<>> DiG 9.11.5-P4-5.1+deb10u8-Raspbian <<>> @dns.google google.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13497
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 221 IN A 172.217.19.78
;; Query time: 25 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Feb 16 10:44:24 UTC 2023
;; MSG SIZE rcvd: 55
$ dig @1.1.1.1 google.com
; <<>> DiG 9.11.5-P4-5.1+deb10u8-Raspbian <<>> @1.1.1.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54885
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 65 IN A 142.250.147.101
google.com. 65 IN A 142.250.147.113
google.com. 65 IN A 142.250.147.138
google.com. 65 IN A 142.250.147.139
google.com. 65 IN A 142.250.147.100
google.com. 65 IN A 142.250.147.102
;; Query time: 13 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Feb 16 10:44:33 UTC 2023
;; MSG SIZE rcvd: 135
이는 덴마크에서 출발하는 여러 인터넷 연결에서 유사합니다.
전혀 문제가 없다는 결과도 있었습니다. 동일한 ASN 번호이지만 다른 하위 IP 범위를 통해 실행되는 다른 장치에 문제가 있는 동안 한 장치에서는 DNS 확인이 빨랐습니다.
MTR/traceroute에는 문제의 징후가 없습니다. 왜 100.xxx IP 주소로 가는지 잘 모르겠지만 일종의 라우팅이 있어야 합니다. 다른 연결에서는 이런 일이 발생하지 않습니다.
My traceroute [v0.92]
devicename (xx.x.x.xxx) 2023-02-16T11:50:47+0000
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. xx.x.x.x 0.0% 211 3.0 2.2 1.4 8.3 0.8
2. 31.3.xx.xxx 0.0% 211 1.7 2.1 1.4 7.3 0.7
3. 100.64.x.xxx 0.0% 211 6.8 8.1 6.1 37.8 3.5
4. 94.127.48.17 1.4% 211 7.4 8.3 6.1 48.0 6.3
5. xe-2-1-0-311.alb2nqe10.d 0.0% 211 6.9 9.4 6.3 46.4 6.3
6. ae0-0.stkm2nqp7.se.ip.td 0.0% 211 15.7 16.4 14.8 35.1 2.8
7. 72.14.214.162 0.0% 211 17.4 17.1 15.3 33.4 2.7
8. 209.85.254.3 0.0% 211 16.1 17.0 15.4 48.7 3.8
9. 108.170.253.181 0.9% 211 18.4 17.8 15.2 60.1 6.2
10. 108.170.227.249 10.0% 211 20.6 17.8 15.4 41.2 4.2
209.85.246.61
11. 142.251.51.215 2.8% 211 26.7 26.4 24.0 54.7 4.6
209.85.248.7
12. 142.250.214.184 1.4% 210 44.6 25.9 23.7 48.6 4.1
142.251.239.219
13. 172.253.70.203 0.5% 210 25.1 24.8 23.9 28.2 0.6
142.250.46.23
14. ???
15. ???
16. ???
17. ???
18. ???
19. ???
20. ???
21. ???
22. ???
23. rd-in-f139.1e100.net 38.3% 210 24.8 25.0 24.1 30.7 0.7
Traceroute는 하나의 실제 IP 주소로 이동한 다음 가짜(100.xxx) IP 주소로 이동함을 보여줍니다.
traceroute to google.com (142.250.147.102), 30 hops max, 60 byte packets
1 xx.x.x.x (xx.x.x.x) 2.436 ms 2.624 ms 2.510 ms
2 31.3.xx.xxx (31.3.xx.xxx) 2.392 ms 2.941 ms 2.834 ms
3 100.64.x.xxx (100.64.x.xxx) 6.451 ms 6.629 ms 6.519 ms
4 94.127.48.17 (94.127.48.17) 6.403 ms 6.600 ms 6.762 ms
5 xe-2-1-0-311.alb2nqe10.dk.ip.tdc.net (87.48.169.225) 6.653 ms 8.382 ms 8.074 ms
6 ae0-0.stkm2nqp7.se.ip.tdc.net (83.88.2.128) 16.956 ms 16.121 ms 15.401 ms
7 72.14.214.162 (72.14.214.162) 16.827 ms 16.741 ms 16.650 ms
8 * * *
9 108.170.254.33 (108.170.254.33) 17.564 ms 209.85.242.10 (209.85.242.10) 16.346 ms 108.170.253.161 (108.170.253.161) 17.412 ms
10 108.170.254.38 (108.170.254.38) 17.255 ms 108.170.253.182 (108.170.253.182) 17.105 ms 108.170.254.54 (108.170.254.54) 16.645 ms
11 209.85.246.61 (209.85.246.61) 16.484 ms 72.14.234.107 (72.14.234.107) 17.352 ms 142.250.235.228 (142.250.235.228) 17.045 ms
12 108.170.236.41 (108.170.236.41) 26.269 ms 26.088 ms 142.251.51.217 (142.251.51.217) 26.110 ms
13 142.251.239.219 (142.251.239.219) 24.352 ms 142.250.214.198 (142.250.214.198) 26.021 ms 142.250.214.178 (142.250.214.178) 26.295 ms
14 142.250.214.229 (142.250.214.229) 25.056 ms 142.250.215.9 (142.250.215.9) 25.494 ms 142.250.229.93 (142.250.229.93) 25.310 ms
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * rd-in-f102.1e100.net (142.250.147.102) 25.956 ms *
답변1
출력 'dig'가 A 요청(즉, 하나의 DNS 요청)만 수행했으며 RTT 시간이 있는 ipv4 모드의 mtr이 있습니다. 컬의 경우 ipv4와 ipv6(A 및 AAAA)에 대한 두 개의 DNS 요청이 있다고 가정합니다. ipv4 해결에 대해서만 'time_namelookup'을 비교하기 위해 '-4' 옵션을 사용하여 해당 컬 예제를 실행하려고 했습니까?