DNS 확인이 때때로 시간 초과로 연결됨

DNS 확인이 때때로 시간 초과로 연결됨

좋은 하루 되세요. 다음 명령을 실행하십시오. nslookup kafka.zxc.stage @dns1.prod 때때로 다음과 같은 답변을 받습니다. - ;;Connection timed out server;

예를 들어 1초마다 명령을 실행하면 6초에 6개의 요청이 발생합니다. 대답의 일부는 "서버에 연결할 수 없습니다"입니다.

나는 이것이 매우 이상하다고 생각합니다. 나는 tcpdump 유틸리티를 사용하여 살펴보기로 결정했습니다. 두 가지 예를 들어보겠습니다. nslookup이 A 레코드를 반환하고 "서버에 연결할 수 없습니다."

모든 것이 괜찮습니다. 콘솔에 응답이 반환됨 -

3926 IP (tos 0x0, ttl 64, id 40303, offset 0, flags [none], proto UDP (17), length 202) 
dns-int.prod > kafka.zxc.stage.33173: [bad udp cksum 0x4e30 -> 0x6909!] 14677* q: A? kafka.stage. 2/2/2 kafka.stage. [10m] CNAME kafka.zxc.stage., kafka.zxc.stage. [10m] A 100.200.40.22 ns: stage.zone. [30m] NS dns2-int.prod., stage.zone. [30m] NS dns-int.prod . ar: dns-int.prod . [1h] A 100.100.100.200, dns2-int.prod. [30m] A 100.100.100.100 (174)

다음 요청을 보내고 2~3초 정도 기다리면 콘솔에서 ";;Connection timed out; Unable to connect to the server"를 반환합니다.

4662 IP (tos 0x0, ttl 64, id 40543, offset 0, flags [none], proto UDP (17), length 129) 
dns-int.prod > kafka.zxc.stage.52157: [bad udp cksum 0x4de7 -> 0x6fe7!] 53* q: AAAA? kafka.zxc.stage. 0/1/0 ns: stage.zone. [4d] SOA dns1.prod. admindn.mail.(101)

내가 아는 바로는 A 레코드는 IPv4용이고 AAAA 레코드는 IPv6용입니다.

왜 그가 이런 식으로 요청을 보내려고 하는지 아직도 이해가 되지 않습니다. 누구든지 나에게 해결책을 찾는 방향을 알려줄 수 있다면 매우 기쁠 것입니다. 나는 또한 해결책을 찾을 것입니다. 감사해요.

즉, dns1에 nslookup 논스톱 요청을 보내면 dns2(슬레이브)에는 오류가 없습니다.

dns1에 대한 nslookup의 예 -

 # nslookup kafka.zxc.stage 100.100.100.100
Server:     100.100.100.100
Address:    100.100.100.100#53

kafka.zxc.stage canonical name = kafka.stage.
Name:   kafka.zxc.stage
Address: 100.200.40.22
;; connection timed out; no servers could be reached

답변을 보냈으나 연결 시간이 초과되었습니까? 또는

# nslookup kafka.zxc.stage 100.100.100.100
;; connection timed out; no servers could be reached

이것이 플로팅 문제입니다.

너무 오랜만이라 확인 중이에요

for i in {0..5}; do time dig @100.100.100.100 +short kafka.zxc.stage ; done 2>&1 | grep real
real    0m5.018s
real    0m5.012s
real    0m0.016s
real    0m0.013s
real    0m5.015s
real    0m10.021s

지정된 구성이 변경되지 않았습니다. 그러나 운영 체제 구성이 변경되었습니다. 추가로 확인 중이에요

답변1

가상 IP가 잘못되었습니다. 그는 듣지 않고 일하고 있습니다. netstat에서 새 행을 다시 만든 후 -

tcp        0      0 100.100.100.100:53         0.0.0.0:*               LISTEN      29671/named 

다시 생성하면 모든 것이 잘 될 것입니다.

관련 정보