DNSSec: คืออะไรและเพราะเหตุใด การตรวจสอบค่า TTL สูงสุดในโซนโดเมน DNSSEC ทำงานอย่างไร
นอกจากนี้ ระเบียน NSEC3 ยังมีฟิลด์แฟล็กที่ NSEC ไม่มี ในขณะนี้ มีการกำหนดธงเดียวเท่านั้น - OPT-OUT ซึ่งเป็นไปได้ที่จะลงนามไม่ใช่ทั้งโซน (ซึ่งหากมีขนาดใหญ่อาจเป็นกระบวนการที่ยาวมาก) แต่มีเพียงชื่อโดเมนที่มี DS เท่านั้น บันทึก
ในอีกด้านหนึ่ง การเลือกไม่ใช้สามารถลดเวลาลายเซ็นได้อย่างมาก แต่เมื่อใช้แล้ว การเข้าถึงไฟล์โซนของผู้โจมตีจะทำให้เขาสามารถเพิ่มบันทึกที่ไม่ได้รับการป้องกัน ซึ่งอาจทำให้เกิดปัญหาได้ในอนาคต
กลไกการทำงาน
สมมติว่าเราต้องการค้นหาที่อยู่ test.bar.example.com:- เราขอชื่อโดเมนจากตัวแก้ไข
- ตัวแก้ไขจะตั้งค่าบิต DO และร้องขอ test.bar.example.com จากเซิร์ฟเวอร์รูท
- ตัวแก้ไขรู้ว่ามีการเซ็นชื่อโซนโดเมนราก - โดยมีคีย์หรือแฮชของคีย์อยู่ (ที่เรียกว่า trust-anchor) ดังนั้นจึงขอเซิร์ฟเวอร์รูทสำหรับบันทึก DNSKEY สำหรับโซนรูทและเปรียบเทียบสิ่งที่ได้รับ กับสิ่งที่มีอยู่
- เซิร์ฟเวอร์รูทไม่ทราบชื่อโดเมนดังกล่าว และโดยทั่วไปสิ่งที่ทราบมากที่สุดก็คือเซิร์ฟเวอร์ใดที่โซน com ตั้งอยู่ โดยจะรายงานที่อยู่ของเซิร์ฟเวอร์เหล่านี้ไปยังรีโซลเวอร์ของเราพร้อมกับบันทึก DS ที่ลงนามแล้วสำหรับโซน com
- ตัวแก้ไขจะตรวจสอบความถูกต้องของบันทึก DS ด้วยคีย์โซนราก ZSK ที่ได้รับและตรวจสอบแล้ว
- ตอนนี้ตัวแก้ไขรู้ว่าโซน com ได้รับการลงนามแล้ว ดังนั้นจึงถามเซิร์ฟเวอร์ DNS สำหรับ DNSKEY และตรวจสอบความถูกต้อง หลังจากนั้นจึงสอบถามเกี่ยวกับ bar.example.com โดยปกติแล้ว เซิร์ฟเวอร์ของโซน com จะไม่ทราบเกี่ยวกับสิ่งเหล่านี้ แต่จะรู้เพียงว่าโซน example.com นั้นอยู่บน ns.example.com และ ns1.example.com และนี่คือสิ่งที่ตอบสนองต่อตัวแก้ไขพร้อมกับ - ใช่ ใช่ - บันทึก DS;
- ดังนั้นตัวแก้ไขจึงได้สร้างสายโซ่แห่งความไว้วางใจให้กับ example.com โดยจะจดจำเนมเซิร์ฟเวอร์ของโซน bar.example.com และ DS ของมัน
- ในท้ายที่สุด ตัวแก้ไขจะค้นหาที่อยู่ของเซิร์ฟเวอร์ DNS ที่รับผิดชอบ bar.example.com ซ้ำๆ จากนั้นไปหาที่อยู่เหล่านั้นและได้สิ่งที่ต้องการในที่สุด ตรวจสอบข้อมูลทั้งหมด และมอบบันทึกที่อยู่ให้เรา โดยตั้งค่าบิต AD ใน การตอบสนอง.
ผลกระทบ
- การรับส่งข้อมูลขาออกไปยังเซิร์ฟเวอร์ DNS ที่เชื่อถือได้เพิ่มขึ้นประมาณ 4 เท่า
- ขนาดของไฟล์โซนหลังจากการลงนาม (โดยไม่ต้อง OPT-OUT) เพิ่มขึ้น 6-7 เท่า
- การเพิ่มความยาวของคีย์จะทำให้ qps ของตัวแก้ไขลดลงอย่างเห็นได้ชัด ซึ่งจะส่งผลต่อเซิร์ฟเวอร์ที่เชื่อถือได้ในระดับที่น้อยลง
- ในทางตรงกันข้าม มีจำนวนการวนซ้ำเพิ่มขึ้นเมื่อใช้ NSEC3
- DNSSec นำไปสู่การเพิ่มขึ้นอย่างมากในการตอบสนอง DNS ดังนั้นจึงจำเป็นที่อุปกรณ์เครือข่ายทั้งหมดทำงานอย่างถูกต้องกับแพ็กเก็ต DNS ที่มีขนาดใหญ่กว่า 512 ไบต์
เหตุใดจึงจำเป็น?
มันเป็นคำถามที่ยาก ขั้นแรกต้องคำนึงถึงผลกระทบที่สร้างขึ้น ประการที่สอง จำเป็นต้องจัดระเบียบที่เก็บคีย์ที่เชื่อถือได้ ประการที่สาม ตรวจสอบการหมุนคีย์ ประการที่สี่ ตรวจสอบวันหมดอายุของลายเซ็น ประการที่ห้า DNSSec ปรับปรุงผลกระทบของ ddos ที่ขยายเพิ่มทั้งหมดนี้เป็นราคาที่ต้องจ่ายเพื่อให้มั่นใจในข้อมูลที่คุณได้รับจากเซิร์ฟเวอร์ DNS ที่เชื่อถือได้ อย่างไรก็ตาม ในตอนนี้ ชุมชนกำลังคิดว่ามีอะไรอีกบ้างที่สามารถรวมไว้ใน DNSSec เพื่อให้สามารถสร้างรายได้ และบางคนถึงกับถามคำถามที่กล้าหาญและน่าสนใจ เช่น Phil Regnauld สมาชิกของสภาวิทยาศาสตร์ AFNIC ที่ถาม “DNSSEC จะทำให้อุตสาหกรรมใบรับรองล่มสลายหรือไม่” ในงานสัมมนาของสภาแห่งนี้
บริษัทจัดการชื่อโดเมนและที่อยู่ IP หรือ ICANN เตือนถึงการหยุดชะงักที่อาจเกิดขึ้นในเครือข่ายทั่วโลก เนื่องจากการอัปเดตคีย์การเข้ารหัสสำหรับการร้องขอการตั้งชื่อเซิร์ฟเวอร์การแก้ไขชื่อโดยใช้โปรโตคอล DNSSEC ตามข่าวประชาสัมพันธ์ของ ICANN
คีย์การเข้ารหัส DNSSEC ได้รับการอัปเดตเป็นครั้งแรกนับตั้งแต่ระบบเปิดตัวในวันที่ 15 กรกฎาคม 2010 เมื่อมีการลงนามโซนราก ซึ่งบางครั้งเรียกว่า “จุด” ซึ่งก็คือโซนเหนือโดเมนระดับบนสุด เช่น . com., .ru., .org. และอื่นๆ (ในอินเทอร์เฟซของเบราว์เซอร์ โดยปกติจะละเว้นจุดต่อท้าย) การตัดสินใจออก "คีย์การลงนามคีย์" หรือ KSK ใหม่สำหรับโซนรูทนั้นล่าช้าหลายครั้ง แผนเดิมคือการลงนามโซนรูทอีกครั้งทุก ๆ ห้าปีเพื่อความปลอดภัย - มีการวางแผนการเปลี่ยนคีย์ครั้งแรก 2558. ข้อกังวลของ ICANN คือเซิร์ฟเวอร์ DSN ที่เปิดใช้งาน DNSSEC บางเครื่องจะเปลี่ยนไปใช้คีย์การเข้ารหัสใหม่: เซิร์ฟเวอร์ที่ได้รับการกำหนดค่าครั้งหนึ่งอาจทำงานได้อย่างถูกต้องตลอดเวลานี้ แต่เจ้าของอาจไม่ได้พิจารณาถึงความเป็นไปได้ในการอัปเดต KSK
บริการกำหนดค่า DNSSEC อย่างง่ายสำหรับเจ้าของโดเมนจากเซ็กเมนต์รัสเซีย ซึ่งก็คือในโซน ru “рф” และ su นั้นให้บริการโดยผู้รับจดทะเบียนเพียงสามรายเท่านั้น ซึ่งเป็นเจ้าของเซิร์ฟเวอร์ DNS ของตนเองด้วย: nic.ru, reg.ru และ ชื่อเว็บ.ru. จนถึงตอนนี้ โปรโตคอลยังไม่ได้รับความนิยมเป็นพิเศษ: จากสถิติของ "ศูนย์ประสานงาน" ที่ควบคุมโซนรัสเซีย จากจำนวนโดเมนรัสเซีย 5.6 ล้านโดเมน จำนวนโดเมนที่รองรับ DNSSEC ไม่เกิน 3,000 รายการ ณ เดือนกันยายน 2018 แม้ว่าสิ่งเหล่านี้จะรวมถึง ทรัพยากร Runet ที่ใหญ่ที่สุดและเป็นที่นิยมมากที่สุด ในเวลาเดียวกัน บริการยอดนิยมในหมู่เจ้าของโดเมนรัสเซีย Yandex Connect ไม่รองรับ DNSSEC แม้ว่า Yandex.DNS จะให้การสนับสนุนโปรโตคอลที่ปลอดภัยสำหรับผู้ใช้ตามบ้านก็ตาม ในพื้นที่โดเมนส่วนกลาง มีโดเมนจำนวนมากที่ใช้ DNSSEC: ตาม statdns จาก 135 ล้านโดเมนใน com โซนเพียงอย่างเดียว มีชื่อโดเมนเกือบล้านชื่อที่มี DNSSEC
ในความคิดเห็นเกี่ยวกับการอัพเกรด นายทะเบียนชาวรัสเซียทั้งสามรายที่สนับสนุน DNSSEC ระบุว่าพวกเขาพร้อมที่จะเปลี่ยน KSK แล้ว ขณะนี้พวกเขากำลังทำงานกับคีย์เก่าในโหมดแอคทีฟ และด้วยคีย์ใหม่ ซึ่งเป็นส่วนสาธารณะที่เผยแพร่โดย ICANN เมื่อเดือนกันยายน 11 ต.ค. 2017 - อยู่ในโหมดพาสซีฟ ตามคำสั่งของ ICANN นายทะเบียนพร้อมที่จะเปลี่ยนสถานะของคีย์และไม่คาดว่าจะเกิดข้อผิดพลาด ผู้ถือครองเซิร์ฟเวอร์แก้ไขชื่อโดเมนรายใหญ่ที่สุดของตนเองซึ่งไม่ได้มาจากผู้รับจดทะเบียน ได้แก่ Rostelecom, Megafon, Beeline และ MTS ระบุในความคิดเห็นต่อ RBC ว่าพวกเขาพร้อมที่จะเปลี่ยนคีย์ด้วย อย่างไรก็ตาม เป็นไปไม่ได้ที่จะคาดการณ์ได้ว่าการเปลี่ยนแปลง KSK จะนำไปสู่ความล้มเหลวสำหรับเจ้าของเซิร์ฟเวอร์ DNS ขนาดเล็กหรือไม่ เช่น สำหรับผู้ให้บริการในเมืองเล็ก ๆ แม้ว่า ICANN จะทำงานอย่างกระตือรือร้นกับผู้ดูแลระบบด้านเทคนิคของผู้ให้บริการ ผู้ให้บริการโทรคมนาคม และบริษัทอื่น ๆ ที่ทำงานโดยตรง ด้วยโครงสร้างพื้นฐานอินเทอร์เน็ต
บริการ DNS หรือ Domain Name System ได้รับการพัฒนาเกือบจะพร้อมกันกับการเปิดตัวโดเมนในช่วงทศวรรษ 1980 เมื่อเข้าถึงชื่อโดเมน (เช่น เว็บไซต์) ผ่านบริการ DNS ผู้ให้บริการอินเทอร์เน็ตจะค้นหาที่อยู่ IP (เช่น 87.236.16.85) ที่สอดคล้องกับชื่อโดเมน เจ้าของโดเมนระบุสิ่งที่เรียกว่า "บันทึกทรัพยากร" (เช่น * A 87.236.16.85) บนเซิร์ฟเวอร์ DNS ของตนเอง (เช่น ns1.beget.com) เซิร์ฟเวอร์ DNS อื่นๆ จะคัดลอกบันทึกเหล่านี้เมื่อเวลาผ่านไป และสร้างแคชจากบันทึกเหล่านี้ เพื่อไม่ให้ติดต่อกับเซิร์ฟเวอร์เดิมในแต่ละครั้ง ก่อนที่จะมีการเปิดตัว DNSSEC เซิร์ฟเวอร์ DNS จะเชื่อถือข้อมูลของกันและกันโดยไม่มีเงื่อนไข ซึ่งทำให้เซิร์ฟเวอร์เหล่านี้เสี่ยงต่อการถูกโจมตีโดยผู้โจมตีเพื่อ “ทำลายแคช” กล่าวคือ ให้เซิร์ฟเวอร์ DNS “ที่เชื่อถือได้” พร้อมบันทึกแทนที่ที่อยู่ IP สำหรับที่อยู่ของผู้โจมตี . ดังนั้นผู้เยี่ยมชมแหล่งข้อมูลขนาดใหญ่ ธนาคารออนไลน์ โซเชียลเน็ตเวิร์ก บริการค้นหา และไซต์อื่น ๆ อาจถูกนำไปยังแหล่งข้อมูลปลอม
เพื่อกำจัดปัญหาแคช DNS และภัยคุกคามอื่นๆ จึงได้มีการพัฒนา “DNS Security Extensions” หรือ DNSSEC การใช้งานโปรโตคอลแบบขยายถูกชะลอตัวลงเนื่องจากความต้องการในพลังการประมวลผลของเซิร์ฟเวอร์และภาระงานสูงบนเครือข่าย โปรโตคอล DNSSEC-bis แบบง่าย ซึ่งเข้ากันได้กับระบบ DNS แบบย้อนหลัง ได้นำเสนอใบรับรองอิเล็กทรอนิกส์ที่เน้นการประมวลผลน้อยกว่าจากโซนรูทไปยังแต่ละโดเมนที่เซิร์ฟเวอร์ DNS สามารถตรวจสอบได้ทันทีเพื่อความถูกต้องของคำขอแต่ละรายการ KSK ของโซนรากต้องมีการอัปเดตเป็นระยะ: คีย์ 1024 บิต KSK-2010 สร้างขึ้นในปี 2010 มีความซับซ้อนในปี 2560 เป็น KSK-2017 2048 บิตเพื่อตอบสนองต่อการเพิ่มขึ้นของพลังการประมวลผลของโลกซึ่งอาจเพียงพอ เพื่อเลือกรหัส
ระบบแก้ไขชื่อ DNS ซึ่งเป็นหนึ่งในรากฐานของระบบการสื่อสารเครือข่ายสมัยใหม่ได้รับการพัฒนามานานกว่า 20 ปีที่แล้ว โดยแทบไม่ได้คำนึงถึงปัญหาด้านความปลอดภัยของข้อมูลเลย ข้อเสียเปรียบหลักประการหนึ่งของระบบ DNS คือความสามารถในการปลอมแปลงการตอบสนองต่อคำขอ DNS
ปัญหาคือความถูกต้องของการตอบสนองของเซิร์ฟเวอร์ DNS ไม่ได้รับการยืนยันในทางใดทางหนึ่ง ซึ่งหมายความว่าหากเซิร์ฟเวอร์ DNS ถูกแฮ็ก (และเปลี่ยนเส้นทางไปยังเซิร์ฟเวอร์ DNS ปลอม) บันทึก DNS จะถูกแก้ไข หรือเกิดอาการแคช DNS ขึ้น ผู้ใช้ สามารถส่งไปยังที่อยู่ IP ที่กำหนดเองได้ และผู้ใช้จะมั่นใจอย่างเต็มที่ว่าเขาทำงานกับไซต์หรือบริการที่ถูกต้องตามกฎหมาย ผู้โจมตีใช้เทคนิคเหล่านี้กันอย่างแพร่หลาย โดยเปลี่ยนเส้นทางผู้ใช้ไปยังไซต์ที่มีโค้ดที่เป็นอันตราย หรือเก็บรวบรวมข้อมูลส่วนบุคคล (รหัสผ่าน หมายเลขบัตรเครดิต ฯลฯ) โดยใช้สิ่งที่เรียกว่า การโจมตีทางฟาร์ม
เหตุใดเราจึงต้องมีเทคโนโลยี DNSSEC
ส่วนขยายการรักษาความปลอดภัยของ DNS (DNSSEC)– เทคโนโลยีที่ออกแบบมาเพื่อเพิ่มความปลอดภัยของบริการ DNS ผ่านการใช้ลายเซ็นเข้ารหัสที่ช่วยให้สามารถตรวจสอบความถูกต้องของข้อมูลที่ได้รับจากเซิร์ฟเวอร์ DNS ได้โดยไม่ซ้ำกัน เหล่านั้น. การสอบถามและการตอบกลับทั้งหมดจากเซิร์ฟเวอร์ DNS ที่เปิดใช้งาน DNSSEC จะต้องลงนามแบบดิจิทัล ซึ่งไคลเอ็นต์สามารถตรวจสอบความถูกต้องได้โดยใช้รหัสสาธารณะ ลายเซ็นดิจิทัลเหล่านี้ถูกสร้างขึ้นเมื่อมีการลงนามโซน (ใช้ DNSSEC)
กลไกการตรวจสอบ DNSSEC ทำงานในลักษณะที่เรียบง่าย: ไคลเอนต์ส่งคำขอไปยังเซิร์ฟเวอร์ DNS เซิร์ฟเวอร์ส่งคืนการตอบสนอง DNS ด้วยลายเซ็นดิจิทัล เพราะ ไคลเอนต์มีคีย์สาธารณะของผู้ออกใบรับรองที่ลงนามบันทึก DNS โดยสามารถถอดรหัสลายเซ็น (ค่าแฮช) และตรวจสอบการตอบสนองของ DNS เมื่อต้องการทำเช่นนี้ ต้องกำหนดค่าทั้งไคลเอ็นต์และเซิร์ฟเวอร์ DNS ให้ใช้จุดยึดที่เชื่อถือได้เดียวกัน เชื่อถือสมอ– คีย์สาธารณะที่กำหนดค่าล่วงหน้าซึ่งเชื่อมโยงกับโซน DNS เฉพาะ หากเซิร์ฟเวอร์ DNS รองรับหลายโซน ก็สามารถใช้จุดยึดที่เชื่อถือได้หลายรายการได้
สิ่งสำคัญที่ควรทราบคือวัตถุประสงค์หลักของ DNSSEC คือเพื่อป้องกันการปลอมแปลงและการแก้ไขคำขอและการตอบกลับ DNS แต่ข้อมูลที่ส่งผ่านเครือข่ายนั้นไม่ได้เข้ารหัส (แม้ว่าการรักษาความลับของข้อมูล DNS ที่ส่งสามารถมั่นใจได้โดยใช้การเข้ารหัส แต่นี่เป็นทางเลือกและไม่ใช่วัตถุประสงค์หลักของ DNSSEC)
ส่วนประกอบหลักของ DNSSEC ถูกกำหนดไว้ใน RFC ต่อไปนี้:
- อาร์เอฟซี 4033
- อาร์เอฟซี 4034
- อาร์เอฟซี 4035
DNSSEC บนระบบ Windows
การสนับสนุนเทคโนโลยี DNSSEC ปรากฏใน Windows Server 2008 R2 และ Windows 7 อย่างไรก็ตามเนื่องจากการตั้งค่าที่ซับซ้อนและไม่ชัดเจนจึงไม่ได้ใช้กันอย่างแพร่หลาย DNSSEC ได้รับการพัฒนาเพิ่มเติมใน Windows Server 2012 ซึ่งฟังก์ชันการทำงานของ DNSSEC ได้รับการขยายอย่างมาก และช่วยให้สามารถกำหนดค่าผ่านอินเทอร์เฟซแบบกราฟิกได้
ในบทความนี้ เราจะอธิบายการติดตั้งพื้นฐานและการกำหนดค่า DNSSEC ตามเซิร์ฟเวอร์ DNS ที่ใช้ Windows Server 2012 การสร้างโซนที่ลงนามและจุดความน่าเชื่อถือ
การติดตั้งและกำหนดค่า DNSSEC ใน Windows Server 2012
มาสร้างโซน DNS ใหม่ dnssec.contoso.com และเพิ่มบันทึก A ของเซิร์ฟเวอร์ SRV12 หนึ่งรายการด้วยที่อยู่ 192.168.1.14 ลงไป
บันทึก- ใน Windows 8/2012 แทนที่จะใช้ยูทิลิตี้ nslookup หากต้องการรับข้อมูลจากเซิร์ฟเวอร์ DNS จะดีกว่าถ้าใช้ Powershell cmdlet Resolve-DnsName
แก้ไข-DnsName srv12.dnssec.contoso.com –เซิร์ฟเวอร์ SRV12-SUB-CA –DnssecOk
เพราะ โซนไม่ได้ลงนาม คำขอจะไม่ส่งคืนบันทึก RRSIG
มาลงนามโซน DNS ภายใน dnssec.contoso.com ด้วยใบรับรองดิจิทัล ในการดำเนินการนี้ ในคอนโซล DNS ให้คลิกขวาที่โซนแล้วเลือก DNSSEC->ลงนามในโซน.
ในตัวช่วยสร้างการลงนามโซนที่ปรากฏขึ้น ให้คงการตั้งค่าเริ่มต้นไว้ทั้งหมด (ใช้การตั้งค่าเริ่มต้นเพื่อลงนามโซน) -> ถัดไป -> ถัดไป -> เสร็จสิ้น
หลังจากตัวช่วยสร้างเสร็จสิ้น เรกคอร์ดทรัพยากรใหม่ต่อไปนี้จะถูกสร้างขึ้นโดยอัตโนมัติในโซนที่เซ็นชื่อ:
- RRSIG (ลายเซ็นการอ่านทรัพยากร) - ลายเซ็นบันทึกทรัพยากร
- DNSKEY (คีย์สาธารณะ) – เก็บส่วนสาธารณะของคีย์และตัวระบุ
- DS (Delegation Signer) – มีแฮชของชื่อโดเมนของทายาทและคีย์ KSK
- NSEC (Next Secure) และ NSEC3 (Next Secure 3) – ใช้สำหรับการป้องกันการโจมตีด้วยการปลอมแปลงที่เชื่อถือได้
เมื่อลงนามโซนแล้ว รหัสสาธารณะจะถูกจัดเก็บไว้ในไฟล์ %windir%\system32\dns\keyset-dnssec
เรานำเข้าคีย์สาธารณะของโซน (จุดยึดที่เชื่อถือได้เดียวกัน) ไปยัง DNS โดยไปที่ส่วน Trust Point ในคอนโซล DNS เลือกนำเข้า -> DNSKEY และระบุเส้นทางไปยังชุดคีย์-dnssec
บันทึก- คีย์นี้จะต้องถูกแจกจ่ายไปยังเซิร์ฟเวอร์ DNS ทั้งหมดที่จะมีส่วนร่วมในกระบวนการแคชข้อมูลโซนที่เซ็นชื่ออย่างปลอดภัย
จากการนำเข้าคีย์ คีย์ประเภท DNSKEY สองคีย์จะปรากฏในส่วน Trust Points -> dnssec (คีย์หนึ่งใช้งานอยู่ ส่วนอีกคีย์อยู่ในสถานะสแตนด์บาย)
ใน Windows Server 2012 เป็นไปได้ที่จะจำลองคีย์ Trust Anchors ข้ามตัวควบคุมโดเมนทั้งหมดในฟอเรสต์ที่ให้บริการโซน DNS ที่กำหนดโดยอัตโนมัติ เมื่อต้องการทำเช่นนี้ในคุณสมบัติของโซนที่ต้องการ (dnssec) บนแท็บ เชื่อแองเคอร์เปิดใช้งานตัวเลือก เปิดใช้งานการกระจาย Trust Anchors สำหรับโซนนี้และบันทึกการเปลี่ยนแปลง
ลองสำรวจโซนนี้จากไคลเอนต์อีกครั้ง
ดังที่เราเห็น การตอบสนองของเซิร์ฟเวอร์ DNS มีข้อมูลเกี่ยวกับบันทึก RRSIG และลายเซ็นดิจิทัล
การกำหนดค่าไคลเอนต์ WIndows เพื่อใช้ DNSSEC
หากต้องการบังคับให้ไคลเอนต์ Windows ใช้เฉพาะคำสั่ง "ปลอดภัย" (DNSSEC) เท่านั้น เช่น หากต้องการยอมรับข้อมูล DNS เฉพาะในกรณีที่ลายเซ็นดิจิทัลถูกต้อง จำเป็นต้องใช้นโยบาย NRPT (ตารางนโยบายการแก้ไขชื่อ) โดยใช้ GPO
โดยในส่วน GPO การกำหนดค่าคอมพิวเตอร์ -> นโยบาย -> การตั้งค่า Windows -> นโยบายการจำแนกชื่อบนแท็บ ดีเอสเอสอีซีเปิดใช้งานตัวเลือก:
- เปิดใช้งาน DNSSEC ในกฎนี้
- กำหนดให้ไคลเอ็นต์ DNS ตรวจสอบว่าข้อมูลชื่อและที่อยู่ได้รับการตรวจสอบโดยเซิร์ฟเวอร์ DNS แล้ว
สิ่งที่เหลืออยู่คือการกำหนดนโยบายให้กับ OU ที่ต้องการ หลังจากใช้นโยบายแล้ว ตรวจสอบให้แน่ใจว่าไคลเอนต์ได้รับการกำหนดค่าให้ใช้ DNS “ที่ปลอดภัย”:
รับ-DnsClientNrptPolicy
ความหมาย DNSSecValidationRequired=จริง, เช่น. จำเป็นต้องมีการตรวจสอบความถูกต้องของการตอบสนอง DNS บนไคลเอนต์
หากการตอบสนองที่ได้รับจากเซิร์ฟเวอร์ DNS ไม่ได้ลงนามหรือลงนามด้วยใบรับรองที่ไม่ถูกต้อง คำสั่งจะส่งกลับข้อผิดพลาด แพ็กเก็ต DNS ที่ไม่ปลอดภัย.
DNSSEC สำหรับโซนภายนอก
เพื่อให้เซิร์ฟเวอร์ DNS จำเป็นต้องมีการตรวจสอบ DNSSEC บังคับสำหรับโซนภายนอก คุณต้องไปที่คุณสมบัติบนแท็บ ขั้นสูงเปิดใช้งานตัวเลือก เปิดใช้งานการตรวจสอบ DNSSEC สำหรับการตอบกลับระยะไกล.
คุณสามารถนำเข้า Trust Anchor ของโซนรากได้ด้วยตนเอง (ตามที่อธิบายไว้ด้านบน) หรือใช้คำสั่ง:
Dnscmd / ดึงข้อมูล RootTrustAnchors
คำแนะนำ- เพื่อให้ DNSSEC ทำงานได้อย่างถูกต้อง จำเป็นต้องทำการเปลี่ยนแปลงไฟร์วอลล์หลายประการ:
- เปิดพอร์ต 53 พอร์ตของโปรโตคอล TCP และ UDP ในทั้งสองทิศทาง
- เพราะ ขนาดข้อมูลในแพ็กเก็ต DNSSec เกิน 512 ไบต์ จำเป็นต้องอนุญาตให้แพ็กเก็ต DNS ที่มีขนาดใหญ่กว่า 512 ไบต์ผ่าน UDP และ TCP
ชมวิดีโอสอน
DNSSEC เป็นส่วนขยายของโปรโตคอล DNS ที่ใช้ลายเซ็นดิจิทัลของข้อมูล DNS เพื่อรักษาความปลอดภัยกระบวนการแก้ไขชื่อโดเมน ข้อมูลทั่วไปเกี่ยวกับ DNSSEC และการใช้งานมีอยู่ที่ https://tools.ietf.org/html/rfc6781
บันทึก- การสนับสนุน DNSSEC มีอยู่ใน Plesk สำหรับ Linux ผู้ให้บริการโฮสต์จะต้องติดตั้งส่วนขยาย Plesk DNSSECในเปลสค์
คุณสามารถทำสิ่งต่อไปนี้เพื่อปกป้องข้อมูล DNS ของโดเมนโดยใช้ DNSSEC:
- ลงนามโซนหรือโซนที่ไม่ได้ลงนามตามข้อกำหนด DNSSEC
- (ไม่บังคับ) ระบุการตั้งค่าแต่ละรายการสำหรับการสร้างคีย์
- รับการแจ้งเตือน
- ดูและคัดลอกบันทึกทรัพยากร DS
- ดูและคัดลอกชุดระเบียนทรัพยากร DNSKEY
การลงนามโซนโดเมน
หากต้องการเริ่มใช้การป้องกัน DNSSEC สำหรับโซน DNS ของคุณ ให้ลงนามในโซน Plesk ลงนามโซนด้วยลายเซ็นที่สร้างขึ้นโดยอัตโนมัติโดยใช้คีย์ที่ไม่สมมาตรสองคู่: สำหรับการลงนามคีย์ - Key Signing Key (KSK) และสำหรับการลงนามโซน - Zone Signing Key (ZSK)
หากต้องการลงนามในโซนโดเมน:
กำลังอัปเดตระเบียน DS ในโซนหลัก
หากโซนหลักมีระเบียน DS ที่ล้าสมัย ชื่อโดเมนจะไม่ได้รับการแก้ไขโดย DNS อีกต่อไป
คุณต้องเพิ่มหรืออัปเดตระเบียน DS ในโซนหลักด้วยตนเองในทุกกรณีที่มีการอัปเดตคีย์ DNSSEC ดังนี้:
- คุณได้ลงนามในโซนโดเมนโดยใช้คีย์ที่สร้างขึ้นใหม่
- KSK (คีย์การลงนามคีย์) ได้รับการอัปเดตแล้ว
Plesk จะส่งการแจ้งเตือนถึงคุณและให้เวลาคุณในการอัปเดตบันทึก DS ของคุณ - ช่วงเวลานี้เท่ากับหนึ่งช่วงการอัปเดต KSK ในช่วงเวลานี้ รายการ DS ก่อนหน้ายังคงใช้ได้
ถ้าคุณลบลายเซ็นโซนโดเมน คุณต้องลบระเบียน DS ออกจากโซนโดเมนหลักด้วยตนเอง
หากต้องการอัปเดตระเบียน DS ในโซนหลัก:
สำหรับโดเมนใน Plesk ซึ่งมีโซนหลักอยู่นอก Plesk ให้อัปเดตระเบียน DS กับผู้รับจดทะเบียนโดเมนของคุณ
สำหรับโดเมนย่อยของโดเมนที่โฮสต์ใน Plesk ซึ่งมีโซน DNS ตั้งอยู่ใน Plesk:
- ไปที่หน้าการตั้งค่า DNS ของโดเมนหลัก ( เว็บไซต์และโดเมน> โดเมนหลัก > การตั้งค่า DNS).
- เพิ่มรายการใหม่เช่น ดี.เอส. (เพิ่มบันทึก) และวางค่าที่ Plesk แสดงลงในช่อง บันทึกทรัพยากร DSในการตั้งค่า DNSSEC ของโดเมนย่อย
การลบลายเซ็นโซนโดเมน
การลบลายเซ็นโซนโดเมนจะปิดใช้งานการป้องกัน DNSSEC สำหรับโซนนั้น คุณอาจต้องลบลายเซ็นโซนหากคีย์ถูกบุกรุก เพื่อให้คุณสามารถเซ็นชื่อโซนอีกครั้งด้วยคีย์ใหม่ได้
หากต้องการลบลายเซ็นโซนโดเมน:
- ไปที่หน้า เว็บไซต์และโดเมน> เลือกโดเมน > ดีเอสเอสอีซีและกด ลบลายเซ็น.
- เอาระเบียนทรัพยากร DS ออกจากโซนหลัก มิฉะนั้นชื่อโดเมนจะไม่ได้รับการแก้ไข
บันทึก- เมื่อคุณลบลายเซ็นโซน คีย์จะไม่ถูกลบออกจาก Plesk คุณสามารถลงนามโซนได้อีกครั้งโดยใช้คีย์เดียวกัน
กำลังดูบันทึกทรัพยากร DNSKEY
คุณอาจต้องรับระเบียนทรัพยากร DNSKEY ที่มีส่วนสาธารณะของคีย์การเซ็นชื่อคีย์ที่ใช้สำหรับโดเมน
หากต้องการดูบันทึก DNSKEY:
- ไปที่หน้า เว็บไซต์และโดเมน> เลือกโดเมน > ดีเอสเอสอีซี.
- คลิก ดูบันทึก DNSKEY.
แสดงความคิดเห็นของคุณในหัวข้อนี้ที่นี่
หากคุณมีคำถามหรือต้องการความช่วยเหลือ โปรดไปที่ฟอรัม Plesk หรือติดต่อผู้ให้บริการโฮสติ้งของคุณ
ความคิดเห็นด้านล่างมีไว้สำหรับข้อเสนอแนะเกี่ยวกับเอกสารประกอบเท่านั้น จะไม่มีการตอบกลับหรือความช่วยเหลืออย่างทันท่วงที