DNS في Active Directory: افهم سجلات SRV وليش الإنترنت يشتغل والدومين ما ينلقى

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

سجلات SRV تساعد العميل يلقى جهات تقدم خدمة معينة، مثل LDAP في سياق الدومين. بنقرأ هذه السجلات داخل لاب lab.test مصرح، ونتتبع الفرق بين اكتشاف الخدمة وحل عنوانها والوصول إليها. ما بنغير DNS ولا نحذف سجلًا؛ نبي نفهم النتيجة قبل أي معالجة يديرها مسؤول البيئة.

السؤال عن اسم جهاز غير السؤال عن خدمة دومين

لو تسأل DNS عن عنوان dc01.lab.test، فأنت تعرف اسم جهاز وتريد عنوانه. أما عميل يحتاج Domain Controller مناسبًا فقد يبدأ بسؤال عن خدمة داخل دومين، لا عن خادم قررته أنت مسبقًا. نجاح السؤال الأول لا يضمن صحة الإجابة عن الثاني.

هذا يشبه معرفتك رقم مكتب في جهة، بينما شخص آخر يحتاج دليلًا يخبره أي مكتب يقدم الخدمة المطلوبة. التشبيه يوضح الفرق فقط. في Active Directory توجد عملية DC Locator تعتمد على اكتشاف جهات مناسبة والتحقق منها، وليس اختيار أول اسم تعرفه من ورقة التدريب.

لذلك اكتب اسم الدومين DNS المؤهل في التجربة، مثل lab.test، وفرق بينه وبين اسم جهاز dc01.lab.test وبين اسم NetBIOS المختصر إن وجد. الاسم المختصر قد لا يطابق جزء DNS بالطريقة التي تتوقعها. لا تستنتج الاسم المؤهل من حروف اسم قديم أو من بريد المستخدم بدون مراجعة إعداد اللاب.

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

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

قبل الاستعلام: أي DNS يستخدمه جهازك فعلًا؟

على جهاز ويندوز تدريبي، ابدأ بقراءة إعداد خوادم DNS للواجهات دون تغييرها:

Get-DnsClientServerAddress

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

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

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

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

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

استعلم عن SRV واضح داخل النطاق

مثال على ويندوز داخل اللاب:

Resolve-DnsName -Name '_ldap._tcp.dc._msdcs.lab.test' -Type SRV -DnsOnly

هذا يسأل عن سجل خدمة محدد في الدومين التدريبي. الاسم متعمد ومقيد، وليس محاولة جرد كل أسماء الشبكة. خيار -DnsOnly يحصر حل الاستعلام في DNS وفق الأداة، بدل الاعتماد على بدائل مثل LLMNR أو NetBIOS لتفسير الإجابة.

إذا تصريحك يحدد DNS تدريبيًا بعينه، تستطيع مقارنة السؤال نفسه بجهة معروفة:

Resolve-DnsName -Name '_ldap._tcp.dc._msdcs.lab.test' -Type SRV -DnsOnly -Server 10.10.20.10

العنوان هنا مثال لا تستخدمه خارج لابك. وجود -Server لا يغير خوادم DNS للواجهة؛ يوجه هذا الاستعلام المحدد. الفرق مهم إذا كانت المقارنة تهدف لمعرفة هل جهة اللاب تعرف السجل بينما جهة الطلب المعتاد لا تجيب كما توقعت.

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

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

اقرأ Target وPort وPriority وWeight بدون اختراع معنى

سجل SRV يصف جهة الخدمة والمنفذ وبعض معلومات اختيارها. Target يشير إلى اسم الجهة، وPort إلى منفذ الخدمة في السجل. Priority وWeight يدخلان في طريقة تفضيل وجهات الخدمة وفق قواعد SRV؛ الرقم الأقل في الأول يدل على أولوية أعلى، والثاني يستخدم بين سجلات لها الأولوية نفسها بحسب الآلية المحددة.

لا تقرأ Priority كدرجة خطورة أمنية، ولا Weight كنسبة تحميل CPU على الخادم. هذه قيم اكتشاف خدمة في DNS. كذلك كون المنفذ 389 في سجل LDAP لا يثبت أن الخدمة تستجيب الآن أو أن أي حساب يستطيع البحث فيها. الإعلان عن جهة مختلف عن نجاح الاتصال والمصادقة والتفويض عليها.

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

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

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

بعد SRV: هل اسم Target يحل إلى عنوان مناسب؟

خلنا نفترض أن القراءة رجعت dc01.lab.test. الخطوة المنطقية أن تسأل عن عنوان هذا الاسم، ضمن النطاق نفسه. على ويندوز يمكن قراءة A مثلًا:

Resolve-DnsName -Name dc01.lab.test -Type A -DnsOnly -Server 10.10.20.10

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

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

بعدها فحص خدمة معتمدة على Target يجاوب سؤال الوصول، لكنه لا يعيد إثبات كل قرارات اكتشاف العميل. مثلًا استجابة LDAP أو نجاح TCP إلى منفذ محدد له معنى محدود. لا تكتب أن الدومين «جاهز بالكامل» بعد حل الاسم وفتح منفذ؛ المصادقة والحقوق وبقية الاعتماديات تحتاج اختبارها وفق غرض المهمة.

وهنا تستفيد من الربط بين الطبقات: سجل SRV موجود، لكن Target لا يحل؟ راجع حل اسم الجهة. Target يحل لكن الخدمة لا تصل؟ راجع المسار والاستماع حسب التصميم. الخدمة تصل لكن الحساب يرفض؟ انتقل إلى رسالة المصادقة وسياقها. تقسيم المشكلة أدق من إعادة تثبيت أدواتك لأن النتيجة النهائية كانت فشلًا.

نتيجة فارغة، NXDOMAIN، وTimeout: ثلاث حالات لا تسميها كلها «DNS خربان»

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

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

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

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

ولا تكرر الاستعلام بوتيرة عالية لأنك تنتظر «جوابًا صح». إذا كانت المشكلة مؤقتة، تكفي إعادة محدودة لها سبب واضح ووقت معروف، أو قراءة مراقبة معتمدة. كثرة المحاولات بلا تغيير أو تفسير تنتج ضوضاء، وما تجعل نتيجة سابقة أقل حاجة للفهم.

التخزين المؤقت وSites: ليش جهازان قد يشوفان سلوكًا مختلفًا؟

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

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

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

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

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

تمرين تشخيص كامل بدون تعديل سجل واحد

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

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

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

للقراءة المكملة، شرح ldapsearch وشرح Clock Skew في المجتمع:
https://courses.cyberpts.com/community/70/shrh-ldapsearch-ma-active-directory-abhth-mn-lynks-wafhm-lysh-alntyjh-naqsh-aw-f
https://courses.cyberpts.com/community/78/khta-clock-skew-fy-kerberos-afhm-akhtlaf-alwqt-wafhsh-bastkhdam-w32tm

المراجع: توثيق مايكروسوفت للتحقق من سجلات SRV وDC Locator، ومعيار SRV في RFC 2782:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/verify-srv-dns-records-have-been-created
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/dc-locator
https://www.rfc-editor.org/rfc/rfc2782.html

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