สิทธิประโยชน์ด้านความปลอดภัย

บทนํา: ภัยคุกคามและการบรรเทาปัญหาด้านความปลอดภัยของ DNS

การออกแบบที่กระจายออกไปของระบบชื่อโดเมนและมีการใช้งานโปรโตคอล User Datagram (UDP) ทําให้ DNS มีช่องโหว่ในการโจมตีรูปแบบต่างๆ โดยเฉพาะอย่างยิ่ง ตัวระบุสาธารณะหรือ &ret;open" รีโซลเวอร์ DNS ที่เกิดซ้ําจะมีความเสี่ยงอย่างยิ่ง เนื่องจากจะไม่จํากัดแพ็กเก็ตขาเข้ากับชุดที่อยู่ IP ต้นทางที่อนุญาต เรามักจะกังวลเกี่ยวกับการโจมตีที่พบบ่อย 2 ประเภทดังนี้

• การโจมตีการปลอมแปลงทําให้เกิดการเป็นพิษจากแคช DNS การปลอมแปลงและการปลอมแปลงปลอมแปลง DNS ประเภทต่างๆ นั้นมีเป้าหมายเพื่อเปลี่ยนเส้นทางผู้ใช้จากเว็บไซต์ที่ถูกต้องไปยังเว็บไซต์ที่เป็นอันตราย การดําเนินการเหล่านี้เรียกว่าการโจมตี Kaminsky ซึ่งผู้โจมตีจะเป็นผู้ควบคุมโซน DNS ทั้งหมดโดยเชื่อถือได้
• การโจมตีแบบปฏิเสธการให้บริการ (DoS) ผู้โจมตีอาจโจมตี DDoS ต่อรีโซลเวอร์ หรือลักลอบใช้บัญชีเพื่อโจมตีการโจมตี DoS ในระบบอื่น การโจมตีที่ใช้เซิร์ฟเวอร์ DNS เพื่อเปิดการโจมตี DoS ในระบบอื่นโดยการใช้ประโยชน์จากระเบียน DNS/การตอบกลับขนาดใหญ่เรียกว่าการโจมตีในการขยาย

การโจมตีแต่ละคลาสมีดังนี้

การโจมตีแบบ Cache Poison

การโจมตี DNS ที่มีการปลอมแปลงหลายรูปแบบอาจทําให้เกิดการเป็นพิษจากแคชได้ แต่สถานการณ์ทั่วไปมีดังต่อไปนี้

1. ผู้โจมตีจะส่งการค้นหา DNS เป้าหมายหลายตัวสําหรับชื่อโดเมนที่รู้ว่าเซิร์ฟเวอร์ไม่มีข้อมูล และมักจะไม่อยู่ในแคชของเซิร์ฟเวอร์
2. รีโซลเวอร์จะส่งคําขอไปยังเนมเซิร์ฟเวอร์อื่น (ซึ่งที่อยู่ IP ที่ผู้โจมตีคาดคะเนได้)
3. ในขณะเดียวกัน ผู้โจมตีก็ล้นเซิร์ฟเวอร์เหยื่อด้วยคําตอบปลอมที่ดูเหมือนว่ามาจากเนมเซิร์ฟเวอร์ที่ได้รับมอบสิทธิ์ การตอบกลับจะมีบันทึกที่แก้ไขโดเมนที่ส่งคําขอเป็นที่อยู่ IP ที่ผู้โจมตีควบคุมในท้ายที่สุด โดยอาจมีบันทึกคําตอบสําหรับชื่อที่ได้ข้อยุติแล้ว หรือแย่ไปกว่านั้นคืออาจมอบสิทธิ์ให้แก่เนมเซิร์ฟเวอร์ที่ผู้โจมตีเป็นเจ้าของ เพื่อให้สามารถควบคุมโซนทั้งหมดได้
4. หากการตอบสนองที่ปลอมแปลงตรงกับคําขอของรีโซลเวอร์ (เช่น ตามชื่อการค้นหา ประเภท รหัส และพอร์ตแหล่งที่มารีโซลเวอร์) และได้รับก่อนการตอบสนองจากเนมเซิร์ฟเวอร์จริง รีโซลเวอร์จะยอมรับการตอบกลับที่ปลอมแปลงและแคช และยกเลิกการตอบกลับจริง
5. การค้นหาสําหรับโดเมนหรือโซนที่ถูกบุกรุกในอนาคตจะได้รับคําตอบด้วยการแปลง DNS จากแคช หากผู้โจมตีระบุเป็นระยะเวลานานมากในการตอบสนองที่ปลอมแปลง ระเบียนที่ปลอมแปลงจะอยู่ในแคชนานที่สุดเท่าที่จะทําได้โดยไม่มีการรีเฟรช

สําหรับข้อมูลเบื้องต้นเกี่ยวกับการโจมตี Kaminsky โปรดดูคู่มือภาพเกี่ยวกับช่องโหว่ของ DNS ของ Kaminsky

การโจมตี DoS และการขยายเรื่องราว

รีโซลเวอร์ DNS อยู่ภายใต้ภัยคุกคาม DoS ปกติที่โจมตีระบบเครือข่าย อย่างไรก็ตาม การโจมตีด้วยการขยายเสียงมักจะเป็นข้อกังวลเป็นพิเศษ เนื่องจากรีโซลเวอร์ DNS เป็นเป้าหมายที่น่าสนใจของผู้โจมตีที่แสวงหาประโยชน์จากรีโซลเวอร์&#39 อัตราส่วนขนาดต่อคําขอขนาดใหญ่เพื่อรับแบนด์วิดท์ฟรีเพิ่มเติม รีโซลเวอร์ที่รองรับ EDNS0 (กลไกส่วนขยายสําหรับ DNS) จะมีช่องโหว่มากเป็นพิเศษเนื่องจากแพ็กเก็ตมีขนาดที่ส่งคืนมาได้เป็นจํานวนมาก

ในสถานการณ์การขยายเสียง การโจมตีจะดําเนินต่อไปดังนี้

1. ผู้โจมตีจะส่งการค้นหาเซิร์ฟเวอร์ DNS สําหรับเหยื่อโดยใช้ที่อยู่ IP ต้นทางปลอม การค้นหาอาจส่งมาจากระบบเดียวหรือเครือข่ายระบบทั้งหมดโดยใช้ที่อยู่ IP ปลอมเดียวกัน การค้นหามีไว้สําหรับระเบียนที่ผู้โจมตีรู้จะส่งผลให้เกิดการตอบสนองที่มีขนาดใหญ่กว่ามากถึง 10 เท่า¹ ขนาดของการค้นหาแรกเริ่ม (ซึ่งคือชื่อ "การขยายเสียงและการโจมตี)
2. เซิร์ฟเวอร์เหยื่อจะส่งการตอบกลับขนาดใหญ่ไปยังที่อยู่ IP ต้นทางที่ส่งผ่านในคําขอที่ถูกปลอมแปลง ซึ่งทําให้ระบบทํางานหนักเกินไปและทําให้เกิดสถานการณ์ DoS

การลดปัญหา

โซลูชันทั่วทั้งระบบมาตรฐานของช่องโหว่ DNS คือ DNSSEC อย่างไรก็ตาม ตัวแปลค่า DNS แบบเปิดต้องใช้มาตรการบางอย่างเพื่อบรรเทาภัยคุกคามที่รู้จัก จนกว่าจะนําไปใช้ได้ทั่วไป มีการนําเสนอเทคนิคมากมาย โปรดดู IETF RFC 5452: มาตรการที่ทําให้ DNS มีความยืดหยุ่นยิ่งขึ้นสําหรับคําตอบที่ถูกปลอมแปลง สําหรับภาพรวมของเทคนิคส่วนใหญ่ ใน DNS สาธารณะของ Google เราได้เปิดตัวและแนะนําวิธีต่อไปนี้

• การรักษาความปลอดภัยโค้ดจากบัฟเฟอร์ส่วนเกิน โดยเฉพาะโค้ดที่ทําหน้าที่แยกวิเคราะห์และเรียงลําดับข้อความ DNS
• การจัดสรรทรัพยากรของเครื่องมากเกินไปเพื่อป้องกันการโจมตี DoS โดยตรงต่อรีโซลเวอร์ เนื่องจากที่อยู่ IP กลายเป็นสิ่งที่ผู้บุกรุกสามารถปลอมแปลงไม่ได้ จึงเป็นไปไม่ได้ที่จะบล็อกคําค้นหาตามที่อยู่ IP หรือซับเน็ต วิธีเดียวที่จะจัดการกับการโจมตีดังกล่าวได้คือการดูดซับการโหลดเท่านั้น
• การใช้การตรวจสอบความถูกต้องพื้นฐานของแพ็กเก็ตการตอบสนองและความน่าเชื่อถือของเนมเซิร์ฟเวอร์เพื่อป้องกันการป้องกันการเป็นพิษจากแคชแบบง่าย สิ่งเหล่านี้คือกลไกและการตรวจสอบมาตรฐานที่รีโซลเวอร์การแคชตามมาตรฐานเป็นไปตามมาตรฐาน
• การเพิ่มเอนโทรปีเพื่อส่งคําขอข้อความ เพื่อลดความเป็นไปได้ที่จะเกิดการโจมตีโดยการปลอมแปลง/วางแคชที่ซับซ้อนมากขึ้น เช่น การโจมตีของ Kaminsky มีเทคนิคที่แนะนํามากมายในการเพิ่มเอนโทรปี ข้อมูลด้านล่างนี้พูดถึงภาพรวมประโยชน์ ข้อจํากัด และความท้าทายของแต่ละเทคนิค
• การนําคําค้นหาที่ซ้ํากันออกเพื่อต่อสู้กับความน่าจะเป็นของ "การโจมตีวันเกิด"
• คําขอจํากัดอัตราคําขอ เพื่อป้องกันการโจมตีจาก DoS และการขยายเนื้อหา
• คอยตรวจสอบบริการสําหรับ IP ของไคลเอ็นต์โดยใช้แบนด์วิดท์มากที่สุด และ หลีกเลี่ยงอัตราส่วนของขนาดต่อคําขอสูงสุด

DNSSEC

จะมีการระบุมาตรฐาน Domain Name Security Extensions (DNSSEC) ไว้ใน IETF RFCs หลายตัว ได้แก่ 4033, 4034, 4035 และ 5155

รีโซลเวอร์ที่ใช้การโจมตีแบบ Cache Poison ที่เป็นปัญหาโดยการยืนยันความถูกต้องของการตอบสนองที่ได้รับจากเนมเซิร์ฟเวอร์ โซน DNS แต่ละโซนจะเก็บรักษาชุดคู่คีย์ส่วนตัว/สาธารณะ และสําหรับระเบียน DNS แต่ละรายการ ระบบจะสร้างลายเซ็นดิจิทัลที่ไม่ซ้ํากันและเข้ารหัสโดยใช้คีย์ส่วนตัว จากนั้นคีย์สาธารณะที่เกี่ยวข้องจะได้รับการตรวจสอบสิทธิ์ผ่านเชนที่เชื่อถือได้โดยคีย์ที่เป็นของโซนหลัก รีโซลเวอร์ที่สอดคล้องกับ DNSSEC จะปฏิเสธการตอบกลับที่ไม่มีลายเซ็นที่ถูกต้อง DNSSEC ป้องกันการปลอมแปลงการตอบสนองโดยมีประสิทธิภาพ เนื่องจากในทางปฏิบัติ ลายเซ็นจะแทบเลียนแบบไม่ได้หากไม่มีสิทธิ์เข้าถึงคีย์ส่วนตัว

ตั้งแต่เดือนมกราคม 2013 เป็นต้นไป DNS สาธารณะของ Google รองรับ DNSSEC อย่างเต็มรูปแบบ เรายอมรับและส่งต่อข้อความในรูปแบบ DNSSEC และตรวจสอบการตอบกลับเพื่อการตรวจสอบสิทธิ์ที่ถูกต้อง เราขอแนะนําอย่างยิ่งให้ตัวแก้ไขอื่นๆ ทําเช่นเดียวกัน

นอกจากนี้ เรายังแคชการตอบกลับ NSEC ตามที่ระบุไว้ใน IETF RFC 8198: การใช้งานเชิงรุกของแคชที่ตรวจสอบ DNSSEC อย่างเข้มงวด ซึ่งจะช่วยลดการค้นหา NXDOMAIN ไปยังเนมเซิร์ฟเวอร์ที่ใช้ DNSSEC และใช้ NSEC สําหรับคําตอบเชิงลบ

การรับส่งข้อมูลที่เข้ารหัสฝั่งไคลเอ็นต์

Google Public DNS รองรับโปรโตคอลการขนส่งที่เข้ารหัส DNS ผ่าน HTTPS และ DNS ผ่าน TLS โปรโตคอลเหล่านี้ช่วยป้องกันการปลอมแปลง การดักฟังและการปลอมแปลง ซึ่งช่วยเพิ่มความเป็นส่วนตัวและความปลอดภัยระหว่างไคลเอ็นต์กับ DNS สาธารณะของ Google ได้อย่างมาก โดยจะช่วยเสริม DNSSEC เพื่อมอบการค้นหา DNS ที่มีการตรวจสอบสิทธิ์จากต้นทางถึงปลายทาง

การใช้การตรวจสอบความถูกต้องพื้นฐาน

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

• อย่าตั้งค่าบิตที่เกิดซ้ําในการส่งคําขอขาออก และทําตามเชนการมอบสิทธิ์อย่างชัดเจนเสมอ การปิดใช้บิตซ้ําๆ จะช่วยให้รีโซลเวอร์ของคุณทํางานในโหมด"iterative" ช่วยให้คุณค้นหาเนมเซิร์ฟเวอร์แต่ละรายการในเชนการมอบสิทธิ์อย่างชัดแจ้ง แทนที่จะอนุญาตให้เนมเซิร์ฟเวอร์อื่นดําเนินการค้นหาในนามของคุณเอง
• ปฏิเสธข้อความตอบกลับที่น่าสงสัย ดูรายละเอียดเกี่ยวกับสิ่งที่เราเห็นว่าเป็น "quot;น่าสงสัย" ด้านล่าง
• อย่าส่งคืนระเบียน A ไปยังไคลเอ็นต์โดยอิงตาม Glue Record ที่แคชจากคําขอก่อนหน้า เช่น หากได้รับการค้นหาไคลเอ็นต์สําหรับ ns1.example.com คุณควรแก้ไขปัญหาดังกล่าว แทนที่จะส่งระเบียน A ตามระเบียน Glue Cache ที่ส่งคืนมาจากเนมเซิร์ฟเวอร์ TLD แบบ .com

การปฏิเสธคําตอบที่ไม่ตรงตามเกณฑ์ที่จําเป็น

DNS สาธารณะของ Google จะปฏิเสธสิ่งต่อไปนี้ทั้งหมด

• คําตอบที่แยกวิเคราะห์ไม่ได้หรือผิดรูปแบบ
• การตอบสนองที่ช่องคีย์ไม่ตรงกับช่องที่สอดคล้องกันในคําขอ ซึ่งรวมถึงรหัสคําค้นหา, IP ต้นทาง, พอร์ตแหล่งที่มา, IP ปลายทาง หรือชื่อการค้นหา ดู RFC 5452 ส่วนที่ 3 สําหรับคําอธิบายที่สมบูรณ์เกี่ยวกับลักษณะการทํางานของการปลอมแปลง DNS
• ระเบียนที่ไม่เกี่ยวข้องกับคําขอ
• คําตอบคําตอบที่เราไม่สามารถสร้างเชน CNAME ใหม่ได้
• ระเบียน (ในคําตอบ ผู้ออกใบรับรอง หรือส่วนเพิ่มเติม) ที่เนมเซิร์ฟเวอร์ที่เกี่ยวข้องไม่น่าเชื่อถือ เรากําหนด "ความน่าเชื่อถือ" ของเนมเซิร์ฟเวอร์โดยเรียงตามตําแหน่งในสายการมอบสิทธิ์ของโดเมนที่ระบุ DNS สาธารณะของ Google จะแคชข้อมูลการมอบสิทธิ์ของเชน และเรายืนยันแต่ละข้อมูลที่เข้ามาใหม่กับข้อมูลที่แคชไว้ เพื่อระบุความน่าเชื่อถือของเนมเซิร์ฟเวอร์และการตอบสนองของการตอบกลับคําขอหนึ่งๆ

กําลังเพิ่มเอนโทรปีในคําขอ

เมื่อรีโซลเวอร์บังคับใช้การตรวจสอบความเรียบร้อยพื้นฐาน ผู้โจมตีจะต้องน้ําท่วมกับรีโซลเวอร์การตอบสนองด้วยความพยายามจับคู่รหัสคําค้นหา, พอร์ต UDP (ของคําขอ), ที่อยู่ IP (ของการตอบกลับ) และชื่อคําค้นหาของคําขอแรกก่อนเนมเซิร์ฟเวอร์ที่ถูกต้อง

แต่ขออภัย การดําเนินการนี้ไม่ใช่เรื่องง่าย เนื่องจากรหัสคําค้นหาที่ไม่ซ้ํากันของช่องจะมีความยาวเพียง 16 บิต (เช่น สําหรับโอกาส 1/65,536 ที่จะได้รหัสที่ถูกต้อง) ส่วนช่องอื่นๆ ก็มีช่วงค่าจํากัดทําให้จํานวนชุดค่าผสมที่ไม่ซ้ํากันทั้งหมดค่อนข้างต่ํา โปรดดู RFC 5452 ส่วน 7 สําหรับการคํานวณชุดค่าผสม

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

เราได้นําเสนอรีวิวที่อัปเดตของเทคนิคที่กล่าวถึงที่นี่ในการประชุม DNS OARC 38 ในเดือนกรกฎาคม 2022 ในงานนําเสนอจะมีคําแนะนํา สําหรับโอเปอเรเตอร์เนมเซิร์ฟเวอร์ด้วย

การสุ่มพอร์ตแหล่งที่มา

ขั้นตอนเบื้องต้นจะไม่อนุญาตให้แพ็กเก็ตคําขอขาออกใช้พอร์ต UDP 53 เริ่มต้น หรือใช้อัลกอริทึมที่คาดการณ์ได้สําหรับการกําหนดพอร์ตหลายพอร์ต (เช่น การเพิ่มอย่างง่ายๆ) ใช้พอร์ตจํานวนมากตั้งแต่ 1024 ถึง 65535 ที่ระบบอนุญาตให้ใช้ได้ และใช้เครื่องมือสุ่มตัวเลขที่เชื่อถือได้เพื่อกําหนดพอร์ต เช่น DNS สาธารณะของ Google ใช้ประมาณ 15 บิตเพื่อรองรับพอร์ตประมาณ 32,000 หมายเลข

โปรดทราบว่าหากเซิร์ฟเวอร์ของคุณใช้งานเบื้องหลังไฟร์วอลล์ ตัวจัดสรรภาระงาน หรืออุปกรณ์อื่นๆ ที่ทําการแปลที่อยู่เครือข่าย (NAT) อุปกรณ์เหล่านั้นอาจนําพอร์ตออกจากแพ็กเก็ตขาออก ตรวจสอบว่าได้กําหนดค่าอุปกรณ์ NAT เพื่อปิดใช้การสุ่มพอร์ต

การเลือกเนมเซิร์ฟเวอร์แบบสุ่ม

ในการแก้ไขข้อบกพร่องบางอย่าง เมื่อส่งคําขอไปยังรูท, TLD หรือเนมเซิร์ฟเวอร์อื่นๆ ให้เลือกที่อยู่ IP ของเนมเซิร์ฟเวอร์ตามระยะทางที่สั้นที่สุด (เวลาในการตอบสนอง) เราขอแนะนําให้คุณสุ่มที่อยู่ IP ปลายทางเพื่อเพิ่มเอนโทรปีลงในคําขอขาออก ใน DNS สาธารณะของ Google เราจะเลือกเนมเซิร์ฟเวอร์แบบสุ่มจากเนมเซิร์ฟเวอร์ที่กําหนดค่าไว้ในแต่ละโซน ซึ่งจะชื่นชอบเนมเซิร์ฟเวอร์ที่รวดเร็วและน่าเชื่อถือ

หากคุณกังวลเกี่ยวกับเวลาในการตอบสนอง คุณสามารถใช้แถบเวลาไป-กลับ (RTT) ซึ่งประกอบด้วยการสุ่มภายในช่วงที่อยู่ต่ํากว่าเกณฑ์เวลาในการตอบสนองที่กําหนด (เช่น 30 มิลลิวินาที, 300 มิลลิวินาที ฯลฯ)

คุกกี้ DNS

RFC 7873 กําหนดตัวเลือก EDNS0 สําหรับการเพิ่มคุกกี้ 64 บิตลงในข้อความ DNS ไคลเอ็นต์ DNS ที่รองรับคุกกี้จะมีคุกกี้ 64 บิตแบบสุ่มและ (หรือที่รู้จัก) คุกกี้ของเซิร์ฟเวอร์ในคําขอ (ไม่บังคับ) หากเซิร์ฟเวอร์ที่รองรับพบตัวเลือกคุกกี้ที่ถูกต้องในคําขอ ให้แสดงถึงคุกกี้ของไคลเอ็นต์และคุกกี้เซิร์ฟเวอร์ที่ถูกต้องในการตอบกลับ จากนั้นไคลเอ็นต์สนับสนุนจะตรวจสอบได้ว่าการตอบกลับมาจากเซิร์ฟเวอร์ที่คาดไว้โดยยืนยันคุกกี้ของไคลเอ็นต์ในการตอบสนอง

หากเนมเซิร์ฟเวอร์ไม่รองรับคุกกี้ DNS คุณใช้ 2 ตัวเลือกต่อไปนี้เพื่อเพิ่มเอนโทรปีได้

การสุ่มกรณีในชื่อการค้นหา

มาตรฐาน DNS กําหนดให้เนมเซิร์ฟเวอร์จัดการกับชื่อที่มีการพิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่ เช่น ชื่อ example.com และ EXAMPLE.COM ควรเปลี่ยนเป็นที่อยู่ IP เดียวกัน² นอกจากนี้ เนมเซิร์ฟเวอร์บางส่วนยกเว้นส่วนเล็กๆ บางส่วนจะสะท้อนชื่อในการตอบกลับ ดังที่ปรากฏในคําขอโดยยังคงรักษากรณีเดิมไว้

ดังนั้น อีกวิธีหนึ่งในการเพิ่มเอนโทรปีลงในคําขอคือสุ่มเลือกตัวอักษรในชื่อโดเมนตามที่ค้นหา เทคนิคนี้ (หรือที่เรียกว่า "0x20" เนื่องจากมีการใช้บิต 0x20 ในการกําหนดกรณีของตัวอักษร US-ASCII ในร่างอินเทอร์เน็ต IETF ฉบับแรก การใช้ Bit 0x20 ในป้ายกํากับ DNS เพื่อปรับปรุงข้อมูลระบุตัวตนของธุรกรรม เทคนิคนี้อาจทําให้การตอบกลับเนมเซิร์ฟเวอร์ต้องตรงกันทั้งชื่อการค้นหาและตัวพิมพ์เล็ก/ใหญ่ของสตริงชื่อเท่านั้น เช่น wWw.eXaMpLe.CoM หรือ WwW.ExamPLe.COm การดําเนินการนี้อาจเพิ่มเอนเวโลปเอนกประสงค์ให้แก่คําค้นหาโดเมนระดับบนสุดและรากน้อยหรือไม่เลย แต่จะมีผลกับชื่อโฮสต์ส่วนใหญ่

ความท้าทายที่สําคัญอย่างหนึ่งที่เราพบเมื่อใช้เทคนิคนี้ก็คือ เนมเซิร์ฟเวอร์บางรายการไม่เป็นไปตามลักษณะการทํางานในการตอบกลับดังที่คาดไว้

• เนมเซิร์ฟเวอร์บางรายการตอบกลับโดยคํานึงถึงตัวพิมพ์เล็กและตัวพิมพ์ใหญ่โดยสมบูรณ์ ซึ่งจะแสดงผลลัพธ์เดียวกันอย่างถูกต้องโดยไม่คํานึงถึงคําขอในคําขอ แต่การตอบสนองไม่ตรงกับกรณีของชื่อในคําขอ
• เนมเซิร์ฟเวอร์อื่นๆ ตอบสนองโดยพิจารณาตัวพิมพ์เล็กและตัวพิมพ์ใหญ่โดยสมบูรณ์ (ที่ละเมิดมาตรฐาน DNS): จะจัดการชื่อที่เทียบเท่าโดยขึ้นอยู่กับกรณีต่างๆ ในคําขอ หรือไม่ตอบกลับเลยหรือไม่แสดงผลการตอบกลับ NXDOMAIN ที่ไม่ถูกต้องซึ่งตรงกับกรณีของชื่อในคําขอ
• เนมเซิร์ฟเวอร์บางรายการทํางานได้อย่างถูกต้อง ยกเว้นการค้นหา PTR ในโซน arpa

สําหรับเนมเซิร์ฟเวอร์ทั้ง 2 ประเภทนี้ การเปลี่ยนตัวพิมพ์เล็กและใหญ่ของชื่อการค้นหาจะให้ผลลัพธ์ที่ไม่พึงประสงค์ เช่น สําหรับกลุ่มแรก การตอบสนองจะคล้ายกันกับการตอบสนองที่ปลอมแปลงไม่ได้ สําหรับกลุ่มที่สอง คําตอบ (หากมี) อาจไม่ถูกต้องทั้งหมด

วิธีแก้ปัญหาปัจจุบันของเราคือใช้การสุ่มกรณีที่มีเฉพาะในเนมเซิร์ฟเวอร์ที่เราทราบว่าใช้มาตรฐานอย่างถูกต้อง นอกจากนี้ เรายังแสดงโดเมนย่อยของข้อยกเว้นที่เหมาะสมสําหรับแต่ละโดเมนย่อย โดยอิงตามการวิเคราะห์บันทึกของเรา หากการตอบกลับที่ดูเหมือนว่ามาจากเซิร์ฟเวอร์เหล่านั้นไม่มีเคสที่ถูกต้อง เราจะปฏิเสธการตอบกลับนั้น เนมเซิร์ฟเวอร์ที่เปิดใช้งานมากกว่า 70% ของการเข้าชมขาออกของเรา

ติดป้ายกํากับค่าล่วงหน้าให้กับชื่อคําค้นหา

หากรีโซลเวอร์ไม่สามารถแปลชื่อจากแคชโดยตรงได้ หรือไม่สามารถค้นหาเนมเซิร์ฟเวอร์ที่เชื่อถือได้โดยตรง เซิร์ฟเวอร์ดังกล่าวจะต้องอ้างอิงการอ้างอิงจากเนมเซิร์ฟเวอร์ระดับรากหรือ TLD ในกรณีส่วนใหญ่ คําขอที่ส่งไปยังเนมเซิร์ฟเวอร์ของรูทหรือ TLD จะส่งผลให้เกิดการอ้างอิงไปยังเนมเซิร์ฟเวอร์อื่น แทนที่จะพยายามแปลงชื่อให้เป็นที่อยู่ IP สําหรับคําขอดังกล่าว จึงปลอดภัยที่จะแนบป้ายกํากับแบบสุ่มให้แก่ชื่อการค้นหาเพื่อเพิ่มเอนโทรปีของคําขอ โดยไม่ต้องเสี่ยงกับการแก้ไขชื่อที่ไม่มีอยู่จริง กล่าวคือ การส่งคําขอไปยังเซิร์ฟเวอร์ชื่อที่อ้างอิงสําหรับชื่อที่มีป้ายกํากับระยะเวลานําหน้า เช่น entriih-f10r3.www.google.com ควรแสดงผลการค้นหาเดียวกันกับคําขอสําหรับ www.google.com

แม้ว่าในทางปฏิบัติแล้ว คําขอที่ประกอบกันขึ้นมานั้นไม่ถึง 3% ของคําขอขาออก โดยถือว่าการเข้าชมปกติ (เนื่องจากคําตอบส่วนใหญ่สามารถตอบกลับได้โดยตรงจากแคชหรือโดยคําค้นหาเดียว) คําขอเหล่านี้คือประเภทคําขอที่ผู้บุกรุกพยายามบังคับให้รีโซลเวอร์ออก เทคนิคนี้จึงเป็นวิธีที่มีประสิทธิภาพมากในการป้องกันการใช้ประโยชน์จากรูปแบบ Kaminsky

การใช้เทคนิคนี้กําหนดให้ใช้ป้ายกํากับ "เท่านั้น" กับคําขอที่รับประกันการแสดงผลไปยังการอ้างอิงเท่านั้น กล่าวคือ คําตอบที่ไม่มีระเบียนในส่วนคําตอบ อย่างไรก็ตาม เราพบปัญหาหลายอย่างขณะพยายามกําหนดชุดคําขอดังกล่าว เช่น

• จริงๆ แล้วเนมเซิร์ฟเวอร์ TLD (ccTLD) ของรหัสประเทศบางรายการเชื่อถือได้สําหรับ TLD (2LDs) ระดับที่ 2 อื่นๆ แม้ว่าจะมีป้ายกํากับ 2 รายการ แต่ 2LD2 จะมีลักษณะคล้ายกับ TLD ซึ่งเป็นเหตุผลว่าทําไม 2LD เหล่านี้จึงจัดการโดยเนมเซิร์ฟเวอร์ของ ccTLD ตัวอย่างเช่น เนมเซิร์ฟเวอร์ .uk ยังมีประโยชน์สําหรับโซน mod.uk และ nic.uk และมีชื่อโฮสต์ที่อยู่ในโซนเหล่านั้น เช่น www.nic.uk, www.mod.uk เป็นต้น หรือพูดอีกอย่างก็คือ คําขอที่ส่งไปยังเนมเซิร์ฟเวอร์ ccTLD สําหรับการแก้ปัญหาชื่อโฮสต์ดังกล่าวจะไม่ส่งผลให้เกิดการอ้างอิง แต่เป็นคําตอบที่เชื่อถือได้ การต่อท้ายป้ายกํากับที่ไม่ใช่ชื่อโฮสต์กับชื่อโฮสต์ดังกล่าวจะทําให้ระบบแปลงชื่อไม่ได้
• บางครั้งเนมเซิร์ฟเวอร์ TLD (gTLD) ทั่วไปอาจตอบกลับการตอบสนองที่ไม่น่าเชื่อถือสําหรับเนมเซิร์ฟเวอร์ กล่าวคือ มีชื่อโฮสต์เนมเซิร์ฟเวอร์บางรายการที่อาศัยอยู่ในโซน gTLD มากกว่าในโซนสําหรับโดเมน gTLD จะส่งคืนคําตอบที่ไม่ได้รับอนุญาตสําหรับชื่อโฮสต์เหล่านี้ โดยใช้ Glue Record ที่เกิดขึ้นในฐานข้อมูลแทนที่จะส่งการอ้างอิงกลับมา เช่น เนมเซิร์ฟเวอร์ ns3.indexonlineserver.com เคยอยู่ในโซน gTLD ของ .COM ไม่ใช่ในโซน indexonlineserver.com เมื่อเราส่งคําขอให้เซิร์ฟเวอร์ gTLD สําหรับ n3.indexonlineserver.com ได้รับที่อยู่ IP ไม่ใช่การอ้างอิง อย่างไรก็ตาม หากเราเพิ่มป้ายกํากับที่ไม่เกี่ยวข้อง เราก็จะได้รับการอ้างอิงไปยัง indexonlineserver.com ซึ่งแก้ไขชื่อโฮสต์ไม่ได้ ดังนั้น เราจึงเพิ่มป้ายกํากับที่ไม่ใช่ป้ายกํากับสําหรับเนมเซิร์ฟเวอร์ที่ต้องใช้ความละเอียดจากเซิร์ฟเวอร์ gTLD ไม่ได้
• การให้สิทธิ์สําหรับโซนและชื่อโฮสต์จะเปลี่ยนแปลงเมื่อเวลาผ่านไป ปัญหานี้อาจทําให้ชื่อโฮสต์ที่ยังไม่ได้เขียนขึ้นข้างหน้าซึ่งแก้ไขไม่ได้เมื่อแปลงเชนไม่ได้

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

การนําคําค้นหาที่ซ้ํากันออก

รีโซลเวอร์ DNS มีความเสี่ยงต่อ "วันเกิดวันเกิด" ทําให้ถูกเรียกเนื่องจาก พบอุปสรรคทางคณิตศาสตร์ "วันเกิดวันเกิด" โดยที่ความเป็นไปได้ที่รายการที่ตรงกันจะไม่ต้องอาศัยข้อมูลจํานวนมาก การโจมตีวันเกิดนั้นทําให้เซิร์ฟเวอร์ของเหยื่อเสียหายเต็มไปหมด ไม่เพียงแค่ตอบคําขอปลอมๆ เท่านั้น แต่ยังรวมถึงคําค้นหาเริ่มต้น การนับตัวรีโซลเวอร์เพื่อออกคําขอหลายรายการสําหรับการแก้ปัญหาชื่อเดียว ยิ่งมีคําขอขาออกมากเท่าไหร่ ความเป็นไปได้ที่ผู้โจมตีจะจับคู่หนึ่งในคําขอเหล่านั้นกับการตอบกลับปลอมมากขึ้นเท่านั้น ผู้โจมตีต้องการลําดับคําขอที่กําลังดําเนินการ 300 คําขอเพื่อโอกาสที่จะประสบความสําเร็จในการจับคู่คําตอบที่ปลอมแปลง 50% และคําขอ 700 รายการสําหรับความสําเร็จเกือบ 100%

เพื่อป้องกันกลยุทธ์การโจมตีนี้ คุณต้องยกเลิกการค้นหาที่ซ้ํากันทั้งหมดจากคิวขาออก ตัวอย่างเช่น DNS สาธารณะของ Google จะไม่อนุญาตคําขอที่ค้างอยู่มากกว่า 1 คําขอสําหรับชื่อการค้นหา ประเภทการค้นหา และที่อยู่ IP ปลายทางเดียวกัน

คําค้นหาที่จํากัดอัตราคําขอ

การป้องกันการโจมตีแบบปฏิเสธการให้บริการอาจทําให้เกิดความท้าทายหลายอย่างขึ้นสําหรับรีโซลเวอร์ DNS แบบเรียกซ้ํา เช่น

• รีโซลเวอร์ที่เกิดซ้ําเป็นเป้าหมายที่น่าสนใจสําหรับการเปิดตัวการโจมตีด้วยการขยายเสียง เซิร์ฟเวอร์เหล่านี้มีขีดความสามารถสูง ความเสถียรสูง และสร้างการตอบสนองที่มีขนาดใหญ่กว่าเนมเซิร์ฟเวอร์ที่เชื่อถือได้ทั่วไป โดยเฉพาะหากผู้โจมตีแทรกการตอบกลับขนาดใหญ่ลงในแคชได้ นักพัฒนาซอฟต์แวร์ทุกรายในบริการ DNS แบบเปิดมีการป้องกันเซิร์ฟเวอร์ของตนที่จะใช้ในการโจมตีระบบอื่น
• การโจมตีด้วยการขยายเสียงอาจเป็นเรื่องยากที่จะตรวจพบขณะเกิดเหตุการณ์ ผู้โจมตีสามารถเปิดการโจมตีผ่านรีโซลเวอร์แบบเปิดหลายพันรายการ เพื่อให้ผู้โจมตีแต่ละรายเห็นเพียงส่วนเล็กๆ ของปริมาณคําค้นหาโดยรวมและไม่สามารถแยกสัญญาณที่ชัดเจนได้ว่าผู้โจมตีถูกบุกรุก
• โดยการเข้าชมที่เป็นอันตรายต้องถูกบล็อกโดยไม่มีการรบกวนหรือเลิกใช้งานของบริการ DNS แก่ผู้ใช้ปกติ DNS เป็นบริการเครือข่ายที่สําคัญ ดังนั้นการปิดเซิร์ฟเวอร์เพื่อตัดการโจมตีจึงเป็นตัวเลือก และไม่ควรปฏิเสธบริการกับ IP ไคลเอ็นต์หนึ่งๆ นานเกินไป รีโซลเวอร์จะต้องบล็อกการโจมตีได้อย่างรวดเร็วทันทีที่เริ่มขึ้น และกู้คืนบริการที่ใช้งานได้เต็มรูปแบบทันทีที่การโจมตีสิ้นสุดลง

วิธีที่ดีที่สุดสําหรับการต่อสู้กับการโจมตี DoS ก็คือการกําหนดกลไกการจํากัดอัตราหรือ "การควบคุมปริมาณการใช้เนื้อหา" DNS สาธารณะของ Google ใช้การควบคุมอัตรา 2 ประเภทดังนี้

• ควบคุมอัตราคําขอขาออกสู่เนมเซิร์ฟเวอร์อื่น Google Public DNS จะบังคับใช้การจํากัด QPS ของคําขอขาออกจากคลัสเตอร์การแสดงผลแต่ละรายการสําหรับที่อยู่ IP ของเนมเซิร์ฟเวอร์แต่ละรายการ เพื่อป้องกันเนมเซิร์ฟเวอร์ของ DNS อื่นๆ จากการโจมตี DoS ที่อาจเปิดใช้งานได้จากเซิร์ฟเวอร์รีโซลเวอร์ของเรา

• ควบคุมอัตราการตอบกลับของลูกค้าขาออก เพื่อป้องกันระบบอื่นๆ จากการขยายและการโจมตี DoS (Botnet) แบบดั้งเดิมที่อาจเผยแพร่จากเซิร์ฟเวอร์รีโซลเวอร์ Google DNS สาธารณะจะทําอัตรา 2 ประเภทที่จํากัดสําหรับคําค้นหาไคลเอ็นต์ ได้แก่

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

  หากคําขอ DNS จากที่อยู่ IP ต้นทางสูงกว่าอัตรา QPS สูงสุด การค้นหาส่วนที่เกินจะหายไป หากคําขอ DNS ผ่าน UDP จากที่อยู่ IP ต้นทางเดียวเกินขีดจํากัดแบนด์วิดท์หรือการขยายโดยเฉลี่ยอย่างต่อเนื่อง (การตอบสนองขนาดใหญ่เป็นครั้งคราว) คําขออาจหายไปหรือมีการส่งการตอบกลับเพียงเล็กน้อย การตอบสนองเล็กๆ อาจเป็นการตอบกลับข้อผิดพลาดหรือการตอบสนองที่ว่างเปล่าด้วยชุดบิตของการตัดข้อความ (เพื่อให้ระบบลองใช้การค้นหาที่ถูกต้องที่สุดผ่าน TCP และสําเร็จ) บางระบบหรือบางโปรแกรมจะลองใหม่ผ่าน TCP และ DNS ผ่าน TCP อาจถูกบล็อกโดยไฟร์วอลล์ในฝั่งไคลเอ็นต์ ดังนั้นแอปพลิเคชันบางอย่างอาจทํางานไม่ถูกต้องเมื่อมีการตัดการตอบกลับ แต่ในกรณีส่วนใหญ่ การตัดข้อความจะช่วยให้ไคลเอ็นต์ที่เป็นไปตาม RFC ทํางานได้อย่างถูกต้องในกรณีส่วนใหญ่