Tra cứu DNS đôi khi mất 5 giây

Tôi có một VM chạy Debian Wheezy mà trên đó một số tra cứu tên máy chủ phải mất vài giây để hoàn thành, mặc dù trình giải quyết trả lời ngay lập tức. Kỳ lạ thay, tra cứu với getaddrinfo()bị ảnh hưởng, nhưng gethostbyname()không.

Tôi đã chuyển sang các trình phân giải Google để loại trừ khả năng các bộ lọc cục bộ bị hỏng, vì vậy, giao diện của tôi /etc/resolv.confnhư sau:

search my-domain.com
nameserver 8.8.4.4
nameserver 8.8.8.8

Của tôi nsswitch.confcó dòng:

hosts: files dns

và của tôi /etc/hostskhông chứa bất cứ điều gì bất thường.

Nếu tôi thử telnet webserver 80, nó sẽ bị treo trong vài giây trước khi nhận được độ phân giải tên. Một ltraceđầu ra [1] cho thấy hang bị treo trong một getaddrinfo()cuộc gọi:

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

Tuy nhiên, tcpdumptiết lộ rằng máy chủ tên đã trả lời ngay lập tức và đó chỉ là câu trả lời thứ hai được telnetbỏ chặn. Các câu trả lời trông giống hệt nhau:

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)

Tôi đã kiểm tra nhật ký tường lửa máy chủ và không có gì trên cổng 53 bị chặn.

Điều gì gây ra phản hồi DNS đầu tiên bị bỏ qua?

[1] Tôi đã thêm một vài dòng vào ltrace.confđể tôi có thể nhìn thấy bên trong addrinfocấu trúc.

Câu trả lời DNS đầu tiên không bị bỏ qua. getaddrinfo()đã không trả lại cho đến khi nhận được phản hồi cho truy vấn AAAA đầu tiên (ID: 26090). Vì vậy, vấn đề thực sự ở đây là tại sao máy của bạn chưa nhận được phản hồi ngay lập tức cho truy vấn AAAA, trong khi nó đã nhận được phản hồi cho truy vấn A (ID: 54755).

Một trong những khác biệt giữa getaddrinfo()và gethostbyname()cái trước là hỗ trợ cả IPv4 và IPv6, trong khi cái sau chỉ hỗ trợ IPv4. Vì vậy, khi bạn gọi getaddrinfo()với số ai_family0 ( AF_UNSPEC), nó sẽ không trả về cho đến khi nhận được phản hồi (hoặc hết thời gian chờ) cho cả truy vấn A và AAAA cho tên miền được cung cấp. gethostbyname()chỉ truy vấn cho một bản ghi A.

Thật khó để xác định từ xa những gì có thể gây ra vấn đề của bạn, đặc biệt là bạn đã cắt bỏ một số tcpdumpđầu ra. Một cái gì đó có thể được lọc / thả lưu lượng DNS giữa bộ phân giải VM và Google Public DNS của bạn. Tôi đã cố gắng tái tạo vấn đề của bạn bằng máy ảo KVM Debian Wheezy, nhưng telnet ifconfig.megần như ngay lập tức in Trying <IP_address_here>...dòng này (có nghĩa là nó đã giải quyết được tên đó rồi).

Điều này được gây ra bởi một quy tắc hạn chế quá mức trên tường lửa Juniper nằm trước cơ sở hạ tầng của VMware.

Tôi đã xây dựng một trình phân giải thử nghiệm để tôi có thể nhìn thấy cả hai mặt của cuộc trò chuyện và gói bị thiếu được xác định bởi Kempniu trong câu trả lời tuyệt vời của anh ta thực sự đã bị bỏ ở đâu đó trên đường đi. Như đã lưu ý trong câu trả lời đó, getaddrinfo()không có địa chỉ gia đình nào được chỉ định sẽ chờ câu trả lời liên quan đến tất cả các gia đình được hỗ trợ trước khi quay lại (hoặc, trong trường hợp của tôi, hết thời gian).

Đồng nghiệp của tôi, người điều hành mạng lưu ý rằng

Hành vi mặc định trên tường lửa Juniper là đóng phiên liên quan đến DNS ngay khi nhận được phản hồi DNS khớp với phiên đó.

Vì vậy, tường lửa đã nhìn thấy phản hồi của IPv4, lưu ý rằng nó đã trả lời truy vấn của VM và đóng đường dẫn gửi đến cho cổng đó. Do đó, gói trả lời IPv6 sau đây đã bị loại bỏ. Tôi không biết tại sao cả hai gói lại xuất hiện lần thứ hai, nhưng việc vô hiệu hóa tính năng này trên tường lửa đã khắc phục vấn đề.

Đây là một trích xuất có liên quan từ Juniper KB:

Đây là một kịch bản trong đó các gói DNS Trả lời bị hủy:

1. Một phiên cho lưu lượng DNS được tạo khi gói truy vấn DNS đầu tiên chạm vào tường lửa và có chính sách cho phép được định cấu hình. Thời gian chờ mặc định là 60 giây.
2. Ngay trước khi phiên kết thúc, một truy vấn DNS mới được truyền đi và vì nó khớp với phiên hiện có (vì cặp cổng / cổng đích và IP luôn giống nhau), nó được chuyển tiếp bởi tường lửa. Lưu ý rằng thời gian chờ phiên không được làm mới theo bất kỳ gói mới đến.
3. Phiên DNS đã tạo bị cũ khi phản hồi truy vấn DNS (trả lời) đầu tiên chạm vào thiết bị, bất kể thời gian chờ còn lại là bao nhiêu.
4. Khi một phản hồi DNS được chuyển qua tường lửa, phiên bị lỗi thời.
5. Tất cả các phản hồi DNS tiếp theo đều bị tường lửa bỏ, vì không có phiên nào tồn tại.

Nếu bạn đang nghĩ đến việc nâng cao câu trả lời này, vui lòng cũng nêu lên câu trả lời của Kempniu. Không có nó, tôi vẫn loay hoay tìm cách tìm một số vấn đề cấu hình trên VM.