NXDOMAIN melalui VPN bukan berarti tunnel mati

Menggoda untuk membaca satu pencarian yang gagal sebagai bukti bahwa tunnel runtuh, terutama ketika nama itu berfungsi sepuluh menit sebelumnya. Jawabannya mengatakan hal lain. NXDOMAIN adalah transaksi DNS yang selesai di mana resolver menyatakan bahwa nama yang ditanyakan tidak ada; tunnel yang rusak biasanya menghasilkan kesunyian, timeout, atau upaya resolusi ke server yang salah. Versi argumen tanpa wireshark adalah satu kueri, satu penjawab, dan satu kode jawaban, dan tiga serangkai itu layak dicatat sebelum ada perubahan konfigurasi.

Apa yang sebenarnya dibuktikan jawaban itu

DNS memisahkan hasil yang sering digabung klien menjadi satu kegagalan. Nama yang tidak ada menghasilkan jawaban negatif dengan kode NXDOMAIN, sedangkan nama yang ada tetapi tidak memiliki record dengan tipe yang diminta menghasilkan jawaban sukses dengan bagian jawaban kosong. Keduanya tampak tidak berguna bagi aplikasi, dan hanya satu di antaranya berarti namanya salah.

Perbedaan itu menentukan di mana perbaikan seharusnya dilakukan. Record AAAA yang hilang pada host yang memiliki record A bukanlah host yang hilang, dan menerbitkan ulang sertifikat atau membangun ulang tunnel untuk mengejarnya membuang satu-satunya petunjuk yang tersedia. Perbedaan itu juga menentukan bentuk tindak lanjutnya: masalah penamaan diperbaiki di zona, dan masalah tipe diperbaiki dengan meminta record yang benar atau dengan menerima bahwa keluarga alamat memang tidak ada.

Mitos: nama privat yang hilang berarti tunnel gagal

Mitos itu bertahan karena kedua peristiwa begitu sering datang bersamaan. Klien terhubung ke VPN, sistem operasi mempertahankan resolver yang sudah dipercayainya, dan nama internal yang kini dibutuhkannya ditanyakan ke server yang belum pernah mendengar tentang zona privat. Server itu menjawab dengan jujur dan negatif. Tunnel sedang membawa paket; jawabannya hanya tentang ruang nama yang tidak dilayani penjawab.

Pengaturan split-horizon membuat ini rutin: nama zona yang sama ada secara publik dan internal dengan isi berbeda, dan hanya resolver internal yang mengetahui record privat. Karena itu, memperoleh jawaban negatif yang tampak otoritatif adalah bukti tentang resolver mana yang menjawab, bukan bukti tentang keadaan antarmuka.

Dua detail konfigurasi menentukan hasilnya. Tunnel harus mendorong atau memilih resolver internal, dan klien harus menerapkan pilihan itu pada nama yang dicari. Aturan per domain yang menyebut sufiks sedikit berbeda dari record yang Anda ketik akan mengirim kueri ke jalur publik, dan jawabannya akan benar tetapi tidak berguna.

Tanyakan ke resolver yang tepat dengan nama yang tepat

Catat penjawab sebelum mencatat putusannya. Pencarian yang tidak menunjukkan server mana yang menjawab tidak dapat membedakan masalah kebijakan dari masalah ruang nama, dan keduanya punya perbaikan yang tidak berhubungan.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Dua baris pertama menunjukkan apa yang diputuskan resolver lokal dan siapa yang akan ditanyanya. Pencarian +search mereproduksi apa yang dilakukan aplikasi ketika menambahkan sufiks pencarian, yang sering kali merupakan kueri sebenarnya dan bukan yang diketik ke alat diagnostik. Baris terakhir menanyakan server internal secara langsung, melewati kebijakan klien; jika itu berhasil sementara pencarian biasa gagal, zonanya baik dan perutean kueri tidak.

Cache negatif menjelaskan penundaan setelah perbaikan

Jawaban negatif di-cache secara desain, dan RFC 2308 menjelaskan bagaimana masa hidup cache negatif diturunkan dari record otoritas zona. Karena itu, memperbaiki record atau aturan resolver tidak menjamin perubahan segera pada klien, dan mengulangi pencarian yang terus mengembalikan jawaban cache tidak membuktikan hal baru. Hanya penjawab berbeda, nama berbeda, atau cache yang dikosongkan yang menghasilkan bukti segar.

Kosongkan cache lokal, lalu ulangi kueri yang sama ke penjawab yang sama. Pada sistem yang memakai layanan resolver lokal itu satu perintah; pada sistem lain itu restart layanan atau utilitas platform, dan alat yang spesifik kurang penting daripada mengulang uji yang identik sesudahnya.

Pisahkan nama dari jalur

Setelah nama beresolusi ke alamat privat yang diharapkan, DNS selesai sebagai topik dan jalur aplikasi menjadi pertanyaan berikutnya. Host yang menjawab pencarian tetapi menolak koneksi punya masalah lain, dan terus menyesuaikan resolver setelah jawaban yang benar adalah cara sebuah insiden memperoleh tiga perubahan yang tidak berhubungan. Bandingkan alamat hasil resolusi dengan alamat yang benar-benar didengarkan layanan sebelum menganggap keduanya cocok.

Simpan transkrip: kueri, penjawab, kode, dan alamat hasil resolusi. Catatan itu juga yang membuat laporan kemudian dapat diverifikasi, dan itulah perbedaan antara diagnosis dan cerita tentang tunnel yang tampak lambat.