Score:2

DNSSEC มีประโยชน์หรือไม่

ธง fr

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

  1. แม้ว่าตัวแก้ไข DNS จะตรวจสอบว่าเนมเซิร์ฟเวอร์ที่ได้รับอนุญาตได้ส่งข้อมูลที่ถูกต้องโดยไม่ถูกแก้ไข เราจะป้องกันไม่ให้ตัวแก้ไข DNS ส่งการตอบกลับ DNS ที่ดัดแปลงไปยังไคลเอนต์ DNS ได้อย่างไร

  2. หากตัวแก้ไข DNS ไม่รองรับ DNSSEC จะยังสามารถส่งการสืบค้น DNS ไปยังเนมเซิร์ฟเวอร์ที่มีสิทธิ์ซึ่งเปิดใช้งาน DNSSEC สำหรับโซนของตนได้หรือไม่

ขอขอบคุณ

cn flag
1.ค่อนข้างง่าย การตรวจสอบและการบังคับใช้ต้องทำกับไคลเอนต์ ระยะเวลา. Windows สามารถทำได้โดยกำเนิด ฉันไม่แน่ใจเกี่ยวกับ Linux หรือแพลตฟอร์มอื่นๆ
Patrick Mevzek avatar
cn flag
@GregAskew เพียงแค่ติดตั้ง unbound และสามารถตรวจสอบทุกอย่างในเครื่องได้
Score:2
ธง cn

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 เพื่อตรวจสอบความถูกต้อง บันทึกใด ๆ ที่กำหนด)

Score:1
ธง cn
  1. ตามหลักการแล้ว คุณควรตรวจสอบความถูกต้องภายในเครื่องไคลเอ็นต์ (ไม่ใช่สิ่งที่พบได้ทั่วไปในทุกวันนี้ แต่ยังห่างไกลจากสิ่งที่ไม่เคยได้ยินมาก่อน) หรือใช้เส้นทางเครือข่ายที่ปลอดภัยที่เชื่อมช่องว่างจากไคลเอนต์ไปยังตัวแก้ไขที่ตรวจสอบความถูกต้องที่เชื่อถือได้
    เส้นทางเครือข่ายที่ปลอดภัยนี้อาจหมายถึงบางอย่างเช่น DNS-over-TLS, DNS-over-HTTPS, DNSCrypt หรือเครือข่ายท้องถิ่นในระดับหนึ่ง (ระดับความน่าเชื่อถือที่อ่อนแอ แต่ก็ยังมีประโยชน์สำหรับสถานการณ์การโจมตีบางส่วน)
  2. ใช่
cn flag
สำหรับ 1. ฉันคิดว่าการใช้งาน DNSSEC ที่ไม่ได้ตรวจสอบไคลเอนต์นั้นเป็นอันตราย นี่เป็นเฉพาะแพลตฟอร์ม มีจุดสิ้นสุดระยะไกลของ Windows มากขึ้น ดังนั้นนั่นคือจุดที่มีความเสี่ยง การตรวจสอบความถูกต้องของไคลเอ็นต์บน Windows นั้นง่ายต่อการกำหนดค่าและการไม่ทำเช่นนั้นถือว่าผิด มันไม่ใช่สถานการณ์ทั้งหมดหรือไม่มีอะไรเลย จากมุมมองของไคลเอนต์ Windows ความเสี่ยงส่วนใหญ่เกิดขึ้นกับโดเมนภายใน ดังนั้นหากมีการบังคับใช้เฉพาะโดเมนเหล่านี้ จะเป็นการเริ่มต้นที่ดี ในฝั่งเซิร์ฟเวอร์ การหมุนเวียนคีย์ทั้งหมดจะเป็นไปโดยอัตโนมัติ ดังนั้นมันจึงใช้งานได้ค่อนข้างดี คุณเพียงแค่ต้องโหลดระเบียน DNS และแบนด์วิธที่ใช้มากขึ้นบนรถบรรทุก
cn flag
@GregAskew ตัวชี้ใด ๆ เกี่ยวกับวิธีการดำเนินการนี้บน Windows
cn flag
ตารางนโยบายการแก้ไขชื่อ คุณสามารถกำหนด DNSSEC/IPSEC สำหรับชื่อโดเมนได้ https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn593632(v=ws.11)
cn flag
@GregAskew ขอบคุณที่ชี้แจงอย่างไรก็ตาม ฉันได้เห็นการตั้งค่าเหล่านั้นแล้ว แต่เพื่อให้เข้าใจถึงตัวเลือก "ต้องมีการตรวจสอบความถูกต้อง" นั้นไม่ได้หมายถึงการตรวจสอบไคลเอ็นต์ แต่ไคลเอ็นต์ต้องการให้ตั้งค่าแฟล็ก `AD` หรือไม่ แนวทางดังกล่าวเป็นปัญหาทั้งที่ขึ้นอยู่กับว่าทราฟฟิกไปยังตัวแก้ไขที่กำหนดค่าไว้นั้นปลอดภัยจากการดัดแปลง แต่ก็เป็นไปไม่ได้เช่นกันที่จะเปิดใช้งานตัวเลือกนั้นทั่วโลก เนื่องจากจะละทิ้งสิ่งที่ไม่ได้ลงนามซึ่งตรงข้ามกับพฤติกรรมการตรวจสอบความถูกต้องปกติของการละทิ้งสิ่งต่างๆ ที่เป็นของปลอม (กล่าวคือ ควรเซ็นชื่อแต่ไม่มีลายเซ็นที่ถูกต้อง)
cn flag
@GregAskew ตัวเลือก IPSec ในทางกลับกันจะเข้าสู่แนวทาง "สร้างเส้นทางเครือข่ายที่ปลอดภัยไปยังตัวแก้ไขที่เชื่อถือได้" ที่ฉันแนะนำในคำตอบของฉัน IPSec ใช้งานได้อย่างแน่นอน แม้ว่ามันจะค่อนข้างเฉพาะเจาะจงสำหรับบางสิ่งที่คุณสามารถตั้งค่าด้วยโครงสร้างพื้นฐานของคุณเอง แทนที่จะคาดหวังให้ผู้ให้บริการรายอื่นจัดหาให้ (ซึ่งก็ใช้ได้ แต่เพียงจำกัดขอบเขตที่เกี่ยวข้อง) แต่โดยรวมแล้ว ไม่มีตัวเลือกใดที่ดูเหมือนจะให้การตรวจสอบกับไคลเอ็นต์ เท่าที่ฉันสามารถบอกได้

โพสต์คำตอบ

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