دنیا بھر میں روٹ نیم سرورز کے صرف 13 گروپ کیوں ہیں؟

1۔ پروٹوکول کی سخت حد: 512 بائٹس

1.1 IPv4 MTU اور فریگمنٹیشن کے بغیر 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 بائٹ کل لمبائی − عام 20 بائٹ IP ہیڈر − 8 بائٹ UDP ہیڈر ≈ 548 بائٹس قابل استعمال (IP آپشنز کے ساتھ ہیڈر 60 بائٹ تک ہو سکتا ہے، جس سے گنجائش اور کم رہ جاتی ہے)
• RFC 1035 § 4.2.1 نے زیادہ محتاط قدر، یعنی 2 کی طاقت 512 بائٹس کو UDP پر DNS کی سخت حد مقرر کیا — جو IP ہیڈر میں تمام آپشنز ہونے پر بھی محفوظ ہے
• اگر UDP جواب 512 بائٹس سے بڑا ہو تو اسے کاٹ کر TC فلیگ سیٹ کرنا لازمی ہے، جس سے کلائنٹ TCP پر منتقل ہوتا ہے — اور TCP کا تھری وے ہینڈ شیک پہلی ریزولوشن کی لیٹنسی کو کئی گنا بڑھا دیتا ہے

یعنی «روٹ سرورز کی مکمل فہرست کا ایک ہی 512 بائٹ UDP پیکٹ میں سمانا ضروری ہے» — ورنہ دنیا بھر کی ہر روٹ کوئری کو TCP پر جانا پڑتا، جو 1980 کی دہائی کے ہارڈویئر پر تقریباً تباہ کن ہوتا۔

1.2 DNS پیغام کی بائٹ ساخت

جب . کے NS ریکارڈز کی کوئری کی جائے تو مکمل جواب کا ڈھانچہ یہ ہوتا ہے (سرور تمام روٹ NS ریکارڈز اور گلو A ریکارڈز لوٹاتا ہے):

Header   (12 bytes)

کل لمبائی کا فارمولا:

512 بائٹ کی حد رکھنے پر:

نظریاتی طور پر اس سے زیادہ سے زیادہ 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 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 کہاں سے آیا؟ مختصر تاریخ

یہ تعداد شروع سے طے نہیں تھی۔ روٹ سرورز کی تعداد میں کئی بار اضافہ ہوا؛ 1997 میں M-root (WIDE، جاپان) کے فعال ہونے کے بعد یہ پھر کبھی نہیں بدلی:

13 پر طے ہونے کے بعد A سے M تک کے حرفی نام کبھی نہیں بدلتے — صرف ہارڈویئر اپ گریڈ ہوتا ہے اور اینی کاسٹ مررز بڑھتے ہیں۔ انٹرنیٹ کی روٹ ہنٹ فائل (named.root) عرصے سے اربوں ریکرسیو ریزالورز اور stub کلائنٹس کے کوڈ میں شامل ہے؛ ایک عدد بدلنے کا مطلب پورے انٹرنیٹ کو اپ گریڈ کرنا ہو گا۔

3۔ لیکن کیا دنیا بھر میں واقعی صرف 13 مشینیں ہیں؟

نہیں۔ یہ سب سے عام غلط فہمی ہے۔ «13 روٹ سرور گروپس» سے مراد 13 NS نام (a–m.root-servers.net) ہیں، جن میں سے ہر ایک کا ایک IPv4 اور ایک IPv6 ایڈریس ہے — 13 فزیکل مشینیں نہیں۔

ہر IP کے پیچھے ایک اینی کاسٹ کلسٹر ہوتا ہے — ایک ہی IP ایڈریس دنیا بھر کے سینکڑوں ڈیٹا سینٹرز سے بیک وقت BGP کے ذریعے اعلان کیا جاتا ہے، اور صارف کی DNS کوئری RTT کے لحاظ سے قریب ترین مرر تک روٹ ہوتی ہے۔ جب کوئی روٹ سرور «ڈاؤن» ہوتا ہے تو عموماً اس کا مطلب صرف یہ ہوتا ہے کہ کسی ایک شہر کا مرر مینٹیننس میں ہے — عالمی ریزولوشن متاثر نہیں ہوتی۔

2024 میں 13 روٹ سرور گروپس کی صورتحال

مین لینڈ چین (بیجنگ، شنگھائی، شینزین، گوانگژو، ہیفے وغیرہ) میں F / I / J / K / L سمیت کئی روٹ سرورز کے اینی کاسٹ مرر نوڈز موجود ہیں؛ چین کے اندر سے روٹ سرورز تک ناپا گیا RTT عموماً 20ms سے کم ہوتا ہے۔

4۔ EDNS0 کے بعد 512 بائٹس حقیقی حد نہیں رہی

آپ پوچھ سکتے ہیں: آج کل 4KB یا اس سے بڑے DNS پیکٹ عام ہیں، تو پھر «13 کی حد» کیوں نہیں توڑی جاتی؟

• EDNS0 (1999 میں RFC 2671، موجودہ RFC 6891) — بڑے UDP پے لوڈ (عام طور پر 4096 بائٹس) پر باہمی اتفاق کرتا ہے، اور ہر جدید ریزالور اسے سپورٹ کرتا ہے
• DNSSEC کے لیے EDNS0 لازمی ہے، کیونکہ صرف دستخطوں کا ڈیٹا ہی 512 بائٹس سے کہیں زیادہ ہوتا ہے
• TCP فال بیک — جدید TCP تھری وے ہینڈ شیک اور TLS / کوکیز اب سستے ہیں

لیکن روٹ سرور کی فہرست اب ایک پورے نیٹ ورک کا اتفاق رائے ہے: دنیا کا ہر ریکرسیو ریزالور اپنی ہنٹ فائل (named.root) میں یہ 13 گروپ ہارڈ کوڈ کرتا ہے، اور ان ریزالورز کے پیچھے اربوں ڈیوائسز ہیں۔ بدلنے کی ترغیب صفر ہے، اور خطرہ عالمی انٹرنیٹ کے ٹوٹ جانے کا ہے، اس لیے یہ تعداد تقریباً یقینی طور پر ہمیشہ 13 ہی رہے گی۔

مختصر یہ کہ: «13 گروپ» فزیکل لحاظ سے کب کے فرسودہ ہو چکے، لیکن انجینئرنگ کے لحاظ سے انہیں بدلنا ناممکن ہے۔

5۔ اہم نکات

1. تاریخی وجہ: UDP پر DNS کی 512 بائٹ حد ← ریاضیاتی طور پر 15 گروپوں کی حد ← گنجائش رکھ کر 13 کا انتخاب، جو 1997 میں M-root کے فعال ہونے پر طے ہو گیا
2. پروٹوکول کا جمود: اربوں ڈیوائسز پر ہنٹ فائلز اپ گریڈ کرنا ناقابل عمل ہے، اس لیے یہ کبھی نہیں بدلتی
3. حقیقی گنجائش: 1395+ اینی کاسٹ مرر نوڈز، جس سے کسی ایک نقطے پر ناکامی کا خطرہ تقریباً صفر ہے
4. چین سے رسائی: F / I / J / K / L سمیت کئی روٹ سرورز کے مررز مین لینڈ چین میں ہیں، اور ناپا گیا RTT <؛ 20ms ہے