خلاصه
پروتکل DNS در اصل برای اجرا روی IPv4 + UDP طراحی شد که در آن حداکثر بار مفید UDP بدون قطعه‌قطعه شدن 512 بایت است. فهرست سرورهای نام ریشه باید در یک بسته پاسخ UDP جا شود (تا از بازگشت به TCP که تأخیر و پیچیدگی می‌افزاید جلوگیری شود). با محاسبه معکوس از ساختار بایتی پیام DNS، حداکثر تعداد سرور ریشه‌ای که جا می‌شود 13 است. این عدد به این دلیل انتخاب نشده که «همین کافی بود» — بلکه سقف سخت پروتکل از سال 1995 است که برای سازگاری با میلیاردها دستگاه پایانی تا امروز بدون تغییر مانده است.
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 معمول 20 بایتی − هدر UDP هشت‌بایتی ≈ 548 بایت قابل استفاده (با گزینه‌های IP، هدر می‌تواند به 60 بایت برسد و فضای کمتری باقی می‌ماند)
- RFC 1035 § 4.2.1 توان دوی محافظه‌کارانه‌تر، یعنی 512 بایت، را به‌عنوان سقف سخت DNS روی UDP برگزید — که حتی وقتی هدر IP همه گزینه‌ها را حمل کند نیز امن است
- اگر پاسخ UDP از 512 بایت بیشتر شود، باید با تنظیم پرچم TC کوتاه شود و کلاینت را مجبور به بازگشت به TCP کند — و دست‌دهی سه‌مرحله‌ای TCP تأخیر نخستین تفکیک نام را چند برابر می‌کند
به بیان دیگر، «فهرست کامل سرورهای ریشه باید در یک بسته UDP با 512 بایت جا شود» — وگرنه هر استعلام ریشه در سراسر جهان باید از طریق TCP انجام می‌شد که روی سخت‌افزار دهه 1980 تقریباً فاجعه‌بار بود.
1.2 ساختار بایتی پیام DNS
ساختار کامل پاسخ برای استعلام رکوردهای NS مربوط به . (سرور همه رکوردهای NS ریشه به‌همراه رکوردهای A چسب را برمی‌گرداند):
Header (12 bytes)فرمول طول کل:
L(N) = 12 + 5 + 31 + 15(N-1) + 16N = 31N + 33با جای‌گذاری محدودیت 512 بایت:
31N + 33 ≤ 512 ⇒ N ≤ 15.45از نظر تئوری این امکان تا 15 گروه را می‌دهد، اما باید برای امضاهای DNSSEC، شبه‌رکورد EDNS0 OPT و پرکردن فیلدها فضای اضافه گذاشت؛ از این رو روی 13 گروه ثابت شد — RFC 2010 (1996) معیارهای عملیاتی سرورهای ریشه را تعیین کرد و از زمان راه‌اندازی M-root در سال بعد، این تعداد تغییر نکرده است.
1.3 خودتان آزمایش کنید — <code>dig +noedns -t ns .</code> حدود 490–510 بایت برمی‌گرداند
این تئوری بود. حالا واقعاً با 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.
… (در مجموع 13 رکورد NS، 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
… (هر 13 رکورد glue از نوع A جا شدند)
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
↑ فقط 2 رکورد AAAA جا شد — بسته پر شده است
;; Query time: 8 msec
;; SERVER: 192.168.1.1#53
;; MSG SIZE rcvd: 492
خط کلیدی در انتها — اندازه کل پاسخ حدود 490–510 بایت است که به‌راحتی زیر 512 قرار می‌گیرد (عدد دقیق به اینکه از کدام ریشه بپرسید و چند رکورد چسب IPv6 برگردد بستگی دارد) — با بودجه بایتی بالا مطابقت دارد. به پرچم +noedns توجه کنید: dig به‌طور پیش‌فرض EDNS0 ارسال می‌کند که پاسخی بسیار بیش از 800 بایت برمی‌گرداند. دقیقاً به همین دلیل، پس از همه‌گیر شدن EDNS0، دیگر 512 بایت محدودیت سختی نبود — اما عدد 13 تا آن زمان قطعی شده بود.
2. عدد 13 از کجا آمده؟ تاریخچه‌ای کوتاه
این عدد از ابتدا ثابت نبود. تعداد سرورهای ریشه چندین بار افزایش یافت؛ پس از راه‌اندازی M-root (WIDE، ژاپن) در سال 1997، دیگر هرگز تغییر نکرد:
| سال | تعداد | رویداد کلیدی |
|---|---|---|
| 1984 | 4 | طراحی اولیه پروتکل DNS؛ همه سرورها در آمریکا |
| 1991 | 7 | افزوده شدن گره‌های دانشگاهی / وزارت دفاع آمریکا |
| 1995 | 9 | پیوستن RIPE NCC (K-root) — نخستین در اروپا |
| 1997 | 13 | پیوستن WIDE Project (M-root) — نخستین در آسیا، تعداد قطعی شد |
| 2007 | 13 | پشتیبانی دوپشته IPv6 افزوده شد، اما «تعداد گروه‌های» IP بدون تغییر ماند |
| 2023 | 13 | USC-ISI آدرس IP مربوط به B-root را به 170.247.170.2 منتقل کرد (IP قدیمی 199.9.14.201 بازنشسته شد) |
پس از قطعی شدن در 13، نام‌های حرفی A تا M هرگز تغییر نمی‌کنند — فقط سخت‌افزار ارتقا می‌یابد و آینه‌های Anycast اضافه می‌شوند. فایل root hint اینترنت (named.root) مدت‌هاست در کد میلیاردها ریزالور بازگشتی و کلاینت stub جاسازی شده است؛ تغییر حتی یک عدد به معنای ارتقای کل اینترنت است.
3. اما آیا واقعاً فقط 13 دستگاه در سراسر جهان وجود دارد؟
خیر. این رایج‌ترین تصور نادرست است. «13 گروه سرور ریشه» به 13 نام NS (a–m.root-servers.net) اشاره دارد که هر کدام به یک آدرس IPv4 و یک آدرس IPv6 نگاشت می‌شوند — نه 13 دستگاه فیزیکی.
پشت هر IP یک خوشه Anycast قرار دارد — همان آدرس IP به‌طور هم‌زمان توسط صدها دیتاسنتر در سراسر جهان از طریق BGP اعلام می‌شود و استعلام DNS کاربر بر اساس RTT به نزدیک‌ترین آینه هدایت می‌شود. وقتی یک سرور ریشه «از کار می‌افتد»، معمولاً فقط آینه یک شهر در حال نگهداری است — تفکیک نام جهانی تحت تأثیر قرار نمی‌گیرد.
وضعیت 13 گروه سرور ریشه در 2024
| حرف | اپراتور | IPv4 | IPv6 | آینه‌های Anycast |
|---|---|---|---|---|
| A | Verisign, Inc. | 198.41.0.4 | 2001:503:ba3e::2:30 | 53 |
| B | Information Sciences Institute (USC) | 170.247.170.2 | 2801:1b8:10::b | 6 |
| C | Cogent Communications | 192.33.4.12 | 2001:500:2::c | 12 |
| D | University of Maryland | 199.7.91.13 | 2001:500:2d::d | 187 |
| E | NASA Ames Research Center | 192.203.230.10 | 2001:500:a8::e | 254 |
| F | Internet Systems Consortium | 192.5.5.241 | 2001:500:2f::f | 274 |
| G | US DOD Network Information Center | 192.112.36.4 | 2001:500:12::d0d | 6 |
| H | US Army Research Laboratory | 198.97.190.53 | 2001:500:1::53 | 17 |
| I | Netnod | 192.36.148.17 | 2001:7fe::53 | 75 |
| J | Verisign, Inc. | 192.58.128.30 | 2001:503:c27::2:30 | 168 |
| K | RIPE NCC | 193.0.14.129 | 2001:7fd::1 | 113 |
| L | ICANN | 199.7.83.42 | 2001:500:9f::42 | 218 |
| M | WIDE Project | 202.12.27.33 | 2001:dc3::35 | 12 |
| مجموع آینه‌های Anycast (2024) | 1395 | |||
چین اصلی (پکن، شانگهای، شن‌جن، گوانگجو، هفی و دیگر شهرها) میزبان گره‌های آینه Anycast برای چندین سرور ریشه از جمله F / I / J / K / L است؛ RTT اندازه‌گیری‌شده تا سرورهای ریشه از داخل چین معمولاً کمتر از 20ms است.
4. پس از EDNS0، دیگر 512 بایت محدودیت واقعی نبود
شاید بپرسید: امروزه بسته‌های DNS با حجم 4KB یا بیشتر رایج‌اند، پس چرا «از 13 فراتر نرویم»؟
- EDNS0 (RFC 2671 در 1999، اکنون RFC 6891) — بار مفید UDP بزرگ‌تری را مذاکره می‌کند (معمولاً 4096 بایت) و همه ریزالورهای مدرن از آن پشتیبانی می‌کنند
- DNSSEC استفاده از EDNS0 را الزامی می‌کند، زیرا داده‌های امضا به‌تنهایی بسیار بیش از 512 بایت است
- بازگشت به TCP — دست‌دهی سه‌مرحله‌ای TCP مدرن به‌همراه TLS / کوکی‌ها اکنون کم‌هزینه است
اما فهرست سرورهای ریشه اکنون یک اجماع در سطح کل شبکه است: هر ریزالور بازگشتی روی زمین این 13 گروه را در فایل hint خود (named.root) به‌صورت ثابت دارد و پشت این ریزالورها میلیاردها دستگاه پایانی قرار دارند. انگیزه تغییر صفر است و ریسک آن، از هم گسستن اینترنت جهانی؛ بنابراین این عدد تقریباً به‌طور قطع برای همیشه 13 باقی می‌ماند.
به‌طور خلاصه: «13 گروه» از نظر فیزیکی مدت‌هاست منسوخ شده، اما از نظر مهندسی کنار گذاشتنش ناممکن است.
5. نکات کلیدی
- دلیل تاریخی: محدودیت 512 بایتی DNS روی UDP ← سقف ریاضی 15 گروه ← انتخاب 13 با حاشیه اطمینان، ثابت‌شده پس از راه‌اندازی M-root در 1997
- اینرسی پروتکل: ارتقای فایل‌های hint روی میلیاردها دستگاه پایانی عملی نیست، پس هرگز تغییر نمی‌کند
- ظرفیت واقعی: بیش از 1395 گره آینه Anycast، که ریسک خرابی تک‌نقطه‌ای را تقریباً به صفر می‌رساند
- دسترس‌پذیری از چین: چندین سرور ریشه از جمله F / I / J / K / L در چین اصلی آینه دارند و RTT اندازه‌گیری‌شده <؛ 20ms است
مطالعه بیشتر
- Tencent Cloud (سرویس ابری Tencent): چرا در سراسر جهان فقط 13 گروه سرور نام ریشه وجود داردمنبع مرجع محاسبات طول بایتی پروتکل در این مقاله
- فهرست رسمی سرورهای ریشه IANAمنبع معتبر برای اپراتورها / IPها / تعداد آینه‌های Anycast
- نقشه زنده توزیع آینه‌ها در root-servers.orgآمار لحظه‌ای تعداد آینه‌ها در سراسر جهان
- RFC 1035 § 4.2.1 — DNS UDP usage متن اصلی محدودیت 512 بایت
- RFC 6891 — Extension Mechanisms for DNS (EDNS0) چگونه از 512 بایت فراتر رفت