ทำไมโซน Route 53 ส่วนตัวจึงตอบ NXDOMAIN สำหรับชื่อสาธารณะ

โซน Route 53 ส่วนตัวแทนที่คำตอบสำหรับชื่อหนึ่งแทนที่จะรวมเข้ากับระเบียนสาธารณะ และนั่นทำให้ผู้คนประหลาดใจในจังหวะที่แย่ที่สุด เพิ่มระเบียนภายในหนึ่งรายการสำหรับ api.example.net ในโซนส่วนตัวสำหรับ example.net ผูกกับ VPC แล้วชื่ออื่นทุกชื่อใต้ชื่อหลักนั้นจะตอบจากโซนส่วนตัวเท่านั้น ไคลเอนต์ที่เมื่อวานเข้าถึง www.example.net ได้ วันนี้กลับได้รับคำตอบเชิงลบ คำอธิบายด้านล่างเริ่มจากคำถามที่ล้มเหลวนั้นและไล่ออกไปจนถึงโซนที่ตอบมัน

เริ่มจากคำถาม ไม่ใช่จากคอนโซล

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

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

คำสั่งที่สองคือคำสั่งที่สำคัญ บรรทัดสถานะและส่วน authority ของมันระบุโซนที่สร้างคำตอบ คุณจึงแยกคำตอบเชิงลบจากโซนส่วนตัวออกจากหมดเวลา พอร์ตที่ถูกบล็อก หรือรีโซลเวอร์ที่ไม่เคยได้รับคำถามได้ resolvectl แสดงว่าเซิร์ฟเวอร์ต้นทางใดถูกถาม และบ่อยครั้งไม่ใช่รีโซลเวอร์ที่คุณสันนิษฐานว่า VPN ส่งมา

ถ้าคำถามที่ติดตามคืนที่อยู่สาธารณะแต่คำถามปกติไม่คืน ระเบียนสาธารณะยังสมบูรณ์และมุมมองส่วนตัวเป็นฝ่ายตอบ การเปรียบเทียบเพียงครั้งเดียวนั้นตัดสินว่าครึ่งใดของส่วนที่เหลือของหน้านี้ใช้กับคุณ

อ่านว่าโซนใดตอบ

คำตอบที่พก NXDOMAIN พร้อม SOA ของโซนส่วนตัวในส่วน authority คือคำตอบสุดท้ายจากโซนนั้น ไม่ใช่การค้นหาที่ล้มเหลว Route 53 Resolver เลือกโซนโฮสต์ส่วนตัวเพราะชื่อตรงกัน จากนั้นไม่พบระเบียนประเภทที่ขอ และพฤติกรรมที่บันทึกไว้คือการคืนคำตอบเชิงลบแทนที่จะส่งต่อคำถามไปยัง DNS สาธารณะ

การเลือกเป็นไปตามความจำเพาะ เมื่อมีเนมสเปซส่วนตัวหลายอันทับซ้อนกัน โซนที่ตรงและจำเพาะที่สุดจะเป็นฝ่ายชนะ และโซนแม่ส่วนตัวที่กว้างกว่าจะไม่ได้โอกาสที่สองสำหรับชื่อที่โซนลูกซึ่งถูกเลือกไม่มี การส่งต่อเพิ่มอีกชั้น เพราะกฎ Resolver ที่เจาะจงโดเมนอาจชนะการเชื่อมโยงโซนโฮสต์ส่วนตัวได้ จงระบุรายการการเชื่อมโยงและกฎก่อนสรุปว่าโซนหนึ่งว่างเปล่า

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]"

ทั้งสองคำสั่งต้องใช้ข้อมูลรับรองของบัญชีที่เป็นเจ้าของโซน และคำสั่งที่สองต้องใช้ ID โซนจากคำสั่งแรก แทนที่ด้วย ID ของคุณเอง ตัวยึดตำแหน่งด้านบนจงใจไม่ใช่ของจริง

ทำไมโซนส่วนตัวจึงชนะ

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

เนมสเปซที่ทับซ้อนกันเป็นแหล่งความสับสนที่สอง โซนส่วนตัวสำหรับ example.net และโซนส่วนตัวสำหรับ api.example.net ทั้งสองตรงกับคำถาม API และอันที่จำเพาะกว่าจะตอบ นั่นมีประโยชน์เมื่อคุณต้องการเนมสเปซภายในที่แคบ และเป็นอันตรายเมื่อโซนแคบขาดระเบียนที่โซนกว้างกว่ามี ข้อพิจารณาเกี่ยวกับโซนโฮสต์ส่วนตัวใน เอกสาร Route 53 อธิบายทั้งพฤติกรรมการตกผ่านและลำดับความสำคัญของกฎ และคุ้มค่าที่จะอ่านก่อนเพิ่มโซนทับซ้อนที่สอง

ไม่มีสิ่งใดในนี้เปลี่ยนโซนสาธารณะ รีโซลเวอร์สาธารณะยังตอบระเบียนสาธารณะอย่างถูกต้อง และนั่นคือเหตุผลที่คนนอก VPC ทุกคนเห็นความล้มเหลวนี้เป็นปัญหาของไคลเอนต์

เลือกเนมสเปซก่อนเพิ่มระเบียน

ถ้ามีเพียงกลุ่มบริการภายในชุดใหม่ที่ต้องการชื่อส่วนตัว ให้โดเมนย่อยส่วนตัวเฉพาะและปล่อยโซนแม่สาธารณะไว้ ชื่ออย่าง internal.example.net ไม่สามารถบดบัง www.example.net และรัศมีผลกระทบของระเบียนที่หายไปจำกัดอยู่ที่ชื่อที่คุณสร้างขึ้นเพื่อการนั้น ต้นทุนคือ URL และใบรับรองที่มีอยู่อาจไม่ตรงกับชื่อใหม่

เมื่อผู้ใช้สาธารณะและส่วนตัวต้องคงชื่อโฮสต์เดียวกัน DNS แบบมุมมองแยกคือการออกแบบที่รองรับ และต้องดูแลระเบียนในแต่ละมุมมองอย่างชัดเจน โซนส่วนตัวกว้างที่มีระเบียนเดียวไม่รักษาการพึ่งพาสาธารณะใต้โซนนั้น มันแทนที่ด้วยโซนที่มีระเบียนเดียว

จัดทำบัญชีชื่อที่แอปพลิเคชันเรียกจริงก่อนชี้ประชากรไคลเอนต์ไปที่มุมมองส่วนตัว โฮสต์เข้าสู่ระบบ โฮสต์สินทรัพย์คงที่ เป้าหมายการเปลี่ยนเส้นทาง และจุดสิ้นสุด API เป็นสิ่งที่พังก่อน และมักกระจายอยู่ทั่วระเบียนของหลายทีม

ติดตามเส้นทางของรีโซลเวอร์ แล้วจึงติดตามเส้นทางเครือข่าย

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

เมื่อชื่อแก้ได้แล้ว ให้ทดสอบเส้นทางไปยังที่อยู่ที่คืนมาเป็นขั้นตอนแยก เช่น ด้วย ip route get เทียบกับที่อยู่ที่คำถามคืนมา คำตอบส่วนตัวที่ถูกต้องโดยไม่มีเส้นทางไปยังที่อยู่คือปัญหาเส้นทาง และคำตอบว่าระเบียนหายไปคือปัญหามุมมอง DNS การถือว่าเป็นปัญหาเดียวกันจะได้การแก้ไขที่ไม่ยั่งยืน ปล่อยการตรวจชื่อโฮสต์ TLS และใบรับรองของบริการไว้ไม่เปลี่ยน เพราะที่อยู่ส่วนตัวเปลี่ยนว่าการเชื่อมต่อไปที่ใด และไม่เปลี่ยนว่าใบรับรองใดใช้ได้

จบด้วยการบันทึกโซน การเชื่อมโยง รีโซลเวอร์ และชื่อที่คุณตรวจสอบในบันทึกการเปลี่ยนแปลง จากนั้นคนถัดไปที่เพิ่มระเบียนจะรู้ว่าเนมสเปซใดมีอำนาจสำหรับประชากรไคลเอนต์นั้น