الشبكات والاتصال

نظام أسماء النطاقات وكيف تُحلَّل الأسماء

18 دقيقة الدرس 2 من 10

نظام أسماء النطاقات وكيف تُحلَّل الأسماء

في كل مرة يكتب فيها مستخدم https://api.example.com في متصفحه، أو تُنفَّذ استدعاء بين الخدمات باستخدام اسم مضيف، تنبري قطعة صغيرة لكنها بالغة الأهمية من البنية التحتية: نظام أسماء النطاقات (DNS). يُشبه DNS دليل الهاتف الموزّع للإنترنت؛ يترجم الأسماء المقروءة للبشر إلى عناوين IP التي تفهمها أجهزة التوجيه والخوادم فعلياً. بالنسبة لمصمم الأنظمة، DNS ليس مجرد سباكة تقنية، بل هو أداةٌ للتحكم في توجيه الحركة، وضمان الاستمرارية عند الإخفاق، وتوزيع الحمل على المستوى العالمي، وضبط زمن الاستجابة.

التسلسل الهرمي لـ DNS

DNS هو فضاء أسماء هرمي ومفوَّض مُنظَّم على شكل شجرة. في القمة تقع المنطقة الجذرية (النقطة .) التي تديرها ICANN. تحتها توجد نطاقات المستوى الأعلى (TLDs) مثل .com و.org و.io ورموز الدول. يفوّض كل TLD الصلاحية الخاصة بنطاقات المستوى الثاني إلى خوادم الأسماء الموثوقة التي يديرها المسجّلون أو أصحاب النطاقات. لا يوجد خادم واحد يعرف كل شيء؛ عبقرية DNS أن كل مستوى يعرف فقط من يسأل بعده — وهو نموذج يُعرف بـالحل التكراري.

رحلة الحل الكاملة خطوة بخطوة

عندما يحتاج العميل إلى حل api.example.com، تنطلق السلسلة التالية:

  1. ذاكرة التخزين المؤقت في المتصفح / نظام التشغيل — يتحقق نظام التشغيل من ذاكرة DNS المحلية (وذاكرة المتصفح أيضاً). إذا وُجدت إجابة حديثة، يُعاد توجيهها فوراً دون أي اتصال بالشبكة.
  2. المحلّل الفرعي → المحلّل المتكرر — في حالة عدم وجود إجابة مخزّنة، يستفسر المحلّل الفرعي للنظام من المحلّل المتكرر المُضبوط على الجهاز (مثل 8.8.8.8 لـ Google Public DNS). يتولى المحلّل المتكرر كل العمل الشاق نيابةً عن العميل.
  3. المحلّل المتكرر → خوادم الجذر — يسأل المحلّل أحد مجموعات خوادم الجذر الـ13: "من يتولى .com؟" يُجيب الجذر بعنوان خوادم أسماء TLD الخاص بـ.com.
  4. المحلّل المتكرر → خوادم TLD — يسأل المحلّل خوادم TLD الخاصة بـ.com: "من الموثوق لـexample.com؟" يردون بسجلات NS لخادم الأسماء الموثوق الخاص بـexample.com.
  5. المحلّل المتكرر → خادم الأسماء الموثوق — يستفسر المحلّل من ns1.example.com: "ما عنوان IP لـapi.example.com؟" يُعيد الخادم الموثوق سجل A (IPv4) أو AAAA (IPv6).
  6. إعادة الإجابة إلى العميل — يخزّن المحلّل المتكرر النتيجة ويمررها إلى المحلّل الفرعي الذي يسلّمها بدوره إلى التطبيق. يستطيع المتصفح الآن فتح اتصال TCP.

عملياً، يُخزّن المحلّل المتكرر الإجابات في كل خطوة. على ذاكرة تخزين دافئة، تُنفَّذ الخطوة الثانية فقط (العميل → المحلّل المتكرر) — بزمن ذهاب وإياب لا يتجاوز بضعة ميلي ثانية. أما البحث الكامل البارد عبر المستويات الأربعة، فيُضيف 50–150 مللي ثانية على الاتصال النموذجي بالإنترنت، وهذا هو السبب وراء أهمية التخزين المؤقت.

DNS Resolution Flow Client (Browser/App) Recursive Resolver (8.8.8.8) Root Server (13 clusters) TLD Server (.com / .io) Authoritative NS (ns1.example.com) OS Cache (local TTL) ① check cache ② query ③ who handles .com? ④ NS for example.com? ⑤ A record for api.…? ⑥ IP answer query answer
سلسلة حل DNS التكرارية ذات الست خطوات — من التحقق من ذاكرة التخزين المؤقت للعميل وصولاً إلى خادم الأسماء الموثوق والعودة.

أنواع سجلات DNS الرئيسية

  • A — يربط اسم مضيف بعنوان IPv4. النوع الأكثر شيوعاً.
  • AAAA — يربط اسم مضيف بعنوان IPv6.
  • CNAME — الاسم القانوني؛ يُنشئ اسماً بديلاً يشير إلى اسم آخر. لا يمكن استخدامه في قمة المنطقة (النطاق الجذري).
  • NS — خادم الأسماء؛ يفوّض المنطقة لخوادم محددة.
  • MX — خادم البريد؛ يوجّه حركة البريد الإلكتروني إلى خوادم البريد مع ترتيب الأولويات.
  • TXT — نص عشوائي؛ يُستخدم لـ SPF وDKIM والتحقق من النطاقات واكتشاف الخدمات.
  • SRV — محدد الخدمة؛ يحدد المضيف والمنفذ والأولوية لبروتوكول أو خدمة معينة. يُستخدم بكثرة في Kubernetes وشبكات الخدمات.
  • ALIAS / ANAME — سجل غير قياسي خاص بمزودي الخدمة، يتصرف مثل CNAME لكن يمكن استخدامه عند قمة المنطقة. تُسميه AWS Route 53 سجل Alias.

TTL والتخزين المؤقت

كل سجل DNS يحمل مدة صلاحية (TTL) — عدد الثواني التي يُسمح فيها للمحلّل بتخزين الإجابة. TTL هو أهم معامل ضبط يتحكم فيه مصممو الأنظمة:

  • TTL منخفض (30–300 ث) — تنتشر التغييرات بسرعة. استخدمه أثناء عمليات النقل والنشر الأزرق/الأخضر أو قبل التبديل المخطط. التكلفة هي زيادة استعلامات DNS التي تصل لخوادمك الموثوقة.
  • TTL مرتفع (3600–86400 ث) — يُقلّل من عمليات البحث المتكررة ومن زمن الاستجابة. مناسب للسجلات الثابتة التي نادراً ما تتغير.
فخ انتشار TTL: إذا احتجت إلى تبديل طارئ لكن TTL لديك يساوي 86400 ثانية (24 ساعة)، ستخدم بعض المحلّلات عنوان IP القديم لمدة 24 ساعة بغض النظر عما تضعه في DNS. الممارسة الشائعة هي تخفيض TTL قبل أيام من أي تغيير مخطط، ثم انتظار دورة TTL كاملة، ثم إجراء التغيير، ثم رفع TTL مجدداً.

طبقات التخزين المؤقت لـ DNS

يحدث التخزين المؤقت على مستويات متعددة، لكل منها أفق TTL خاص به:

  1. ذاكرة المتصفح — يخزّن Chrome و Firefox DNS لمدة 60 ثانية. هذا خارج نطاق سيطرتك.
  2. ذاكرة محلّل نظام التشغيل — تحتفظ أدوات مثل nscd وsystemd-resolved بذاكرة تخزين لكل جهاز.
  3. ذاكرة المحلّل المتكرر — يخزّن مزود الإنترنت أو المحلّل العام (Google، Cloudflare) الإجابات لجميع مستخدميه. السجلات بـTTL يساوي 300 ثانية تُخزَّن عبر ملايين العملاء هنا.
  4. ذاكرة خادم الأسماء الموثوق — عندما يعمل خادم الأسماء الموثوق أيضاً كثانوي أو تابع، يُخزّن عمليات نقل المنطقة.
التخزين المؤقت السلبي (NXDOMAIN): تخزّن المحلّلات أيضاً الإجابات السلبية — "هذا الاسم غير موجود." يُحدَّد TTL للاستجابة السلبية في حقل MINIMUM لسجل SOA (RFC 2308). إذا نشرت نطاقاً فرعياً جديداً ولم يظهر، ربما خزّن محلّل ما NXDOMAIN لمدة تصل إلى 5 دقائق.

DNS في قرارات تصميم الأنظمة

DNS ليس مجرد أداة بحث — بل هو طبقة فعّالة لإدارة الحركة:

  • GeoDNS / التوجيه بناءً على زمن الاستجابة — يمكن لخوادم الأسماء الموثوقة إعادة عناوين IP مختلفة بناءً على موقع المحلّل. تستخدم AWS Route 53 "Latency Routing" وشبكة Anycast الخاصة بـ Cloudflare هذا المبدأ لتوجيه المستخدمين تلقائياً إلى المنطقة الأقرب.
  • التوجيه الموزون — إعادة IP-A بنسبة 90% وIP-B بنسبة 10% لإجراء إصدار قناري تدريجي على مستوى DNS.
  • التعافي التلقائي مع فحص الصحة — تدعم Route 53 وCloudflare وNS1 عمليات فحص الصحة النشطة. إذا فشلت نقطة النهاية الرئيسية، يتوقف خادم الأسماء الموثوق تلقائياً عن إعادة ذلك IP — تعافٍ على مستوى DNS دون تغيير الكود.
  • اكتشاف الخدمات في المايكروسيرفيس — يستخدم Kubernetes خادم DNS داخلي (CoreDNS) لتحليل أسماء الخدمات مثل payments-service.default.svc.cluster.local إلى IP افتراضي. كل حاوية تحصل على اكتشاف خدمة DNS مجاناً.
GeoDNS Routing: same hostname, different IPs per region Authoritative NS GeoDNS enabled EU Resolver (Frankfurt) US Resolver (Virginia) EU Origin 1.2.3.4 US Origin 5.6.7.8 query query → 1.2.3.4 → 5.6.7.8
GeoDNS: يُعيد نفس اسم المضيف عناوين IP مختلفة بحسب موقع المحلّل المتكرر، موجّهاً المستخدمين إلى أقرب خادم أصلي.

أخطاء شائعة يجب على مصممي الأنظمة تجنّبها

  • ترميز عناوين IP بشكل ثابت — تفقد الخدمات التي تتجاوز DNS وترمّز عناوين IP بشكل ثابت جميع مزايا التعافي والتوجيه وتوزيع الحمل. دائماً قم بالتحليل بالاسم.
  • إهمال TTL قبل عمليات النقل — كما ذُكر، خفّض TTL مسبقاً قبل أي تغيير مخطط لعناوين IP.
  • نقطة فشل وحيدة في سجلات NS — اضبط دائماً خادمَي أسماء موثوقَين على الأقل في شبكتين مختلفتين. تطلب ICANN ذلك كحد أدنى والممارسة الأفضل هي أربعة خوادم.
  • إغفال زمن استجابة DNS في حسابات SLA — يُضيف بحث DNS بارد 50–150 مللي ثانية لأول اتصال. تزيل أحواض الاتصال وإبقاؤها حية عمليات البحث المتكررة، لكن زمن الاستجابة لأول طلب يؤثر على اتفاقيات مستوى الخدمة.
  • سلاسل CNAME الطويلة — كل CNAME يشير إلى CNAME آخر يكلّف عملية بحث إضافية. بعض المحلّلات تفرض حداً (عادةً 8 قفزات). أبقِ السلاسل قصيرة.
سخّن ذاكرة DNS مسبقاً في استراتيجية فحص الصحة: عند تشغيل منطقة جديدة أثناء التوسع التلقائي أو حدث تعافٍ، حلّل سجلات DNS من داخل تلك المنطقة قبل توجيه الحركة الفعلية إليها. هذا يضمن دفء ذاكرات التخزين المحلية للنظام والحاويات، ويمنع الطلب الأول الحقيقي من دفع ثمن بحث بارد فوق تكلفة بدء تشغيل تطبيق بارد.

ملخص

حل DNS هو بحث مفوَّض متعدد المستويات يكتمل عادةً في أقل من 5 مللي ثانية على ذاكرة دافئة، لكنه قد يضيف 150 مللي ثانية في المسار البارد الكامل. TTL هو معامل الضبط الرئيسي — خفّضه قبل التغييرات وارفعه للاستقرار. على نطاق واسع، يصبح DNS أداةً من الدرجة الأولى لهندسة الحركة: GeoDNS، والتوجيه الموزون، والتعافي التلقائي بناءً على فحص الصحة، كلها تعمل على هذه الطبقة. فهم التسلسل الهرمي للتخزين المؤقت وتأخيرات الانتشار أمرٌ جوهري كلما صممت عملية ترحيل، أو نشراً متعدد المناطق، أو استراتيجية إصدار بدون توقف.