DNS สาธารณะใช้งานได้ไม่ได้หมายความว่าจะพบ Active Directory ได้
การโหลดหน้าเว็บในเบราว์เซอร์พิสูจน์เพียงการค้นหาหนึ่งครั้ง การลงชื่อเข้าใช้โดเมนต้องมีระเบียนตัวระบุตำแหน่ง SRV ที่อยู่ของคอนโทรลเลอร์ และเส้นทาง ซึ่งทั้งหมดต้องแก้ได้ผ่าน VPN
VPN เชื่อมต่อได้ เบราว์เซอร์เปิดเว็บไซต์สาธารณะ แต่แล็ปท็อปยังลงชื่อเข้าใช้โดเมนไม่ได้ ข้อสรุปปกติคือ DNS ปกติดีเพราะชื่อแก้ได้ ซึ่งไม่จริง และเหตุผลคือการทดสอบในเบราว์เซอร์ใช้เพียงการค้นหาหนึ่งครั้งจากห่วงโซ่ที่ไคลเอนต์ซึ่งเชื่อมกับโดเมนต้องใช้ การค้นพบโดเมนถามระเบียนบริการก่อน จากนั้นถามที่อยู่ของคอนโทรลเลอร์ที่ระเบียนเหล่านั้นระบุชื่อ และสุดท้ายถามเส้นทางไปยังพอร์ตที่คอนโทรลเลอร์เหล่านั้นรอรับ คำตอบสาธารณะไม่ตอบสนองขั้นตอนใดเลย
ตำนาน: ชื่อแก้ได้ DNS จึงเสร็จแล้ว
การที่เว็บไซต์สาธารณะแก้ได้บอกเพียงว่าตัวแก้ชื่อบางตัวตอบคำถาม A หรือ AAAA หนึ่งครั้งสำหรับชื่อในโซนสาธารณะ Active Directory ใช้โปรโตคอลเดียวกันกับคำถามอื่น คือบริการของโดเมนอยู่ที่ใด และไคลเอนต์นี้ควรใช้คอนโทรลเลอร์ตัวใด คำถามนี้แสดงเป็นระเบียน SRV ใต้โซนที่ตั้งชื่อตามโดเมน และตัวแก้ชื่อสาธารณะแบบเรียกซ้ำไม่มีเหตุผลจะเก็บระเบียนเหล่านั้นไว้
เมื่อระเบียนหายไป ตัวแก้ชื่อจะคืนคำตอบเชิงลบ ซึ่งเป็นคำตอบ DNS ที่ถูกต้อง ไม่ใช่เหตุขัดข้อง จากนั้นไคลเอนต์จะถอยกลับไปใช้ข้อมูลคอนโทรลเลอร์ที่แคชไว้ถ้ามี และนั่นคือเหตุผลที่เดสก์ท็อปดูปกติดีได้หลายชั่วโมงแล้วล้มเหลวหลังรีบูตหรือเปลี่ยนรหัสผ่าน
ไคลเอนต์โดเมนถามอะไรจริง ๆ ตามลำดับ
สำหรับโดเมนอย่าง corp.example คำถามตัวระบุตำแหน่งทั่วไปคือ _ldap._tcp.dc._msdcs.corp.example คำตอบ SRV ระบุชื่อคอนโทรลเลอร์ที่เป็นไปได้และพอร์ตของมัน จากนั้นไคลเอนต์ต้องมีระเบียนที่อยู่สำหรับชื่อโฮสต์เหล่านั้นก่อนจะเปิดการเชื่อมต่อ การค้นพบที่คำนึงถึงไซต์เพิ่มคำถามใต้โดเมนย่อยของไซต์ และคำตอบกำหนดว่าคอนโทรลเลอร์ใดได้รับความนิยม ไม่ใช่ว่าตัวใดบังคับ
nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.exampleตามห่วงโซ่ตามลำดับนั้น จากเครือข่ายที่เกิดปัญหา ชื่อโฮสต์ที่แก้เป็นที่อยู่ที่เข้าถึงไม่ได้คือความล้มเหลวในการกำหนดเส้นทาง ไม่ใช่ความล้มเหลวของ DNS คอนโทรลเลอร์ที่เข้าถึงได้แต่ขาดระเบียนตัวระบุตำแหน่งคือความล้มเหลวของ DNS ไม่ใช่ความล้มเหลวในการกำหนดเส้นทาง ทั้งสองให้ข้อร้องเรียนของผู้ใช้ที่คล้ายกันและการซ่อมแซมที่ต่างกันโดยสิ้นเชิง
ทำไมตัวแก้ชื่อสาธารณะตอบได้แต่การลงชื่อเข้าใช้ยังพัง
ถ้าอะแดปเตอร์ให้ตัวแก้ชื่อสาธารณะกับไคลเอนต์ ชื่อสาธารณะจะใช้ได้และเนมสเปซภายในจะใช้ไม่ได้ การเพิ่มตัวแก้ชื่อสาธารณะตัวที่สองไม่ช่วย เพราะทั้งสองไม่ได้ถือโซนนั้นไว้ และรายการตามปกติ “ภายในก่อน สาธารณะทีหลัง” ก็ไม่ทำงานเหมือนกฎต่อโดเมน เพราะคำตอบเชิงลบจากเซิร์ฟเวอร์ตัวแรกเป็นคำตอบที่ชอบด้วยกฎหมาย และไคลเอนต์ไม่ลองเซิร์ฟเวอร์ตัวที่สองซ้ำเพียงเพราะคำตอบว่างเปล่า
ตัวแก้ชื่อภายในทั้งสองตัว ถ้าคุณใช้งานสองตัว ต้องถือเนมสเปซของ AD และเข้าถึงได้จากเครือข่ายปัจจุบันของไคลเอนต์ นี่คือส่วนที่การออกแบบอุโมงค์แยกทางทำพัง เพราะ VPN อาจขนซับเน็ตของอุโมงค์ ขณะที่ตัวแก้ชื่อภายในอยู่บนคำนำหน้าที่อุโมงค์ไม่กำหนดเส้นทาง คำถามจึงออกไปยังตัวแก้ชื่อที่ไม่สามารถตอบได้
Windows ยังใช้นโยบายการแก้ชื่อที่กำหนดเนมสเปซเฉพาะไปยังเซิร์ฟเวอร์เฉพาะได้ และที่อยู่ DNS ที่อะแดปเตอร์แสดงไม่ใช่เรื่องทั้งหมด การเปลี่ยนรายการอะแดปเตอร์โดยไม่เปลี่ยนนโยบายนั้นอาจทำให้การกำหนดค่าที่มีผลจริงไม่ถูกแตะต้อง และนั่นคือเหตุผลที่การแก้ไขที่ดูเหมือนใช้แล้วไม่มีผลใด ๆ
รักษา DNS ของอุโมงค์และเส้นทางให้สอดคล้องกัน
โปรไฟล์ VPN ที่ดันตัวแก้ชื่อแต่ไม่ดันคำนำหน้าที่บรรจุมันสร้างตัวแก้ชื่อที่ไคลเอนต์เข้าถึงไม่ได้ ส่วนที่ดันคำนำหน้าโดยไม่มีตัวแก้ชื่อทำให้ไคลเอนต์ต้องถามตัวในเครื่อง มองทั้งคู่เป็นรายการกำหนดค่าเดียวและตรวจทั้งสองหลังการเปลี่ยนโปรไฟล์ทุกครั้ง เพราะการดันที่จัดลำดับใหม่หรือนโยบายอุโมงค์แยกทางใหม่สามารถแยกทั้งสองออกจากกัน
ตรวจด้วยว่าไคลเอนต์ทำอะไรกับการตั้งค่าที่ถูกดัน ไคลเอนต์บางตัวใช้เซิร์ฟเวอร์ DNS กับอินเทอร์เฟซของอุโมงค์เท่านั้นและปล่อยตัวแก้ชื่อของอะแดปเตอร์จริงไว้ที่เดิม ดังนั้นตัวใดจะชนะขึ้นอยู่กับเมตริกของอินเทอร์เฟซและชื่อที่ถาม ถ้าคำตอบภายในมาเฉพาะเมื่อปิดอะแดปเตอร์จริง นั่นคือกลไกที่ต้องแก้ไข ไม่ใช่ระเบียนของโดเมน
ยอมรับด้วยการเรียกค้นพบและการดำเนินการจริงหนึ่งครั้ง
การทดสอบการยอมรับที่มีประโยชน์จะรันคำถามตัวระบุตำแหน่งแล้วดำเนินการที่ผ่านการพิสูจน์ตัวตนจริงหนึ่งครั้ง เช่น เปิดแชร์ที่รองรับโดยไดเรกทอรีหรือขอตั๋ว ทำก่อนการเปลี่ยน VPN และอีกครั้งหลัง จากเครื่องเดียวกัน โดยไม่รีบูตคั่นกลาง ข้อมูลรับรองที่แคชไว้และเซสชันที่เปิดอยู่แล้วจะทำให้เส้นทางที่พังดูแข็งแรงได้อย่างเต็มใจ การลงชื่อเข้าใช้เดสก์ท็อปที่สำเร็จจึงไม่ใช่การทดสอบ
คำแนะนำของ Microsoft สำหรับไคลเอนต์ DNS ลากเส้นเดียวกันระหว่างการแก้เนมสเปซภายในกับการส่งต่อคำถามสาธารณะขึ้นไป และนั่นคือการจัดวางที่ต้องรักษาไว้เมื่อนำ VPN มาใช้
ถ้าความล้มเหลวเป็นเพียงความล่าช้า ไม่ใช่ล้มเหลว ให้แยกความหน่วงออกจากการวินิจฉัย การหมดเวลาระหว่างการค้นพบอาจมาจากคอนโทรลเลอร์ที่เข้าถึงไม่ได้ พอร์ตที่ถูกบล็อก หรือตัวแก้ชื่อที่ตอบช้า และไม่มีข้อใดพิสูจน์ได้ด้วยการรอเพียงอย่างเดียว บันทึกคำถามจริง คำตอบ และความพยายามเชื่อมต่อก่อนเปลี่ยนการตั้งค่าตัวแก้ชื่อ