حل أسماء النطاقات من البداية إلى النهاية

في كل مرة تكتب اسم نطاق في المتصفح، تنطلق سلسلة من عمليات البحث قبل وصول حتى حزمة واحدة إلى الموقع الذي تريده. معظم هذه السلسلة غير مرئي، ومعظم الشروحات تتوقف عند "إنه مثل دليل الهاتف". إليك ما يحدث فعلياً، خطوة بخطوة، بما فيه الأجزاء التي يتخطاها الناس عادة.

stub resolver ليس ذكياً

نظام التشغيل الخاص بك لا يقوم بحل DNS حقيقي من تلقاء نفسه. يشغّل stub resolver، وهي قطعة كود رقيقة تقوم فقط بإعادة توجيه استعلامك إلى أي خادم DNS مكون في /etc/resolv.conf على Linux أو في إعدادات بطاقة الشبكة على Windows. تحقق من إعداداتك باستخدام:

cat /etc/resolv.conf

عادة ما يشير هذا الملف إلى جهاز التوجيه الخاص بك (مثل 192.168.1.1)، أو resolver مزود الخدمة، أو واحد عام مثل 1.1.1.1 أو 8.8.8.8. لا يمتلك stub resolver أي منطق تخزين مؤقت خاص به إلا ما يوفره نظام التشغيل أو daemon محلي مثل systemd-resolved.

recursive resolver يقوم بالعمل الحقيقي

عندما يصل استعلامك إلى recursive resolver، يتولى هذا الخادم مهمة البحث عن الإجابة، حتى لو اضطر للسؤال عدة خوادم أخرى للوصول إليها. إذا كانت الإجابة مخزنة مؤقتاً بالفعل من بحث سابق، تحصل عليها على الفور. تحقق من TTL باستخدام:

dig example.com

انظر إلى ANSWER SECTION — الرقم قبل نوع السجل (مثل 300 قبل A) هو TTL بالثواني. هذا هو الوقت المسموح به للـ resolvers لتخزين السجل مؤقتاً قبل السؤال مرة أخرى.

إذا لم يكن هناك شيء مخزن مؤقتاً، يبدأ recursive resolver بالسير في هرمية DNS من الجذر.

خوادم الجذر وخوادم TLD والخوادم الموثوقة

هناك 13 عنوان خادم جذر (من a.root-servers.net إلى m.root-servers.net)، كل منها مدعوم بآلات فيزيائية متعددة من خلال توجيه anycast. خادم الجذر لا يعرف أين يوجد example.com، لكنه يعرف أي خوادم تتعامل مع .com، فيرسل إجابة تحيل.

ثم يسأل resolver خادم TLD .com، الذي بدوره لا يعرف الإجابة النهائية لكنه يعرف أي nameservers موثوقة لـ example.com تحديداً. يمكنك رؤية هذا التفويض بنفسك:

dig +trace example.com

هذا الأمر يوضح كل قفزة: الجذر، ثم TLD، ثم nameservers الموثوقة للنطاق، منتهياً بسجل A أو AAAA الفعلي. إنه أفضل أمر لفهم DNS بصرياً بدلاً من نظرياً.

خادم الاسم الموثوق هو المحطة الأخيرة. إنه الخادم الذي كونه مالك النطاق فعلياً، غالباً من خلال لوحة DNS الخاصة بمسجل النطاق أو خدمة مثل Route 53 أو Cloudflare DNS. هذا هو الخادم الوحيد في السلسلة كلها الذي يمتلك الإجابة الحقيقية والقانونية بدلاً من نسخة مخزنة مؤقتاً أو إجابة تحيل.

أنواع السجلات التي ستواجهها

سجل A يربط اسماً بعنوان IPv4، AAAA يفعل الشيء ذاته لـ IPv6. CNAME يوجه اسماً إلى اسم آخر وليس إلى IP، وهي كيفية توجيه CDNs مثل Cloudflare أو Fastly حركة المرور دون الكشف عن IPs الخام. سجلات MX تتعامل مع توجيه البريد، وسجلات TXT تحمل نصاً عشوائياً، تُستخدم الآن غالباً لـ SPF و DKIM وسلاسل التحقق من النطاق. سجلات NS تخبر العالم أي خوادم موثوقة لمنطقة ما، وهو نوع السجل الذي يجعل التفويض ممكناً في المقام الأول.

حيث يعيش التخزين المؤقت فعلياً

يحدث التخزين المؤقت في طبقات متعددة في نفس الوقت: المتصفح نفسه (Chrome لديه cache DNS خاص به قابل للعرض في chrome://net-internals/#dns)، cache resolver نظام التشغيل، جهاز التوجيه المحلي، و recursive resolver في المنبع. هذا هو السبب في أن تغيير DNS قد يظهر أنه يعمل بسرعة على جهاز واحد ويستغرق ساعات للظهور على جهاز آخر — أنت لا تستخدم نفس cache.

عندما تخفّض TTL سجل قبل هجرة مخطط لها، أنت لا تسرع شيئاً على الفور. أنت فقط تقلل النافذة الزمنية التي قد تستمر فيها البيانات القديمة في الوجود بمجرد حدوث التغيير فعلياً. افعل هذا قبل دورة TTL واحدة على الأقل، لا قبل خمس دقائق من التحويل.

لماذا يهم هذا للبحث عن المشاكل

عندما يكون الموقع غير قابل للوصول، dig +trace يخبرك بالضبط أي طبقة مكسورة: مشكلة جذر/TLD تبدو مختلفة تماماً عن خادم موثوق مكون بشكل خاطئ أو cache قديم على جهازك الخاص. مقارنة dig example.com مقابل resolver معروف أنه جيد، مثل dig example.com @1.1.1.1، تحدد ما إذا كانت المشكلة في resolver المحلي أم في إعداد DNS الفعلي للنطاق.

DNS يبدو بسيطاً من الخارج لأنه عادة ما ينحل في أقل من 100ms ولا أحد يفكر فيه. تحتيه، إنها نظام استعلام موزع ومخزن مؤقتاً وهرمي كان يعمل دون تغيير كبير في البنية منذ الثمانينات، وهي حجة جيدة جداً لمدى جودة الاحتفاظ التصميم الأصلي به.

إذا أردت الذهاب أبعد من هذا، Korra Studio لديها مقاطع ذات صلة على DEFENSE_GRID تغطي DNS security extensions و DNS tunneling كتقنية للتسريب، وبناء resolver خاص بك من الصفر في Python.