สรุปสั้น

นักวิจัยด้านความมั่นคงปลอดภัยไซเบอร์เปิดเผยการโจมตีปฏิเสธการให้บริการสองรูปแบบที่ใช้ประโยชน์จากวิธีที่เครือข่ายส่งมอบเนื้อหาหรือ CDN รายใหญ่แปลงทราฟฟิก HTTP/3 ที่รับมาจากฝั่งผู้ใช้ให้กลายเป็นคำขอ HTTP/1.1 ก่อนส่งต่อไปยังเว็บไซต์ที่ตนให้บริการอยู่ ผลคือกระแสคำขอที่ใช้แบนด์วิดท์ต่ำมากจากฝั่งผู้โจมตี ถูกขยายได้สูงสุดถึง 350 เท่าเมื่อไปกระทบเซิร์ฟเวอร์ต้นทาง การโจมตีชุดนี้ถูกเรียกรวมกันว่า CDN Tsunami และถูกทดสอบกับผู้ให้บริการหกราย ได้แก่ Alibaba, Baidu, Cloudflare, Amazon CloudFront, Fastly และ Tencent

ผลการทดสอบพบว่าทั้งหกรายเปราะบางต่อรูปแบบที่โจมตีแบนด์วิดท์ และห้ารายเปราะบางต่อรูปแบบที่โจมตีจำนวนการเชื่อมต่อ โดย Cloudflare ไม่ได้รับผลจากรูปแบบหลังเพราะระบบจะรอรับคำขอให้ครบก่อนจึงเปิดการเชื่อมต่อไปยังเซิร์ฟเวอร์ต้นทาง เงื่อนไขของการโจมตีคือเว็บไซต์เป้าหมายต้องโฮสต์อยู่บนหนึ่งในหกผู้ให้บริการนี้ และเปิดให้บริการ HTTP/3 ที่ขอบเครือข่าย โดยเจ้าของเว็บไซต์ไม่จำเป็นต้องตั้งค่าอะไรเป็นพิเศษเลย

ปัจจุบันยังไม่มีการกำหนดหมายเลข CVE ให้กับเทคนิคทั้งสอง และยังไม่มีรายงานการโจมตีจริง โดย Baidu และ Tencent ยืนยันรายงานและติดตั้งมาตรการแก้ไขที่นักวิจัยเสนอแล้ว ขณะที่ผู้ให้บริการอีกสี่รายรับทราบการเปิดเผยและยังอยู่ระหว่างการหารือภายใน ประเด็นสำคัญที่นักวิจัยย้ำคือมาตรการบรรเทาทุกข้อที่เสนอไว้ต้องดำเนินการที่ฝั่ง CDN ไม่ใช่ที่เว็บไซต์ต้นทาง ซึ่งหมายความว่าเจ้าของเว็บไซต์แทบไม่มีทางป้องกันตัวเองได้โดยตรง

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 20 สิงหาคม 2569 ว่า คณะนักวิจัยได้เผยแพร่งานวิจัยที่อธิบายการโจมตีปฏิเสธการให้บริการสองเทคนิค ซึ่งอาศัยช่องว่างของการติดตั้งใช้งานโปรโตคอลที่เหมือนกันในผู้ให้บริการ CDN รายใหญ่หลายราย

เทคนิคทั้งสองมีชื่อว่า HTTP/3 Bandwidth Amplification หรือ HBA และ HTTP/3 Connection Amplification หรือ HCA โดยทั้งคู่ตั้งอยู่บนช่องว่างเดียวกัน นั่นคือการที่ CDN สื่อสารกับเบราว์เซอร์ด้วย HTTP/3 แต่สื่อสารกับเว็บไซต์ที่อยู่ด้านหลังด้วย HTTP/1.1 เท่านั้น ความไม่ตรงกันนี้เกิดขึ้นเพราะตามที่ทีมวิจัยระบุไว้ CDN ยังไม่รองรับ HTTP/3 แบบต้นทางถึงปลายทาง

ตัวเลขการขยาย 350 เท่าใช้ได้เฉพาะกับ Alibaba, Baidu และ Tencent เท่านั้น เนื่องจากผู้ให้บริการสามรายนี้รองรับตารางแบบไดนามิกของ QPACK และวัดค่าได้ที่ราว 64 สตรีมที่ทำงานพร้อมกัน ส่วนค่าสูงสุดของ Cloudflare, CloudFront และ Fastly อยู่ระหว่าง 36.41 เท่าถึง 51.2 เท่า

งานวิจัยระบุว่า HTTP/3 ถูกเปิดใช้งานเป็นค่าเริ่มต้นที่ Cloudflare และ CloudFront อย่างไรก็ตาม เอกสารของ Cloudflare อธิบายว่า HTTP/3 พร้อมใช้งานในทุกแพ็กเกจและมีขั้นตอนสำหรับเปิดใช้งาน มากกว่าจะระบุว่าเปิดใช้เป็นค่าเริ่มต้น ขณะที่เอกสารของ AWS ระบุว่า http2 คือเวอร์ชัน HTTP ที่เป็นค่าเริ่มต้นสำหรับ CloudFront distribution ที่สร้างใหม่ ซึ่งเป็นจุดที่คำอธิบายของงานวิจัยกับเอกสารของผู้ให้บริการไม่ตรงกัน

เพื่อประเมินขอบเขตของผู้ที่อาจได้รับผลกระทบ ทีมวิจัยได้รวบรวมโดเมนย่อยภายใต้รายชื่อ Tranco Top 1M แล้วไล่ดูระเบียน CNAME และ NS จับคู่กับส่วนต่อท้ายที่ผู้ให้บริการ CDN กำหนดไว้ จากนั้นตรวจสอบแต่ละรายการด้วยเครื่องมือ aioquic ผลที่ได้คือโดเมนย่อย 151,685 รายการที่โฮสต์อยู่กับผู้ให้บริการทั้งหกราย ในจำนวนนี้ 42,330 รายการตอบสนองต่อคำขอ HTTP/3 และถูกจัดว่าอาจเปราะบาง โดยกลุ่มที่มีจำนวนมากที่สุดคือ CloudFront จำนวน 17,431 รายการ Cloudflare จำนวน 12,371 รายการ และ Fastly จำนวน 11,606 รายการ ทั้งนี้การตรวจสอบดังกล่าวยืนยันได้เพียงว่าขอบเครือข่ายของ CDN ตอบสนองต่อคำขอ HTTP/3 เท่านั้น และไม่มีเซิร์ฟเวอร์ต้นทางรายใดนอกเหนือจากชุดทดสอบของนักวิจัยเองที่ถูกโจมตี

งานวิจัยชิ้นนี้เป็นผลงานของนักวิจัยจาก National University of Singapore, Fuzhou University, University of Sheffield และ Johns Hopkins University และมีกำหนดนำเสนอในงาน Symposium on Reliable Distributed Systems ที่กรุงโรม ระหว่างวันที่ 22 ถึง 24 กันยายน 2569 โดยผลการทดลองถูกนำไปเทียบกับงานวิจัยชื่อ CDN Judo เมื่อปี 2563 ซึ่งศึกษาการแปลง HTTP/2 เป็น HTTP/1.1 ที่ CDN ในลักษณะเดียวกัน และรายงานค่าการขยายราว 44 เท่าเมื่อใช้ตารางแบบสถิต และ 166 เท่าเมื่อใช้ตารางแบบไดนามิก

CDN Tsunami HTTP/3 to HTTP/1.1 translation amplification denial of service attack

วิธีการโจมตี

เทคนิค HBA อาศัย QPACK ซึ่งเป็นรูปแบบการบีบอัดส่วนหัวที่มาพร้อมกับ HTTP/3 เนื่องจาก HTTP/1.1 ไม่มีกลไกเทียบเท่า CDN จึงต้องขยายค่าดัชนีขนาดเล็กทุกค่าที่ได้รับกลับไปเป็นส่วนหัวแบบเต็มก่อนส่งต่อ ผลคือคำขอที่ผู้โจมตีจ่ายเพียงไม่กี่ไบต์บนสายส่ง กลายเป็นภาระขนาดเท่าข้อมูลที่ถูกคลายบีบอัดแล้วสำหรับเซิร์ฟเวอร์ต้นทาง จากการวัด แบนด์วิดท์ฝั่งผู้โจมตีอยู่ต่ำกว่า 500 Kbps เมื่อโจมตี CDN สามรายที่รองรับตารางแบบไดนามิก และต่ำกว่า 5 Mbps สำหรับรายที่เหลือ ขณะที่แบนด์วิดท์ที่วัดได้ที่เซิร์ฟเวอร์ต้นทางเกิน 100 Mbps ตลอดการทดสอบ

รูปแบบที่ใช้ตารางแบบไดนามิกต้องให้ผู้โจมตีส่งคำขอ HTTP/3 หนึ่งครั้งที่บรรจุส่วนหัวขนาดใหญ่เข้าไปก่อน เพื่อให้ CDN นำไปใส่ในตาราง จากนั้นจึงอ้างถึงรายการนั้นซ้ำ ๆ ด้วยค่าดัชนีขนาดเล็ก การรองรับจำกัดอยู่เฉพาะ Alibaba, Baidu และ Tencent ซึ่งแต่ละรายประกาศตารางขนาด 4KB และขนาดรายการสูงสุด 3,072 ไบต์ ค่าการขยายแบนด์วิดท์สูงสุดที่วัดได้จากการใช้ตารางแบบสถิตเรียงจากมากไปน้อยคือ Baidu ที่ 66.06 เท่า Alibaba ที่ 65.8 เท่า Tencent ที่ 54.08 เท่า Amazon CloudFront ที่ 51.2 เท่า Cloudflare ที่ 48.27 เท่า และ Fastly ที่ 36.41 เท่า โดยสามรายแรกรองรับตารางแบบไดนามิกส่วนสามรายหลังไม่รองรับ

เทคนิค HCA เล็งไปที่ขีดความสามารถด้านจำนวนการเชื่อมต่อแทนแบนด์วิดท์ ผู้ให้บริการห้าในหกรายจะเปิดการเชื่อมต่อ HTTP/1.1 ไปยังเซิร์ฟเวอร์ต้นทางทันทีที่ได้รับเฟรม HEADERS ของ HTTP/3 ก่อนที่เนื้อหาของคำขอจะมาถึง ประกอบกับการที่ HTTP/3 รองรับการมัลติเพล็กซ์ ทำให้การเชื่อมต่อเดียวจากฝั่งผู้ใช้สามารถบรรทุกหลายสตรีมได้ และแต่ละสตรีมจะกระตุ้นให้เกิดการเชื่อมต่อ TCP ไปยังเซิร์ฟเวอร์ต้นทางของตัวเอง จากนั้นผู้โจมตีเพียงส่งเฟรม DATA ด้วยอัตราที่ช้ามากเพื่อคงการเชื่อมต่อเหล่านั้นไว้ โดย CDN ยังคงถือว่าคำขอนั้นยังไม่สมบูรณ์

ในการทดสอบกับเซิร์ฟเวอร์ Apache ที่ตั้งค่าหมดเวลาที่ 300 วินาทีและจำกัดการเชื่อมต่อไว้ที่ 256 รายการ การเชื่อมต่อ HTTP/3 เพียงสี่รายการที่แต่ละรายการมัลติเพล็กซ์ 96 สตรีม สามารถบังคับให้เกิดการเชื่อมต่อฝั่งหลังบ้าน 384 รายการได้ ส่วน Fastly ต้องใช้ 48 การเชื่อมต่อที่รายการละ 8 สตรีม เนื่องจากจำกัดการเชื่อมต่อไปยังเซิร์ฟเวอร์ต้นทางไว้ที่ 10 รายการต่อการเชื่อมต่อ HTTP/3 หนึ่งรายการ ผลกระทบที่วัดจากฝั่งผู้ใช้ทั่วไปคือเวลาตอบสนองพุ่งถึง 60 วินาทีบน Alibaba และสูงถึง 90 วินาทีบน Baidu และ CloudFront ซึ่งทั้งสองรายคืนค่า HTTP 504 Gateway Timeout ขณะที่ Fastly เพิ่มเป็น 15 วินาทีและคืนค่า HTTP 503 Service Unavailable ส่วน Tencent ปิดการเชื่อมต่อฝั่งผู้ใช้ราว 10 วินาทีหลังได้รับคำขอตรวจสอบและไม่คืนค่าใด ๆ

ข้อจำกัดของข้อมูลที่ต้องระบุมีหลายจุด การทดลองทั้งหมดถูกจำกัดด้วยเพดานที่นักวิจัยตั้งขึ้นเอง โดยกำหนดเซิร์ฟเวอร์ต้นทางไว้ที่ 100 Mbps และฝั่งผู้โจมตีไว้ที่ 30 Mbps และไม่มีการรายงานผลการทดสอบที่เกินตัวเลขดังกล่าว งานวิจัยระบุว่าการโจมตีขยายขนาดไปยังเซิร์ฟเวอร์ที่มีขีดความสามารถสูงกว่านี้ได้ ซึ่งเป็นข้อกล่าวอ้างที่ไม่ได้ทดสอบจริง นอกจากนี้ค่าการขยายยังถูกพบว่าขึ้นสูงสุดที่ราว 64 สตรีมพร้อมกันแล้วลดลง ซึ่งนักวิจัยอธิบายว่าเกิดจากภาระของหน่วยประมวลผลที่ขอบเครือข่ายของ CDN แต่ไม่มีการนำเสนอผลการวัดหน่วยประมวลผลที่ขอบเครือข่ายประกอบ และงานวิจัยไม่ได้รายงานว่ามีการทดสอบซ้ำหลังจาก Baidu และ Tencent ติดตั้งมาตรการแก้ไขแล้วหรือไม่ รวมถึงไม่ได้ระบุว่าโค้ดโจมตีหรือกรอบการวัดผลจะถูกเผยแพร่หรือไม่

มาตรการบรรเทาที่เสนอต่อผู้ให้บริการ

มาตรการทั้งหมดที่นักวิจัยเสนอต่อผู้ให้บริการถูกออกแบบให้ดำเนินการที่ฝั่ง CDN ประกอบด้วยการจำกัดขนาดของรายการส่วนหัวเดี่ยวที่จะถูกใส่ลงในตารางแบบไดนามิกของ QPACK ซึ่งเสนอไว้ที่ 512 ไบต์ การจำกัดจำนวนครั้งที่รายการหนึ่งในตารางแบบไดนามิกจะถูกอ้างถึงได้ภายในสตรีมเดียว ซึ่งเสนอไว้ที่ไม่เกิน 10 ครั้ง การบังคับใช้ขนาดสูงสุดของคำขอ HTTP/1.1 หลังคลายบีบอัดและปฏิเสธคำขอที่เกินกว่านั้นก่อนส่งต่อ ซึ่งเสนอไว้ที่ 64KB การรอรับคำขอ HTTP/3 ให้ครบทั้งเฟรม HEADERS และ DATA ก่อนเปิดการเชื่อมต่อจาก CDN ไปยังเซิร์ฟเวอร์ต้นทาง การจำกัดจำนวนการเชื่อมต่อจาก CDN ไปยังเซิร์ฟเวอร์ต้นทางที่การเชื่อมต่อ HTTP/3 หนึ่งรายการจะกระตุ้นได้ และการตั้งเวลาหมดอายุของการเชื่อมต่อระหว่าง CDN กับเซิร์ฟเวอร์ต้นทางแยกอิสระจากการเชื่อมต่อฝั่งผู้ใช้ ซึ่งเสนอไว้ที่ 30 วินาทีเมื่อไม่มีข้อมูลที่มีความหมายถูกส่งต่อ

ตามส่วนที่ว่าด้วยการเปิดเผยช่องโหว่ในงานวิจัย มาตรการที่ Tencent ติดตั้งแล้วคือการจำกัดจำนวนการเชื่อมต่อจาก CDN ไปยังเซิร์ฟเวอร์ต้นทางและการจำกัดขนาดของส่วนหัวในตารางแบบไดนามิก โดยเอกสารเดียวกันบันทึกว่ามีการมอบรางวัลจากโครงการ bug bounty ราว 350 ดอลลาร์จาก Baidu และ 150 ดอลลาร์จาก Tencent ส่วนผู้ให้บริการอีกสี่รายรับทราบการเปิดเผยและยังหารือกันภายใน

ในบริบทที่กว้างขึ้น ตารางแบบไดนามิกของ QPACK เพิ่งเป็นประเด็นของช่องโหว่อีกรายการเมื่อวันที่ 8 กรกฎาคม เมื่อนาย Sébastien Féry นักวิจัยจาก FoxIO รายงานว่าทราฟฟิก QPACK ที่ถูกต้องตามข้อกำหนดเพียงราว 260 ไบต์ สามารถทำให้เซิร์ฟเวอร์ที่รัน XQUIC ซึ่งเป็นไลบรารี QUIC และ HTTP/3 ของ Alibaba ล่มได้ โดยไลบรารีดังกล่าวเป็นตัวให้บริการ HTTP/3 แก่เว็บเซิร์ฟเวอร์ Tengine ที่ Alibaba ใช้ทั่วโครงสร้างพื้นฐานคลาวด์และ CDN ของตัวเอง เว็บไซต์ Cloud Thunder รายงานกรณีดังกล่าวไว้ที่ 2026/07/108

นอกจากนี้ เมื่อวันที่ 13 สิงหาคม โครงการ OpenSSL ได้เปิดเผย CVE-2026-14456 ซึ่งเป็นช่องโหว่ระดับความรุนแรงต่ำ โดยเซิร์ฟเวอร์ QUIC จะเข้าคิวช่องสัญญาณขาเข้าสำหรับหมายเลขการเชื่อมต่อปลายทางที่ไม่รู้จักโดยไม่มีการบังคับขีดจำกัดใด ๆ และการแก้ไขได้เพิ่มขีดจำกัดของการเชื่อมต่อที่รออยู่ โดยตั้งค่าเริ่มต้นไว้ที่ 256 รายการ ขณะที่ Cloudflare ระบุในรายงานภัยคุกคาม DDoS ครึ่งแรกของปี 2569 ที่เผยแพร่ในสัปดาห์เดียวกันว่า จุดศูนย์ถ่วงของช่องทางการโจมตีได้ขยับจากการยิงด้วยบอตเน็ตไปสู่การสะท้อนและการขยายสัญญาณ โดยการโจมตีที่อาศัย DNS คิดเป็น 34.3 เปอร์เซ็นต์ของกิจกรรมทั้งหมดในระดับเครือข่ายในช่วงครึ่งแรกของปี

ผลกระทบ

ประเด็นที่ทำให้ CDN Tsunami ต่างจากข่าวช่องโหว่ทั่วไปคือ ผู้ที่รับผลกระทบกับผู้ที่แก้ไขได้เป็นคนละคนกัน เจ้าของเว็บไซต์คือฝ่ายที่เซิร์ฟเวอร์ล่มและลูกค้าเข้าไม่ได้ แต่มาตรการบรรเทาทุกข้อที่นักวิจัยเสนอต้องดำเนินการที่ฝั่ง CDN ทั้งหมด เจ้าของเว็บไซต์จึงไม่มีสวิตช์ใดให้กดเพื่อป้องกันตัวเอง นอกจากการเลือกผู้ให้บริการหรือปิดการใช้งาน HTTP/3 ที่ขอบเครือข่ายซึ่งแลกมาด้วยประสิทธิภาพที่ลดลง สถานการณ์นี้เป็นภาพสะท้อนของความเสี่ยงจากบุคคลที่สามในรูปแบบที่มักถูกมองข้าม เพราะโดยทั่วไปองค์กรวาง CDN ไว้ในฐานะเกราะป้องกันการโจมตี DDoS ไม่ใช่ในฐานะช่องทางที่ทำให้การโจมตีมีประสิทธิภาพขึ้น

จุดที่ควรเน้นเชิงเทคนิคคือรากของปัญหาไม่ใช่บั๊กในซอฟต์แวร์ตัวใดตัวหนึ่ง แต่คือการที่โปรโตคอลสองฝั่งไม่เท่ากัน CDN พูด HTTP/3 กับเบราว์เซอร์เพื่อประสิทธิภาพ แต่ยังพูด HTTP/1.1 กับเซิร์ฟเวอร์ต้นทางเพราะเป็นสิ่งที่เว็บเซิร์ฟเวอร์ส่วนใหญ่รองรับ ตัวการแปลระหว่างสองโปรโตคอลนี้เองที่กลายเป็นเครื่องขยาย และเป็นเหตุผลที่ทำให้ปัญหาลักษณะเดียวกันเคยเกิดมาแล้วในยุคที่ CDN แปลง HTTP/2 เป็น HTTP/1.1 ตามงานวิจัย CDN Judo เมื่อปี 2563 นั่นหมายความว่าทุกครั้งที่โปรโตคอลฝั่งผู้ใช้ก้าวหน้าไปก่อนโปรโตคอลฝั่งหลังบ้าน ช่องว่างแบบเดียวกันมีโอกาสเกิดซ้ำ

ในแง่ความเร่งด่วน ต้องอ่านข่าวนี้ตามสถานะที่มันเป็น นั่นคืองานวิจัยเชิงวิชาการที่ยังไม่มีรายงานการโจมตีจริง ไม่มีหมายเลข CVE และผลการทดลองถูกจำกัดด้วยเพดานแบนด์วิดท์ที่นักวิจัยตั้งเอง อย่างไรก็ตาม สิ่งที่ทำให้เทคนิคกลุ่มนี้น่ากังวลในระยะกลางคือต้นทุนฝั่งผู้โจมตีที่ต่ำมาก การใช้แบนด์วิดท์ต่ำกว่า 500 Kbps เพื่อสร้างภาระเกิน 100 Mbps ที่ปลายทาง หมายความว่าผู้โจมตีไม่จำเป็นต้องมีบอตเน็ตขนาดใหญ่ ซึ่งสอดคล้องกับที่ Cloudflare ระบุว่าจุดศูนย์ถ่วงของการโจมตีกำลังขยับจากการยิงด้วยบอตเน็ตไปสู่การขยายสัญญาณ เว็บไซต์ Cloud Thunder เคยรายงานบอตเน็ตที่ยิง DDoS ผ่าน HTTP/2 ไว้ที่ 2026/08/072

คำแนะนำ

สำหรับองค์กรที่ใช้บริการ CDN สิ่งแรกที่ทำได้ทันทีคือตรวจสอบว่าโดเมนของตนเปิดให้บริการ HTTP/3 ที่ขอบเครือข่ายอยู่หรือไม่ และเปิดโดยการตั้งค่าของตัวเองหรือเปิดมาโดยค่าเริ่มต้นของผู้ให้บริการ เพราะงานวิจัยกับเอกสารของผู้ให้บริการให้ข้อมูลเรื่องค่าเริ่มต้นไม่ตรงกัน การตรวจสอบจากสถานะจริงของ distribution หรือ zone ที่ใช้อยู่จึงเชื่อถือได้มากกว่าการอนุมานจากเอกสาร

ประเด็นถัดมาคือการตั้งค่าฝั่งเซิร์ฟเวอร์ต้นทาง แม้จะไม่ใช่มาตรการบรรเทาที่นักวิจัยเสนอ แต่ค่าที่ใช้ในการทดลองบอกบางอย่างได้ กล่าวคือเซิร์ฟเวอร์ Apache ที่ตั้งเวลาหมดอายุไว้ 300 วินาทีและจำกัดการเชื่อมต่อไว้ 256 รายการถูกทำให้ล่มด้วยการเชื่อมต่อเพียงสี่รายการจากฝั่งผู้โจมตี องค์กรจึงควรทบทวนค่าเวลาหมดอายุของการเชื่อมต่อที่ไม่มีข้อมูลไหลเข้ามา และพิจารณาว่าขีดจำกัดจำนวนการเชื่อมต่อที่ตั้งไว้สอดคล้องกับปริมาณการเชื่อมต่อที่ CDN อาจเปิดเข้ามาจริงหรือไม่

ในด้านการเฝ้าระวัง ควรตั้งการแจ้งเตือนที่มองความไม่สมดุลระหว่างทราฟฟิกฝั่งผู้ใช้กับทราฟฟิกที่มาถึงเซิร์ฟเวอร์ต้นทาง เพราะลักษณะเฉพาะของการโจมตีชุดนี้คือปริมาณคำขอที่ขอบเครือข่ายดูปกติ แต่ภาระที่ต้นทางสูงผิดสัดส่วน หากระบบเฝ้าระวังดูเฉพาะตัวเลขที่ขอบเครือข่ายหรือดูเฉพาะจำนวนคำขอต่อวินาที การโจมตีลักษณะนี้จะไม่ปรากฏเป็นความผิดปกติจนกว่าเซิร์ฟเวอร์จะเริ่มคืนค่า 502, 503 หรือ 504 ให้ผู้ใช้จริง สุดท้าย องค์กรที่มีสัญญาระดับบริการกับผู้ให้บริการ CDN ควรใช้จังหวะนี้สอบถามผู้ให้บริการโดยตรงว่ามีการติดตั้งมาตรการที่นักวิจัยเสนอแล้วหรือไม่ โดยเฉพาะการรอรับคำขอให้ครบก่อนเปิดการเชื่อมต่อไปยังต้นทาง และการจำกัดจำนวนการเชื่อมต่อต่อการเชื่อมต่อฝั่งผู้ใช้หนึ่งรายการ

แหล่งอ้างอิง