Respons dan Timeout Server DNS

Kami mengalami masalah yang membuat frustrasi pada LAN kami. Secara berkala, DNS menanyakan batas waktu server nama ISP kami yang memaksa penundaan 5 detik. Bahkan jika saya memotong /etc/resolv.confdengan menggunakan penggalian langsung ke salah satu server DNS kami, saya masih mengalami masalah. Ini sebuah contoh:

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

Di lain waktu, kueri merespons secara instan, seperti di bawah 20 ms atau lebih. Saya telah melakukan penelusuran paket dan menemukan sesuatu yang menarik. Server DNS yang menanggapi tetapi klien mengabaikan respon awal, kemudian mengirimkan permintaan identik kedua yang segera menanggapi.

Lihat jejak paket . Perhatikan port sumber identik dengan kueri (62076).

Pertanyaan: apa yang menyebabkan permintaan DNS pertama gagal?

MEMPERBARUI

Sumber:

Jejak paket:

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

Dtruss (strace for mac):

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

Firewall Mountain Lion secara acak menunda permintaan DNS dari apple.stackexchange.com:

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

PEMBARUAN 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

— dmourati
sumber

dtrussoutput terlihat terpotong. Kami tidak pernah melihat panggilan sistem yang menulis output program ke STDOUT.

— Andrew B

Sudahkah Anda mencoba server nama publik lainnya misalnya Google DNS.

— vasco.debian

@ vasco.debian ya, perilaku yang sama.

— dmourati

Hanya perbedaan yang saya lihat antara kedua pasangan permintaan-respons ini adalah penundaan antara permintaan dan respons. Saya juga tidak melihat masalah di jaringan. Eksperimen dan periksa apakah penundaan itu penting - OS mungkin menjatuhkan beberapa paket udp ke aplikasi untuk beberapa alasan, meskipun hal itu ditunjukkan dalam penganalisa. Jelas, itu bukan masalah dengan konfigurasi jaringan atau umum, "menggali" harus bekerja. Mungkin ada yang salah dengan penyetelan tumpukan jaringan. Periksa pengaturan sysctl untuk jaringan. Suka rolande.wordpress.com/2010/12/30/…

— GioMac

Anda tidak mengatakan apakah Anda memiliki firewall yang berjalan di mac?

— JustinP

Tampaknya ini adalah bug di firewall Lion. Apakah ini diaktifkan di sistem Anda?

Di utas MacRumors ini ( masalah DNS setelah memperbarui ke Mountain Lion (10.8) ), solusi yang mungkin dibahas:

Coba kurangi ukuran MTU.

Preferensi Sistem> Jaringan> WiFi> Lanjutan> Perangkat Keras> Secara Manual> MTU: Kustom> 1300

Bekerja untukku.

Bisakah Anda memeriksa apakah mengurangi ukuran MTU mengurangi masalah Anda?

— Mels
sumber

Mengubah pengaturan firewall membuat masalah hilang. MTU tidak berpengaruh. Firewall harus dinonaktifkan, atau "Blokir semua koneksi yang masuk."

— dmourati

Mengubah firewall ke salah satu pengaturan mengurangi frekuensi masalah tetapi tidak sepenuhnya menghilangkan masalah. Mampu melaporkan ulang 1/200 kali atau lebih.

— dmourati

Saya akan mempertimbangkan hilangnya paket sebesar itu cukup masuk akal ketika melintasi internet, terutama jika ada hop padat pada rute. Ingat, DNS menggunakan UDP, yang tidak menjamin pengiriman datagram. Itulah sebabnya protokol DNS itu sendiri telah mencoba ulang dan mekanisme batas waktu terpasang.

— Mels

Ngomong-ngomong, aku tahu kita tidak seharusnya memposting komentar "terima kasih" di sini, tetapi kamu baru saja meningkatkan reputasiku enam kali lipat :)

— Mels

Saya memiliki masalah yang sama baru-baru ini dan menemukan bahwa firewall ASA Cisco tidak dikonfigurasi untuk mendukung EDNS0, spesifikasi yang memungkinkan paket DNS UDP lebih besar dari 512 byte. Setelah admin fw saya mengijinkan hingga 4096 bytes, masalahnya telah teratasi. Info hebat di sini:

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

— rampok
sumber

Saya tidak berpikir itu berlaku di sini. Responsnya jauh di bawah 512 byte untuk permintaan DNS khusus ini, bahkan dengan otoritas dan bagian tambahan.

— Andrew B