لماذا يمكن لخادم DNS ثانٍ أن يحل مشكلات في المنزل لا علاقة لها بالإنترنت

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

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

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

سواءً كان الأمر جيداً أم سيئاً، فإن أعطال نظام أسماء النطاقات (DNS) تبدو وكأنها مشكلة في الإنترنت نفسه. فإذا تعذر تحميل موقع إلكتروني ما، يبدو الأمر وكأنه مشكلة في اتصالك بالإنترنت، لكنه يختلف عن انقطاع الخدمة من قِبل مزود خدمة الإنترنت (ISP)؛ ففي حالة أعطال DNS، قد تكون بقية جوانب الشبكة تعمل على أكمل وجه، ومع ذلك تواجه المواقع الإلكترونية صعوبة في التحميل.

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

لقد كان لنظام DNS دور أكبر بكثير مما أدركتُه في شبكتي المنزلية؛

إذ لا تزال هناك حاجة لتحويل الأسماء المحلية إلى عناوين (حل الأسماء).

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

أنا أستخدم أسماء مضيفة (hostnames) للأجهزة والخدمات الموجودة على شبكتي المحلية أيضاً، ولا بد من تحويل هذه الأسماء إلى عناوين IP حتى يتمكن جهاز الكمبيوتر الخاص بي من معرفة كيفية التعامل مع حركة البيانات (traffic) الموجهة إليها. لذا، كان من الممكن أن يعمل جهاز التخزين الشبكي (NAS) واتصال الإيثرنت (Ethernet) بشكل مثالي، ومع ذلك، عند محاولة الوصول إليه باستخدام اسم المضيف، كان يبدو وكأنه غير متصل بالشبكة. كان هذا الوضع مزعجاً؛ ففي البداية ألقيت باللوم على مزود خدمة الإنترنت، ثم على جهاز NAS نفسه أو على الاتصال به، لكن كان هناك فارق جوهري.

وبما أنني كنت قادراً على الوصول إلى الخدمة مباشرةً عبر عنوان IP الخاص بها، بينما كانت تختفي عند محاولة استخدام اسمها، فقد استنتجت أن مسار الشبكة كان سليماً على الأرجح (وهو استنتاج تطلب مني بعض الوقت للتوصل إليه)؛ إذ كانت المشكلة تكمن في عملية “تحويل الأسماء” (name resolution).

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

لقد تسببتُ عن غير قصد في إنشاء نقطة فشل أحادية.

إذ كان بإمكان جهاز التوجيه (الراوتر) أن يعمل بشكل سليم بينما كانت خدمة DNS متوقفة تماماً.

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

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

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

الخادم الثاني ليس بالضرورة في حالة انتظار لدوره

يُعد مصطلحا “الأساسي” (Primary) و”الاحتياطي” (Backup) مجرد تسميات مريحة للاستخدام، وليسا قاعدة عالمية ثابتة.

عند هذه المرحلة، بدا إضافة خادم DNS ثانٍ هو الخيار البديهي؛ فإذا تعطل الخادم الأول أو فشل في أداء مهمته، سيتولى الخادم الثاني زمام الأمور فوراً، أليس كذلك؟

نظرياً، نعم.

إن تسمية هذه الخوادم بـ “الأساسي” (primary) و”الثانوي” (secondary) قد توحي بأن أحدهما يتولى إنجاز كامل العمل بينما يظل الآخر خاملاً دون القيام بأي شيء إلى حين الحاجة إليه، إلا أن تعامل أجهزة العملاء (clients) مع خوادم DNS متعددة لا يتم دائماً بهذه البساطة والسلاسة. فعلى سبيل المثال، يمكن لنظام Windows الانتقال إلى خادم DNS آخر مُعدّ مسبقاً في حال عدم استجابة الخادم الأول، كما يمكنه تغيير الخادم الذي يُعتبر “أساسياً” بناءً على مستوى الاستجابة.

لذا، يتلخص الأمر في أن خادم DNS الثاني هذا لم يكن “ثانوياً” بالمعنى الحرفي، بل كان أشبه بخادم “موازٍ” أو “مجاور” للأول، وهذا ما تسبب في بعض المشكلات؛ إذ كان يتعين عليه معرفة أسماء المضيفين المحلية (local hostnames) ذاتها وتقديم نفس نوعية الإجابات التي يقدمها الخادم الأول.

يمكنك إثبات وجود المشكلة دون الحاجة إلى التخمين:

اختبر الأسماء والعناوين بشكل منفصل.

كان الأمر برمته محبطاً -لن أكون مجافياً للحقيقة إن قلت ذلك- لكن اختباراً بسيطاً نسبياً منحني الإجابات التي كنت بحاجة إليها. تمثّل الهدف في الفصل بين الاتصال الأساسي وعملية تحليل الأسماء (name resolution).

كما ذُكر آنفاً، إذا كانت الخدمة المحلية تستجيب عند إدخال عنوان IP الخاص بها ولكنها تفشل في التحميل عند استخدام اسم المضيف (hostname)، فهذه إشارة قوية جداً إلى احتمال مواجهتك لهذه المشكلة. وبمجرد إدراكي لذلك، تمكنت من الاستعلام عن خادم DNS مباشرةً للتحقق مما إذا كان المُحلِّل (resolver) يعيد استجابة فعلية أم لا.

في نظام Windows، كل ما تحتاجه هو أدوات مثل `nslookup` و`Resolve-DnsName`. يمكنك توجيه الاستعلام إلى خادم DNS محدد، مما يتيح لك اختبار المُحلِّل الأصلي والمُحلِّل الجديد بشكل مستقل، ثم مقارنة السجلات المحلية. وبعد التأكد من أن كلا المُحلِّلين يعملان ويستجيبان بشكل صحيح، قم بإيقاف تشغيل الأول وأعد إجراء عملية بحث (lookup) عادية. هل سارت الأمور على ما يرام؟ هذا يعني أن الخادم الثاني يوفر بالفعل ميزة التكرار الاحتياطي (redundancy).

كان لا بد أن يكون خادم DNS الثاني مستقلاً تماماً؛

فوجود عنواني IP لا يجدي نفعاً إذا كان تعطل أحدهما يؤدي إلى توقف كليهما.

ثمة عقبة أخرى هنا بالطبع؛ وهي أنه حتى لو توفر لديك عنوانان لخادم DNS، فقد لا تتمتع فعلياً بميزة التكرارية (Redundancy) أو النسخ الاحتياطي المدمج.

طالما أن كلا مُحلِّلي الأسماء (resolvers) يعملان على الجهاز نفسه، فإن مصيرهما مرتبط بذلك الجهاز؛ فإذا قمت بإعادة تشغيله أو توقف عن العمل، سيتوقف المُحلِّلان معاً. وهذا يجعل الفكرة برمتها عديمة الجدوى نوعاً ما، إذ تفتقر حينها إلى آلية الحماية من الفشل (fail-safe) التي كنت تسعى لإعدادها في المقام الأول.

بالنسبة لي، تمثّل الحل في ضرورة تشغيل المُحلِّل الثاني في موقع مختلف، مع تخصيص عنوان IP مستقل له، وضمان احتوائه على نفس السجلات المحلية.

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

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

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