Mengapa catatan SRV hanya membantu klien yang menanyakannya sendiri

Menambahkan catatan SRV ke zona Anda tidak mengajari klien VPN mana pun untuk mencarinya. Klien harus mengetahui labelnya, memutuskan untuk mengirim kueri, dan bertindak berdasarkan apa yang kembali, dan DNS tidak dapat menyediakan dua hal pertama itu. Karena itu sebagian besar rencana SRV yang gagal adalah masalah klien yang berkostum DNS. Baca dulu perilaku penemuan klien, lalu terbitkan hanya label yang benar-benar ditanyakannya.

Catatan yang tidak ditanyakan siapa pun tidak dapat membantu siapa pun

SRV menerbitkan lokasi sebuah layanan; ia tidak mengumumkannya. Tidak ada yang mendorong catatan ke arah klien, dan tidak ada resolver yang menawarkan nama yang tidak pernah diminta. Pencarian dimulai ketika aplikasi memutuskan untuk melakukannya, jadi labelnya harus berasal dari dokumentasi produk atau dari pengamatan perangkat lunak di jaringan. Di tempat klien tidak memiliki langkah penemuan, sebuah catatan mengubah zona dan tidak yang lain.

Itulah sebabnya satu produk di jaringan dapat mulai berfungsi sementara produk lain tidak terpengaruh oleh perubahan yang sama. Variabelnya adalah perangkat lunak, dan server DNS melakukan persis apa yang diperintahkan. Baca kembali zona setelah penyuntingan juga, karena label yang salah ketik mudah bersembunyi di antara catatan yang semuanya tampak sama.

Baca kolomnya sebelum menulisnya

Sebuah catatan membawa empat nilai, dan masing-masing menjawab pertanyaan yang berbeda: prioritas mengurutkan target yang dapat dicoba klien, bobot membagi beban di antara target dengan prioritas sama, port menamai port transportasi, dan target menamai host. Spesifikasi juga mengizinkan target . untuk berarti layanan sengaja tidak tersedia, yang merupakan jawaban berguna dan bukan jawaban rusak.

Tak satu pun dari kolom itu membawa kredensial, kebijakan sertifikat, atau versi aplikasi, dan klien yang mengabaikan bobot tetap terhubung, hanya tanpa keseimbangan yang dimaksudkan. Target memerlukan catatan alamatnya sendiri, dan seharusnya berupa nama kanonis dan bukan alias. Menerbitkan catatan yang menunjuk ke host tanpa pendengar menghasilkan galat koneksi yang terbaca seperti kesalahan DNS, dan itulah jenis penyesatan termahal. Terbitkan seluruh rantai atau tidak sama sekali.

Temukan label yang benar-benar dikirim klien

Tetapkan label berdasarkan bukti, bukan dugaan tentang nama produk. Entah dokumentasi menyebutkan nama layanan, atau tangkapan menunjukkan kueri yang dikirim klien saat mulai. Kedua jalur berakhir di tempat yang sama: nama dan tipe persis untuk diuji terhadap resolver.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Bandingkan jawaban dengan catatan yang Anda terbitkan, karakter demi karakter, karena garis bawah dan titik di akhir adalah bagian dari nama. Jawaban kosong untuk kueri yang benar-benar dikirim menunjuk ke zona, sedangkan tidak adanya kueri sama sekali menunjuk ke klien, dan temuan itu mengirim Anda ke tim yang berbeda. Jawaban sungguhan tampak seperti baris di bawah, di mana prioritas 20 kalah dari catatan mana pun dengan prioritas lebih rendah dan klien memutar port 8443 pada target yang disebutkan.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

Targetnya juga harus ada

Target yang ter-resolve tidak sama dengan layanan yang menjawab. Periksa catatan alamat untuk target, lalu periksa bahwa ada sesuatu yang mendengarkan pada port dan protokol yang diterbitkan. Catatan TCP yang menunjuk ke pendengar hanya UDP adalah ketidaksesuaian yang tidak dapat diperbaiki oleh penyuntingan zona mana pun. Jaga TTL tetap pendek selama target berubah-ubah, dan perpanjang setelah namanya berhenti bergerak.

Klien yang benar-benar menerapkan penemuan berbeda dalam seberapa banyak catatan yang mereka hormati. Sebagian hanya memakai prioritas, sebagian memperlakukan bobot sebagai saran, dan beberapa mengabaikan port serta menganggap nilai bawaan. Perbedaan itu termasuk dalam catatan Anda di samping label, karena menjelaskan perilaku yang jika tidak tampak seperti kerusakan resolver.

Penemuan bukan autentikasi

Jawaban SRV mengatakan ke mana harus terhubung, dan ia tidak mengatakan apa pun tentang siapa yang dipercaya setelah tiba. Biarkan validasi sertifikat dan pemeriksaan identitas server di klien persis seperti semula, karena catatan yang dapat dipalsukan orang lain tidak boleh menjadi keputusan kepercayaan. Jawaban DNS dapat di-cache dan disunting oleh siapa pun yang mengendalikan zona, yang menjadikannya tempat buruk untuk menyandikan kebijakan.

Untuk klien tanpa dukungan penemuan, distribusikan profil atau URL gateway yang diterimanya, dan catat produk mana yang memakai metode mana. Catatan itu mencegah administrator berikutnya menambahkan catatan dan berharap itu berfungsi di mana-mana. Spesifikasi SRV menjelaskan pemilihan di antara target, dan membacanya sebagai mekanisme otorisasi adalah cara catatan yang membantu menjadi asumsi keamanan. Terbitkan dengan sengaja, sebutkan labelnya dalam dokumentasi Anda, dan perlakukan klien sebagai komponen yang menentukan apakah semua itu penting.