การจับ Split-DNS: บอกว่าแต่ละการสังเกตเกิดขึ้นที่ไหน

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

การค้นหาหนึ่งครั้ง จุดสังเกตหลายจุด

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

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

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

ตัวกรองของไคลเอนต์อยู่ระหว่างแอปกับสาย

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

คำแนะนำ Split-DNS ของ Secure Client จาก Cisco ครอบคลุมการจับคู่โดเมนและตัวกรอง Windows และแยกสิ่งที่แอปเห็นเมื่อใช้ API ของ resolver แบบเนทีฟออกจากสิ่งที่เครื่องมืออย่าง nslookup เห็น ความแตกต่างเหล่านั้นคือประเด็น

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

nslookup ใช้เส้นทางต่างจากแอป

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

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

อ่านนโยบายแล้วถามคำถามเดียวกันผ่าน resolver ปกติ:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

resolver ที่เข้ารหัสซ่อนคำขอ ไม่ใช่การเชื่อมต่อ

เบราว์เซอร์ที่มี resolver DNS-over-HTTPS ของตัวเองเป็นอีกกรณีหนึ่งโดยสิ้นเชิง คำขอออกไปภายใน TLS ดังนั้นการจับแพ็กเก็ตจึงแสดงการเชื่อมต่อกับที่อยู่ resolver แต่ไม่แสดงชื่อที่ถาม

หาแนวทางนโยบายที่จัดการของเบราว์เซอร์ก่อน แล้วเปรียบเทียบกับการค้นหาของระบบปฏิบัติการ เบราว์เซอร์ที่ได้รับอนุญาตให้เลือก resolver เองอาจไม่เห็นนโยบาย Split-DNS เลย

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

เปรียบเทียบกับการทดสอบที่มีป้ายกำกับ

เลือกชื่อภายในที่ได้รับอนุมัติสำหรับการทดสอบ พร้อมชื่อสาธารณะที่ไม่มีความหมายอ่อนไหว สำหรับแต่ละชื่อ บันทึกเวลา ชนิดระเบียน คำตอบ และนโยบายที่คาดไว้

ในที่ที่อนุญาต ให้เปรียบเทียบการรับของ resolver กับการสังเกตที่แคบหนึ่งครั้งจากไคลเอนต์หรือเกตเวย์:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

อย่าส่งชื่อส่วนตัวไปยัง resolver สาธารณะที่ไม่เกี่ยวข้องเพียงเพื่อสร้างการเปรียบเทียบ และปกปิดทุกสิ่งที่คุณแบ่งปัน สุดท้าย แยกคำตอบ DNS ที่ถูกต้องออกจากการเชื่อมต่อบริการที่ตามมา ที่อยู่ส่วนตัวที่แปลงแล้วยังต้องมีเส้นทางและการอนุญาตของแอปพลิเคชัน