أساسيات الشبكات لـ DevOps

نظام أسماء النطاقات بعمق

18 دقيقة الدرس 3 من 30

نظام أسماء النطاقات بعمق

كل استدعاء لخدمة، وكل kubectl apply، وكل اتصال بقاعدة بيانات في مجموعتك يبدأ بطلب DNS. DNS هو دليل الهاتف الموزع للإنترنت — وحين يتعطل، يتعطل كل شيء بطرق محيرة تبدو كأنها أعطال شبكية أو أخطاء تطبيق أو مشاكل TLS. فهم DNS على مستوى المُحلِّل أمر لا تهاون فيه لأي مشغّل يريد تشخيص الحوادث بسرعة.

تدفق التحليل

حين يستدعي تطبيقك getaddrinfo("api.example.com")، لا يعرف نظام التشغيل عنوان IP بطريقة سحرية. بل يمر عبر سلسلة محددة من المُحلِّلات:

  1. فحص الكاش المحلي: يتحقق المُحلِّل من كاشه في الذاكرة. إن وُجدت إجابة مخزّنة وصالحة (TTL لم ينته)، يُرجعها فوراً دون أي طلب شبكي.
  2. المُحلِّل العودي (مزود الإنترنت أو الخادم المُهيَّأ): عند الغياب، يُحيل المُحلِّل الطلبَ إلى مُحلِّل عودي — عادة 8.8.8.8 أو 1.1.1.1 أو مُحلِّل VPC (مثل 169.254.169.253 في AWS). يملك المُحلِّل العودي كاشه الخاص، ويُجيب فوراً عند توفر إجابة مخزّنة.
  3. خوادم الجذر: عند غياب الكاش، يسأل المُحلِّل العودي أحد مجموعات خوادم الجذر الثلاثة عشر عن أي خادم موثوق يُدير .com.
  4. خوادم أسماء TLD: يُعيد خادم الجذر خوادم TLD الخاصة بـ .com. يسأل المُحلِّل العودي: "من هو الخادم الموثوق لـ example.com؟"
  5. الخادم الموثوق: يُعيد خادم TLD سجلات NS الموثوقة لـ example.com. يستعلم المُحلِّل العودي ذلك الخادم الذي يمتلك بيانات المنطقة الفعلية ويُعيد سجل A (أو AAAA أو CNAME إلخ).
  6. تسليم الإجابة وتخزينها: يُخزّن المُحلِّل العودي الإجابة بمقدار TTL السجل، ثم يُعيدها للمُحلِّل، الذي يُخزّنها في نظام التشغيل. يحصل تطبيقك أخيراً على عنوان IP.
DNS Resolution Flow Application getaddrinfo() Stub Resolver OS cache Recursive Resolver / ISP query miss Root Servers 13 clusters (a–m) TLD Nameservers .com / .org / .io … Authoritative NS Owns zone data 1. who handles .com? NS for .com NS for example.com A record + TTL cached answer IP address مسار الطلب مسار الإجابة (مُخزَّنة عند كل نقطة)
سلسلة تحليل DNS الكاملة: من مُحلِّل التطبيق صعوداً عبر خوادم الجذر وTLD والخوادم الموثوقة، ثم عودة الإجابة المُخزَّنة.
الفكرة الأساسية: المُحلِّل العودي هو من يقوم بالعمل الثقيل. تطبيقك لا يتحدث إلا مع المُحلِّل المحلي (عادة نظام التشغيل). مُحلِّل VPC السحابي (Route 53 Resolver في AWS على 169.254.169.253، وGCP على 169.254.169.254) يُدير كلاً من DNS الخاص (اكتشاف الخدمات) وDNS العام من نقطة واحدة.

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

يُخزّن DNS أنواعاً مختلفة من البيانات كسجلات مُصنَّفة. لكل نوع سجل هيكل وغرض محدد:

  • سجل A: يربط اسم المضيف بعنوان IPv4. النوع الأكثر شيوعاً. يمكن لاسم مضيف واحد أن يملك عدة سجلات A لتوزيع الحمل دوراً — وإن كان هذا شكلاً بدائياً بلا فحص صحة.
  • سجل AAAA: مثل A لكن لعناوين IPv6. المعيار الحديث يستلزم دعم البروتوكولين: كلا سجلي A وAAAA على كل اسم عام.
  • سجل CNAME: الاسم الكنسي — يُنشئ اسماً بديلاً يُشير إلى اسم مضيف آخر (لا إلى IP). يتبع المُحلِّل السلسلة حتى يصل إلى A أو AAAA. لا يمكن للـ CNAME أن يتعايش مع سجلات أخرى على الاسم ذاته، والأهم لا يمكن استخدامه عند قمة المنطقة (النطاق الجذري). استخدم ALIAS أو ANAME أو Route 53 Alias بدلاً منه.
  • سجل MX: مُبادِل البريد — يُشير إلى المضيفين الذين يستقبلون البريد الإلكتروني للنطاق. يتضمن دائماً أولوية (كلما انخفضت زادت الأولوية). القيمة يجب أن تكون اسم مضيف لا عنوان IP مباشر.
  • سجل TXT: نص حر. يُستخدم للتحقق من ملكية النطاق (Google Search Console، AWS Certificate Manager)، وسياسة SPF للبريد، ومفاتيح DKIM العامة، وسياسة DMARC. إن وقع بريدك في البريد المزعج، ابدأ من هنا.
  • سجل SRV: محدِّد الخدمة. يُضمِّن البروتوكول والأولوية والوزن والمنفذ واسم مضيف الهدف في سجل واحد. تستخدمه Kubernetes لاكتشاف الخدمات داخل DNS المجموعة. الصيغة: _service._proto.name TTL IN SRV priority weight port target.
  • سجل NS: خادم الأسماء — يُفوّض منطقة لمجموعة خوادم موثوقة. تغيير سجلات NS هو الطريقة للانتقال بين مزودي استضافة DNS.
  • سجل PTR: المؤشر — DNS العكسي. يربط عنوان IP باسم المضيف. ضروري لقابلية تسليم البريد. يُدار من قِبَل مالك كتلة IP (عادة مزود السحابة أو مزود الإنترنت).
  • سجل SOA: بداية الصلاحية — كل منطقة تملك واحداً بالضبط. يحمل NS الرئيسي وبريد مسؤول المنطقة ورقم التسلسل وموقيتات التحديث.

TTL: الحقل الأكثر سوء فهم

وقت الحياة على سجل DNS (بالثواني) يخبر كل مُحلِّل في السلسلة كم يمكنه تخزين الإجابة. TTL هو ذراع تحكم سلبي: بمجرد أن يُخزّن المُحلِّل سجلك، لا يمكنك إجباره على إعادة الاستعلام حتى تنتهي صلاحية TTL. لهذا تبعات تشغيلية:

  • TTL بقيمة 300 (5 دقائق) يعني أن تغيير الفشل التدريجي ينتشر في أقصاه 5 دقائق — لكن فقط إن ضبطت هذا الـ TTL قبل الحادثة.
  • TTL بقيمة 86400 (يوم كامل) — شائع في النطاقات مُهملة الإعداد — يعني أن الهجرة أو التحويل يستغرق حتى 24 ساعة للانتشار. لا يمكنك تغيير TTL مُخزَّن في منتصف الطريق.
  • الممارسة على مستوى الشركات الكبرى: خفّض TTL إلى 60–300 ثانية قبل أي هجرة مخطط لها بيوم كامل، انتظر حتى تنتهي صلاحية TTL القديم، ثم نفّذ التغيير، وبعدها ارفع TTL مجدداً.
ممارسة احترافية: اضبط سجلات DNS للبنية التحتية (نقاط موازنات الحمل، بوابات API، أصول CDN) على TTL بقيمة 60 ثانية افتراضياً. للسجلات التي لا تتغير أبداً (SPF، DKIM، MX) القيمة من 3600 إلى 86400 مناسبة. لا تستخدم TTL بقيمة 0 في الإنتاج — فهو يُلغي التخزين المؤقت كلياً ويُغرق خادمك الموثوق بالطلبات.

تصحيح أخطاء DNS مع dig

dig (Domain Information Groper) هو الأداة الرسمية لتصحيح DNS. كل مهندس DevOps يجب أن يتقنها. nslookup محدودة؛ dig تُظهر الصورة الكاملة على مستوى البروتوكول.

# طلب سجل A بسيط dig api.example.com # طلب نوع سجل محدد dig example.com MX dig example.com TXT dig example.com NS dig example.com SOA # الاستعلام من خادم أسماء محدد (تجاوز المُحلِّل العودي كلياً) # مفيد للتحقق من تغيير على الخادم الموثوق قبل الانتشار dig @8.8.8.8 api.example.com A dig @ns1.example.com api.example.com A # إخراج مختصر — قسم الإجابة فقط dig +short api.example.com # التتبع الكامل — مشاهدة سلسلة التحليل خطوة بخطوة dig +trace api.example.com # بحث DNS عكسي (PTR) dig -x 93.184.216.34 # قياس زمن الاستجابة (انظر "Query time" في التذييل) dig api.example.com | grep "Query time" # مقارنة الإجابة الموثوقة مقابل الإجابة المُخزَّنة dig @ns1.example.com api.example.com +short # موثوق dig @1.1.1.1 api.example.com +short # كاش Cloudflare dig @8.8.8.8 api.example.com +short # كاش Google

يملك إخراج dig الخام أربعة أقسام: QUESTION (ما طلبته)، ANSWER (السجلات المطابقة)، AUTHORITY (خوادم NS الموثوقة للمنطقة)، وADDITIONAL (سجلات الغراء — سجلات A لخوادم NS نفسها لتجنب مشكلة الدجاجة والبيضة). يُظهر التذييل زمن الاستعلام والخادم المجيب والتوقيت.

# قراءة إخراج dig — مثال مُشروح # $ dig api.example.com ; <<>> DiG 9.18.24 <<>> api.example.com ;; QUESTION SECTION: ;api.example.com. IN A ;; ANSWER SECTION: api.example.com. 60 IN A 203.0.113.42 ; TTL=60, IPv4 ;; AUTHORITY SECTION: example.com. 3600 IN NS ns1.example.com. example.com. 3600 IN NS ns2.example.com. ;; ADDITIONAL SECTION: ns1.example.com. 3600 IN A 198.51.100.1 ; سجل غراء ;; Query time: 18 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) <-- systemd-resolved على Ubuntu ;; WHEN: Wed Jun 11 09:14:22 UTC 2025 ;; MSG SIZE rcvd: 128
مصيدة إنتاجية: حين "لا ينتشر" تغيير DNS، أكثر المهندسين ينتظرون ويراقبون. الخطوة الصحيحة هي استعلام خوادم الأسماء الموثوقة مباشرة بـ dig @ns1.example.com hostname A. إن أظهر الخادم الموثوق السجل الجديد لكن المُحلِّلات لا تزال تُظهر القديم، فأنت تنتظر انتهاء TTL — متوقع. إن أظهر الخادم الموثوق السجل القديم بعد، فالتغيير لم يُحفَظ صحيحاً. هذان مشكلتان مختلفتان تماماً؛ الخلط بينهما يُضيع ساعات خلال الحادثة.

أنماط فشل DNS في الإنتاج

أعطال DNS من بين الأكثر خداعاً تشغيلياً لأنها تظهر على شكل انتهاء مهل أو رفض اتصال أو عدم تطابق شهادات TLS — لا كـ "DNS فشل". إليك أكثر أنماط الفشل شيوعاً على نطاق واسع:

  • كاش قديم بعد تدوير لا يراعي TTL: توجّه CNAME إلى موازن حمل جديد لكن تنسى أن TTL القديم هو 86400. تستمر حركة المرور في ضرب الخادم القديم حتى 24 ساعة.
  • إعداد أفق منقسم خاطئ: DNS الموثوق يُعيد إجابات مختلفة للاستعلامات الداخلية مقابل الخارجية. إعداد خاطئ يمكن أن يجعل خدمات يمكن الوصول إليها من الإنترنت غير قابلة للوصول داخلياً — مصدر شائع لتقارير "يعمل على جهازي، معطوب في الإنتاج".
  • CNAME عند قمة المنطقة: وضع CNAME على النطاق الجذري يكسر استعلامات MX وNS وSOA. استخدم ALIAS أو ANAME أو Route 53 Alias بدلاً منه.
  • إشباع CoreDNS في Kubernetes: CoreDNS هو DNS المجموعة في Kubernetes. تحت معدلات استعلام عالية، يمكن أن تصبح حِزم CoreDNS مُثقَلة بالمعالجة وتبدأ بإسقاط الطلبات. راقب زمن استجابة CoreDNS كـ SLI درجة أولى.
  • سجلات PTR المفقودة للبريد: خادم SMTP الصادر لا يملك إدخال DNS عكسي. خوادم الاستقبال ترفض بريدك بصمت أو تُصنّفه بريداً مزعجاً. تحقق دائماً من سجلات PTR لعناوين IP خوادم البريد.
ملاحظة حول Kubernetes DNS: داخل حِزمة pod، تبحث استعلامات DNS أولاً في نطاق الـ pod، ثم نطاق الخدمة، ثم svc.cluster.local، ثم cluster.local، ثم الخارج — تتحكم فيه نطاقات البحث في /etc/resolv.conf وإعداد ndots. استعلام عن redis داخل pod يُنشئ فعلياً استعلامات عدة قبل الحل. استخدم أسماء النطاقات الكاملة (تنتهي بـ .) أو اضبط dnsConfig.ndots: 1 للخدمات الحساسة للزمن.

DNS كبنية تحتية — أنماط الإنتاج

على نطاق الشركات الكبرى، يُعامَل DNS كبنية تحتية حرجة لا كإعداد لمرة واحدة:

  • خوادم أسماء موثوقة متعددة في شبكات ASN مختلفة: Route 53 وCloudflare وNS1 تشغّل شبكات anycast. لا تعتمد على NS واحدة أبداً. تفويض المنطقة يستلزم سجلَي NS على الأقل، والممارسة المثلى أربعة عبر مجموعات منفصلة جغرافياً.
  • DNS كتوجيه بفحص صحة: Route 53 Health Checks وCloudflare Load Balancing وNS1 Pulsar تُتيح توجيه مُرجَّحاً أو بديلاً بناءً على نتائج الفحص — يصبح DNS جزءاً من مستوى إدارة حركة المرور النشط.
  • DNSSEC: يُضيف توقيعات تشفيرية للسجلات، مانعاً تسميم الكاش (هجوم Kaminsky). إلزامي في الصناعات المُنظَّمة؛ ويُتوقع بشكل متزايد على جميع المناطق العامة. يُضيف تعقيداً تشغيلياً — يجب التخطيط لتبديل المفاتيح.
  • TTL منخفض + CNAME لـ CDN: CDNs الحديثة (Cloudflare وFastly وAkamai) تريد منك CNAME لاسم المضيف إلى حافتها. ادمجه مع TTL من 60 ثانية وتوجيه بفحص صحة لتحقيق تعافٍ أقل من دقيقة على نطاق عالمي.
الدرس السابق عناوين IP والشبكات الفرعية
الدرس التالي HTTP و HTTPS للمشغّلين
العودة للدورة