ทำไมระเบียน SRV จึงช่วยเฉพาะไคลเอนต์ที่สอบถามด้วยตนเอง

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

ระเบียนที่ไม่มีใครสอบถามย่อมช่วยใครไม่ได้

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

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

อ่านฟิลด์ก่อนเขียน

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

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

ค้นหาป้ายที่ไคลเอนต์ส่งจริง

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

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

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

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

ปลายทางต้องมีอยู่จริงด้วย

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

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

การค้นพบไม่ใช่การพิสูจน์ตัวตน

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

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