ทำไม DNS ถึง UDP ถึงขีด จำกัด 512 ไบต์


14

ฉันกำลังมองหาคำตอบสำหรับคำถามนั้น (หนึ่งในชื่อเรื่อง) และสิ่งที่ดีที่สุดที่ฉันพบคือ:

ในการออกแบบ DNS Protocol ขนาดบล็อกการส่งผ่าน UDP (ขนาดของข้อมูลโหลด) จำกัด อยู่ที่ 512- ไบต์เพื่อเพิ่มประสิทธิภาพในขณะที่สร้างการรับส่งข้อมูลเครือข่ายน้อยที่สุด

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


5
คำถามนี้ตั้งอยู่บนพื้นฐานของหลักฐานที่ผิดพลาด (อย่างน้อยที่สุดจะเป็นคำถามที่ล้าสมัย) ขีด จำกัด การโหลด 512 ไบต์ไม่มากโปรดดูคำตอบของฉันด้านล่าง
Håkan Lindqvist

คำตอบ:


18

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

มาตรฐาน IPv4ระบุว่าทุกโฮสต์ต้องสามารถที่จะแพ็คเก็ตกันอีกครั้ง 576 ไบต์หรือน้อยกว่า ด้วยส่วนหัว IPv4 (20 ไบต์แม้ว่าจะสูงถึง 60 ไบต์ต่อตัวเลือก) และส่วนหัว UDP 8 ไบต์แพ็คเก็ต DNS ที่มีขนาดบรรจุ 512 ไบต์จะมีขนาดเล็กกว่า 576 ไบต์

ดังที่ @RyanRies พูดว่า: DNS สามารถใช้ TCP สำหรับเพย์โหลดขนาดใหญ่และสำหรับการถ่ายโอนโซนและ DNSSEC มีความหน่วงมากขึ้นเมื่อ TCP เข้ามาเล่นเนื่องจากไม่เหมือนกับ UDP มีการจับมือกันระหว่างไคลเอนต์และเซิร์ฟเวอร์ก่อนที่ข้อมูลจะเริ่มไหล


7
หมายเหตุที่เกี่ยวข้อง: สาเหตุที่มีชื่อตัวแก้ไข DNS รูท 13 ชื่อ (a.root-servers.net ผ่าน m.root-servers.net) จะเป็นเพราะนั่นคือจำนวนสูงสุดที่สามารถตอบสนอง DNS กับแบบสอบถามได้ รูทไม่เกินขีด จำกัด 512 ไบต์ ดังนั้นแม้ว่าเราจะเพิ่มเซิร์ฟเวอร์ที่มีอยู่จริงในโครงสร้างพื้นฐาน DNS หลัก แต่เหตุผลก็คือเซิร์ฟเวอร์หลักสิบสามเครื่องจะยังคงอยู่
phoebus

2
@RyanRies สำหรับ DNSSEC EDNS0 ที่มี payload ที่ใหญ่กว่านั้นเป็นโหมดการทำงานปกติไม่ใช่ TCP
Håkan Lindqvist

1
MTU ที่เล็กที่สุดที่ได้รับอนุญาตไม่ใช่ 576 ไบต์เป็น 68 ไบต์ใน IPv4 และ 1280 ไบต์ใน IPv6
kasperd

1
@phoebus คุณสามารถแสดงให้ฉันเห็นว่าเซิร์ฟเวอร์ 13 เครื่องไม่เกิน 512 ไบต์ในขณะที่เซิร์ฟเวอร์ 14 เครื่องทำอย่างไร การคำนวณที่อยู่เบื้องหลังมันคืออะไร?
Titi Wangsa bin Damhore

1
512 + 60 + 8 = 580 ไบต์ไม่ใช่ 576 ไม่ใช่?
ไม้คาร์โล

12

DNS สมัยใหม่นั้นไม่ได้ จำกัด อยู่ที่ 512 ไบต์ที่โหลดสำหรับ UDP อีกต่อไป

ด้วยการใช้EDNS0สามารถใช้ขนาดส่วนของข้อมูลที่ใหญ่กว่าได้ซึ่งโดยทั่วไปจะเป็นกรณีสำหรับไคลเอ็นต์ที่รับรู้ DNSSEC

การรองรับ payloads ที่ใหญ่กว่า UDP นั้นเป็นดาบสองคม แต่เป็นส่วนหนึ่งของสาเหตุที่การใช้เนมเซิร์ฟเวอร์สำหรับการโจมตีแบบขยายได้กลายเป็นที่นิยมมากขึ้นในขณะที่คุณสามารถขยายสัญญาณได้ดีขึ้นหากผู้โจมตีใช้แบบสอบถามที่ได้รับการตอบสนองมาก .

ดูrfc2671สำหรับรายละเอียด nitty-gritty ของ EDNS0


2
นี่เป็นเรื่องจริง แต่ก็ยังมีเราเตอร์และไฟร์วอลล์ที่ปล่อยแพ็คเก็ต UDP DNS ให้มากกว่า 512 ไบต์
Ryan Ries

2
@ RyanRies ใช่ในขณะที่เป็นพฤติกรรมของหลักสูตรที่ถือว่าไม่ถูกต้องตามมาตรฐานในปัจจุบันมันเป็นสิ่งที่ยังคงเป็นสาเหตุของปัญหา (ในทางทฤษฎีหากมีข้อ จำกัด เช่นนี้เราควรทราบว่าจะกำหนดค่าซอฟต์แวร์ที่เกี่ยวข้องไม่ให้โฆษณาความสามารถในการจัดการ / ไม่ส่งคำตอบที่ใหญ่กว่า)
Håkan Lindqvist

1

การดำเนินการ DNS เช่นการสอบถามและการบำรุงรักษาโซนโดยใช้พอร์ตเริ่มต้น 53 ด้วยเหตุผลด้านประสิทธิภาพการสืบค้นใช้โปรโตคอล UDP ที่มีขนาดบล็อกสูงสุด 512 ไบต์ สามารถเลือกที่จะเจรจาต่อรอง TCP บนพื้นฐานการทำธุรกรรมตามธุรกรรมสำหรับการดำเนินการสืบค้น แต่เนื่องจากค่าใช้จ่ายด้านประสิทธิภาพที่เกิดขึ้นกับ TCP จึงเป็นความสามารถทางทฤษฎี ในอดีตแล้วมักจะหลีกเลี่ยงเกินขีด จำกัด ขนาดการตอบสนอง 512 ไบต์และค่า จำกัด สูงสุดของเซิร์ฟเวอร์ราก IPv4 13 รายการเป็นจำนวนสูงสุดที่สามารถส่งคืนได้ในธุรกรรม UDP ขนาด 512 ไบต์เดียว

Ron Aitchison - Pro DNS และ BIND 10 - 2011


ขอบคุณ เราขอทราบแหล่งที่มาของคำพูด
Pothi Kalimuthu

-2

มันเป็นสิ่งที่ QOS

เนื่องจาก UDP ไม่มีสถานะการจัดการข้อผิดพลาดของแพ็กเก็ตจึงไม่สามารถทำได้

ดังนั้นการรักษาแพ็คเก็ตให้มีขนาดใหญ่ที่สุดจะมีการเปลี่ยนแปลงมากขึ้นพวกเขาจะไปถึงปลายทางลดผลกระทบจากการขาดการจัดการที่ผิดพลาด


แพ็คเก็ตที่มีขนาดใหญ่ไม่ได้หมายความว่า UDP จะล้มเหลวไปยัง TCP ฉันเข้าใจผิดว่าคุณกำลังพูดอะไรอยู่
mfinni

คุณอาจพูดถูก ฉันคิดว่าฉันอ่านมันใน RFC ที่เสนอที่ไหนสักแห่ง
Garreth McDaid

UDP ไม่ได้ล้มเหลว แต่สำหรับ DNS โดยเฉพาะหากการตอบสนองมีขนาดใหญ่เกินกว่าที่จะพอดีเมื่อใช้ UDP สิ่งนี้จะส่งผลให้เกิดการตอบสนองที่ถูกตัดทอน (การตอบสนองที่เกิดขึ้นจริงไม่ได้มีข้อมูลทั้งหมดและตั้งค่าสถานะ ไคลเอ็นต์สามารถลองอีกครั้งโดยใช้ TCP แทน
Håkan Lindqvist
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.