ทำไมทั่วโลกจึงมี root server เพียง 13 กลุ่ม?

1. ข้อจำกัดตายตัวของโปรโตคอล: 512 ไบต์

1.1 MTU ของ IPv4 และ UDP แบบไม่แบ่งแฟรกเมนต์

เครือข่าย ARPANET / IPv4 ยุคแรกกำหนดให้ MTU ขั้นต่ำคือ 576 ไบต์ โฮสต์ทุกเครื่องต้องรับแพ็กเก็ตขนาดนี้ได้ ไม่เช่นนั้นจะรับประกันแม้แต่การเชื่อมต่อถึงกันขั้นพื้นฐานไม่ได้ (RFC 791)

Total Length is the length of the datagram, measured in octets,
including internet header and data.  This field allows the length of
a datagram to be up to 65,535 octets.  Such long datagrams are
impractical for most hosts and networks.  All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments).  It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

• ความยาวรวม 576 ไบต์ − IP header ปกติ 20 ไบต์ − UDP header 8 ไบต์ ≈ ใช้ได้ 548 ไบต์ (หาก IP header มี options อาจยาวถึง 60 ไบต์ ทำให้เหลือน้อยลง)
• RFC 1035 § 4.2.1 เลือกค่ากำลังของ 2 ที่อนุรักษ์นิยมกว่า คือ 512 ไบต์ เป็นเพดานตายตัวของ DNS over UDP — ปลอดภัยแม้ IP header จะมี options เต็มที่
• หากคำตอบ UDP เกิน 512 ไบต์ จะต้องถูกตัดทอน (truncate) และตั้งแฟล็ก TC เพื่อบังคับให้ไคลเอนต์ fallback ไปใช้ TCP — และ three-way handshake ของ TCP ทำให้ความหน่วงของการ resolve ครั้งแรกเพิ่มขึ้นหลายเท่า

กล่าวคือ “รายชื่อ root server ทั้งหมดต้องใส่ได้ในแพ็กเก็ต UDP ขนาด 512 ไบต์เพียงแพ็กเก็ตเดียว” — ไม่เช่นนั้นการสอบถาม root ทุกครั้งทั่วโลกต้องวิ่งผ่าน TCP ซึ่งบนฮาร์ดแวร์ยุค 1980 แทบจะเท่ากับหายนะ

1.2 โครงสร้างไบต์ของข้อความ DNS

โครงสร้างคำตอบทั้งหมดเมื่อสอบถามเรคคอร์ด NS ของ . (เซิร์ฟเวอร์ส่งเรคคอร์ด NS ของ root ทั้งหมดพร้อม glue record ประเภท A กลับมา):

Header   (12 ไบต์)

สูตรความยาวรวม:

แทนค่าเพดาน 512 ไบต์:

ในทางทฤษฎีจะได้สูงสุด 15 กลุ่ม แต่ต้องเผื่อพื้นที่ไว้สำหรับลายเซ็น DNSSEC เรคคอร์ดเทียม EDNS0 OPT และ padding ของฟิลด์ จึงลงตัวที่ 13 กลุ่ม — RFC 2010 (1996) วางเกณฑ์การดำเนินงานของ root server ไว้ และจำนวนนี้ไม่เคยเปลี่ยนอีกเลยนับตั้งแต่ M-root เริ่มให้บริการในปีถัดมา

1.3 ลองทดสอบเอง — <code>dig +noedns -t ns .</code> ได้คำตอบประมาณ 490–510 ไบต์

นั่นคือทฤษฎี ทีนี้ลองสอบถาม root server จริง ๆ ด้วย dig แล้วดูว่าคำตอบจริงมีขนาดเท่าไร:

$ dig +noedns -t ns .

; <<>> DiG 9.10.6 <<>> +noedns -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35973
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                                IN      NS

;; ANSWER SECTION:
.                       430502  IN      NS      a.root-servers.net.
.                       430502  IN      NS      b.root-servers.net.
…  (มีเรคคอร์ด NS ทั้งหมด 13 รายการ ละ c–l ไว้)
.                       430502  IN      NS      m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     516909  IN      A       198.41.0.4
b.root-servers.net.     562547  IN      A       170.247.170.2
…  (glue record ประเภท A ทั้ง 13 รายการใส่ได้ครบ)
m.root-servers.net.     516941  IN      A       202.12.27.33
a.root-servers.net.     516930  IN      AAAA    2001:503:ba3e::2:30
b.root-servers.net.     562547  IN      AAAA    2801:1b8:10::b
↑ ใส่เรคคอร์ด AAAA ได้แค่ 2 รายการ — แพ็กเก็ตเต็มแล้ว

;; Query time: 8 msec
;; SERVER: 192.168.1.1#53
;; MSG SIZE  rcvd: 492

บรรทัดสำคัญอยู่ท้ายสุด — คำตอบมีขนาดรวมประมาณ 490–510 ไบต์ ต่ำกว่า 512 อย่างสบาย ๆ (ตัวเลขที่แน่นอนขึ้นอยู่กับว่าคุณถาม root ตัวไหน และได้ glue record ของ IPv6 กลับมากี่รายการ) — ตรงกับงบประมาณไบต์ข้างต้น สังเกตแฟล็ก +noedns: dig ส่ง EDNS0 ไปเป็นค่าเริ่มต้น ซึ่งจะได้คำตอบเกิน 800 ไบต์ไปมาก นี่คือเหตุผลที่ 512 ไบต์เลิกเป็นข้อจำกัดตายตัวเมื่อ EDNS0 แพร่หลาย — แต่ถึงตอนนั้นตัวเลข 13 ก็ถูกล็อกไว้แล้ว

2. ตัวเลข 13 มาจากไหน? ประวัติโดยย่อ

ตัวเลขนี้ไม่ได้ถูกกำหนดไว้ตั้งแต่แรก จำนวน root server ผ่านการขยายมาหลายครั้ง และหลังจาก M-root (WIDE ญี่ปุ่น) เริ่มให้บริการในปี 1997 ก็ไม่เคยเปลี่ยนอีกเลย:

เมื่อจำนวนถูกล็อกไว้ที่ 13 แล้ว ชื่อตัวอักษร A ถึง M ก็ไม่เคยเปลี่ยน — มีเพียงการอัปเกรดฮาร์ดแวร์และเพิ่มมิเรอร์ anycast ไฟล์ root hint ของอินเทอร์เน็ต (named.root) ถูกฝังอยู่ในโค้ดของ recursive resolver และ stub client หลายพันล้านตัวมานานแล้ว การเปลี่ยนตัวเลขเพียงตัวเดียวจึงหมายถึงการอัปเกรดอินเทอร์เน็ตทั้งโลก

3. แต่ทั่วโลกมีเครื่องเพียง 13 เครื่องจริงหรือ?

ไม่ใช่ นี่คือความเข้าใจผิดที่พบบ่อยที่สุด “root server 13 กลุ่ม” หมายถึง ชื่อ NS 13 ชื่อ (a–m.root-servers.net) ซึ่งแต่ละชื่อผูกกับที่อยู่ IPv4 หนึ่งที่อยู่และ IPv6 หนึ่งที่อยู่ — ไม่ใช่เครื่องจริง 13 เครื่อง

เบื้องหลัง IP แต่ละตัวคือ คลัสเตอร์ anycast — ที่อยู่ IP เดียวกันถูกประกาศผ่าน BGP พร้อมกันจากดาต้าเซ็นเตอร์หลายร้อยแห่งทั่วโลก และคำขอ DNS ของผู้ใช้จะถูกส่งไปยังมิเรอร์ที่ใกล้ที่สุดตาม RTT เมื่อมีข่าวว่า root server “ล่ม” ส่วนใหญ่หมายถึงมิเรอร์ในเมืองหนึ่งกำลังปิดปรับปรุง — การ resolve ทั่วโลกไม่ได้รับผลกระทบ

สถานะของ root server 13 กลุ่มในปี 2024

จีนแผ่นดินใหญ่ (ปักกิ่ง เซี่ยงไฮ้ เซินเจิ้น กวางโจว เหอเฝย์ และอื่น ๆ) มีโหนดมิเรอร์ anycast ของ root server หลายกลุ่ม รวมถึง F / I / J / K / L และ RTT ที่วัดได้จริงจากในจีนไปยัง root server มักต่ำกว่า 20ms

4. หลังมี EDNS0 ตัวเลข 512 ไบต์ก็ไม่ใช่ข้อจำกัดจริงอีกต่อไป

คุณอาจสงสัยว่า ทุกวันนี้แพ็กเก็ต DNS ขนาด 4KB ขึ้นไปเป็นเรื่องปกติ แล้วทำไมไม่ “ทะลุ 13” ไปเลย?

• EDNS0 (RFC 2671 ปี 1999 ฉบับปัจจุบันคือ RFC 6891) — เจรจาขนาดเพย์โหลด UDP ที่ใหญ่ขึ้นได้ (ปกติ 4096 ไบต์) และ resolver สมัยใหม่ทุกตัวรองรับ
• DNSSEC บังคับใช้ EDNS0 เพราะข้อมูลลายเซ็นอย่างเดียวก็เกิน 512 ไบต์ไปมากแล้ว
• TCP fallback — ปัจจุบัน three-way handshake ของ TCP รวมกับ TLS / cookies มีต้นทุนต่ำแล้ว

แต่รายชื่อ root server ตอนนี้เป็น ฉันทามติของทั้งเครือข่าย: recursive resolver ทุกตัวบนโลกฮาร์ดโค้ด 13 กลุ่มนี้ไว้ในไฟล์ hint (named.root) และเบื้องหลัง resolver เหล่านั้นคืออุปกรณ์ปลายทางหลายพันล้านเครื่อง แรงจูงใจในการเปลี่ยนเป็นศูนย์ ส่วนความเสี่ยงคืออินเทอร์เน็ตทั่วโลกแตกเป็นเสี่ยง ตัวเลขนี้จึงแทบแน่นอนว่าจะเป็น 13 ตลอดไป

สรุปสั้น ๆ: “13 กลุ่ม” ล้าสมัยในทางกายภาพมานานแล้ว แต่ในทางวิศวกรรมไม่อาจเปลี่ยนได้

5. ประเด็นสำคัญ

1. เหตุผลทางประวัติศาสตร์: เพดาน 512 ไบต์ของ DNS over UDP → เพดานทางคณิตศาสตร์ 15 กลุ่ม → เลือก 13 กลุ่มเพื่อเผื่อพื้นที่ และตายตัวตั้งแต่ M-root เริ่มให้บริการในปี 1997
2. ความเฉื่อยของโปรโตคอล: การอัปเกรดไฟล์ hint บนอุปกรณ์ปลายทางหลายพันล้านเครื่องเป็นไปไม่ได้ในทางปฏิบัติ จึงไม่มีวันเปลี่ยน
3. ขีดความสามารถจริง: มีโหนดมิเรอร์ anycast 1395+ โหนด ทำให้ความเสี่ยงจากจุดล้มเหลวเดียวแทบเป็นศูนย์
4. เข้าถึงได้จากจีน: root server หลายกลุ่ม รวมถึง F / I / J / K / L มีมิเรอร์ในจีนแผ่นดินใหญ่ โดยวัด RTT ได้จริง < 20ms