DNSSEC มีประโยชน์หรือไม่
ไม่สามารถตอบได้ (สำหรับคำใดก็ตามที่คุณใส่แทน "DNSSEC" ในประโยคนั้น) จนกว่าคุณจะเริ่มอธิบายถึงสิ่งที่คุณต้องการปกป้อง
เมื่อคุณมีรายการความเสี่ยง/ช่องโหว่/ภัยคุกคามที่คุณต้องการป้องกันตัวเองแล้ว คุณจะพบว่าโซลูชันใดมีอยู่และพิจารณาว่าโซลูชันนั้นมีประโยชน์มากน้อยเพียงใดสำหรับแต่ละโซลูชัน
DNSSEC มีประโยชน์สำหรับปัญหา DNS บางประเภท แต่ไม่ใช่กับปัญหาทั้งหมด มันนำเสนอปัญหาใหม่ ๆ (การบำรุงรักษาลายเซ็นและคีย์อย่างต่อเนื่องสำหรับหนึ่งรายการ) แต่ยังรวมถึงคุณสมบัติใหม่ (การแคชเชิงรุกของทุกสิ่งที่อยู่ด้านล่าง a NXDOMAIN หากได้รับการตรวจสอบอย่างถูกต้องโดย DNSSEC)
แม้ว่าตัวแก้ไข DNS จะตรวจสอบว่าเนมเซิร์ฟเวอร์ที่ได้รับอนุญาตได้ส่งข้อมูลที่ถูกต้องโดยไม่ถูกแก้ไข เราจะป้องกันไม่ให้ตัวแก้ไข DNS ส่งการตอบกลับ DNS ที่ดัดแปลงไปยังไคลเอนต์ DNS ได้อย่างไร
ไม่มีอะไรแตกต่างจากวันนี้: หากคุณใช้ตัวแก้ไข DNS สาธารณะ (8.8.8.8, 1.1.1.1, 9.9.9.9 เพื่อบอกชื่อไม่กี่คน) แน่นอนว่าคุณมีความเสี่ยงโดยสิ้นเชิงที่จะส่งข้อมูลขยะให้คุณ นั่นคือการแลกเปลี่ยน DoH/DoT ไม่ได้ช่วยแก้ปัญหาใดๆ ในที่นี้ เนื่องจากจะปกป้องเฉพาะการส่งผ่านเนื้อหาระหว่างคุณกับตัวแก้ไขนี้ ไม่ใช่ตัวเนื้อหาเอง เนื้อหาใดได้รับการ "ป้องกัน" โดย DNSSEC ตราบใดที่ชื่อโดเมนที่คุณกำลังค้นหานั้นได้รับการป้องกันด้วย DNSSEC (ซึ่งเป็นส่วนหนึ่งที่คุณลืมในคำถามของคุณ และทำให้ DNSSEC เป็นเรื่องยาก: เจ้าของชื่อโดเมนต้องเปิดใช้งาน และ ตัวแก้ไข DNS ต้องใช้ลายเซ็นใหม่และทำการตรวจสอบความถูกต้อง หากไม่มีส่วนใดส่วนหนึ่งของสมการ 2 ตัวแปรนี้ DNSSEC ก็ไม่มีประโยชน์เพราะมันใช้งานไม่ได้)
ดังนั้นคำถามจึงวนเวียนอยู่รอบ ๆ ตัว: เนมเซิร์ฟเวอร์แบบเรียกซ้ำตัวใดที่จะใช้และควรเรียกใช้ที่ใด แน่นอน เพื่อการควบคุมสูงสุด คุณต้องการให้ตัวแก้ไขทำงานบนเครื่องของคุณ ยังคงสามารถใช้ทรัพยากรภายนอกและตัวแก้ไข DNS ที่นั่นได้ แต่การตรวจสอบ DNSSEC ขั้นสุดท้ายควรเกิดขึ้นบนเนมเซิร์ฟเวอร์ของคุณ ไม่ใช่ที่อื่น แน่นอนว่านี่เป็นการทำงานมากกว่าการพึ่งพาทรัพยากรอื่นใดที่ทำ DNSSEC ทั้งหมด "ฟรี" ให้คุณ
หากตัวแก้ไข DNS ไม่รองรับ DNSSEC จะยังสามารถส่งการสืบค้น DNS ไปยังเนมเซิร์ฟเวอร์ที่มีสิทธิ์ซึ่งมีการตั้งค่า DNSSEC สำหรับโซนของตนได้หรือไม่
ใช่.
ตัวแก้ไขที่ต้องการมีข้อมูล DNSSEC จะต้องเปลี่ยนแฟล็ก "DO" ในคำขอ
จาก ขุด เอกสาร:
+[ไม่]dnssec
ตัวเลือกนี้ขอให้ส่งระเบียน DNSSEC โดยการตั้งค่าบิต DNSSEC OK (DO) ในระเบียน OPT ในส่วนเพิ่มเติมของแบบสอบถาม
ซึ่งคุณสามารถดูได้ว่า:
$ ขุด +dnssec example.com
; <<>> DiG 9.16.18 <<>> +dnssec example.com
;; ตัวเลือกส่วนกลาง: +cmd
;; การส่ง:
;; ->>HEADER<<- opcode: QUERY, สถานะ: NOERROR, id: 40492
;; ธง: โฆษณา rd; คำถาม: 1, คำตอบ: 0, ผู้มีอำนาจ: 0, เพิ่มเติม: 1
;; เลือก PSEUDOSECTION:
; EDNS: เวอร์ชัน: 0, แฟล็ก: ทำ; UDP: 4096
^^
หรือจาก §3.2.1 ของ RFC 4035:
3.2.1. DO บิต
ต้องตั้งค่าด้านตัวแก้ไขของเซิร์ฟเวอร์ชื่อเรียกซ้ำที่คำนึงถึงความปลอดภัย
บิต DO เมื่อส่งคำขอ โดยไม่คำนึงถึงสถานะของ DO
บิตในคำขอเริ่มต้นที่ได้รับจากฝั่งเนมเซิร์ฟเวอร์ ถ้า
ไม่ได้ตั้งค่าบิต DO ในการสืบค้นเริ่มต้น ซึ่งเป็นฝั่งเนมเซิร์ฟเวอร์
ต้องตัด DNSSEC RR ที่ตรวจสอบสิทธิ์ออกจากการตอบกลับ แต่ต้อง
ห้ามตัดประเภท DNSSEC RR ใดๆ ที่การสืบค้นเริ่มต้นอย่างชัดเจน
ร้องขอ
หากไคลเอ็นต์ DNS (ตัวแก้ไขแบบเรียกซ้ำ) ทำสิ่งนี้ และหากเนมเซิร์ฟเวอร์ที่มีสิทธิ์ถูกสอบถามเปิดใช้งาน DNSSEC (ด้วยเหตุนี้ อาร์เอสซิก/ส.ป.ก/กศน.3 ประเภทเรคคอร์ดในโซน) จากนั้นตัวแก้ไขจะรับเรคคอร์ดเหล่านั้นและจากนั้นจะทำการตรวจสอบความถูกต้องของ DNSSEC
เมื่อคุณ (ต้นขั้ว DNS/ไคลเอนต์ไม่ใช่ตัวแก้ไข) สอบถามตัวแก้ไขแบบเรียกซ้ำ คุณจะมีตัวเลือกในการใช้ ซีดี ธง กำหนดไว้ดังนี้:
+[no]ซีดีแฟล็ก
ตัวเลือกนี้ตั้งค่า [หรือไม่ได้ตั้งค่า] บิตซีดี (ปิดการตรวจสอบ) ในแบบสอบถาม สิ่งนี้ร้องขอให้เซิร์ฟเวอร์ไม่ดำเนินการตรวจสอบ DNSSEC ของการตอบสนอง
(ระวังการปฏิเสธสองครั้งที่เป็นไปได้)
หากลูกค้าไม่ได้ใช้ ซีดีจากนั้นการตรวจสอบ DNSSEC จะไม่ถูกปิดใช้งาน ดังนั้นจึงเปิดใช้งานและเซิร์ฟเวอร์การลบจะให้บริการคำตอบสุดท้าย (หากเปิดใช้งาน DNSSEC สำหรับบันทึกและการตรวจสอบความถูกต้องสำเร็จ) หรือจะตอบกลับด้วย NXDOMAIN หากการตรวจสอบ DNSSEC ล้มเหลว
ธง ค.ศ จะถูกตั้งค่าให้แสดงว่าระเบียนทั้งหมดได้รับการตรวจสอบแล้วว่าปลอดภัย หากเป็นกรณีนี้ (หากการสืบค้นมาจากเนมเซิร์ฟเวอร์แบบเรียกซ้ำ แฟล็กนั้นจะไม่มีอยู่จากอันที่มีสิทธิ์ เนื่องจากคุณต้องการเชน DNSSEC แบบเต็มจากรูท IANA เพื่อตรวจสอบความถูกต้อง บันทึกใด ๆ ที่กำหนด)