NXDOMAIN ผ่าน VPN ไม่ได้หมายถึงอุโมงค์ล่ม

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

คำตอบพิสูจน์อะไรจริง ๆ

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

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

ความเชื่อผิด: ชื่อส่วนตัวที่หายไปหมายความว่าอุโมงค์ล้มเหลว

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

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

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

ถามตัวแก้ชื่อที่ถูกต้องด้วยชื่อที่ถูกต้อง

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

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

แคชเชิงลบอธิบายความล่าช้าหลังการซ่อม

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

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

แยกชื่อออกจากเส้นทาง

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

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