Catatan DNS klien VPN: pemilik, TTL, dan pembersihan adalah hal terpisah

Laptop terhubung, menerima alamat VPN, dan nama yang diresolusi sistem lain masih menunjuk ke alamat kantor kemarin. Tidak ada yang gagal: sebuah alamat dialokasikan, sebuah catatan tidak diperbarui, dan sebuah cache masih menyimpan jawaban lama. Itu tiga objek dengan tiga pemilik, dan hanya satu di antaranya milik VPN. Merencanakan penerbitan berarti memutuskan siapa yang menulis nama, antarmuka mana yang berpartisipasi, dan kapan data usang hilang.

Gejalanya: nama yang mengikuti alamat yang salah

Dari perangkat, terowongan aktif dan alamat VPN menjawab. Dari stasiun kerja rekan, nama host yang sama diresolusi ke alamat privat yang tidak lagi dipegang perangkat, sehingga koneksi kehabisan waktu terhadap mesin yang sudah pindah. Catatan itu otoritatif dan salah, yang lebih buruk daripada tidak ada. Semua orang mempercayainya dan tidak ada yang bisa terhubung.

Kasus sebaliknya lebih sunyi: catatan hilang dan nama berhenti diresolusi sama sekali. Kedua hasil berasal dari celah desain yang sama, dan tidak satu pun diperbaiki dengan menurunkan TTL. Masa hidup cache yang lebih pendek mengubah berapa lama jawaban salah bertahan, bukan apakah jawaban itu ditulis.

Mulailah dengan bertanya objek mana yang usang. Alamat yang dialokasikan VPN, catatan di zona, dan jawaban di cache resolver punya masa hidup dan pemilik berbeda.

Tiga objek, tiga pemilik

VPN memiliki alokasi alamat, dan dapat memberikan alamat dari kumpulan internal tanpa pertukaran DHCP apa pun mencapai laptop. Zona DNS memiliki catatan, dan model keamanannya menentukan siapa yang boleh membuat atau mengubahnya. Cache resolver memiliki salinan yang sedang dipakai pembaca, dan tidak ada yang dilakukan perangkat dapat menjangkaunya.

Mengasumsikan satu komponen melakukan ketiganya adalah titik desain itu patah. Alamat yang tampak berasal dari rentang terkelola tidak membuktikan server DHCP melakukan pendaftaran, dan pendaftaran yang berhasil tidak membuktikan pembaca telah menyegarkan cache mereka.

Siapa yang boleh memperbarui catatan

Di zona terintegrasi Active Directory dengan pembaruan dinamis yang aman, izin berada pada catatan itu sendiri. Catatan yang dibuat akun layanan DHCP mungkin tidak dapat ditulis oleh akun komputer laptop, dan mengubah model kepemilikan nanti adalah transisi, bukan tombol. Itulah sebabnya konflik kepemilikan bertahan terhadap setiap pengaturan sisi klien.

Panduan pembaruan dinamis Microsoft mengutamakan pendaftaran sisi klien untuk titik akhir hibrida yang tergabung dalam domain. Mengadopsinya berarti memindahkan catatan yang ada secara sengaja, bukan sekadar mencentang kotak pada adaptor VPN dan berharap pemilik lama mengalah.

Ketika layanan DHCP harus mendaftar untuk kelas perangkat lain, berikan model kredensial dan izin yang didukung untuk peran itu. Jaga catatan maju dan balik dalam satu rencana, karena keduanya sering dipelihara komponen berbeda dan salah satunya biasanya terlupakan.

ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042

Perintah pertama menunjukkan alamat mana yang diyakini dimiliki perangkat dan apakah koneksi diatur untuk mendaftarkannya. Perintah kedua dan ketiga membandingkan apa yang diresolusi klien dengan apa yang sebenarnya disimpan zona, yang memisahkan masalah cache dari masalah otoritatif.

Tiga jam, bukan satu

Penerbitan dan penyegaran adalah jam pertama: kapan pembaru yang berwenang mengumumkan bahwa alamat berubah. TTL cache adalah jam kedua: berapa lama resolver boleh menyimpan jawaban yang diterimanya. Pembersihan otoritatif adalah jam ketiga: bagaimana catatan usang dihapus oleh proses pendaftaran atau oleh penuaan dan penyapuan.

Jam-jam ini independen, dan mencampurnya menghasilkan perbaikan yang tidak bekerja. Perubahan pada satu tidak terlihat oleh dua lainnya. TTL pendek mempersingkat umur jawaban yang di-cache dan tidak memberikan izin pembaruan. Penyapuan menghapus catatan yang tidak disegarkan, dan tidak dapat memperbaiki catatan yang tidak pernah ditulis pemilik yang benar.

Tetapkan TTL dari seberapa cepat pembaca harus melihat perubahan, dan tetapkan penyapuan dari berapa lama perangkat yang ditinggalkan harus menyimpan nama. Tidak ada dari kedua angka itu yang menentukan siapa yang boleh menulis catatan, dan tidak ada nilai TTL yang mengubah alokasi alamat menjadi hak administrasi DNS.

Rencanakan penerbitan untuk perangkat keliling

Putuskan antarmuka mana yang berpartisipasi dalam pendaftaran. Alamat Wi-Fi rumah, alamat VPN, dan alamat kantor lama melayani audiens berbeda, dan menerbitkan semuanya menghasilkan nama dengan beberapa jawaban yang kegunaannya tidak setara. Daftarkan antarmuka yang benar-benar dapat dijangkau pembaca yang dituju.

Pertahankan nama komputer yang stabil sebagai identitas dan perlakukan alamat sebagai atributnya. Pertahankan catatan penemuan domain yang dibutuhkan perangkat, dan jangan menonaktifkan pendaftaran secara menyeluruh untuk menyelesaikan masalah catatan ganda yang bisa diperbaiki oleh perubahan izin.

Tulis pengalokasi, pembaru, dan pemilik pembersihan ke dalam satu catatan, dengan pembaca yang dituju disebutkan. Ketika nama menunjuk ke alamat yang salah lagi, catatan itu memberi tahu Anda mana dari ketiganya yang harus diperiksa lebih dulu alih-alih memulai penyelidikan dari awal.