Mengapa Zona Route 53 Privat Mengembalikan NXDOMAIN untuk Nama Publik

Zona Route 53 privat menggantikan jawaban untuk sebuah nama alih-alih menggabungkannya dengan catatan publik, dan itu mengejutkan orang pada saat terburuk. Tambahkan satu catatan internal untuk api.example.net di zona privat untuk example.net, kaitkan dengan sebuah VPC, dan setiap nama lain di bawah induk itu kini dijawab hanya dari zona privat. Klien yang kemarin bisa menjangkau www.example.net hari ini mendapat jawaban negatif. Penelusuran di bawah dimulai dari kueri yang gagal itu dan bergerak keluar menuju zona yang menjawabnya.

Mulailah dari kueri, bukan dari konsol

Reproduksi kegagalan pada klien yang melaporkannya, dan catat nama serta tipe catatan yang tepat. Nama yang gagal untuk A mungkin masih bisa diselesaikan untuk AAAA, dan peramban yang mencoba ulang nama tersimpan di cache menyembunyikan mana yang rusak. Jalankan kueri dua kali: sekali melalui resolver yang benar-benar dipakai klien, dan sekali dengan penelusuran yang melewatinya.

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

Perintah kedua adalah yang penting. Baris status dan bagian otoritasnya menyebut zona yang menghasilkan jawaban, sehingga Anda bisa membedakan jawaban negatif dari zona privat dengan timeout, port yang diblokir, atau resolver yang tidak pernah menerima kueri. resolvectl menunjukkan upstream mana yang ditanyai, dan sering kali itu bukan resolver yang Anda anggap dikirim oleh VPN.

Jika kueri yang ditelusuri mengembalikan alamat publik sedangkan kueri normal tidak, catatan publik utuh dan tampilan privat yang menjawab. Perbandingan tunggal itulah yang menentukan separuh mana dari sisa halaman ini berlaku bagi Anda.

Baca zona mana yang menjawab

Jawaban yang membawa NXDOMAIN dengan SOA zona privat di bagian otoritas adalah jawaban pasti dari zona itu, bukan kegagalan pencarian. Route 53 Resolver memilih zona terkelola privat karena namanya cocok, lalu tidak menemukan catatan dengan tipe yang diminta, dan perilaku yang didokumentasikan adalah mengembalikan jawaban negatif alih-alih meneruskan pertanyaan ke DNS publik.

Pemilihan mengikuti kekhususan. Bila ada beberapa ruang nama privat yang tumpang tindih, zona yang paling spesifik dan cocok menang, dan induk privat yang lebih luas tidak mendapat kesempatan kedua untuk nama yang tidak dimiliki zona anak terpilih. Aturan penerusan menambah lapisan lain, karena aturan Resolver khusus domain bisa mengalahkan pengaitan zona terkelola privat. Sebutkan pengaitan dan aturannya sebelum menyimpulkan bahwa sebuah zona 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 perintah memerlukan kredensial untuk akun yang memiliki zona, dan yang kedua memerlukan ID zona dari yang pertama. Gantilah dengan ID Anda sendiri; placeholder di atas sengaja bukan ID nyata.

Mengapa zona privat menang

Pengaitanlah yang membuat zona terlihat oleh sebuah VPC, dan resolver di VPC itulah yang menerapkannya. Zona privat yang tidak dikaitkan dengan VPC asal lalu lintas klien tidak berpengaruh sama sekali, sedangkan pengaitan ke VPC yang salah menghasilkan jawaban privat untuk populasi yang salah. Periksa daftar pengaitan sebelum menyunting catatan, karena zona bisa benar tetapi tetap tidak terlihat.

Ruang nama yang tumpang tindih adalah sumber kebingungan kedua. Zona privat untuk example.net dan zona privat untuk api.example.net keduanya cocok dengan kueri API, dan yang lebih spesifik yang menjawab. Itu berguna ketika Anda ingin ruang nama internal yang sempit, dan berbahaya ketika zona sempit itu kehilangan catatan yang dimiliki zona yang lebih luas. Pertimbangan zona terkelola privat di dokumentasi Route 53 menjelaskan perilaku penerusan ke bawah dan prioritas aturan, dan keduanya layak dibaca sebelum Anda menambahkan zona tumpang tindih kedua.

Tidak ada dari semua ini yang mengubah zona publik. Resolver publik tetap menjawab catatan publik dengan benar, dan itulah sebabnya kegagalan ini tampak seperti masalah klien bagi semua orang di luar VPC.

Pilih ruang nama sebelum menambahkan catatan

Jika hanya keluarga baru layanan internal yang membutuhkan nama privat, beri ia subdomain privat khusus dan biarkan induk publik tetap apa adanya. Nama seperti internal.example.net tidak bisa membayangi www.example.net, dan radius dampak dari catatan yang hilang terbatas pada nama yang Anda buat untuk keperluan itu. Biayanya adalah URL dan sertifikat yang ada mungkin tidak cocok dengan nama baru.

Ketika pengguna publik dan privat harus mempertahankan nama host yang sama, DNS tampilan terpisah adalah desain yang didukung dan mengharuskan Anda memelihara catatan di setiap tampilan secara eksplisit. Zona privat luas dengan satu catatan di dalamnya tidak mempertahankan dependensi publik di bawah zona itu; ia menggantinya dengan zona yang punya satu catatan.

Inventarisasi nama yang benar-benar dipanggil aplikasi sebelum Anda mengarahkan populasi klien ke tampilan privat. Host login, host aset statis, tujuan pengalihan, dan titik akhir API adalah yang pertama rusak, dan biasanya tersebar di catatan beberapa tim.

Lacak jalur resolver, lalu rute

Laptop hanya melihat tampilan privat jika kuerinya mencapai resolver yang memiliki pengaitan itu. Menyunting berkas hosts di server VPN tidak menerbitkan apa pun ke klien yang terhubung, dan klien yang dikonfigurasi dengan resolver publik akan terus mendapat jawaban publik selama terowongan aktif. Pastikan alamat resolver yang diterima klien, lalu ulangi kueri dari klien, bukan dari server.

Setelah nama terselesaikan, uji jalur ke alamat yang dikembalikan sebagai langkah terpisah, misalnya dengan ip route get terhadap alamat yang dikembalikan kueri. Jawaban privat yang benar tanpa rute ke alamat itu adalah masalah perutean, dan jawaban tentang catatan yang hilang adalah masalah tampilan DNS; memperlakukan keduanya sebagai satu masalah menghasilkan perbaikan yang tidak bertahan. Biarkan pemeriksaan nama host TLS dan sertifikat layanan tidak berubah, karena alamat privat mengubah ke mana koneksi pergi dan bukan apa pun tentang sertifikat mana yang valid.

Akhiri dengan mencatat zona, pengaitan, resolver, dan nama yang Anda verifikasi di catatan perubahan. Dengan begitu orang berikutnya yang menambahkan catatan akan tahu ruang nama mana yang berwenang untuk populasi klien itu.