عملية تحليل DNS كاملة — كم خطوة من المتصفح إلى خادم الجذر؟

1. المسار الكامل في 8 خطوات

┌─────────────────────────────────────────────────────────────┐
│  المتصفح (Chrome / Firefox) — كتابة google.com              │
└────────────────┬────────────────────────────────────────────┘
                 │ ① ذاكرة DNS المؤقتة في المتصفح (Chrome ~60s)
                 ↓ غير موجود
┌─────────────────────────────────────────────────────────────┐
│  محلل stub في نظام التشغيل + ذاكرة DNS المؤقتة للنظام       │
└────────────────┬────────────────────────────────────────────┘
                 │ ② غير موجود في ذاكرة النظام → يرسل استعلام UDP إلى جهاز التوجيه
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  تمرير DNS في جهاز التوجيه المنزلي + ذاكرته المؤقتة         │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ غير موجود في ذاكرة جهاز التوجيه → يمرره إلى المحلل العودي لمزود خدمة الإنترنت
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  محلل عودي لمزود الإنترنت أو عام (1.1.1.1 / 8.8.8.8 / 223.5.5.5) │
│  موجود في الذاكرة: يعيد الإجابة مباشرة، وتستغرق العملية كلها 1-5ms │
│  غير موجود: ينتقل إلى مسار «الاستعلام الكامل» أدناه         │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ يسأل NS الجذر: «أين google.com؟»
                 ↓
        13 مجموعة من خوادم أسماء الجذر (a~m.root-servers.net)
                 │ ⑤ يرد: «لا أعرف، اسأل خادم NS للنطاق .com: a.gtld-servers.net»
                 ↓
        خوادم TLD الموثوقة للنطاق .com (Verisign)
                 │ ⑥ يرد: «ليست لدي الإجابة كاملة أيضًا، اسأل خادم NS للنطاق google.com: ns1.google.com»
                 ↓
        الخوادم الموثوقة للنطاق google.com (تديرها Google بنفسها)
                 │ ⑦ يرد: «سجل A للنطاق google.com = 142.250.x.x»
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ يخزن المحلل العودي الإجابة مؤقتًا (وفق TTL)              │
│     ويعيدها إلى العميل — وتحتفظ كل طبقة على طول المسار      │
│     بنسخة خاصة بها أيضًا                                    │
└─────────────────────────────────────────────────────────────┘

فكرة أساسية: في الواقع العملي، لا يكاد المسار الكامل ذو الخطوات الثماني يحدث أبدًا. فعناوين IP للمواقع الكبرى موجودة في الغالب في ذاكرة المحلل العودي المؤقتة، لذا لا يتجاوز المستخدم العادي الخطوة ④ قبل أن يتلقى الإجابة. ولا يمر بالمسار الكامل إلا النطاقات غير المشهورة، أو المواقع نادرة الزيارة، أو عند انتهاء TTL، أو النطاقات المسجلة حديثًا.

2. شرح طبقات التخزين المؤقت الخمس في DNS

عندما صمم DNS عام 1983، أخذ مصمموه في الحسبان حقيقة واحدة: عدد الاستعلامات يفوق عدد التغييرات بمقدار 100,000 ضعف. لذلك يوجد التخزين المؤقت في كل مكان، وتحتفظ كل طبقة بالبيانات طوال مدة TTL (Time To Live).

3. الاستعلام العودي مقابل التكراري — مفاهيم أساسية

3.1 العودي (Recursive)

يقول العميل (المتصفح / محلل stub في نظام التشغيل) للمحلل العودي لدى مزود خدمة الإنترنت: «ابحث لي عن IP للنطاق google.com — ولا يهمني كيف تفعل ذلك.» ويجب على المحلل العودي إتمام عملية الاستعلام كاملة وإعادة النتيجة النهائية.

3.2 التكراري (Iterative)

عندما يتواصل المحلل العودي مع خوادم الجذر وTLD والخوادم الموثوقة، يكون هذا التبادل تكراريًا — فهو يسأل الجذر، فيرد الجذر: «اسأل .com»، فيذهب ويسأل .com، فيرد .com: «اسأل google»، فيذهب ويسأل google. ولا تتجاوز كل خطوة قفزة واحدة — فليس الأمر أن «أسأل الجذر فيتولى الجذر كل شيء نيابة عني».

4. جربه بنفسك — dig +trace

يفرض dig +trace إجراء استعلام تكراري كامل ويعرض كل خطوة:

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

؛ ① القفزة 1 — سؤال الجذر (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 سجلًا من نوع NS للجذر)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

؛ ② القفزة 2 — سؤال TLD للنطاق .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (4 خوادم NS للنطاق .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

؛ ③ القفزة 3 — سؤال الخوادم الموثوقة للنطاق cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

؛ ④ الحصول على الإجابة أخيرًا
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

التفسير:

• استغرقت العملية كلها 5 + 121 + 53 + 12 = 191 ms — فالاستعلام البارد الأول بطيء فعلًا
• لكن الاستعلام عن النطاق نفسه بعد ثانية واحدة لا يستغرق سوى 1-2 ms، لأن الذاكرة المؤقتة العودية لدى مزود خدمة الإنترنت تحتوي عليه بالفعل (TTL مدته 300 ثانية)
• 104.21.x.x / 172.67.x.x عناوين CDN تابعة لشركة Cloudflare — أما IP الخادم الأصلي الحقيقي لموقعنا فمخفي خلف CDN

5. شرح TTL — كم تدوم مدة التخزين المؤقت فعلًا

TTL (Time To Live) هو الحقل الذي يخبر فيه الخادم الموثوق كل محلل عودي: «يمكنك تخزين هذا مؤقتًا لهذه المدة كحد أقصى»، ويقاس بالثواني.

ملاحظة: TTL هو «الحد الأقصى لمدة التخزين المؤقت» — إذ يمكن لأي محلل مسح ذاكرته المؤقتة قبل ذلك، لكنه لا يستطيع تمديدها أبدًا. لذا حتى لو كان TTL على الخادم الموثوق ساعة واحدة، فقد تعيد بعض المحللات الاستعلام بعد 10 دقائق فقط.

فخ شائع: قبل تبديل عنوان IP، قصر TTL أولًا (1-5 دقائق) وانتظر حتى تنتهي مدة TTL القديمة بالكامل قبل التحويل — وإلا فسيظل بعض المستخدمين يصلون إلى IP القديم لأكثر من ساعة.

6. مرجع سريع لأنواع سجلات DNS

7. تحسين DNS — كيف تجعل التحليل أسرع

7.1 اختر محللًا عوديًا قريبًا

في البر الرئيسي الصيني: 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) هما الأسرع في تحليل المواقع داخل الصين. وفي بقية العالم: 1.1.1.1 (Cloudflare، صاحب أوسع انتشار لنقاط Anycast) / 8.8.8.8 (Google). راجعدليل محللات DNS العامة.

7.2 تفعيل DoH (DNS-over-HTTPS)

يمنع تشفير استعلامات DNS عبر HTTPS مزودي خدمة الإنترنت من الاطلاع عليها أو التلاعب بها (ويصد اختطاف NXDOMAIN). تدعمه Chrome وFirefox وEdge جميعها — ما عليك سوى تفعيله من الإعدادات.

7.3 التحليل المسبق (DNS Prefetch)

أضف <link rel="dns-prefetch" href="//api.example.com"> إلى <head> في موقعك ليحلل المتصفح النطاق في أوقات الخمول — وعند حدوث الطلب الفعلي تكون الإجابة جاهزة في الذاكرة المؤقتة.

7.4 استخدم CDN مع NS بتقنية Anycast

ضع خوادم NS الموثوقة على Anycast (Cloudflare / Route 53) ليصل المستخدمون حول العالم إلى أقرب نسخة — مما يخفض زمن الاستجابة في الخطوة ③ من 100ms إلى 10ms.

7.5 اضبط TTL بحكمة

اضبط TTL طويلًا (1-7 أيام) للسجلات نادرة التغيير (NS / MX)؛ واضبط TTL قصيرًا (5-60 دقيقة) لسجلات A التي قد تحتاج إلى التبديل.

8. الأسئلة الشائعة

8.1 غيرت DNS لكن لم يحدث شيء — لماذا؟

فكر أولًا في قيمة TTL الحالية. بعد تغيير DNS، سيواصل كل محلل عودي إعادة IP القديم حتى تنتهي مدة TTL القديمة. ويستغرق «الانتشار العالمي» عمومًا نحو ضعف مدة TTL (لمراعاة عدم تزامن المحللات فيما بينها).

• على جهاز العميل: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• انتظار انتهاء صلاحية الذاكرة المؤقتة لمحلل عودي عام: يوفر كل من 1.1.1.1 / 8.8.8.8 أداة «purge» خاصة به لمسحها يدويًا

8.2 بعض المستخدمين يصلون إلى الموقع وآخرون لا — تلويث DNS

شائع عند الوصول إلى مواقع خارجية من البر الرئيسي الصيني — بسبب حقن GFW استجابات DNS مزيفة / واختطاف مزودي خدمة الإنترنت للاستعلامات. ويمكن بالتحول إلى DoH (DNS مشفر في المتصفح) تجاوز معظم حالات تلويث DNS.

8.3 متى يمكنني استخدام النطاق بعد تسجيله؟

بعد التسجيل، تدفع جهة تسجيل TLD سجلات NS الخاصة بك إلى الخوادم الموثوقة للنطاقات العليا مثل .com / .net وغيرها — ويستغرق ذلك عادةً من 15 دقيقة إلى 24 ساعة. وقد تتطلب نطاقات .cn / .com.cn الحصول على ترخيص ICP قبل أن يتسنى تحليلها داخل البر الرئيسي الصيني.