Rekod DNS klien VPN: pemilik, TTL dan pembersihan adalah berasingan
Alamat VPN, rekod DNS dan entri cache mempunyai pemilik berasingan: tentukan siapa boleh menerbitkan nama, antara muka mana yang mendaftar dan bila rekod luput.
Komputer riba menyambung, menerima alamat VPN, dan nama yang diselesaikan oleh sistem lain masih menunjuk ke alamat pejabat semalam. Tiada apa yang gagal: alamat diperuntukkan, rekod tidak dikemas kini, dan cache masih menyimpan jawapan lama. Itu tiga objek dengan tiga pemilik, dan hanya satu daripadanya milik VPN. Merancang penerbitan bermakna memutuskan siapa menulis nama, antara muka mana yang mengambil bahagian dan bila data lapuk hilang.
Gejala: nama yang mengikut alamat yang salah
Dari peranti, terowong aktif dan alamat VPN menjawab. Dari stesen kerja rakan sekerja, nama hos yang sama diselesaikan ke alamat peribadi yang tidak lagi dipegang peranti, jadi sambungan tamat masa terhadap mesin yang telah berpindah. Rekod itu berwibawa dan salah, yang lebih buruk daripada tiada. Semua orang mempercayainya dan tiada siapa boleh menyambung.
Kes sebaliknya lebih senyap: rekod hilang dan nama berhenti diselesaikan sama sekali. Kedua-dua hasil datang dari jurang reka bentuk yang sama, dan tiada satu pun dibetulkan dengan menurunkan TTL. Jangka hayat cache yang lebih pendek mengubah berapa lama jawapan salah bertahan, bukan sama ada ia ditulis.
Mulakan dengan bertanya objek mana yang lapuk. Alamat yang diperuntukkan VPN, rekod dalam zon dan jawapan dalam cache penyelesai mempunyai jangka hayat dan pemilik yang berbeza.
Tiga objek, tiga pemilik
VPN memiliki peruntukan alamat, dan boleh memberikan alamat dari kolam dalaman tanpa sebarang pertukaran DHCP sampai ke komputer riba. Zon DNS memiliki rekod, dan model keselamatannya menentukan siapa boleh mencipta atau mengubahnya. Cache penyelesai memiliki salinan yang sedang digunakan pembaca, dan tiada apa yang dilakukan peranti boleh mencapainya.
Menganggap satu komponen melakukan ketiga-tiganya ialah titik reka bentuk itu patah. Alamat yang kelihatan datang dari julat terurus tidak membuktikan pelayan DHCP melakukan pendaftaran, dan pendaftaran yang berjaya tidak membuktikan pembaca telah menyegarkan cache mereka.
| Object | Owner | What it decides |
|---|---|---|
| VPN address | Tunnel gateway pool | Which address the device holds now |
| DNS record | Zone security model | Which name resolves to which address |
| Cached answer | Each resolver | How long a reader keeps the old answer |
Siapa boleh mengemas kini rekod
Dalam zon bersepadu Active Directory dengan kemas kini dinamik yang selamat, kebenaran berada pada rekod itu sendiri. Rekod yang dicipta oleh akaun perkhidmatan DHCP mungkin tidak boleh ditulis oleh akaun komputer riba, dan menukar model pemilikan kemudian ialah peralihan, bukan suis. Itulah sebabnya konflik pemilikan bertahan terhadap setiap tetapan sebelah klien.
Panduan kemas kini dinamik Microsoft mengutamakan pendaftaran sebelah klien untuk titik akhir hibrid yang menyertai domain. Menerimanya bermakna memindahkan rekod sedia ada secara sengaja, bukan sekadar menanda kotak pada penyesuai VPN dan berharap pemilik lama mengalah.
Apabila perkhidmatan DHCP mesti mendaftar untuk kelas peranti lain, berikan model kelayakan dan kebenaran yang disokong untuk peranan itu. Kekalkan rekod hadapan dan balik dalam satu pelan, kerana ia sering diselenggara oleh komponen berbeza dan salah satunya biasanya terlupa.
ipconfig /all
Resolve-DnsName laptop-042.corp.example -Type A
Get-DnsServerResourceRecord -ZoneName corp.example -Name laptop-042
Perintah pertama menunjukkan alamat mana yang dianggap dimiliki peranti dan sama ada sambungan ditetapkan untuk mendaftarkannya. Perintah kedua dan ketiga membandingkan apa yang diselesaikan klien dengan apa yang sebenarnya disimpan zon, yang memisahkan masalah cache daripada masalah berwibawa.
Tiga jam, bukan satu
Penerbitan dan penyegaran ialah jam pertama: bila pengemas kini dibenarkan mengumumkan bahawa alamat telah berubah. TTL cache ialah jam kedua: berapa lama penyelesai boleh menyimpan jawapan yang diterimanya. Pembersihan berwibawa ialah jam ketiga: bagaimana rekod lapuk dibuang oleh proses pendaftaran atau oleh penuaan dan penyapuan.
Jam-jam ini bebas, dan mengelirukannya menghasilkan pembetulan yang tidak berkesan. Perubahan pada satu tidak kelihatan kepada dua yang lain. TTL pendek memendekkan hayat jawapan cache dan tidak memberikan sebarang kebenaran kemas kini. Penyapuan membuang rekod yang tidak disegarkan, dan ia tidak boleh membaiki rekod yang tidak pernah ditulis oleh pemilik yang betul.
Tetapkan TTL berdasarkan seberapa cepat pembaca mesti melihat perubahan, dan tetapkan penyapuan berdasarkan berapa lama peranti yang ditinggalkan harus menyimpan nama. Tiada satu pun nombor itu menentukan siapa boleh menulis rekod, dan tiada nilai TTL mengubah peruntukan alamat menjadi hak pentadbiran DNS.
Rancang penerbitan untuk peranti mudah alih
Putuskan antara muka mana yang mengambil bahagian dalam pendaftaran. Alamat Wi-Fi rumah, alamat VPN dan alamat pejabat lama melayani khalayak berbeza, dan menerbitkan semuanya menghasilkan nama dengan beberapa jawapan yang kegunaannya tidak setara. Daftarkan antara muka yang benar-benar boleh dicapai oleh pembaca yang dimaksudkan.
Kekalkan nama komputer yang stabil sebagai identiti dan anggap alamat sebagai atributnya. Pelihara rekod penemuan domain yang diperlukan peranti, dan jangan lumpuhkan pendaftaran sepenuhnya untuk menyelesaikan masalah rekod berganda yang boleh dibetulkan oleh perubahan kebenaran.
Tulis peruntuk, pengemas kini dan pemilik pembersihan dalam satu rekod, dengan pembaca yang dimaksudkan dinamakan. Apabila nama menunjuk ke alamat yang salah lagi, rekod itu memberitahu anda mana antara ketiga-tiganya yang perlu diperiksa dahulu daripada memulakan semula siasatan.