DNS ของ VPN ผิดหรือไม่? เซิร์ฟเวอร์ที่มีอำนาจหนึ่งเครื่องอาจล้าสมัย

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

อาการเปลี่ยนไปตามตัวแปลง

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

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

การทดสอบที่แยกความต่างคือการสอบถามโดยตรงไปยังเซิร์ฟเวอร์ที่เผยแพร่ไว้แต่ละเครื่อง

ถามแหล่งอำนาจแต่ละแห่งโดยตรง

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

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

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

เรียกใช้การสอบถามเหล่านั้นจากเครือข่ายที่ล้มเหลว ไม่ใช่แค่จากโต๊ะของคุณ

แยกมุมมองที่ตั้งใจออกจากมุมมองที่เสีย

บางโดเมนตอบต่างกันโดยเจตนาตามภูมิภาคหรือกลุ่มตัวแปลง และการตั้งค่าแบบขอบฟ้าแบ่งเป็นเรื่องปกติในเครือข่ายองค์กร

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

เซิร์ฟเวอร์ที่ตอบ SERVFAIL วินิจฉัยได้ง่ายกว่าเซิร์ฟเวอร์ที่ตอบอย่างมั่นใจแต่ผิด

การย้ายเผยให้เห็นสิ่งที่แคชซ่อนไว้

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

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

การเปลี่ยนตัวแปลงบนแล็ปท็อปแก้ไขแล็ปท็อปเครื่องนั้นและไม่มีอะไรอื่น

แก้โซน ไม่ใช่ตัวแปลง

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

จากนั้นเรียกใช้การสอบถามโดยตรงอีกครั้งจากทั้งสองเครือข่ายและรอให้ TTL ของระเบียนที่คุณเปลี่ยนหมดอายุ

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