เลือกบทบาท
ตัวแก้ไขแบบเรียกซ้ำเช่น Unbound และอินเทอร์เฟซกรองเช่น AdGuard Home แก้ปัญหาที่เกี่ยวข้องแต่แตกต่างกัน ตัดสินใจว่าบริการจะเรียกซ้ำเองหรือส่งต่อไปยังต้นทาง และเข้าใจว่าฝ่ายใดจะเห็นคำค้นหา
เก็บเป็นส่วนตัว
ตัวแก้ไขชื่อสาธารณะแบบไม่จำกัดอาจถูกใช้ในทางที่ผิดเพื่อการโจมตีแบบสะท้อน ผูกกับเครือข่ายส่วนตัวหรืออนุญาตเฉพาะแหล่งที่ได้รับอนุญาต รวมถึง IPv6 หากใช้ DNS แบบเข้ารหัส ให้ตรวจสอบสิทธิ์หรือจำกัดการเข้าถึงอย่างเหมาะสมแทนที่จะถือว่า HTTPS ทำให้เป็นส่วนตัว
กำหนดนโยบายการบันทึกเหตุการณ์
คำค้น DNS สามารถเปิดเผยกิจกรรมการท่องเว็บและแอปพลิเคชันที่ละเอียดอ่อนได้ ปิดการเก็บรักษาที่ไม่จำเป็น ปกป้องบันทึกที่คุณเก็บไว้ และอธิบายขอบเขตให้ผู้ใช้ทราบ การขนส่งแบบเข้ารหัสปกป้องเส้นทาง แต่ไม่ได้ป้องกันตัว resolver เองจากการมองเห็นคำค้น
ทดสอบมากกว่าหนึ่งชื่อ
ตรวจสอบพฤติกรรม DNSSEC ในกรณีที่เปิดใช้งาน ผลลัพธ์ IPv4 และ IPv6 ข้อยกเว้นการกรอง และการกู้คืนเมื่ออัปสตรีมล้มเหลว เก็บวิธีที่ปลอดภัยในการแก้ไขการเข้าถึงโดยไม่พึ่งพาตัวแก้ไขที่คุณกำลังซ่อมเพียงอย่างเดียว
พิสูจน์ว่าคนแปลกหน้าไม่สามารถสอบถามได้
ผูกตัวแก้ไขกับอินเทอร์เฟซที่ตั้งใจ กำหนดช่วงไคลเอนต์ที่อนุญาต และจำกัดไฟร์วอลล์ ตรวจสอบความถูกต้องของการกำหนดค่าก่อนรีสตาร์ท สอบถามจากไคลเอนต์ที่ได้รับอนุญาต แล้วทำซ้ำจากภายนอกเครือข่ายที่เชื่อถือได้: คำขอนั้นควรถูกปฏิเสธหรือหมดเวลา ตรวจสอบ IPv6 แยกต่างหาก ตัวแก้ไขที่ยอมรับคำถามจากอินเทอร์เน็ตโดยพลการอาจกลายเป็นแหล่งของการละเมิด
- รันตัวตรวจสอบการกำหนดค่าก่อนนำการเปลี่ยนแปลงไปใช้
- ทดสอบไคลเอนต์ที่ได้รับอนุญาตและไคลเอนต์ที่ถูกปฏิเสธ
- เก็บการวินิจฉัยคำขอแบบละเอียดไว้ชั่วคราว
unbound-checkconfเอกสารอย่างเป็นทางการ: การกำหนดค่าการควบคุมการเข้าถึงแบบไม่จำกัด
รักษาการอ้างสิทธิ์ DNS ที่เข้ารหัสไว้ให้แม่นยำ
DNS-over-HTTPS หรือ DNS-over-TLS เข้ารหัสเส้นทางการรับส่งข้อมูลเฉพาะ ตัวแปลงสัญญาณยังคงได้รับคำค้นหา และตัวแปลงสัญญาณแบบส่งต่อสามารถส่งต่อไปยังผู้ให้บริการรายอื่นได้ ตรวจสอบการเลือกต้นทางและการเก็บรักษา หากคุณเปิดเผยปลายทางตัวแปลงสัญญาณที่เข้ารหัส ควรกำหนดนโยบายการเข้าถึงให้รอบคอบเท่ากับพอร์ต DNS ทั่วไป
เลือกห่วงโซ่ตัวแปลงชื่อก่อนเปิดพอร์ต
การออกแบบส่วนตัวที่มีประโยชน์คือไคลเอนต์ VPN ที่สอบถาม AdGuard Home โดย AdGuard ส่งต่อไปยัง Unbound บน loopback จากนั้น Unbound ทำการเรียกซ้ำซ้อน (recursion) ส่วน AdGuard เพิ่มการกรองและอินเทอร์เฟซการจัดการ หรือใช้เฉพาะ Unbound สำหรับสแตกที่เล็กกว่า กำหนดที่อยู่/พอร์ตที่แตกต่างกันให้แต่ละ listener และวาดทิศทางการส่งต่อ: การส่ง Unbound กลับไปยัง AdGuard จะสร้างลูป ตัดสินใจว่าไคลเอนต์ส่วนตัวใดอาจใช้บริการก่อนเผยแพร่สิ่งใด
- ปิดพอร์ต TCP และ UDP ขาเข้าสาธารณะ 53 ไว้ เว้นแต่มีนโยบายไคลเอนต์ที่ได้รับอนุญาตเป็นการเฉพาะ
- กำหนดกฎการเข้าถึงแยกกันสำหรับอินเทอร์เฟซการกรองและตัวรับฟัง DNS
- ตรวจสอบความเป็นเจ้าของพอร์ตก่อนติดตั้ง ตัวแก้ไขระบบที่มีอยู่แล้วอาจผูกกับที่อยู่ที่ต้องการไว้แล้ว
เอกสารอย่างเป็นทางการ: การตั้งค่า AdGuard Home
จุดเริ่มต้นของ Unbound แบบ loopback
บนระบบที่ติดตั้ง Unbound ไว้แล้ว ส่วนย่อยต่อไปนี้แสดงตัวอย่างแบ็กเอนด์ที่เข้าถึงได้เฉพาะบนโฮสต์ ให้ผสานเข้ากับการกำหนดค่าของดิสทริบิวชันแทนการเขียนทับการตั้งค่าแพ็กเกจหรือการจัดการ trust-anchor พอร์ตสูงช่วยให้ฟรอนต์เอนด์ DNS อื่นใช้พอร์ต 53 ได้ ตรวจสอบไฟล์ที่มีผลสมบูรณ์แล้วโหลดใหม่ผ่านตัวจัดการบริการที่ติดตั้งไว้ ไคลเอนต์ระยะไกลต้องมีทันเนลหรือฟรอนต์เอนด์ที่ควบคุมแยกต่างหาก ส่วนย่อยนี้จงใจไม่สร้างตัวแปลงชื่อสาธารณะ
server:
interface: 127.0.0.1
port: 5335
access-control: 127.0.0.0/8 allow
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
# Validate the complete installed configuration:
unbound-checkconfเอกสารอย่างเป็นทางการ: เอกสารอ้างอิงการกำหนดค่า Unbound
เรียกใช้รายการตรวจสอบการยอมรับจากสองเครือข่าย
สอบถามแบ็กเอนด์ภายในเครื่องก่อน จากนั้นจึงใช้เส้นทางไคลเอนต์ปกติ ตรวจสอบระเบียน A/AAAA ทั่วไป ชื่อที่ตั้งใจให้ไม่มีอยู่จริง และการตรวจสอบ DNSSEC โดยใช้โดเมนทดสอบที่มีเอกสารระบุ ทำซ้ำจากเครื่องที่อยู่นอกซับเน็ตที่อนุญาต: เครื่องนั้นต้องไม่ได้รับการเรียกซ้ำ ตรวจสอบว่าเบราว์เซอร์ใช้ตัวแก้ไขแบบเข้ารหัสของตัวเองและข้าม DNS ของอุปกรณ์ที่กำหนดค่าไว้หรือไม่ เก็บตัวแก้ไขอิสระชั่วคราวไว้ใช้ระหว่างการเปลี่ยนแปลง เพื่อให้ข้อผิดพลาดด้าน DNS ไม่ตัดเส้นทางการดูแลระบบของคุณ
- การวินิจฉัยในเครื่อง: dig @127.0.0.1 -p 5335 example.org A
- ตรวจสอบการเข้าถึงทั้ง UDP และ TCP รวมถึงตัวรับฟัง IPv6
- ยืนยันข้อยกเว้นการกรองและบันทึกเฉพาะข้อมูลวินิจฉัยที่จำเป็นจริงๆ
วินิจฉัยการหมดเวลา ลูป และความล้มเหลวในการตรวจสอบความถูกต้อง
การหมดเวลาที่ฟรอนต์เอนด์ขณะแบ็กเอนด์ภายในทำงานปกติบ่งชี้ถึงที่อยู่ฟรอนต์เอนด์ ไฟร์วอลล์ หรือเป้าหมายการส่งต่อ คำถามที่ส่งถึงตัวเองซ้ำ ๆ บ่งชี้ถึงลูป ความล้มเหลวของ DNSSEC ในวงกว้างอาจเกี่ยวข้องกับเวลาระบบที่ไม่ถูกต้องหรือการบำรุงรักษา trust anchor แก้ไขสาเหตุแทนที่จะปล่อยให้การตรวจสอบถูกปิดใช้งาน หากเฉพาะการตอบกลับขนาดใหญ่ล้มเหลว ให้ตรวจสอบ TCP fallback และเส้นทางเครือข่าย เก็บการบันทึกคำถามไว้ชั่วคราว และทดสอบการรีสตาร์ทและการกู้คืนการกำหนดค่าก่อนทำให้ตัวแก้ไขเป็นสิ่งที่ทุกอุปกรณ์ต้องพึ่งพา