DNS privat Azure lewat VPN: endpoint resolver atau forwarder
Kedua desain menjawab zona privat melalui tunnel. Bandingkan endpoint masuk terkelola dengan VM forwarder, lalu periksa jalur yang harus ada dalam kedua kasus.
Server di lokasi lokal menjangkau VM Azure melalui alamat privat dan tetap tidak dapat menyelesaikan nama host privatnya, yang membuat orang mencari tunnel yang rusak. Tunnelnya baik-baik saja. Yang hilang adalah batas DNS: tidak ada di sisi lokal yang tahu bahwa zona privat Azure tertentu harus dijawab oleh resolver di dalam VNet. Dua desain menutup celah itu, dan keduanya berbeda dalam apa yang akhirnya Anda operasikan, bukan dalam apakah kueri berfungsi.
Tunnel membawa kueri, bukan pengetahuan zona
Koneksi site-to-site memberi paket rute antara kedua jaringan. Koneksi itu tidak memberi tahu server DNS lokal ruang nama mana yang milik Azure atau alamat mana yang harus menjawab, sehingga kueri entah pergi ke internet dan kembali kosong, atau tidak pernah meninggalkan resolver lokal.
Perbaikannya punya dua bagian yang mudah dipisahkan. Satu bagian adalah resolver di dalam VNet yang menerima kueri yang datang melalui tunnel. Bagian lain adalah forwarder bersyarat di sisi lokal yang mengirim tepat satu ruang nama ke resolver tersebut. Tidak ada bagian yang bekerja sendiri.
Anggap zonanya adalah cloud.corp.example untuk sisa penjelasan ini, dan perlakukan setiap alamat sebagai ilustrasi.
Opsi A: endpoint masuk terkelola
Azure DNS Private Resolver menyediakan endpoint masuk yang menerima kueri DNS dari luar VNet. Anda menempatkannya di subnet terdelegasi khusus, menautkan zona privat ke VNet tersebut, dan mencatat alamat masuk yang diberikan layanan.
Di server DNS lokal Anda kemudian membuat forwarder bersyarat untuk ruang nama yang tepat menuju alamat itu:
Namespace: cloud.corp.example
Forward to: 10.20.2.4Prosedur DNS hibrida Microsoft mendokumentasikan tautan zona dan langkah forwarder. Jalur terkelola tidak menyisakan perangkat lunak DNS untuk ditambal, dan alamat endpoint tetap stabil sepanjang masa hidup sumber daya.
Harganya adalah Anda kini memiliki sumber daya resolver, delegasi subnetnya, dan biayanya, yang nyata bahkan ketika volume kueri sangat kecil.
Opsi B: VM forwarder di dalam VNet
Desain lama menjalankan perangkat lunak DNS di VM biasa di dalam VNet: Windows DNS, BIND, atau dnsmasq, dengan zona privat dihosting secara lokal atau diteruskan ke resolver Azure di 168.63.129.16. Forwarder bersyarat lokal menunjuk ke alamat privat VM itu.
Opsi ini akrab bagi tim yang sudah mengoperasikan server DNS, dan dapat membawa logika tambahan seperti pencatatan log atau jawaban split-horizon. Opsi ini juga mewarisi setiap tugas operasional server DNS: penambalan, instans kedua untuk ketersediaan, pemantauan, dan jalur pembangunan ulang saat VM diganti dan alamatnya berubah.
Host VNet biasa bukan proksi DNS sampai layanan dipasang dan diizinkan menjawab klien tersebut, dan itulah langkah yang dilewati orang saat mengkloning VM.
Mana yang cocok untuk operasi Anda
Perbandingannya bukan tentang desain mana yang lebih cepat. Ini tentang apakah Anda ingin mengoperasikan perangkat lunak DNS sama sekali, dan apakah volume kueri membenarkan sumber daya terkelola yang menagih per endpoint dan per kueri.
| Question | Managed inbound endpoint | Forwarder VM |
|---|---|---|
| Software to patch | None | The DNS service on every instance |
| Address stability | Fixed for the resource lifetime | Tied to the VM or its reserved address |
| Availability work | Handled by the service | Second instance, health checks, failover |
| Extra logic | Limited to resolver features | Whatever the DNS software supports |
Baris mana pun yang memutuskan, aturan forwarder di sisi lokal terlihat sama. Itulah bagian yang harus ada di kedua desain, dan itulah bagian yang paling sering hilang ketika seseorang melaporkan bahwa resolusi berfungsi dari dalam Azure tetapi tidak dari kantor.
Periksa jalurnya secara berurutan
Pastikan zona tertaut ke VNet yang menyimpan resolver, dan forwarder lokal menyebut ruang nama, bukan domain induk. Forwarder untuk corp.example tidak akan cocok dengan cloud.corp.example kecuali resolver itu sendiri mendelegasikan, dan ketidakcocokan menghasilkan jawaban negatif bersih yang tampak seperti catatan yang hilang.
Lalu periksa apakah kueri mencapai endpoint: sumber lokal memerlukan rute ke alamat resolver dan jalur kembali, dan port 53 untuk UDP maupun TCP sebaiknya diizinkan di tempat kebijakan mengizinkannya. NSG tidak dapat menyediakan catatan zona yang hilang, dan zona yang benar tidak dapat menjawab kueri yang tidak pernah tiba.
Simpan FQDN yang diminta di samping resolver yang Anda pilih saat mendiagnosis, dan pisahkan timeout dari jawaban negatif. Timeout adalah masalah rute atau kebijakan. Jawaban negatif berarti kueri tiba dan ruang nama tidak cocok. Urutan kerja: tautkan zona, tambahkan forwarder bersyarat, buka port 53 di kedua arah, uji satu nama dari lokal, dan baru setelah itu lihat otorisasi aplikasi itu sendiri.