Mengapa Zon Route 53 Peribadi Memulangkan NXDOMAIN untuk Nama Awam

Zon Route 53 peribadi menggantikan jawapan untuk sesuatu nama dan bukannya bergabung dengan rekod awam, dan itu mengejutkan orang pada saat yang paling teruk. Tambah satu rekod dalaman untuk api.example.net dalam zon peribadi untuk example.net, kaitkan dengan VPC, dan setiap nama lain di bawah induk itu kini dijawab hanya daripada zon peribadi. Klien yang semalam boleh mencapai www.example.net hari ini menerima jawapan negatif. Panduan di bawah bermula daripada pertanyaan yang gagal itu dan bergerak ke luar menuju zon yang menjawabnya.

Mulakan dengan pertanyaan, bukan konsol

Hasilkan semula kegagalan pada klien yang melaporkannya, dan catat nama serta jenis rekod yang tepat. Nama yang gagal untuk A mungkin masih boleh diselesaikan untuk AAAA, dan pelayar yang mencuba semula nama dalam cache menyembunyikan yang mana satu rosak. Jalankan pertanyaan dua kali: sekali melalui penyelesai yang benar-benar digunakan oleh klien, dan sekali dengan penjejakan yang memintasnya.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

Perintah kedua yang penting. Baris status dan bahagian autoritinya menamakan zon yang menghasilkan jawapan, jadi anda boleh membezakan jawapan negatif daripada zon peribadi dengan tamat masa, port yang disekat atau penyelesai yang tidak pernah menerima pertanyaan itu. resolvectl menunjukkan huluan mana yang ditanya, dan selalunya ia bukan penyelesai yang anda andaikan dihantar oleh VPN.

Jika pertanyaan yang dijejak memulangkan alamat awam manakala yang biasa tidak, rekod awam itu utuh dan paparan peribadi yang menjawab. Perbandingan tunggal itu menentukan separuh mana daripada baki halaman ini terpakai kepada anda.

Baca zon mana yang menjawab

Jawapan yang membawa NXDOMAIN dengan SOA zon peribadi dalam bahagian autoriti ialah jawapan muktamad daripada zon itu, bukan carian yang gagal. Route 53 Resolver memilih zon dihoskan peribadi kerana namanya sepadan, kemudian tidak menemui rekod jenis yang diminta, dan tingkah laku yang didokumenkan ialah memulangkan jawapan negatif dan bukannya menyerahkan soalan itu kepada DNS awam.

Pemilihan mengikut kekhususan. Apabila beberapa ruang nama peribadi bertindih, zon yang paling khusus dan sepadan menang, dan induk peribadi yang lebih luas tidak mendapat peluang kedua untuk nama yang tidak dimiliki oleh zon anak yang dipilih. Peraturan penghantaran menambah satu lagi lapisan, kerana peraturan Resolver khusus domain boleh mengatasi perkaitan zon dihoskan peribadi. Senaraikan perkaitan dan peraturan sebelum membuat kesimpulan bahawa sesuatu zon kosong.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Kedua-dua perintah memerlukan kelayakan untuk akaun yang memiliki zon itu, dan yang kedua memerlukan ID zon daripada yang pertama. Gantikannya dengan ID anda sendiri; pemegang tempat di atas sengaja bukan yang sebenar.

Mengapa zon peribadi menang

Perkaitan itulah yang menjadikan zon kelihatan kepada VPC, dan penyelesai dalam VPC itu yang menerapkannya. Zon peribadi yang tidak dikaitkan dengan VPC tempat trafik klien datang tidak mempunyai kesan sama sekali, manakala perkaitan dengan VPC yang salah menghasilkan jawapan peribadi untuk populasi yang salah. Semak senarai perkaitan sebelum menyunting rekod, kerana zon boleh betul tetapi masih tidak kelihatan.

Ruang nama yang bertindih ialah sumber kekeliruan kedua. Zon peribadi untuk example.net dan zon peribadi untuk api.example.net kedua-duanya sepadan dengan pertanyaan API, dan yang lebih khusus menjawab. Itu berguna apabila anda mahu ruang nama dalaman yang sempit, dan berbahaya apabila zon sempit itu kekurangan rekod yang ada pada zon yang lebih luas. Pertimbangan zon dihoskan peribadi dalam dokumentasi Route 53 menerangkan tingkah laku jatuh ke bawah dan keutamaan peraturan, dan ia berbaloi dibaca sebelum anda menambah zon bertindih kedua.

Tiada satu pun daripada ini mengubah zon awam. Penyelesai awam masih menjawab rekod awam dengan betul, dan itulah sebabnya kegagalan ini kelihatan seperti masalah klien kepada semua orang di luar VPC.

Pilih ruang nama sebelum menambah rekod

Jika hanya keluarga baharu perkhidmatan dalaman memerlukan nama peribadi, berikannya subdomain peribadi khusus dan biarkan induk awam tidak diusik. Nama seperti internal.example.net tidak boleh membayangi www.example.net, dan jejari kesan rekod yang hilang terhad kepada nama yang anda cipta untuk tujuan itu. Kosnya ialah URL dan sijil sedia ada mungkin tidak sepadan dengan nama baharu.

Apabila pengguna awam dan peribadi mesti mengekalkan nama hos yang sama, DNS paparan berpecah ialah reka bentuk yang disokong dan ia memerlukan anda mengekalkan rekod dalam setiap paparan secara eksplisit. Zon peribadi luas dengan satu rekod di dalamnya tidak memelihara kebergantungan awam di bawah zon itu; ia menggantikannya dengan zon yang mempunyai satu rekod.

Senaraikan nama yang benar-benar dipanggil oleh aplikasi sebelum anda mengarahkan populasi klien ke paparan peribadi. Hos log masuk, hos aset statik, sasaran ubah hala dan titik akhir API ialah yang pertama rosak, dan ia biasanya bertaburan merentas rekod beberapa pasukan.

Jejaki laluan penyelesai, kemudian laluan rangkaian

Komputer riba hanya melihat paparan peribadi jika pertanyaannya sampai kepada penyelesai yang mempunyai perkaitan itu. Menyunting fail hosts pada pelayan VPN tidak menerbitkan apa-apa kepada klien yang bersambung, dan klien yang dikonfigurasikan dengan penyelesai awam akan terus menerima jawapan awam selagi terowong aktif. Sahkan alamat penyelesai yang diterima oleh klien, kemudian ulang pertanyaan daripada klien dan bukan daripada pelayan.

Sebaik sahaja nama diselesaikan, uji laluan ke alamat yang dipulangkan sebagai langkah berasingan, contohnya dengan ip route get terhadap alamat yang dipulangkan oleh pertanyaan. Jawapan peribadi yang betul tanpa laluan ke alamat itu ialah masalah penghalaan, dan jawapan tentang rekod yang hilang ialah masalah paparan DNS; menganggap kedua-duanya sebagai satu masalah menghasilkan pembetulan yang tidak bertahan. Biarkan pemeriksaan nama hos TLS dan sijil perkhidmatan tidak berubah, kerana alamat peribadi mengubah ke mana sambungan pergi dan bukan apa-apa tentang sijil mana yang sah.

Akhiri dengan mencatat zon, perkaitan, penyelesai dan nama yang anda sahkan dalam nota perubahan. Dengan itu orang seterusnya yang menambah rekod akan tahu ruang nama mana yang berwibawa untuk populasi klien itu.