Pembelian akaun AWS: Panduan mendalam untuk penyelesaian dan penyelesaian pengecualian DNS cloud Amazon!
Dalam seni bina pengkomputeran awan, DNS (sistem nama domain) adalah seperti navigator di dunia digital. Setelah resolusi DNS pada AWS tidak normal, perkhidmatan perusahaan mungkin langsung jatuh ke dalam keadaan "hilang": contoh EC2 tidak dapat mengakses API luaran, masa panggilan perkhidmatan mikro dalaman, dan pertemuan pengguna
NXDOMAIN
Atau
SERVFAIL
Laporkan ralat.
Oleh kerana seni bina rangkaian AWS mengintegrasikan VPC (Virtual Private Cloud), Route 53, VPC Resolver(.2 Resolver) dan kemungkinan seni bina awan hibrid tempatan, penyelidikan DNS sering kali mempunyai kerumitan tertentu. Artikel ini akan bermula dari
Analisis rangkaian awam
,
Analisis dalaman VPC
,
Senibina awan hibrid
Serta
Hambatan prestasi
Empat dimensi, untuk anda membongkar proses penyelesaian dan penyelesaian pengecualian resolusi AWS DNS secara mendalam.
1. Kotak alat penyiasatan teras: "stetoskop" pertama
Sebelum masuk ke dalam seni bina, ketika menghadapi pengecualian penghuraian, anda harus terlebih dahulu menggunakan alat asli berikut pada contoh EC2 yang terjejas atau terminal tempatan untuk mendapatkan keadaan ralat yang mendasari:
Dig (Linux/macOS) atau nslookup (Windows) menggunakan di g yourdomain.com untuk memerhatikan Status yang dikembalikan. Keadaan biasa termasuk: NOERROR: Penyelesaian yang berjaya, mungkin masalahnya ialah cache lapisan aplikasi atau port tidak berfungsi. NXDOMAIN: Nama domain tidak ada, biasanya rekod tidak sesuai atau belum diselaraskan. SERVFAIL: Kegagalan pemprosesan pelayan DNS lebih biasa pada kesalahan konfigurasi kunci DNSSEC atau kegagalan penghantaran hulu.
Tentukan ujian pelayan DNS untuk memaksa penggunaan pelayan nama berwibawa AWS Route 53 untuk membuat pertanyaan, dan tentukan sama ada masalah analisis rekursif global atau masalah sisi AWS: Bashdig @ ns-xxxx.awsdns-xx.com yourdomain.com
2. Persekitaran rangkaian awam: Analisis kawasan jagaan awam Route 53 yang tidak normal
Sekiranya anda bertanggungjawab untuk pengurusan berbilang akaun dalam operasi dan penyelenggaraan awan perusahaan, anda mungkin perlu kerap menyesuaikan aset nama domain anda. Sebelum siasatan rasmi, pastikan akaun anda mempunyai kuasa pengurusan yang mencukupi. Sekiranya ia adalah penyebaran skala besar di peringkat perusahaan, pastikan ia dilakukan melalui saluran yang sesuai dan stabil
Pembelian akaun AWS
Penyelenggaraan untuk mendapatkan Sokongan Perusahaan, yang sangat penting ketika menghadapi kegagalan kelas yang tidak dikonfigurasi.
Kegagalan analisis rangkaian awam biasanya disebabkan oleh tiga sebab berikut:
1. Nama Servers (NS) di pendaftar tidak konsisten dengan Route 53
Ini adalah kesilapan manusia yang paling biasa. Apabila anda membuat Zon Hosted Awam baru di Route 53, A
WS akan memberikan 4 pelayan nama secara rawak.
Kaedah penyelesaian: Periksa rantai kebenaran nama domain root melalui e yourdomain.com trac besar, atau gunakan alat Whois untuk melihat rekod NS yang diisi oleh pendaftar.
Penyelesaian: Log masuk ke latar belakang pendaftar nama domain anda dan ubah rekod NS sepenuhnya dan tepat ke 4 pelayan nama AWS yang dipaparkan di kawasan hosting Route 53 semasa.
2. Pautan putus konfigurasi tandatangan DNSSEC
Untuk keselamatan, banyak syarikat telah membuka DNSSEC. Sekiranya rekod DS(Delegation Signer) tidak dikemas kini di pendaftar semasa memindahkan nama domain atau menukar kawasan hosting, penghurai rekursif global akan kembali secara langsung kerana mereka tidak dapat mengesahkan tandatangan.
SERVFAIL
。
Penyelesaian: Sekiranya tidak diperlukan, matikan DNSSEC terlebih dahulu di sisi pendaftar dan Route 53; jika perlu, pastikan untuk mengeksport maklumat KSK (kunci tandatangan kunci) Route 53, dan pergi ke latar belakang pendaftar untuk menghasilkan semula rekod DS yang sepadan.
3. Hubungan antara lokasi geografi/penghalaan tertunda dan pemeriksaan kesihatan menyebabkan "pembunuhan"
Route 53 menyokong dasar penghalaan lanjutan. Sekiranya "Penilaian Kesihatan Sasaran" dikonfigurasikan, setelah pemeriksaan kesihatan belakang (seperti ALB atau EC2) gagal, Route 53 tidak akan kembali ke IP.
Penyelesaian: Masukkan konsol Route 53 untuk memeriksa status Pemeriksaan Kesihatan yang berkaitan. Sekiranya perkhidmatan back-end normal tetapi pemeriksaan menentukan kematian, sila sesuaikan ambang kesihatan atau waktu tamat pemeriksaan kesihatan.
3. Persekitaran dalaman VPC: pengecualian AmazonProvidedDNS
Di dalam VPC, EC2 menggunakan asas segmen rangkaian semasa secara lalai.
2
Alamat IP (mis.
10.0.0.2
) Sebagai pelayan DNS, iaitu
AmazonProvidedDNS
(Atau Route 53 Resolver).
1. Atribut VPC tidak dihidupkan
Sekiranya anda mendapati bahawa contoh EC2 sama sekali tidak dapat menyelesaikan nama domain perkhidmatan dalaman AWS (seperti
*. Amazonaws.com
) Atau nama domain Zon Hosting Swasta, periksa konfigurasi VPC terlebih dahulu.
Penyelesaian dan penyelesaian: Buka konsol VPC Amazon. Pilih VPC anda, klik Tindakan-> Edit Tetapan VPC. Pastikan anda mengaktifkan resolusi DNS dan mengaktifkan nama host DNS (Enabl)
E DNS hostnames) Kedua-dua pilihan ini telah diperiksa.
2. Set Pilihan DHCP (DHCP Options Sets) telah dirusak
Sekiranya syarikat menggunakan Direktori Aktif (AD) atau pelayan BIND yang dibina sendiri, pilihan DHCP VPC boleh diubah suai. Sekiranya Custom DNS tidak dapat menyelesaikan rangkaian awam atau nama domain dalaman AWS, resolusi akan terganggu.
Penyelesaian: Periksa pilihan DHCP yang berkaitan dengan VPC di pusat domain-name-servers. Sekiranya DNS tersuai dikonfigurasi, anda mesti memastikan bahawa pelayan DNS tersuai dikonfigurasi dengan Conditional Forwarder, yang akan meneruskan permintaan untuk nama domain dalaman AWS dan nama domain luaran kembali ke pelayan VPC. 2.
Keempat, awan hibrid dan persekitaran akaun silang: kegagalan nod terminal Resolver
Dalam senario awan hibrid yang menghubungkan pusat data tempatan dengan AWS VPC melalui AWS Direct Connect (DX) atau VPN, biasanya digunakan
Rod Terminal Rod 53 Resolver (Endpoints)
。
[Pusat Data Tempatan DNS] ─── (VPN/DX) ───> [Inbound Endpoint (.2 Resolver) ] ──> [Kawasan hosting peribadi VPC]
Apabila analisis awan hibrid terganggu, ikuti langkah-langkah di bawah untuk memeriksa rangkaian dan kebenaran:
1. Sahkan sambungan rangkaian: Sahkan bahawa lapisan fizikal/lapisan rangkaian tidak terhalang.
Pada pelayan DNS tempatan, gunakan
Telnet <Inbound-Endpoint-IP> 53
Atau
Nc-puv 53 <Inbound-Endpoint-IP>
Port 53 untuk TCP dan UDP diuji secara berasingan. Sekiranya masa tamat, ini bermaksud bahawa aliran yang mendasari belum tiba.
2. Periksa kumpulan keselamatan dan rangkaian ACL: aliran pelepasan.
Node terminal masuk (Inbound Endpoint) akan memenuhi ENI (kad rangkaian fleksibel) di subnet. Periksa kumpulan keselamatan yang terikat dengan ENI dan subnet ACL(NACL) untuk memastikan bahawa mereka membenarkan
Pelabuhan UDP/TCP 53
Aliran masuk, dan aliran port sementara (1024-65535) untuk perjalanan pulang dilepaskan pada masa yang sama.
3. Periksa jadual penghalaan dan pintu masuk NAT: periksa jalan keluar.
Sekiranya nod terminal keluar (Outbound Endpoint) tidak dapat menyelesaikan nama domain tempatan, anda perlu mengesahkan: Outbou
Sama ada jadual penghalaan subnet di mana Nd Endpoint berada mempunyai laluan ke segmen rangkaian tempatan (melalui pintu masuk peribadi maya VGW atau Transit Gateway). Sekiranya sasaran keluar adalah DNS awam rangkaian awam (seperti 8.8.8.8), subnet mestilah subnet peribadi dan jadual penghalaan dilengkapi dengan pintu masuk NAT.
4. Perkaitan kawasan hosting peribadi akaun silang: periksa IAM dan kebenaran bersama.
Dalam struktur berbilang akaun, jika nama domain berada di kawasan hosting peribadi akaun A, dan EC2 berada di VPC akaun B, ia mesti dilaksanakan melalui AWS CLI atau SDK
Associate-vpc-with-hosted-zone
Lakukan perkaitan silang akaun, jika tidak, VPC akaun B tidak dapat melihat kewujudan nama domain walaupun rangkaiannya lancar.
5. Pembunuh yang tidak kelihatan: VPC DNS per had sesaat (Throtttling)
Kadang kala, anomali resolusi DNS adalah
Kehilangan paket yang berselang, tamat atau kelewatan yang tinggi
, Terutama pada masa puncak perniagaan. Ini mungkin mencetuskan had paket sesaat (PPS) AWS.
⚠LimeHad kuota kritikal: AWS menetapkan bahawa pertanyaan DNS yang dimulakan oleh setiap antara muka rangkaian (tahap ENI untuk setiap contoh EC2 pada tahap seni bina rangkaian) ke AmazonProvidedDNS (pelayan. 2) mempunyai had atas 1024 PPS. Permintaan DNS yang melebihi had ini akan dibuang dengan kejam oleh sistem, dan ini adalah sekatan yang sukar, dan kuota tidak dapat ditingkatkan dengan menyerahkan pesanan kerja.
Bagaimana untuk mengesahkan had kadar DNS?
Oleh kerana lalu lintas yang ditolak dibuang di lapisan antara muka rangkaian, mereka
Tidak akan
Dirakam dalam log pertanyaan Route 53.
Kaedah diagnosis: Gunakan tcpdump untuk menangkap lalu lintas port 53 pada contoh Linux EC2 yang terjejas, atau gunakan fungsi Traffic Mirroring dari contoh seni bina AWS Nitro untuk mengimport lalu lintas ke Wireshark untuk analisis. Sekiranya permintaan DNS didapati padat dan kawasan Pelabuhan Unswered yang besar, ia boleh didiagnosis sebagai Throtttling.
Penyelesaian:
Buka cache DNS tempatan: gunakan nscd, dnsmasq atau systemd-resolved tempatan pada contoh Linux. Biarkan sebahagian besar permintaan DNS berulang dicerna secara tempatan dalam sistem operasi dan tidak lagi diserahkan kepada AWS.
Optimumkan kumpulan sambungan lapisan aplikasi: Beberapa bahasa pengembangan (seperti Java) mempunyai tetapan TTL cache DNS lalai (masa bertahan) yang lebih pendek, atau sambungan serentak tinggi dan pendek sering mencetuskan resolusi DNS. Dianjurkan untuk mengoptimumkan seni bina sambungan yang panjang, atau memperpanjang masa tamat cache DNS aplikasi dengan tepat.
Ringkasan dan cadangan
Pembelian akaun AWS
Dalam menghadapi pengecualian resolusi AWS DNS, jangan ubah konfigurasi secara membuta tuli. Dianjurkan untuk mengikuti prinsip "dari dalam ke luar, dari dangkal ke dalam": pertama melihat maklum balas cache dan alat tempatan, kemudian melihat atribut asas VPC DNS, kemudian memeriksa kumpulan keselamatan dan jalan awan hibrid, dan akhirnya mempertimbangkan kuota 1024 PPS dalam senario lalu lintas tinggi had. Pada masa yang sama, mewujudkan tabiat pengurusan infrastruktur yang baik iaitu kod (IaC, seperti Terraform) dan menyeragamkan aliran pengurusan pelbagai akaun perusahaan dapat membantu anda menghilangkan sebahagian besar bencana DNS yang disebabkan oleh salah operasi dari sumbernya.
