DNS 조회에 때때로 5초가 소요됨

DNS 조회에 때때로 5초가 소요됨

Debian Wheezy를 실행하는 VM이 ​​있고 확인자가 즉시 응답하더라도 일부 호스트 이름 조회를 완료하는 데 몇 초가 걸립니다. 이상하게도 조회 getaddrinfo()는 영향을 받지만 gethostbyname()그렇지 않습니다.

로컬 파서가 손상될 가능성을 배제하기 위해 Google 파서로 전환했습니다. 내 /etc/resolv.conf모습은 다음과 같습니다.

search my-domain.com
nameserver 8.8.4.4
nameserver 8.8.8.8

광산 nsswitch.conf에는 다음 줄이 있습니다.

hosts: files dns

내 것에는 /etc/hosts평범한 것이 하나도 들어 있지 않습니다.

시도하면 telnet webserver 80이름이 확인되기 전에 몇 초 동안 멈춥니다. 출력 [1]은 호출 ltrace중에 중단이 발생했음을 보여줍니다 .getaddrinfo()

getaddrinfo("ifconfig.me", "telnet", { AI_CANONNAME, 0, SOCK_STREAM, 0, 0, NULL, '\000', NULL }, 0x7fffb4ffc160) = 0 <5.020621>

그러나 tcpdump표시 이름 서버는 즉시 응답하고 telnet두 번째 응답에서만 차단을 해제합니다. 응답은 정확히 동일합니다.

05:52:58.609731 IP 192.168.1.75.43017 > 8.8.4.4.53: 54755+ A? ifconfig.me. (29)
05:52:58.609786 IP 192.168.1.75.43017 > 8.8.4.4.53: 26090+ AAAA? ifconfig.me. (29)
05:52:58.612188 IP 8.8.4.4.53 > 192.168.1.75.43017: 54755 4/0/0 A 219.94.235.40, A 133.242.129.236, A 49.212.149.105, A 49.212.202.172 (93)

[...five second pause...]

05:53:03.613811 IP 192.168.1.75.43017 > 8.8.4.4.53: 54755+ A? ifconfig.me. (29)
05:53:03.616424 IP 8.8.4.4.53 > 192.168.1.75.43017: 54755 4/0/0 A 219.94.235.40, A 133.242.129.236, A 49.212.149.105, A 49.212.202.172 (93)
05:53:03.616547 IP 192.168.1.75.43017 > 8.8.4.4.53: 26090+ AAAA? ifconfig.me. (29)
05:53:03.618907 IP 8.8.4.4.53 > 192.168.1.75.43017: 26090 0/1/0 (76)

호스트 방화벽 로그를 확인했는데 포트 53에서 차단된 항목이 없습니다.

첫 번째 DNS 응답이 무시되는 원인은 무엇입니까?

[1] 구조 내부를 ltrace.conf볼 수 있도록 파일에 몇 줄을 추가했습니다 .addrinfo

답변1

첫 번째 DNS 응답은 무시되지 않습니다. getaddrinfo()첫 번째 AAAA 쿼리(ID: 26090)에 대한 응답이 수신될 때까지 반환되지 않습니다. 따라서 여기서 실제 질문은 컴퓨터가 이미 A 쿼리(ID: 54755)에 대한 응답을 받았는데 AAAA 쿼리에 대한 즉각적인 응답을 받지 못한 이유입니다.

getaddrinfo()IPv4와 IPv6의 차이점 중 하나 gethostbyname()는 전자는 IPv4와 IPv6를 모두 지원하지만 후자는 IPv4만 지원한다는 것입니다. 따라서 0( )으로 getaddrinfo()설정하여 호출하면 응답을 받을 때까지(또는 시간 초과에 도달할 때까지) 반환되지 않습니다.ai_familyAF_UNSPEC둘 다A 및 AAAA 쿼리는 도메인 이름을 제공했습니다. gethostbyname()A 레코드만 쿼리합니다.

tcpdump특히 출력 의 일부를 제거한 경우 문제의 원인이 무엇인지 원격으로 확인하기가 어렵습니다 . VM과 Google의 공개 DNS 확인자 간의 DNS 트래픽을 선택적으로 필터링/삭제할 수 있습니다. KVM Debian Wheezy VM을 사용하여 문제를 재현하려고 시도했지만 telnet ifconfig.me해당 줄이 거의 즉시 인쇄되었습니다 Trying <IP_address_here>...(이미 이름이 해결되었음을 의미).

답변2

이는 VMware 인프라 앞에 있는 Juniper 방화벽에 설정된 지나치게 엄격한 규칙으로 인해 발생했습니다.

나는 대화의 양쪽 측면을 볼 수 있도록 테스트 파서를 만들었고 Kempniu가 그의 훌륭한 답변에서 식별한 누락된 패킷은 실제로 도중에 어딘가에 삭제되었습니다. 해당 답변에 명시된 바와 같이 getaddrinfo()주소 패밀리가 지정되지 않은 경우 다음과 관련된 답변은 다음과 같습니다.모두돌아오기 전에(또는 제 경우에는 타임아웃) 가족을 부양하세요.

네트워크를 운영하는 동료가 지적했습니다.

Juniper 방화벽의 기본 동작은 해당 세션과 일치하는 DNS 응답이 수신되자마자 DNS 관련 세션을 닫는 것입니다.

따라서 방화벽은 IPv4 응답을 확인하고 가상 머신의 쿼리에 응답한 것을 확인하고 해당 포트에 대한 인바운드 경로를 닫습니다. 따라서 후속 IPv6 응답 패킷은 삭제됩니다. 왜 두 번째 패킷이 모두 통과했는지는 모르겠지만 방화벽에서 이 ​​기능을 비활성화하면 문제가 해결되었습니다.

다음은 Juniper 지식 베이스에서 발췌한 관련 내용입니다.

다음은 DNS 응답 패킷이 삭제되는 시나리오입니다.

  1. 첫 번째 DNS 쿼리 패킷이 방화벽에 도달하고 허용 정책이 구성되면 DNS 트래픽 세션이 생성됩니다. 기본 시간 제한은 60초입니다.
  2. 세션이 종료되기 전에 새로운 DNS 쿼리가 전송되고, 기존 세션과 일치하므로(소스 및 대상 포트/IP 쌍이 항상 동일하기 때문에) 방화벽에 의해 전달됩니다. 세션 시간 초과는 새로 도착하는 패킷에 따라 새로 고쳐지지 않습니다.
  3. 첫 번째 DNS 쿼리 응답(응답)이 장치에 도달하면 생성된 DNS 세션은 남은 시간 초과와 관계없이 시간 초과됩니다.
  4. DNS 응답이 방화벽을 통과하면 세션이 만료됩니다.
  5. 세션이 존재하지 않으므로 이후의 모든 DNS 응답은 방화벽에 의해 삭제됩니다.

이 답변에 투표하려면 Kempniu의 답변에도 투표하세요. 그것이 없었다면 나는 여전히 VM의 일부 구성 문제를 찾아 헤매고 있었을 것입니다.

관련 정보