DNS 조회에는 때때로 5 초가 소요됩니다

리졸버가 즉시 응답하더라도 데비안 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하면 이름 확인을 받기 전에 몇 초 동안 중단됩니다. ltrace출력 취급이되어 [1] 방송 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.

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

차이점 중 하나 getaddrinfo()와 gethostbyname()전 지지체 IPv4 및 IPv6 모두, 후자는 IPv4만을 지원하는 동안이다. 따라서 0 ( ) getaddrinfo()으로 ai_family설정하여 호출하면 제공된 도메인 이름에 대한 A 및 AAAA 쿼리 모두에AF_UNSPEC 대한 응답을 얻거나 시간 종료 될 때까지 리턴되지 않습니다 . A 레코드 만 쿼리합니다.gethostbyname()

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

이는 VMware 인프라 앞에있는 Juniper 방화벽에서 지나치게 제한적인 규칙 세트로 인해 발생했습니다.

나는 대화의 양쪽을 볼 수 있도록 테스트 리졸버를 만들었고, Kempniu가 그의 훌륭한 답변에서 확인한 빠진 패킷은 실제로 어딘가에 떨어졌습니다. 해당 답변에 명시된 바와 같이, getaddrinfo()주소 패밀리가 지정되지 않은 경우 모든 지원되는 패밀리 와 관련된 답변 을 반환하기 전에 기다립니다 (또는 제 경우에는 시간 초과).

네트워크를 운영하는 동료가

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

따라서 방화벽은 IPv4 응답을보고 VM의 쿼리에 응답하고 해당 포트의 인바운드 경로를 닫았다는 점을 지적했습니다. 따라서 다음 IPv6 응답 패킷이 삭제되었습니다. 두 패킷이 두 번째로 패킷을 생성 한 이유를 모르겠지만 방화벽에서이 기능을 비활성화하면 문제가 해결되었습니다.

이것은 Juniper KB의 관련 추출입니다.

DNS 응답 패킷이 삭제되는 시나리오는 다음과 같습니다.

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

이 답변을지지 할 생각이라면 Kempniu의 답변도지지하십시오. 그것 없이는 여전히 VM에서 일부 구성 문제를 찾으려고 노력하고 있습니다.