Pencarian DNS terkadang membutuhkan waktu 5 detik

Saya memiliki VM yang menjalankan Debian Wheezy di mana beberapa pencarian nama host memerlukan beberapa detik untuk diselesaikan, meskipun resolver segera menjawab. Anehnya, pencarian dengan getaddrinfo()terpengaruh, tetapi gethostbyname()tidak.

Saya telah beralih ke resolver Google untuk mengecualikan kemungkinan bahwa yang lokal rusak, jadi /etc/resolv.confsepertinya:

search my-domain.com
nameserver 8.8.4.4
nameserver 8.8.8.8

Saya nsswitch.confmemiliki garis:

hosts: files dns

dan saya /etc/hoststidak mengandung sesuatu yang tidak biasa.

Jika saya mencoba telnet webserver 80, itu hang selama beberapa detik sebelum mendapatkan resolusi nama. Sebuah ltracekeluaran [1] menunjukkan bahwa menguasainya adalah dalam getaddrinfo()panggilan:

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

Namun, tcpdumpterungkap bahwa server nama itu menjawab dengan segera, dan hanya pada balasan kedua yang tidak telnetdiblokir. Balasannya terlihat sama:

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)

Saya telah memeriksa log firewall host dan tidak ada port 53 yang diblokir.

Apa yang menyebabkan balasan DNS pertama diabaikan?

[1] Saya telah menambahkan beberapa baris ke saya ltrace.confsehingga saya dapat melihat di dalam addrinfostruct.

linux dns

— Flup
sumber

Bagaimana pengaturan NIC VM? Dijembatani NAT?

— slm

Itu rusak. Saya tidak yakin persis di mana NAT diterapkan (apakah dengan ESX atau lebih jauh ke hulu); Saya bisa mencari tahu apakah Anda pikir itu penting.

— Flup

Saya menduga bahwa itu adalah NAT + VM yang mempengaruhi ini.

— slm

Bisa jadi - lihat komentar saya pada jawaban Kempniu di bawah ini.

— Flup

Itu jaringan, tetapi tidak secara khusus NAT yang menyebabkan ini - lihat jawaban saya di bawah ini.

— Flup

Jawaban:

Balasan DNS pertama tidak diabaikan. getaddrinfo()tidak kembali sampai ia menerima respons terhadap permintaan AAAA pertama (ID: 26090). Jadi masalah sebenarnya di sini adalah mengapa mesin Anda belum segera menerima respons untuk kueri AAAA, sementara itu telah menerima respons untuk kueri A (ID: 54755).

Salah satu perbedaan antara getaddrinfo()dan gethostbyname()adalah bahwa yang pertama mendukung kedua IPv4 dan IPv6, sedangkan yang kedua hanya mendukung IPv4. Jadi ketika Anda menelepon getaddrinfo()dengan ai_familyset ke 0 ( AF_UNSPEC), itu tidak akan kembali sampai mendapat respon (atau memukul timeout) untuk kedua A dan AAAA query untuk nama domain yang disediakan. gethostbyname()hanya pertanyaan untuk catatan A.

Sulit untuk menentukan dari jarak jauh apa yang mungkin menyebabkan masalah Anda, terutama bahwa Anda telah memotong beberapa tcpdumpoutput. Sesuatu mungkin secara selektif memfilter / menjatuhkan lalu lintas DNS antara VM Anda dan Google DNS resolver. Saya telah mencoba mereproduksi masalah Anda menggunakan KVM Debian Wheezy VM, tetapi telnet ifconfig.mehampir segera mencetak Trying <IP_address_here>...baris (berarti itu sudah menyelesaikan nama saat itu).

— Kempniu
sumber

Terima kasih atas jawaban terinci Anda. Saya belum memotong apa pun dari tcpdump, saya hanya memasukkan garis untuk menjelaskan di mana jeda itu. Anda pasti memberi saya sesuatu untuk dilanjutkan; Saya tidak menyadari perbedaan yang signifikan antara dua panggilan perpustakaan.

— Flup

Jika tidak ada lagi paket terkait-DNS yang mengenai mesin Anda, mungkin ada sesuatu yang menyaring lalu lintasnya (tidak harus dengan sengaja). Lagi pula, jika Anda menemukan solusinya, maukah Anda membagikannya di sini?

— Kempniu

Aku akan melakukannya. Setelah menyiapkan resolver tes, saya dapat melihat secara meyakinkan bahwa satu paket balasan - satu dari pertanyaan saya - akan hilang setiap saat. Saya curiga ada sesuatu di dalam atau di dekat infrastruktur VMware yang melakukannya, jadi saya telah menghubungi rekanan saya yang menangani masalah itu. Ketika saya sampai di bagian bawahnya saya akan kembali dan menambahkan detail. Terima kasih lagi!

— Flup

Solusi ditambahkan dalam jawaban saya sendiri. Sekali lagi terima kasih banyak atas bantuan Anda.

— Flup

Ini disebabkan oleh aturan yang terlalu ketat pada firewall Juniper yang berada di depan infrastruktur VMware.

Saya membuat test resolver sehingga saya bisa melihat kedua sisi percakapan, dan paket yang hilang yang diidentifikasi oleh Kempniu dalam jawabannya yang sangat bagus memang dijatuhkan di suatu tempat di sepanjang jalan. Sebagaimana dicatat dalam jawaban itu, getaddrinfo()tanpa keluarga alamat yang ditentukan akan menunggu jawaban yang berkaitan dengan semua keluarga yang didukung sebelum kembali (atau, dalam kasus saya, waktu habis).

Rekan saya yang menjalankan jaringan mencatat itu

Perilaku default pada firewall Juniper adalah untuk menutup sesi terkait DNS segera setelah balasan DNS yang cocok dengan sesi itu diterima.

Jadi firewall melihat respons IPv4, mencatat bahwa itu menjawab permintaan VM, dan menutup jalur masuk untuk port itu. Paket balasan IPv6 berikut karena itu dijatuhkan. Saya tidak tahu mengapa kedua paket berhasil melewati kedua kalinya, tetapi menonaktifkan fitur ini di firewall memperbaiki masalah.

Ini adalah ekstrak terkait dari Juniper KB:

Berikut adalah skenario di mana paket Balas DNS dijatuhkan:

Sesi untuk lalu lintas DNS dibuat ketika paket kueri DNS pertama mengenai firewall dan ada kebijakan perijinan yang dikonfigurasi. Batas waktu default adalah 60 detik.

Segera sebelum sesi ditutup, permintaan DNS baru dikirimkan, dan karena cocok dengan sesi yang ada (karena pasangan sumber dan port tujuan / IP selalu sama), maka diteruskan oleh firewall. Perhatikan bahwa batas waktu sesi tidak di-refresh sesuai dengan paket yang baru tiba.

Sesi DNS yang dibuat sudah usang saat respons permintaan DNS pertama (balas) mengenai perangkat, berapapun sisa waktu habisnya.

Ketika balasan DNS dilewatkan melalui firewall, sesi sudah usang.

Semua balasan DNS berikutnya dijatuhkan oleh firewall, karena tidak ada sesi.

Jika Anda berpikir untuk memperbaiki jawaban ini, mohon junjung juga jawaban Kempniu. Tanpa itu saya masih akan berusaha mencari beberapa masalah konfigurasi pada VM.

— Flup
sumber

Kami telah mengalami gejala yang sama pada Debian 8.2. Kami disebabkan oleh sebab yang berbeda, dan "solusi" berbeda (sisi klien). Saya membuat blog tentang masalah khusus kami dan masalah yang lebih umum: philippecloutier.com/... Saya ingin berterima kasih kepada Flup dan Kempniu, karena pertanyaan dan jawaban Anda menempatkan saya di jalur yang benar.

— Philippe Cloutier