การซื้อบัญชี AWS: การวิเคราะห์ DNS บนคลาวด์ของ Amazon คู่มือเชิงลึกสำหรับการแก้ไขปัญหาและการแก้ปัญหาที่ผิดปกติ!

ในสถาปัตยกรรมคลาวด์คอมพิวติ้ง DNS (ระบบชื่อโดเมน) เปรียบเสมือนเครื่องนำทางในโลกดิจิทัลเมื่อความละเอียด DNS บน AWS ผิดปกติบริการขององค์กรอาจตกอยู่ในสถานะ "ขาดการเชื่อมต่อ" ทันที: อินสแตนซ์ EC2ไม่สามารถเข้าถึง API ภายนอกได้การหมดเวลาการเรียกใช้ไมโครเซอร์วิสภายในและการเผชิญหน้าของผู้ใช้

NXDOMAIN

หรือ

SERVFAIL

รายงานข้อผิดพลาด

เนื่องจากสถาปัตยกรรมเครือข่ายของ AWS รวม VPC (Virtual Private Cloud), Route 53, VPC Resolver(.2 Resolver) และสถาปัตยกรรมคลาวด์ไฮบริดภายในที่เป็นไปได้การแก้ไข DNS จึงมักมีความซับซ้อนในระดับหนึ่งบทความนี้จะเริ่มจาก

การวิเคราะห์เครือข่ายสาธารณะ

、

การวิเคราะห์ภายใน VPC

、

สถาปัตยกรรมไฮบริดคลาวด์

และ

คอขวดด้านประสิทธิภาพ

สี่มิติสำหรับคุณในการแยกขั้นตอนการแก้ไขปัญหาและการแก้ปัญหาที่ผิดปกติของการแยกวิเคราะห์ AWS DNS

1.กล่องเครื่องมือตรวจสอบหลัก: "เครื่องตรวจฟังเสียง" ครั้งแรก

ก่อนที่จะเจาะลึกลงไปในสถาปัตยกรรมเมื่อคุณพบข้อยกเว้นในการแยกวิเคราะห์ก่อนอื่นคุณควรใช้เครื่องมือเนทีฟต่อไปนี้บนอินสแตนซ์ EC2ที่ได้รับผลกระทบหรือเทอร์มินัลภายในเพื่อรับสถานะข้อผิดพลาดพื้นฐาน:

Dig (Linux/macOS) หรือ nslookup (Windows) ใช้ g yourdomain.com di เพื่อสังเกตสถานะที่ส่งคืนสถานะทั่วไปได้แก่: NOERROR: การแยกวิเคราะห์สำเร็จปัญหาอาจเกิดจากแคชของเลเยอร์แอปพลิเคชันหรือความล้มเหลวของพอร์ต NXDOMAIN: ไม่มีชื่อโดเมนโดยปกติแล้วบันทึกจะตรงกันหรือไม่ตรงกัน SERVFAIL: ความล้มเหลวของการประมวลผลเซิร์ฟเวอร์ DNS พบได้บ่อยในข้อผิดพลาดในการกำหนดค่าคีย์ DNSSEC หรือความล้มเหลวในการส่งต่อต้นน้ำ

ระบุการทดสอบเซิร์ฟเวอร์ DNS บังคับให้ใช้เซิร์ฟเวอร์ชื่อที่เชื่อถือได้ของ AWS Route 53สำหรับการสืบค้นและตรวจสอบว่าเป็นปัญหาการแก้ปัญหาแบบวนซ้ำทั่วโลกหรือปัญหาด้าน AWS: Bashdig @ ns-xxxx.awsdns-xx.com yourdomain.com

ประการที่สองสภาพแวดล้อมเครือข่ายสาธารณะ: การวิเคราะห์พื้นที่โฮสต์สาธารณะ Route 53ผิดปกติ

หากคุณรับผิดชอบการจัดการหลายบัญชีในการดำเนินงานและการบำรุงรักษาระบบคลาวด์ขององค์กรคุณอาจต้องปรับเปลี่ยนสินทรัพย์ชื่อโดเมนบ่อยๆตรวจสอบให้แน่ใจว่าบัญชีของคุณมีอำนาจในการจัดการที่เพียงพอก่อนการตรวจสอบอย่างเป็นทางการหากเป็นการปรับใช้ขนาดใหญ่ในระดับองค์กรตรวจสอบให้แน่ใจว่าได้ดำเนินการผ่านช่องทางที่สอดคล้องและมีเสถียรภาพ

การซื้อบัญชี AWS

การบำรุงรักษาเพื่อขอรับการสนับสนุนระดับองค์กร (Enterprise Support) ซึ่งเป็นสิ่งสำคัญเมื่อพบความล้มเหลวระดับต่ำของคลาสที่ไม่มีการกำหนดค่า

ความล้มเหลวของการวิเคราะห์เครือข่ายสาธารณะมักเกิดจากสาเหตุสามประการต่อไปนี้:

1.ชื่อ Servers (NS) ที่นายทะเบียนไม่สอดคล้องกับ Route 53

นี่เป็นความผิดพลาดของมนุษย์ที่พบบ่อยที่สุดเมื่อคุณสร้างพื้นที่โฮสติ้งสาธารณะใหม่ (Public Hosted Zone) ใน Route 53, A

WS จะสุ่มกำหนดชื่อเซิร์ฟเวอร์4ชื่อ

วิธีการแก้ไขปัญหา: ตรวจสอบห่วงโซ่การอนุญาตชื่อโดเมนรากผ่าน e yourdomain.com dig trac หรือใช้เครื่องมือ Whois เพื่อดูระเบียน NS ที่ผู้รับจดทะเบียนกรอก

วิธีแก้ไข: เข้าสู่พื้นหลังของผู้รับจดทะเบียนชื่อโดเมนของคุณและแก้ไขระเบียน NS ให้สมบูรณ์และถูกต้องเป็นเซิร์ฟเวอร์ชื่อ AWS 4ตัวที่แสดงในพื้นที่โฮสต์ Route 53ปัจจุบัน

2.การกำหนดค่าลายเซ็น DNSSEC เสียโซ่

เพื่อความปลอดภัยหลายบริษัทได้เปิด DNSSEC หากระเบียน DS (ลบ Signer) ไม่ได้รับการอัปเดตที่ผู้รับจดทะเบียนเมื่อย้ายชื่อโดเมนหรือเปลี่ยนพื้นที่โฮสต์ตัวแยกวิเคราะห์แบบวนซ้ำทั่วโลกจะส่งคืนโดยตรงเนื่องจากไม่สามารถยืนยันลายเซ็นได้

เซิร์ฟเฟลีย์

。

วิธีแก้ไข: หากไม่ต้องการให้ซิงโครไนซ์และปิด DNSSEC ที่ฝั่งผู้รับจดทะเบียนและ Route 53หากจำเป็นอย่าลืมส่งออกข้อมูล KSK (คีย์ลายเซ็นคีย์) ของ Route 53และไปที่พื้นหลังของนายทะเบียนเพื่อสร้างระเบียน DS ที่ตรงกันใหม่

3.ตำแหน่งทางภูมิศาสตร์/การเชื่อมโยงการกำหนดเส้นทางล่าช้าและการตรวจสุขภาพนำไปสู่ "การฆ่าคนตาย"

Route 53รองรับกลยุทธ์การกำหนดเส้นทางขั้นสูงหากกำหนดค่า "Evaluate Target Health" เมื่อการตรวจสุขภาพแบ็คเอนด์ที่ผูกไว้ (เช่น ALB หรือ EC2) ล้มเหลว Route 53จะไม่ส่งคืน IP อีกต่อไป

วิธีแก้ไข: เข้าสู่สถานะการตรวจสุขภาพ (Health Checks) ที่เกี่ยวข้องกับการตรวจสอบคอนโซล Route 53。หากบริการแบ็คเอนด์เป็นปกติแต่การตรวจพบว่าเสียชีวิตโปรดปรับเกณฑ์สุขภาพหรือหมดเวลาสำหรับการตรวจสุขภาพ

ประการที่สามสภาพแวดล้อมภายใน VPC: AmazonProvidedDNS ผิดปกติ

ภายใน VPC EC2จะใช้พื้นฐานในส่วนเครือข่ายปัจจุบันตามค่าเริ่มต้นบวก

2

ที่อยู่ IP (เช่น

10.0.0.2

) ในฐานะเซิร์ฟเวอร์ DNS นั่นคือ

AmazonProvidedDNS

(หรือ Route 53 Resolver)

1.คุณสมบัติ VPC ไม่ได้เปิด

หากพบว่าอินสแตนซ์ EC2ไม่สามารถแก้ไขชื่อโดเมนบริการภายใน AWS ได้เลย (เช่น

* .Amazonaws.com

) หรือชื่อโดเมน Private Hosted Zone (Private Hosted Zone) ตรวจสอบการกำหนดค่า VPC ก่อน

การแก้ไขปัญหาและการแก้ปัญหา: เปิดคอนโซล Amazon VPC 。เลือก VPC ของคุณและคลิกที่การกระทำ-> แก้ไขการตั้งค่า VPC (Edit VPC settings) ตรวจสอบให้แน่ใจว่าได้เปิดใช้งาน DNS Resolution (Enable DNS resolution) และเปิดใช้งานชื่อโฮสต์ DNS (Enabl)

E DNS hostnames) สองตัวเลือกนี้ได้รับการตรวจสอบแล้ว

2. DHCP Options Sets (DHCP Options Sets) ถูกดัดแปลง

หากองค์กรใช้เซิร์ฟเวอร์ Active Directory (AD) หรือ BIND ที่สร้างขึ้นเองคุณอาจแก้ไขชุดตัวเลือก DHCP ของ VPC หาก DNS แบบ custom ไม่สามารถแก้ไขชื่อโดเมนภายในของเครือข่ายสาธารณะหรือ AWS ได้การแก้ไขจะถูกขัดจังหวะ

วิธีแก้ไข: ตรวจสอบ domain-name-servers จากตัวเลือก DHCP ที่เกี่ยวข้องกับ VPC 。หากคุณกำหนดค่า DNS ที่กำหนดเองคุณต้องตรวจสอบให้แน่ใจว่าเซิร์ฟเวอร์ DNS ที่กำหนดเองมีการกำหนดค่าช่องสัญญาณแบบมีเงื่อนไขและส่งต่อคำขอสำหรับชื่อโดเมนภายในและภายนอกของ AWS ไปยังเซิร์ฟเวอร์ VPC 2

ประการที่สี่ระบบคลาวด์แบบไฮบริดและสภาพแวดล้อมข้ามบัญชี: โหนดเทอร์มินัล Resolver ล้มเหลว

ในสถานการณ์ระบบคลาวด์แบบไฮบริดที่เชื่อมต่อศูนย์ข้อมูลภายในเครื่องกับ AWS VPC ผ่าน AWS Direct Connect (DX) หรือ VPN โดยปกติจะปรับใช้

Route 53 Resolver เทอร์มินัลโหนด (Endpoints)

。

[Local Data Center DNS ] ──(VPN/DX)──> [ Inbound Endpoint (.2 Resolver) ] ──> [ VPC พื้นที่โฮสติ้งส่วนตัว]

เมื่อความละเอียดระบบคลาวด์แบบไฮบริดถูกขัดจังหวะโปรดปฏิบัติตามขั้นตอนต่อไปนี้อย่างเคร่งครัดเพื่อตรวจสอบเครือข่ายและสิทธิ์:

1.ตรวจสอบการเชื่อมต่อเครือข่าย: ยืนยันว่าเลเยอร์ฟิสิคัล/เลเยอร์เครือข่ายไม่มีสิ่งกีดขวาง

บนเซิร์ฟเวอร์ DNS ในเครื่องให้ใช้

Telnet <Inbound-Endpoint-IP> 53

หรือ

Nc-puv 53 <Inbound-Endpoint-IP>

ทดสอบพอร์ต53ของ TCP และ UDP ตามลำดับหากหมดเวลาแสดงว่ากระแสด้านล่างไม่มาถึง

2.ตรวจสอบกลุ่มความปลอดภัยและเครือข่าย ACL: ปล่อยการจราจร

โหนดเทอร์มินัลขาเข้า (Inbound Endpoint) จะครอบครอง ENI (การ์ดเครือข่ายแบบยืดหยุ่น) ในเครือข่ายย่อยตรวจสอบกลุ่มความปลอดภัย (Security Group) ที่ผูกไว้กับ ENI และเครือข่ายย่อย ACL(NACL) และตรวจสอบให้แน่ใจว่าอนุญาต

UDP/TCP Port 53

การรับส่งข้อมูลขาเข้าและการรับส่งข้อมูลพอร์ตชั่วคราว (1024-65535) สำหรับการส่งคืนในเวลาเดียวกัน

3.ตรวจสอบตารางเส้นทางและเกตเวย์ NAT: ตรวจสอบเส้นทางขาออก

หากโหนดเทอร์มินัลขาออก (Outbound Endpoint) ไม่สามารถแก้ไขชื่อโดเมนภายในเครื่องได้คุณต้องยืนยัน: Outbou

ตารางเส้นทางเครือข่ายย่อยที่ Endpoint ตั้งอยู่มีการกำหนดเส้นทางไปยังส่วนเครือข่ายท้องถิ่นหรือไม่ (ผ่านเกตเวย์ส่วนตัวเสมือน VGW หรือ Transit Gateway) หากเป้าหมายขาออกเป็น DNS สาธารณะบนเครือข่ายสาธารณะ (เช่น8.8.8.8) เครือข่ายย่อยจะต้องเป็นเครือข่ายย่อยส่วนตัวและตารางเส้นทางมีเกตเวย์ NAT

4.การเชื่อมโยงพื้นที่โฮสติ้งส่วนตัวข้ามบัญชี: ตรวจสอบ IAM และสิทธิ์การแชร์

ในสถาปัตยกรรมหลายบัญชีหากชื่อโดเมนอยู่ในพื้นที่โฮสต์ส่วนตัวของบัญชี A และ EC2อยู่ใน VPC ของบัญชี B จะต้องดำเนินการผ่าน AWS CLI หรือ SDK

Associate-vpc-with-hosted-zone

ดำเนินการเชื่อมโยงข้ามบัญชีมิฉะนั้น VPC ของบัญชี B จะไม่สามารถรับรู้การมีอยู่ของชื่อโดเมนได้แม้ว่าเครือข่ายจะไม่มีสิ่งกีดขวางก็ตาม

ห้านักฆ่าที่มองไม่เห็น: VPC DNS ต่อขีดจำกัดต่อวินาที (Throttling)

บางครั้งการแยกวิเคราะห์ DNS จะแสดงเป็น

การสูญเสียแพ็กเก็ตเป็นระยะๆการหมดเวลาหรือความล่าช้าสูง

โดยเฉพาะอย่างยิ่งในช่วงเวลาสูงสุดของธุรกิจสิ่งนี้อาจทำให้เกิดขีดจำกัดแพ็กเก็ตต่อวินาที (PPS) ของ AWS

⚠ข้อจำกัดโควต้าที่สำคัญ: AWS กำหนดว่าแต่ละอินเทอร์เฟซเครือข่าย (ระดับ ENI สำหรับแต่ละอินสแตนซ์ EC2ในระดับสถาปัตยกรรมเครือข่าย) จะเริ่มต้นการสืบค้น DNS ไปยัง AmazonProvidedDNS (เซิร์ฟเวอร์.2) ขีดจำกัดสูงสุดคือ1024 PPS คำขอ DNS ที่เกินขีดจำกัดนี้จะถูกทิ้งอย่างไร้ความปรานีโดยระบบและนี่เป็นข้อจำกัดที่เข้มงวดและไม่สามารถเพิ่มโควต้าได้โดยการส่งใบสั่งงาน

จะวินิจฉัยขีดจำกัดอัตรา DNS ได้อย่างไร?

เนื่องจากการรับส่งข้อมูลที่ถูกปฏิเสธถูกทิ้งที่เลเยอร์อินเทอร์เฟซเครือข่ายพวกเขา

ไม่สามารถ

บันทึกไว้ในบันทึกแบบสอบถามของ Route 53

วิธีการวินิจฉัย: ใช้ tcpdump เพื่อจับการรับส่งข้อมูลของพอร์ต53บนอินสแตนซ์ EC2ของ Linux ที่ได้รับผลกระทบหรือใช้ฟังก์ชัน Traffic Mirroring ของอินสแตนซ์สถาปัตยกรรม AWS Nitro เพื่อนำการรับส่งข้อมูลไปยัง Wireshark เพื่อวิเคราะห์หากพบว่าคำขอ DNS มีความหนาแน่นและพื้นที่ขนาดใหญ่ของพอร์ต Unanswered สามารถวินิจฉัยได้ว่าเป็น Throttling

แนวทางการแก้ไข:

เปิดแคช DNS ในเครื่อง: ปรับใช้ nscd, dnsmasq หรือ systemd-resolved ในอินสแตนซ์ Linux ปล่อยให้คำขอ DNS ที่ซ้ำกันส่วนใหญ่ถูกย่อยในระบบปฏิบัติการและไม่ส่งไปยัง AWS อีกต่อไป

เพิ่มประสิทธิภาพพูลการเชื่อมต่อเลเยอร์แอปพลิเคชัน: ภาษาสำหรับการพัฒนาบางภาษา (เช่น Java) แคช DNS เริ่มต้น TTL (เวลาอยู่รอด) มีการตั้งค่าที่สั้นกว่าหรือการเชื่อมต่อพร้อมกันสูงและสั้นมักเรียกใช้การแก้ปัญหา DNS ขอแนะนำให้ปรับสถาปัตยกรรมการเชื่อมต่อแบบยาวให้เหมาะสมหรือขยายเวลาหมดอายุของแคช DNS ของแอปพลิเคชันอย่างเหมาะสม

สรุปและข้อเสนอแนะ

การซื้อบัญชี AWS

เมื่อเผชิญกับความผิดปกติของการแยกวิเคราะห์ AWS DNS อย่าแก้ไขการกำหนดค่าแบบสุ่มสี่สุ่มห้าขอแนะนำให้ปฏิบัติตามหลักการ "จากภายในสู่ภายนอกจากตื้นไปลึก": ขั้นแรกให้ดูที่แคชในเครื่องและข้อเสนอแนะของเครื่องมือจากนั้นดูคุณสมบัติพื้นฐานของ VPC DNS จากนั้นตรวจสอบกลุ่มความปลอดภัยและเส้นทางคลาวด์แบบไฮบริดและสุดท้ายพิจารณาโควต้า1024 PPS ในสถานการณ์การจราจรขนาดใหญ่ขีดจำกัดในขณะเดียวกันการสร้างโครงสร้างพื้นฐานที่ดีนั่นคือนิสัยการจัดการรหัส (IaC เช่น Terraform) และสร้างมาตรฐานสตรีมการจัดการหลายบัญชีขององค์กรสามารถช่วยคุณกำจัดภัยพิบัติ DNS ส่วนใหญ่ที่เกิดจากการทำงานผิดพลาดจากแหล่งที่มา