فاحص DNS

نظام أسماء النطاقات (DNS) هو دليل الهاتف للإنترنت: يحوّل الأسماء التي يحفظها البشر مثل arabtoolbox.com إلى عناوين IP رقمية تفهمها الأجهزة مثل 93.184.216.34. بدون DNS لاضطررت إلى حفظ سلسلة أرقام لكل موقع تزوره — وهو ما لا يطيقه أحد.

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

فهم DNS ليس ترفًا تقنيًا، بل مهارة عملية: معظم أعطال المواقع والبريد والشهادات جذورها خطأ في سجل DNS لا في الخادم نفسه. من يتقن قراءة السجلات يوفّر على نفسه ساعات من تخمين سبب العطل.

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

عندما تكتب اسم موقع، يحدث ما يلي خلف الكواليس: أولًا يسأل جهازك المُحلِّل (Resolver) لدى مزوّد الخدمة. إن لم يكن يعرف الجواب، يسأل خادم الجذر (Root) الذي يوجّهه إلى خادم النطاق الأعلى المناسب (مثل com. أو sa.). ثم يسأل خادم الأسماء المسؤول (Authoritative) عن النطاق نفسه، فيعيد عنوان IP النهائي.

هذه السلسلة — جذر ثم TLD ثم authoritative — تُسمّى الاستعلام التكراري (Recursive). تبدو معقّدة لكنها تكتمل عادة في أقل من 100 مللي ثانية، وتُخزَّن النتيجة مؤقتًا فلا تتكرّر السلسلة كاملة في كل مرة.

فهم هذه الرحلة يفسّر لماذا قد يعمل موقع على جهازك ويفشل على جهاز آخر: الفرق في المُحلّل الذي يستخدمه كل جهاز وما خزّنه مسبقًا. لهذا يكون تبديل المُحلّل أول خطوة تشخيص عند أي مشكلة غامضة.

الخوادم العامة الشهيرة مثل 8.8.8.8 من Google و 1.1.1.1 من Cloudflare توفّر سرعة وموثوقية أعلى من بعض مُحلّلات مزوّدي الخدمة، وتوفّر خصوصية أفضل عبر DNS المشفّر. تبديلها خطوة بسيطة تحلّ كثيرًا من مشاكل التصفّح.

A و AAAA

سجل A يربط الاسم بعنوان IPv4، وسجل AAAA يربطه بعنوان IPv6. هما السجلان الأساسيان لأي موقع. غياب AAAA يعني أن الموقع لا يدعم IPv6.

وجود عدّة سجلات A لنفس الاسم يوزّع الحمل بين عدّة خوادم (Round-robin)، وهو أبسط صور موازنة الأحمال. عند فحص السجل تأكّد أن كل العناوين صحيحة وتعمل، فعنوان واحد معطّل قد يجعل الموقع يعمل أحيانًا ويفشل أحيانًا.

MX

سجل تبادل البريد (Mail Exchange) يحدّد الخادم الذي يستقبل بريد النطاق، مع أولوية رقمية (الأقل أولًا). أخطاء MX سبب شائع لعدم وصول رسائل البريد الإلكتروني.

CNAME

اسم بديل (Canonical Name) يجعل اسمًا يشير إلى اسم آخر بدل عنوان IP. مفيد عند استخدام خدمات خارجية مثل CDN، لكن لا يجوز وضعه على النطاق الجذر مباشرة.

TXT

نص حر يُستخدم للتحقق من الملكية وسجلات أمان البريد مثل SPF و DKIM و DMARC التي تمنع انتحال بريدك. كثير من خدمات Google و Microsoft تطلب إضافة سجل TXT للتحقق.

خطأ شائع هو إضافة عدّة سجلات SPF منفصلة، بينما المعيار يسمح بسجل SPF واحد فقط؛ تعدّدها يُبطل الحماية بالكامل. لذا ادمج كل المرسِلين المصرّح لهم في سجل SPF واحد وتحقّق منه بأداة فحص.

NS و SOA

سجل NS يحدّد خوادم الأسماء المسؤولة عن النطاق، وسجل SOA يحمل البيانات الإدارية مثل البريد المسؤول وأرقام الإصدار. تغييرهما يعني نقل إدارة DNS بالكامل.

معرفة أي سجل تحتاج توفّر عليك وقتًا كبيرًا: مشكلة في الوصول للموقع تعني النظر في A/AAAA، مشكلة بريد تعني MX/TXT، ومشكلة تحقّق ملكية تعني TXT. تصنيف العطل حسب نوع السجل أول خطوة نحو الحل.

كل سجل DNS يحمل قيمة TTL (Time To Live) بالثواني تحدّد كم يبقى مخزّنًا مؤقتًا قبل إعادة الاستعلام. قيمة عالية (مثل 86400 = يوم) تقلّل الحمل وتسرّع التصفّح، لكنها تبطّئ انتشار أي تغيير. قيمة منخفضة (مثل 300 = 5 دقائق) تجعل التغييرات شبه فورية لكن بحمل أكبر.

القاعدة العملية: قبل أي ترحيل خادم خفّض TTL إلى 300 ثانية بيوم كامل، نفّذ التغيير، ثم أعِده للقيمة العالية بعد التأكد. هكذا تنتشر التحديثات بسرعة دون تعطيل المستخدمين الذين ما زالوا على القيمة القديمة المخزّنة.

اختيار TTL المناسب موازنة بين المرونة والأداء: سجلات نادرة التغيير كـ MX تستحق TTL عاليًا، وسجلات قد تتغيّر أثناء التطوير تستحق TTL منخفضًا مؤقتًا. لا تترك كل السجلات على قيمة واحدة دون تفكير.

عند تغيير سجل DNS لا يراه العالم فورًا، بل تدريجيًا مع انتهاء صلاحية النسخ المخزّنة لدى المُحلّلات حول العالم. لهذا قد يرى زائر في الرياض الموقع الجديد بينما ما زال زائر في القاهرة على القديم لساعات. هذا طبيعي وليس عطلًا.

أدوات فحص الانتشار تستعلم من خوادم في مواقع متعدّدة وتُظهر أين وصل التغيير. مدة الانتشار الكاملة تعتمد على TTL السابق لا الجديد، وقد تصل نظريًا إلى 48 ساعة وإن كانت غالبًا أسرع بكثير.

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

أكثر الأخطاء شيوعًا: NXDOMAIN ويعني أن الاسم غير موجود (خطأ إملائي أو نطاق منتهٍ)، و SERVFAIL ويعني فشل المُحلّل غالبًا بسبب سجل خاطئ أو DNSSEC معطوب. عند ظهور “DNS_PROBE_FINISHED” في المتصفح جرّب تبديل مُحلّل DNS إلى 8.8.8.8 أو 1.1.1.1 لعزل المشكلة عن مزوّد خدمتك.

إذا لم يصل بريدك، افحص سجل MX و SPF أولًا. وإذا توقف الموقع بعد تغيير الاستضافة، تأكد من سجل A وانتظر انتهاء TTL القديم. معظم مشاكل “الموقع لا يعمل” جذورها في DNS لا في الخادم نفسه.

نصيحة تشخيصية: عند أي عطل، افحص السجل من عدّة مواقع جغرافية لا من جهازك فقط، لأن النتيجة قد تكون مخزّنة محليًا وتخدعك. مسح ذاكرة DNS المؤقتة على جهازك قبل الفحص يوفّر عليك تشخيصًا خاطئًا.

DNS هدف شائع للهجمات: تسميم الذاكرة المؤقتة (Cache Poisoning) يحقن عنوانًا مزيّفًا فيوجّهك لموقع احتيالي. الحل DNSSEC الذي يوقّع السجلات رقميًا فيمنع التلاعب. كما توفّر DNS over HTTPS (DoH) تشفير استعلاماتك فلا يراها مزوّد الخدمة أو المتسلّل على الشبكة.

على مستوى النطاق، فعّل قفل النطاق (Registrar Lock) و DNSSEC لمنع اختطاف نطاقك. سجل TXT بصيغة DMARC صارمة يحمي سمعة بريدك من الانتحال. الأمان هنا طبقات متكاملة لا إعداد واحد.

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

تُدار نطاقات المستوى الأعلى للمملكة — وهي sa. ونظيرتها بالعربية .السعودية — عبر المركز السعودي لمعلومات الشبكة (SaudiNIC). التسجيل تحت هذه النطاقات يعطي موقعك هوية محلية واضحة، وهو مفيد للجهات والمتاجر التي تستهدف جمهورًا سعوديًا.

نقطة مهمّة يغفل عنها الكثيرون: جهة تسجيل النطاق ليست بالضرورة هي جهة إدارة DNS. يمكنك تسجيل نطاق sa. ثم توجيه خوادم الأسماء (NS) إلى أي مزوّد DNS تختاره، محليًا كان أو عالميًا. هذا يعطيك مرونة في اختيار مزوّد سريع دون الارتباط بجهة التسجيل.

عند فحص سجلات نطاق sa.، تعامل معها بالقواعد نفسها تمامًا: A/AAAA للوصول، وMX/TXT للبريد، وNS للإدارة. لا توجد معاملة تقنية خاصة للنطاقات المحلية تجعلها تعمل بشكل مختلف عن sa. — الفرق إداري في جهة التسجيل لا في آلية عمل DNS نفسها.

زمن حلّ DNS جزء حقيقي من زمن تحميل أوّل زيارة؛ فقبل أن يبدأ المتصفّح بتحميل أي شيء يجب أن يحوّل الاسم إلى عنوان IP. مزوّد DNS بطيء يضيف تأخيرًا محسوسًا يتكرّر مع كل اسم نطاق جديد تستدعيه الصفحة.

تقنية Anycast التي توفّرها مزوّدات DNS الجادّة توجّه استعلام كل زائر إلى أقرب خادم جغرافيًا، فيقلّ زمن الاستجابة للزوّار المحليين. ورفع قيمة TTL للسجلات نادرة التغيير يقلّل عدد الاستعلامات المتكرّرة ويسرّع التصفّح.

على جانب المتصفّح، يساعد تلميح DNS Prefetch على حلّ أسماء النطاقات الخارجية مبكّرًا قبل الحاجة إليها، فتبدو الصفحة أسرع. الخلاصة: DNS ليس مجرّد دليل عناوين، بل عامل أداء يستحقّ الانتباه عند السعي لتسريع الموقع.

فحص DNS ضروري عند: ترحيل موقع لاستضافة جديدة والتأكد من انتشار سجل A، تشخيص عدم وصول البريد عبر MX و SPF، التحقق من ملكية نطاق لخدمة خارجية عبر TXT، أو كشف سبب بطء الموقع إن كان خادم DNS بطيئًا. المطوّرون يفحصونه قبل إطلاق أي تغيير بنية تحتية، وكثيرًا ما يقرنونه بأداة كشف عنوان IP للتأكد من الخادم الذي يشير إليه السجل.

لإكمال الصورة من المتصفح حتى الخادم، اقرأ أيضًا عن فحص شهادة SSL، فبعد أن يحلّ DNS الاسم إلى IP، تتولّى شهادة SSL تأمين الاتصال نفسه.

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

لفحص DNS عدّة طرق تختلف في العمق. أبسطها أداة فحص عبر المتصفّح تعرض لك السجلات منسّقة دون تثبيت شيء، وهي الأنسب لغير التقنيين وللفحص السريع. أمّا المطوّرون فيفضّلون أدوات سطر الأوامر لأنها أسرع وأدقّ.

أداة dig

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

أداة nslookup

أبسط من dig ومتوفرة على ويندوز وماك ولينكس. كافية للفحص السريع عن سجل A أو MX، لكنها أقل تفصيلاً من dig. للمستخدم العادي على ويندوز، هي أسرع طريقة للتحقق من سجل دون تثبيت أدوات.

النصيحة العملية: استخدم أداة المتصفّح للفحص اليومي السريع، وارجع إلى dig عند تشخيص مشكلة معقّدة تحتاج سؤال خادم معيّن أو قراءة TTL بدقة. لا تحتاج إلى حفظ كل الأوامر، بل إلى معرفة متى تستخدم كل أداة.

إلى جانب DNS العادي الذي يحوّل الاسم إلى عنوان، هناك DNS العكسي الذي يفعل العكس: يحوّل عنوان IP إلى اسم. يُستخدم غالباً لخوادم البريد، لأن كثيراً من مستقبلات البريد ترفض رسائل من خادم ليس له سجل عكسي (PTR) صحيح. لذلك إن كنت تدير خادم بريد، فإن سجل PTR ليس رفاهية.

أمّا DNS الديناميكي (DDNS) فيحدّث السجل تلقائياً عند تغيّر العنوان، وهو مفيد لمن لديه عنوان IP متغيّر من مزوّد الخدمة، كمن يستضيف خدمة من المنزل أو كاميرا مراقبة. بدل تحديث السجل يدوياً كل مرة، يتولّى DDNS ذلك تلقائياً.

للمستخدم العادي، قد لا تحتاج هذين النوعين مباشرة، لكن معرفتهما تفيد عند تشخيص مشاكل البريد أو عند إعداد خدمة منزلية. إذا كان بريدك يصل إلى مجلد الرسائل غير المرغوب دائماً، فتحقّق من سجل PTR إلى جانب SPF و DKIM.

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

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

لا توقِف الخادم القديم فور تغيير السجل، بل اتركه يعمل حتى ينتهي TTL القديم وينتقل كل الزوّار. إيقافه مبكراً يعني أن من ما زال على السجل القديم سيرى موقعاً معطّلاً. هذا «الجسر المزدوج» بين الخادمين يضمن ترحيلاً دون انقطاع واحد.

اجعل هذه القائمة جزءاً من روتينك عند أي تغيير بنية تحتية. كل بند تتجاهله قد يكون سبب عطل غامض لاحقاً:

قبل الإطلاق

تأكد من سجل A/AAAA يشير للخادم الصحيح، وسجل MX للبريد، وسجل SPF واحد يشمل كل المرسِلين، وسجل TXT للتحقق إن لزم. خفّض TTL قبل أي تغيير متوقّع.

بعد الإطلاق

راقب الانتشار من عدّة مواقع جغرافية، وتأكد أن البريد يصل ويُرسل، وأن الشهادة تعمل بعد تغيير العنوان. بعد التأكد من استقرار كل شيء، أعد TTL للقيمة العالية لتقليل الحمل.

هذه المراجعة البسيطة تحوّل DNS من مصدر إزعاج إلى أداة تحت سيطرتك. الفحص الاستباقي يكشف الأخطاء قبل أن يراها زوّارك، ويوفّر عليك ساعات من تخمين سبب العطل.

بشكل افتراضي، تنتقل استعلامات DNS كنص واضح، أي أن مزوّد خدمتك أو أي وسيط على الشبكة يستطيع رؤية المواقع التي تزورها. لمعالجة هذا ظهر بروتوكولان: DNS over HTTPS (DoH) و DNS over TLS (DoT)، وكلاهما يشفّر استعلاماتك فلا يراها أحد.

الفرق البسيط: DoH يخفي استعلامات DNS داخل حركة https العادية فيصعب تمييزها أو حجبها، بينما DoT يستخدم منفذاً مخصصاً للتشفير. كثير من المتصفّحات وأنظمة التشغيل الحديثة تدعم DoH، وتفعيله خطوة خصوصية جيدة دون تعقيد.

الخلاصة للمستخدم العادي: تفعيل DNS المشفّر يحمي خصوصية تصفّحك من المراقبة على الشبكات العامة، ويقلّل فرص توجيهك إلى مواقع مزيّفة عبر تلاعب بالاستعلامات. لكنه لا يغني عن باقي طبقات الحماية مثل DNSSEC والتشفير.

ليس كل مزوّدي DNS سواءً. بعضهم أسرع، وبعضهم أكثر خصوصية، وبعضهم يوفّر ميزات حماية إضافية كحجب المواقع الخبيثة. عند اختيار مزوّد إدارة DNS لنطاقك، انظر إلى ثلاثة عوامل: السرعة (هل يدعم Anycast؟)، الموثوقية (هل لديه سجل توقّف جيد؟)، والميزات (DNSSEC، سجلات متقدمة).

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

للمواقع التي تستهدف جمهوراً محلياً، اختر مزوّداً له حضور قريب جغرافياً لتقليل زمن الاستجابة. ولا تنسَ أن تغيير مزوّد إدارة DNS يعني تغيير سجلات NS، وهو تغيير يحتاج وقتاً لينتشر مثل أي تغيير DNS آخر.

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

لذلك قبل أي فحص تشخيصي، امسح ذاكرة DNS المؤقتة. على ويندوز تستخدم أمر مسح الذاكرة، وعلى ماك أمراً مشابهاً من الطرفية، وفي المتصفّح أعد تشغيله أو امسح ذاكرته. خطوة بسيطة توفّر عليك تشخيصاً خاطئاً تماماً.

القاعدة العملية: عند أي عطل غامض، افحص السجل من أداة خارجية تستعلم من عدّة مواقع، لا من جهازك وحده، لأن جهازك قد يعرض نسخة مخزّنة تخدعك. الجمع بين مسح الذاكرة والفحص الخارجي يعطيك صورة دقيقة.

أكثر مشاكل البريد الإلكتروني جذورها في سجلات DNS لا في خادم البريد. ثلاثة سجلات TXT تحكم مصداقية بريدك: SPF يحدّد الخوادم المصرّح لها بإرسال بريد باسم نطاقك، و DKIM يوقّع الرسائل رقمياً لإثبات أنها لم تُعدّل، و DMARC يحدّد ماذا يفعل المستقبِل بالرسائل التي تفشل في التحقق.

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

الخطوات العملية: تأكد من وجود سجل SPF واحد صحيح، وفعّل DKIM من لوحة مزوّد البريد، ثم أضف سجل DMARC يبدأ بسياسة مراقبة ثم تشدّده تدريجياً. فحص هذه السجلات الثلاثة جزء أساسي من أي فحص DNS جدّي، لأنها تحمي سمعة بريدك من الانتحال.

النطاق الفرعي هو اسم يسبق نطاقك الرئيسي، مثل جزء المدوّنة أو المتجر أو لوحة التحكم. توجّه النطاقات الفرعية عادةً عبر سجل A إلى عنوان IP، أو عبر سجل CNAME إلى اسم آخر عند استخدام خدمة خارجية مثل منصّة استضافة أو CDN.

خطأ شائع: محاولة وضع CNAME على النطاق الجذر مباشرة، وهو غير مسموح تقنياً. للنطاق الجذر استخدم سجل A، واترك CNAME للنطاقات الفرعية. إن كنت تنشئ نطاقات فرعية كثيرة، فشهادة Wildcard تغطّيها جميعاً، وسجل حرف البدل في DNS يوجّهها دفعة واحدة.

عند تشخيص مشكلة في نطاق فرعي، افحصه بالقواعد نفسها: هل سجل A/CNAME صحيح؟ هل انتشر التغيير؟ هل الشهادة تغطّيه؟ كثير من أعطال «النطاق الفرعي لا يعمل» سببها شهادة لا تغطّيه أو سجل لم ينتشر بعد.

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

الربط بين موقعك والشبكة يتم غالباً عبر سجل توجيه في DNS، إما بتغيير خوادم الأسماء إلى الشبكة، أو بتوجيه الاسم إلى اسم توفّره الشبكة. لذلك عند تفعيل شبكة توزيع، ستجد نفسك تعدّل سجلات DNS، وهنا يعود فهم السجلات والانتشار مفيداً جداً.

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

تنتشر حول DNS اعتقادات خاطئة تؤدّي إلى قرارات سيئة وإضاعة وقت في تشخيص الأعطال. تصحيح هذه الخرافات يوفّر عليك جهداً كبيراً.

«تغيير السجل يظهر فوراً»: غير صحيح. التغيير يحتاج وقتاً لينتشر حسب قيمة TTL السابقة، وقد ترى نتيجة مختلفة بين منطقة وأخرى لساعات. التسرّع بإعادة التعديل يزيد الفوضى لا أكثر.

«DNS لا علاقة له بالبريد»: خطأ شائع. أغلب مشاكل البريد ووصوله إلى الرسائل غير المرغوبة جذورها في سجلات DNS: MX و SPF و DKIM و DMARC. البريد والموقع وجهان لعملة واحدة تديرها السجلات.

«العطل دائماً في الخادم»: في الغالب العكس. حين «لا يعمل الموقع»، ابدأ بفحص DNS قبل اتهام الخادم، لأن سجلاً خاطئاً أو انتشاراً لم يكتمل هو السبب الأكثر شيوعاً. فهم هذه الحقيقة وحدها يختصر ساعات من التخمين.

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

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

القاعدة العملية: صنّف العطل حسب نوع السجل. مشكلة وصول للموقع تعني A/AAAA، مشكلة بريد تعني MX/TXT، ومشكلة تحقّق ملكية تعني TXT. وعند أي تغيير كبير، خفّض TTL قبله وراقب الانتشار بعده. بهذا تصبح DNS أداة تحت سيطرتك لا لغزاً يربكك.

وأخيراً، اجعل فحص DNS عادة استباقية لا ردّ فعل وقت العطل. دقيقة واحدة من الفحص قبل وبعد أي تغيير تكشف أخطاء كانت ستكلّفك ساعات من التوقّف وفقدان الزوّار. الفحص رخيص، والعطل غالٍ. ومن يتعوّد الفحص الدوري ينام مرتاح البال وهو يعرف أن موقعه وبريده يعملان كما يجب.

كم يستغرق انتشار تغيير DNS؟

يعتمد على قيمة TTL السابقة لا الجديدة، ويتراوح عادة بين دقائق وبضع ساعات، وقد يصل نظريًا إلى 48 ساعة. إن خفّضت TTL قبل التغيير بيوم، ينتشر التحديث أسرع بكثير.

لماذا يرى صديقي الموقع الجديد وأنا لا؟

لأن جهازك أو مُحلّل مزوّدتك ما زال يحمل النسخة القديمة المخزّنة حتى انتهاء TTL. جرّب مسح ذاكرة DNS أو تبديل المُحلّل إلى 8.8.8.8 لرؤية النتيجة الجديدة فورًا.

هل أحتاج DNSSEC؟

يوفّر DNSSEC توقيعًا رقميًا يمنع تسميم السجلات، ويُنصح به بشدة للنطاقات الحسّاسة كالبنوك والمتاجر. لموقع شخصي بسيط ليس إلزامًا، لكن تفعيله إن دعمه مسجّلك خطوة أمان جيدة دون تكلفة.

ما الفرق بين سجل A و CNAME؟

سجل A يربط الاسم بعنوان IP رقمي مباشرة، بينما CNAME يجعل الاسم يشير إلى اسم آخر بدل عنوان IP. استخدم A للنطاق الجذر وعند الحاجة لعنوان ثابت، و CNAME عند الإشارة لخدمة خارجية مثل CDN، مع ملاحظة أن CNAME لا يجوز على النطاق الجذر مباشرة.

كيف أمسح ذاكرة DNS المؤقتة على جهازي؟

على ويندوز نفّذ الأمر ipconfig /flushdns، وعلى ماك استخدم أمر مسح ذاكرة DNS من الطرفية، وفي المتصفّح أعد تشغيله أو امسح ذاكرته. مسح الذاكرة قبل أي فحص يمنعك من رؤية نتيجة قديمة مخزّنة تخدعك أثناء التشخيص.

هل خادم DNS عام مثل 8.8.8.8 أسرع من خادم مزوّدي؟

غالبًا نعم من حيث السرعة والموثوقية، إضافة إلى خصوصية أفضل عبر التشفير. لكن النتيجة تختلف حسب موقعك وشبكتك، لذا جرّب 8.8.8.8 من Google أو 1.1.1.1 من Cloudflare وقارن قبل التبديل الدائم.

لماذا يصل بريدي إلى الرسائل غير المرغوبة رغم صحة الخادم؟

غالباً بسبب سجلات مصادقة البريد: غياب أو خطأ في SPF أو DKIM أو DMARC، أو غياب سجل عكسي (PTR) لخادم البريد. افحص هذه السجلات أولاً، وتأكد من وجود سجل SPF واحد لا عدّة سجلات متعارضة.

هل يعمل موقعي دون سجل AAAA؟

نعم، سجل A وحده كافٍ لعمل الموقع عبر IPv4. غياب AAAA يعني فقط أن الموقع لا يدعم IPv6، وهو غير إلزامي لأغلب المواقع حالياً، وإن كان دعمه خطوة مستقبلية جيدة.