Máy chủ DNS phản hồi và hết thời gian


17

Chúng tôi đang gặp một vấn đề khó chịu trên mạng LAN của chúng tôi. Theo định kỳ, các truy vấn DNS tới máy chủ tên ISP của chúng tôi đã hết thời gian chờ 5 giây. Ngay cả khi tôi bỏ qua /etc/resolv.confbằng cách sử dụng một máy đào trực tiếp đến một trong các máy chủ DNS của chúng tôi, tôi vẫn gặp phải sự cố. Đây là một ví dụ:

mv-m-dmouratis:~ dmourati$ time dig www.google.com @209.81.9.1 

; <<>> DiG 9.8.3-P1 <<>> www.google.com @209.81.9.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14473
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com.            IN  A

;; ANSWER SECTION:
www.google.com.     174 IN  A   74.125.239.148
www.google.com.     174 IN  A   74.125.239.147
www.google.com.     174 IN  A   74.125.239.146
www.google.com.     174 IN  A   74.125.239.144
www.google.com.     174 IN  A   74.125.239.145

;; AUTHORITY SECTION:
google.com.     34512   IN  NS  ns2.google.com.
google.com.     34512   IN  NS  ns1.google.com.
google.com.     34512   IN  NS  ns3.google.com.
google.com.     34512   IN  NS  ns4.google.com.

;; ADDITIONAL SECTION:
ns2.google.com.     212097  IN  A   216.239.34.10
ns3.google.com.     207312  IN  A   216.239.36.10
ns4.google.com.     212097  IN  A   216.239.38.10
ns1.google.com.     212096  IN  A   216.239.32.10

;; Query time: 8 msec
;; SERVER: 209.81.9.1#53(209.81.9.1)
;; WHEN: Fri Jul 26 14:44:25 2013
;; MSG SIZE  rcvd: 248


real    0m5.015s
user    0m0.004s
sys 0m0.002s

Những lần khác, các truy vấn trả lời ngay lập tức, như trong dưới 20 ms hoặc lâu hơn. Tôi đã thực hiện theo dõi gói tin và phát hiện ra một điều thú vị. Máy chủ DNS đang phản hồi nhưng máy khách bỏ qua phản hồi ban đầu, sau đó gửi truy vấn giống hệt thứ hai được trả lời ngay lập tức.

Xem dấu vết gói . Lưu ý các cổng nguồn giống hệt với các truy vấn (62076).

Câu hỏi: điều gì gây ra truy vấn DNS đầu tiên không thành công?

CẬP NHẬT

Tài nguyên:

Theo dõi gói:

http://www.cloudshark.org/captures/8b1c32d9d015

Dtruss (strace cho mac):

https://gist.github.com/dmourati/6115180

Tường lửa Mountain Lion đang trì hoãn ngẫu nhiên các yêu cầu DNS từ apple.stackexchange.com:

/apple/80678/max-lion-firewall-is-randomly-delaying-dns-requests

CẬP NHẬT 2

System Software Overview:

  System Version:   OS X 10.8.4 (12E55)
  Kernel Version:   Darwin 12.4.0
  Boot Volume:  Macintosh HD
  Boot Mode:    Normal
  Computer Name:    mv-m-dmouratis
  User Name:    Demetri Mouratis (dmourati)
  Secure Virtual Memory:    Enabled
  Time since boot:  43 minutes

Hardware Overview:

  Model Name:   MacBook Pro
  Model Identifier: MacBookPro10,1
  Processor Name:   Intel Core i7
  Processor Speed:  2.7 GHz
  Number of Processors: 1
  Total Number of Cores:    4
  L2 Cache (per Core):  256 KB
  L3 Cache: 6 MB
  Memory:   16 GB

Firewall Settings:

  Mode: Limit incoming connections to specific services and applications
  Services:
  Apple Remote Desktop: Allow all connections
  Screen Sharing:   Allow all connections
  Applications:
  com.apple.java.VisualVM.launcher: Block all connections
  com.getdropbox.dropbox:   Allow all connections
  com.jetbrains.intellij.ce:    Allow all connections
  com.skype.skype:  Allow all connections
  com.yourcompany.Bitcoin-Qt:   Allow all connections
  org.m0k.transmission: Allow all connections
  org.python.python:    Allow all connections
  Firewall Logging: Yes
  Stealth Mode: No

dtrussđầu ra trông bị cắt ngắn. Chúng tôi không bao giờ thấy các cuộc gọi hệ thống ghi đầu ra chương trình vào STDOUT.
Andrew B

Bạn đã thử máy chủ tên công khai khác, ví dụ Google DNS.
vasco.debian

@ vasco.debian có, hành vi tương tự.
dmourati

1
Chỉ có sự khác biệt tôi thấy giữa hai cặp yêu cầu phản hồi này là sự chậm trễ giữa yêu cầu và phản hồi. Tôi không thấy bất kỳ vấn đề nào trên mạng. Thử nghiệm và kiểm tra xem có vấn đề chậm trễ không - OS có thể bỏ một số gói udp vào ứng dụng vì một số lý do, mặc dù nó được hiển thị trong bộ phân tích. Chắc chắn, đó không phải là vấn đề với mạng hoặc cấu hình chung, "đào" phải hoạt động. Có thể có điều gì đó không ổn với điều chỉnh ngăn xếp mạng. Kiểm tra cài đặt sysctl cho mạng. Thích cái này rolande.wordpress.com/2010/12/30/áng
GioMac

1
Bạn không nói nếu bạn có một tường lửa chạy trên mac?
JustinP

Câu trả lời:


3

Đây dường như là một lỗi trong tường lửa của Lion. Nó được kích hoạt trên hệ thống của bạn?

Trong luồng MacRumors này ( các sự cố DNS sau khi cập nhật lên Mountain Lion (10.8) ), một cách giải quyết có thể được thảo luận:

Hãy thử giảm kích thước MTU.

Tùy chọn hệ thống> Mạng> WiFi> Nâng cao> Phần cứng> Thủ công> MTU: Tùy chỉnh> 1300

Đã làm cho tôi.

Bạn có thể kiểm tra xem việc giảm kích thước MTU có làm giảm bớt vấn đề của bạn không?


Thay đổi cài đặt tường lửa làm cho vấn đề biến mất. MTU không có hiệu lực. Tường lửa cần phải bị vô hiệu hóa hoặc "Chặn tất cả các kết nối đến."
dmourati

Thay đổi tường lửa thành cài đặt giảm tần suất sự cố nhưng không loại bỏ hoàn toàn sự cố. Có thể repro 1/200 lần hoặc lâu hơn.
dmourati

Tôi sẽ xem xét việc mất gói tin có cường độ đó khá hợp lý khi truy cập internet, đặc biệt nếu có các bước nhảy bị tắc nghẽn trên tuyến đường. Hãy nhớ rằng, DNS sử dụng UDP, không đảm bảo phân phối datagram. Đó chính xác là lý do tại sao bản thân giao thức DNS đã thử lại và cơ chế hết thời gian được tích hợp.
Mels

1
Nhân tiện, tôi biết chúng tôi không nên đăng bình luận "cảm ơn" ở đây, nhưng bạn chỉ tăng danh tiếng của tôi lên gấp sáu lần :)
Mels

0

Gần đây tôi đã gặp một vấn đề tương tự và thấy rằng tường lửa Cisco ASA không được cấu hình để hỗ trợ EDNS0, thông số cho phép các gói UDP DNS lớn hơn 512 byte. Khi quản trị viên fw của tôi cho phép tối đa 4096 byte, vấn đề đã được giải quyết. Thông tin tuyệt vời ở đây:

http://www.petenetlive.com/KB/Article/0000312.htm


Tôi không nghĩ rằng áp dụng ở đây. Phản hồi nằm dưới 512 byte cho truy vấn DNS cụ thể này, ngay cả với quyền hạn và các phần bổ sung.
Andrew B
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.