คำสั่ง DNS จะเดินทางผ่าน UDP เสมอหรือไม่

ฉันใช้เวลาสักครู่ค้นคว้าหัวข้อนี้และดูเหมือนจะไม่พบคำตอบที่แน่นอนดังนั้นฉันค่อนข้างมั่นใจว่ามันไม่ซ้ำกันและในขณะที่คำถามของฉันขึ้นอยู่กับความต้องการด้านความปลอดภัยฉันคิดว่ามันยังปลอดภัยที่จะ ถามที่นี่ แต่แจ้งให้เราทราบหากฉันต้องการย้ายไปที่ชุมชนความปลอดภัย

โดยพื้นฐานแล้วแบบสอบถาม DNS เคยใช้ TCP (ถ้าเป็นเช่นนั้นสถานการณ์นี้เกิดขึ้นได้อย่างไร) อีกครั้งฉันแค่พูดถึงการค้นหา เป็นไปได้ไหมที่พวกเขาจะเดินทางข้าม TCP? หากโดเมนมีความยาวได้สูงสุด 253 ไบต์เท่านั้นและแพ็คเก็ต UDP อาจมีขนาดใหญ่ถึง 512 ไบต์แบบสอบถามจะไม่ออกเป็น UDP ทุกครั้งหรือไม่ ฉันไม่คิดว่าการสืบค้นที่แก้ไขได้อาจมีขนาดใหญ่พอที่จะต้องใช้ TCP หากเซิร์ฟเวอร์ DNS ได้รับคำขอโดเมนที่มีขนาดใหญ่กว่า 253 ไบต์เซิร์ฟเวอร์จะลบหรือไม่ลองและแก้ไขหรือไม่ ฉันแน่ใจว่าฉันได้ตั้งสมมติฐานที่ผิดพลาดที่นี่

สำหรับบริบทบางอย่างฉันกำลังทำงานกับกลุ่มความปลอดภัยในการสืบค้น DNS ในเครื่องมือตรวจสอบความปลอดภัยและด้วยเหตุผลหลายประการที่เราได้ตัดสินใจว่าเราจะรับส่งข้อมูลนี้ผ่านการจับแพ็คเก็ตมาตรฐานบนเซิร์ฟเวอร์ DNS และตัวควบคุมโดเมน ข้อกำหนดหลักคือการรวบรวมการสืบค้น DNS ทั้งหมดเพื่อให้สามารถระบุสิ่งที่ลูกค้าพยายามแก้ไขโดเมนที่กำหนด ตามข้อกำหนดนี้เราไม่เกี่ยวข้องกับการจับการตอบสนอง DNS หรือการรับส่งข้อมูลอื่น ๆ เช่นการถ่ายโอนโซนซึ่งได้รับแรงหนุนจากข้อเท็จจริงที่ว่าเราจำเป็นต้อง จำกัด ปริมาณการบันทึกให้มากที่สุด ดังนั้นเราจึงวางแผนที่จะรวบรวมเฉพาะการสืบค้น DNS ที่กำหนดไว้สำหรับเซิร์ฟเวอร์ DNS และส่งผ่าน UDP สำหรับบริบทเพิ่มเติม (ชนิดของขอบเขตคำถามคลานที่นี่) ตอนนี้ก็ถูกนำขึ้นมาว่าเราอาจต้องขยายความปลอดภัย ' การมองเห็นเพื่อให้พวกเขาสามารถตรวจสอบกิจกรรมเช่นแชนเนลการแปลงที่ทำงานบน DNS (ซึ่งจะแสดงความต้องการในการจับภาพการตอบสนอง DNS เช่นกันและปริมาณการใช้ TCP ในภายหลัง) แต่ถึงแม้จะอยู่ในสถานการณ์แบบนั้นฉันก็คิดว่าทราฟฟิก DNS ขาออกใด ๆ จะอยู่ในรูปแบบของการค้นหา / การสืบค้นและสิ่งเหล่านี้จะอยู่เหนือ UDP แม้ว่าจะมาจากแหล่งที่เป็นอันตราย (เพราะเหตุผลของฉันในวรรคแรก) ดังนั้นจะมีคำถามเพิ่มเติม:

• อย่างน้อยที่สุดเราจะจับบทสนทนาครึ่งหนึ่งกับแนวทางที่ฉันได้กล่าวไว้หรือไม่? หรือลูกค้าจะส่งปริมาณการใช้งาน DNS ที่ไม่ได้อยู่ในรูปแบบของแบบสอบถาม (อาจจะชอบการตอบสนองต่อการตอบกลับของเซิร์ฟเวอร์ DNS และอาจจบลงด้วยการใช้ TCP)

• สามารถแก้ไขแบบสอบถาม DNS เพื่อใช้ TCP ได้หรือไม่ เซิร์ฟเวอร์ DNS จะยอมรับและตอบกลับแบบสอบถาม DNS ที่มาทาง TCP หรือไม่

ไม่แน่ใจว่าเกี่ยวข้องหรือไม่ แต่เรา จำกัด การร้องขอ DNS ไปยังเซิร์ฟเวอร์ DNS ที่ได้รับอนุญาตและปิดกั้นการรับส่งข้อมูลอื่น ๆ ทั้งหมดผ่านพอร์ต 53 ฉันเป็นมือใหม่แน่นอนฉันขอโทษถ้าคำถามของฉันไม่สอดคล้องและแจ้งให้เราทราบ ฉันควรแก้ไขอย่างไร

แบบสอบถาม DNS ปกติใช้พอร์ต UDP 53 แต่แบบสอบถามที่ยาวกว่า (> 512 octets) จะได้รับคำตอบ 'ถูกตัดทอน' ซึ่งส่งผลให้เกิดการสนทนา TCP 53 เพื่ออำนวยความสะดวกในการส่ง / รับแบบสอบถามทั้งหมด นอกจากนี้เซิร์ฟเวอร์ DNS จะเชื่อมโยงกับพอร์ต 53 แต่คิวรีนั้นมาจากพอร์ตที่มีหมายเลขสูงแบบสุ่ม (49152 ขึ้นไป) ที่ส่งไปยังพอร์ต 53 การตอบสนองจะถูกส่งกลับไปยังพอร์ตเดียวกันนี้จากพอร์ต 53

พอร์ตเครือข่ายที่ใช้โดย DNS | เอกสาร Microsoft

ดังนั้นหากคุณวางแผนที่จะทำการสอดแนมความปลอดภัยในการค้นหา DNS จากเครือข่ายของคุณคุณจะต้องคำนึงถึงข้างต้น

สำหรับทราฟฟิกที่ไม่ใช่การค้นหาให้พิจารณาว่า DNS ใช้การถ่ายโอนโซน (ประเภทการสืบค้น AXFR) เพื่อปรับปรุงเซิร์ฟเวอร์ DNS อื่นด้วยระเบียนใหม่ ผู้ชายที่อยู่ในการโจมตีกลางสามารถเริ่มต้นด้วยการถ่ายโอนเช่น DDOS ในเซิร์ฟเวอร์ชื่อหลักเพื่อที่จะยุ่งเกินไปที่จะตอบสนองต่อการร้องขอรองสำหรับการปรับปรุงระเบียน จากนั้นแฮ็คเกอร์ก็ทำการปลอมแปลง Primary นั้นเพื่อให้ข้อมูล 'พิษ' ไปยัง Secondary ซึ่งเปลี่ยนเส้นทางโดเมน DNS ยอดนิยมไปยังโฮสต์ที่ถูกบุกรุก

ดังนั้นการตรวจสอบความปลอดภัยของคุณควรให้ความสำคัญกับประเภทการสืบค้น AXFR และระบบ DNS ของคุณควรยอมรับการแลกเปลี่ยน AXFR จากที่อยู่ IP ที่ระบุเท่านั้น

SANS Institute InfoSec ห้องอ่านหนังสือ sans.org

สิ่งนี้เริ่มเป็นความเห็นต่อคำตอบของจอร์จ แต่มันก็นาน ภาพใหญ่ขึ้นค่อนข้างซับซ้อนเนื่องจากต้องเข้าใจประวัติบ้าง

• RFC 1035เดิมเรียกว่าขีด จำกัด 512 ไบต์เพื่อหลีกเลี่ยงการกระจายตัวของ UDP การแยกส่วนดาตาแกรม UDP และ TCP ได้รับเลือกเป็นทางเลือกสุดท้ายเพื่อลดค่าใช้จ่ายในการทำธุรกรรม DNS การถ่ายโอนโซนมักจะใช้ TCP เนื่องจากการถ่ายโอนโซนใช้พื้นที่> 512 ไบต์ตามลักษณะของมัน (มันจะเสียแบนด์วิดท์ที่จะเริ่มต้นด้วย UDP เลย)

• รองรับการลอง TCP อีกครั้งในการตัดปลายอย่างกว้างขวางเนื่องจากมีการระบุในRFC 1123ตั้งแต่ปี 1989

• EDNS (0) จะถูกกำหนดโดยRFC 6891 (2013) และก่อนที่มีอยู่เป็นเสนอมาตรฐานย้อนหลังไปถึง 1999 มันกำหนดกลไกที่ลูกค้าและเซิร์ฟเวอร์สามารถเจรจาขนาด UDP มากกว่า 512 เนื่องจากความใหม่ของ EDNS (0), อุปกรณ์ฮาร์ดแวร์จำนวนมากทำให้สมมติฐานเกี่ยวกับโครงสร้างของแพ็กเก็ต DNS ที่ทำให้เกิดแพ็กเก็ตที่เข้ากันได้จะถูกทิ้ง สาเหตุที่พบบ่อยที่สุดคือการสันนิษฐานว่าข้อความ DNS ที่เกิน 512 ไบต์ไม่ถูกต้อง แต่นี่เป็นหนึ่งในหลาย ๆ

หากเราแยกมันออกเป็นพฤติกรรมที่สังเกตได้:

1. คำสั่ง DNS มักจะเริ่มต้นเป็น UDP เว้นแต่จะทราบล่วงหน้าว่าการตอบกลับจะใหญ่เกินไปที่จะเริ่มต้นด้วย (การถ่ายโอนโซน)
2. การตอบกลับอาจทำให้ TCP ลองใหม่ในไคลเอนต์หากเห็นการตอบกลับที่ถูกตัดทอน นี้ได้รับการสนับสนุนค่อนข้างดี
3. การตอบกลับของ UDP ที่มีขนาดใหญ่กว่า 512 ไบต์อาจเห็นได้หากไคลเอนต์ใช้ EDNS (0) เพื่อโฆษณา payload ที่ใหญ่กว่าและเซิร์ฟเวอร์ที่รับนั้นรองรับ สิ่งนี้จะเกิดขึ้นหากฮาร์ดแวร์ที่อยู่ระหว่างทั้งสองนั้นไม่รบกวนและส่งผลให้เกิดแพ็กเก็ตที่หล่นหรือผิด
4. ไคลเอนต์อาจเลือกที่จะลองแบบสอบถาม EDNS (0) ด้วย payload โฆษณาที่มีขนาดเล็กลงถ้าไม่เห็นการตอบกลับ แต่เฉพาะจะแตกต่างกันไประหว่างการใช้งาน
   • เป็นสิ่งสำคัญที่จะต้องทราบว่าการตอบกลับซึ่งทำให้ผ่านมาอาจมีขนาดใหญ่เกินไปที่จะพอดีกับขนาดที่ร้องขอซึ่งส่งผลให้พฤติกรรม # 2 ข้างต้น (เจ้าเก่าลอง TCP อีกครั้ง)
   • ฝั่งไคลเอ็นต์อาจเลือกที่จะจำขนาดที่ในที่สุดก็ส่งผลให้ประสบความสำเร็จ วิธีนี้ช่วยให้สามารถหลีกเลี่ยงการค้นหาที่ไม่จำเป็นโดยไม่จำเป็น หากต้องการทำอย่างอื่นจะค่อนข้างสิ้นเปลืองโดยเฉพาะอย่างยิ่งหากผลลัพธ์สุดท้ายต้องการ TCP fallback

คุณควรจำไว้ว่าRFC 7766 อนุญาตให้ใช้การเชื่อมต่อผ่าน TCPอีกครั้งและเป็นไปได้ที่จะพบการไพพ์ไลน์แบบสอบถามผ่าน TCP ในไวลด์ เครื่องมือบางอย่างตรวจไม่พบการสอบถาม DNS นอกเหนือจากที่พบครั้งแรกในเซสชัน TCP dnscap เป็นตัวอย่างของ

มีเป็น ความต้องการของการดำเนินงาน - RFC 7766, DNS ขนส่งผ่าน TCP

1. บทนำ

ธุรกรรมDNS [ RFC1034 ] ส่วนใหญ่เกิดขึ้นที่ UDP [ RFC768 ] TCP [ RFC793 ] มักใช้สำหรับการถ่ายโอนโซนแบบเต็ม (ใช้ AXFR) และมักจะใช้สำหรับข้อความที่มีขนาดเกินขีด จำกัด 512 ไบต์ดั้งเดิมของโปรโตคอล DNS การปรับใช้ DNS Security ที่เพิ่มขึ้น (DNSSEC) และ IPv6 มีขนาดการตอบสนองเพิ่มขึ้นดังนั้นการใช้ TCP ความจำเป็นในการใช้ TCP ที่เพิ่มขึ้นนั้นได้รับแรงผลักดันจากการป้องกันที่ให้การป้องกันการปลอมแปลงที่อยู่ดังนั้นการใช้ประโยชน์จาก DNS ในการโจมตีแบบสะท้อน / ขยาย ตอนนี้ใช้กันอย่างแพร่หลายในการ จำกัด อัตราการตอบสนอง [ RRL1 ] [ RRL2 ] นอกจากนี้งานล่าสุดในการแก้ปัญหาความเป็นส่วนตัวของ DNS เช่น [ DNS-over-TLS] เป็นอีกแรงจูงใจในการทบทวนข้อกำหนด DNS-over-TCP อีกครั้ง

ส่วน 6.1.3.2 จากสถานะ [RFC1123] :

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

อย่างไรก็ตามผู้ดำเนินการบางคนได้นำข้อความที่ยกมาข้างต้นเพื่อแสดงว่าการสนับสนุน TCP เป็นคุณสมบัติเสริมของโปรโตคอล DNS

ผู้ให้บริการเซิร์ฟเวอร์ DNS ส่วนใหญ่สนับสนุน TCP อยู่แล้วและการกำหนดค่าเริ่มต้นสำหรับการปรับใช้ซอฟต์แวร์ส่วนใหญ่คือการสนับสนุน TCP ผู้ชมหลักสำหรับเอกสารนี้คือผู้ดำเนินการที่ จำกัด การสนับสนุน TCP จำกัด การทำงานร่วมกันและขัดขวางการปรับใช้คุณลักษณะ DNS ใหม่

เอกสารนี้จึงอัปเดตข้อมูลจำเพาะโปรโตคอล DNS หลักซึ่งการสนับสนุนสำหรับ TCP นับจากนี้ไปเป็นส่วนหนึ่งที่จำเป็นของการใช้โปรโตคอล DNS แบบเต็ม

มีข้อดีและข้อเสียหลายประการสำหรับการใช้ TCP ที่เพิ่มขึ้น (ดูภาคผนวก A ) รวมถึงรายละเอียดการใช้งานที่ต้องพิจารณา เอกสารนี้ระบุถึงปัญหาเหล่านี้และแสดง TCP เป็นทางเลือกการขนส่งที่ถูกต้องสำหรับ DNS มันขยายเนื้อหาของ [ RFC5966 ] ด้วยการพิจารณาเพิ่มเติมและบทเรียนที่ได้เรียนรู้จากการวิจัยการพัฒนาและการใช้งาน TCP ใน DNS และในโปรโตคอลอินเทอร์เน็ตอื่น ๆ

ในขณะที่เอกสารนี้ไม่ได้กำหนดข้อกำหนดเฉพาะสำหรับผู้ให้บริการเซิร์ฟเวอร์ DNS แต่จะให้คำแนะนำแก่ผู้ให้บริการเพื่อช่วยให้มั่นใจว่าการสนับสนุน TCP บนเซิร์ฟเวอร์และเครือข่ายของพวกเขานั้นเหมาะสมที่สุด ควรสังเกตว่าความล้มเหลวในการสนับสนุน TCP (หรือการบล็อก DNS ผ่าน TCP ที่เลเยอร์เครือข่าย) อาจส่งผลให้เกิดความล้มเหลวในการแก้ไขและ / หรือหมดเวลาระดับแอปพลิเคชัน

คุณไม่ควรกรอง TCP / 53 ในทิศทางใด ๆ ตัวอย่างเช่นnsupdateแบบสอบถามอาจใช้ TCP ทันทีที่คำขอมีขนาดใหญ่เกินไป (ซึ่งอาจเกิดขึ้นอย่างรวดเร็ว) ดังนั้นคุณควรปล่อยให้ UDP และ TCP สำหรับพอร์ต 53 (เป็น IPv4 & V6!) ไหลในทุกทิศทาง

นอกจากนี้ยังมีการทำงานมากขึ้นใน DNS ผ่าน TLS ดังนั้น TCP จะต้องใช้ทั้งสองทิศทาง ดู RFC7858