ترتيب تحليل الأسماء على Windows ── hosts والذاكرة المؤقّتة لـ DNS وLLMNR/mDNS وDoH

«الإعدادات نفسها، لكن هذا الحاسوب وحده لا يصل إلى الخادم الداخلي.» «يُفتح في المتصفّح، لكن تطبيق الأعمال يفشل في تحليل الأسماء.» «وضعته في hosts ولا أثر.»

عند التحقيق في مشكلات كهذه، أوّل ما تثبته هو أيّ آليّة تجيب عن ذلك الاسم. لـ Windows عدّة مسارات: الذاكرة المؤقّتة، وhosts، وخادم DNS، وLLMNR، وNetBIOS، وmDNS، وبعض التطبيقات تستخدم مساراً خاصّاً منفصلاً عن Windows.

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

مقدّمات هذه المقالة

تغطي مقالة التقاط الحزم الحزم التي تسري على السلك، وتغطي مقالة الوكيل «إعدادات وكيل من تُقرأ». تغطي هذه المقالة الخطوة قبل ذلك: «من أين جاء عنوان IP للوجهة»، منظَّمة على أساس مصادر Microsoft الأوّليّة.

1. الخلاصة أوّلاً

ثلاثة أمور تُحفَظ.

• تحليل الأسماء على Windows لا يمضي دائماً في طابور واحد بالترتيب. تأتي الذاكرة المؤقّتة وhosts أوّلاً، لكن لاسم أحادي الوسم يعمل DNS وLLMNR/NetBT على التوازي افتراضيّاً.³⁴
• الاسم نفسه يعطي نتائج مختلفة عندما تختلف إعدادات الحاسوب ومسار التطبيق. فكّر في اللواحق وVPN وNRPT ومحلّل المتصفّح المضمَّن منفصلين.⁵⁶⁷
• في تحقيق، قيِّد المسار المستخدَم وقارن النتائج. افصل الذاكرة المؤقّتة وDNS والمحلّي للرابط بمفاتيح Resolve-DnsName، ثمّ أكِّد بفرق إعدادات تجاه حاسوب يعمل وبالتقاط.⁸

استخدم المخطّط التالي خريطة كلّيّة.

flowchart TB
    accTitle: تحليل الأسماء كومة طبقات
    accDescr: يمضي طلب تحليل أسماء من واجهة برمجة التطبيق إلى خدمة DNS Client؛ تُفحَص الذاكرة المؤقّتة وhosts أوّلاً، ثمّ خادم DNS، وللأسماء أحاديّة الوسم فقط يُجرَّب LLMNR وNetBIOS (على التوازي مع DNS افتراضيّاً). لأسماء .local، mDNS مسار إضافي إلى جانب DNS المكوَّن. للمتصفّح محلّل خاصّ خارج هذا الطابور
    app["التطبيق (getaddrinfo)"] --> svc["خدمة DNS Client"]
    svc --> cache["الذاكرة المؤقّتة (بما فيها hosts)"]
    cache -->|إن غابت| dns["استعلام خادم DNS"]
    cache -->|"إن غابت، اسم أحادي الوسم (على التوازي مع DNS افتراضيّاً)"| ll["LLMNR / NetBIOS"]
    svc -->|"اسم .local (مسار إضافي)"| mdns["mDNS"]
    browser["المتصفّح"] -.->|محلّل خاصّ، DoH| ext["مسار منفصل"]

تُفحَص الذاكرة المؤقّتة أوّلاً؛ وبعدها يعمل DNS، وللأسماء أحاديّة الوسم LLMNR وNetBIOS، على التوازي. للمتصفّح مسار منفصل.

فيما يلي، «أيّ طبقة تجيب» مشمول في الفصول 3 إلى 5، و«كيف يُرسَل الاستعلام» في الفصل 6، و«كيفيّة التحقّق» في الفصلين 7 و8. DoH ميزة تبدّل النقل إلى خادم DNS إلى HTTPS؛ لا تستبدل ترتيب hosts والذاكرة المؤقّتة وNRPT.⁹

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 48، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. «تحليل الأسماء» ليس عمليّة واحدة

كلّ ما يعود إلى التطبيق عنوان أو خطأ

عندما يتّصل تطبيق باستخدام اسم مثل www.example.com، تُستدعى getaddrinfo في Winsock (الإصدار Unicode هو GetAddrInfoW). لمساحة الأسماء NS_DNS، تحوّل هذه الدالّة الاسم إلى عنوان عبر DNS وملف hosts المحلّي وآليّات أخرى. إن ردّ عدّة موفِّري مساحة أسماء، تجمع استجاباتهم وتعيدها.¹⁰

بعبارة أخرى، من النتيجة التي يتلقّاها التطبيق، لا تستطيع أن تعرف أيّ طبقة أجابت.

يستخدم Dns.GetHostAddresses في .NET أيضاً getaddrinfo على Windows. لمضيف مدرَج في hosts، يعيد ذلك العنوان دون استعلام خادم DNS. يعمل HttpClient فوق صنف Dns هذا أيضاً، لذا يرث تطبيق .NET يتّصل مباشرة بوجهته ترتيب تحليل الأسماء على Windows.¹¹

عبر وكيل HTTP، يتغيّر الاسم الذي يُحلّ. ما يُحلّ محلّيّاً هو اسم الوكيل؛ يُحلّ اسم الوجهة في جانب الوكيل. في تلك الحالة لا دور لـ hosts المحلّي والذاكرة المؤقّتة واللواحق وNRPT في حلّ الوجهة. أيّ إعدادات وكيل تُستخدَم مشمولة في مقالة الوكيل.

2.1 خدمة DNS Client تقرّر الترتيب

ما يعمل تحت getaddrinfo هو خدمة DNS Client (اسم الخدمة Dnscache). تصف وثائق Microsoft الترتيب الأساسي كما يلي.³

1. افحص الذاكرة المؤقّتة.
2. افحص ملف hosts.
3. استعلم خادم DNS.

لأنّ محتويات hosts تُحمَّل إلى الذاكرة المؤقّتة عند بدء الخدمة، تعامل هذه المقالة الأوّلين معاً الطبقة 1، «الذاكرة المؤقّتة وhosts».⁵

بعد ذلك يتفرّع المسار حسب الاسم والنهج.

يرسل «تحليل الأسماء الذكي متعدّد المنازل» الافتراضي استعلامات DNS وLLMNR وNetBT إلى جميع الشبكات على التوازي. أيّ استجابة تُعتمَد تُقرَّر بقواعد القسمين 4.3 و5.2.⁴

لذلك، «متى يُرسَل الاستعلام» و«الأولويّة المعطاة للأجوبة التي تعود» أمران مختلفان. رؤية LLMNR أو NetBT في التقاط لا تعني بمفردها «فشل DNS». «الطبقات الثلاث» في هذه المقالة تقسيم للشرح؛ لا تعني أنّ الطبقات تجري دائماً بالتتابع زمنيّاً.

2.2 أشياء خارج الطابور

الأسهل خلطاً هما هذان.

استخدام العميل المضمَّن في Edge لا يعني بمفرده أنّ خادم DNS يتغيّر. يعامله القسم 6.2 منفصلاً عن إعداد Secure DNS الذي يختار موفِّراً مختلفاً.

3. الطبقة 1 ── الذاكرة المؤقّتة وhosts

ما تريد معرفته في هذه الطبقة هو أيّ أجوبة تبقى داخل الحاسوب. تحمل الذاكرة المؤقّتة لا الأجوبة الصحيحة فحسب بل أيضاً أجوبة قديمة وأجوبة «الاسم غير موجود».

3.1 hosts يُحمَّل إلى الذاكرة المؤقّتة

ملف hosts في C:\Windows\System32\drivers\etc\hosts. عندما تبدأ خدمة DNS Client، تُحمَّل تعيينات الاسم إلى عنوان IP إلى ذاكرة المحلّل المؤقّتة. تُحفَظ السجلات الحاصلة من استعلامات DNS في الذاكرة المؤقّتة نفسها لمدّة TTL (وقت البقاء).⁵

يعرض ipconfig /displaydns كلاً من القيود المحمَّلة من hosts والقيود الحاصلة من استعلامات DNS حديثة.¹³ في مثال Microsoft نفسه، إن وضعت contoso.com في hosts، يعيد Resolve-DnsName contoso.com ذلك العنوان ولا تسري حركة DNS.³

كيفيّة قراءة غياب حزم DNS

إن حلَلت FQDN بلا DoH أو DoT، ونجح تحليل الأسماء، ولا يوجد استعلام على المنفذ 53، فالأرجح أنّ الذاكرة المؤقّتة أو hosts تجيب. أوّلاً مع ذلك، استبعد المسارات الأخرى التالية.

لا تستنتج «ذاكرة مؤقّتة» لمجرد أنّ «لا شيء على المنفذ 53»؛ انظر إلى المسارات التي يمكن أن تكون مستخدَمة أيضاً. سطر واحد من hosts اختباري متروك على آلة تطوير يمكن أن يضلّل تحقيقاً.

يتطلّب تحرير hosts صلاحيات مسؤول، وقد تكتشف منتجات أمنيّة التغيير. ينبغي تجنّب تصميم يجعل تشغيل تطبيق الأعمال يعتمد على hosts.

3.2 الردود السلبيّة تُخزَّن أيضاً

«غير موجود» أيضاً واحد من الأجوبة التي تُخزَّن. يخزّن عميل DNS الردود السلبيّة كما الإيجابيّة.⁵

إن أظهر ipconfig /displaydns «Name does not exist» للاسم المستهدف، يبقى ردّ سلبي من خادم DNS على العميل. يخبرك إجراء Microsoft بطرحه بـ ipconfig /flushdns.¹⁴¹³

زمن احتفاظ الذاكرة المؤقّتة السلبيّة هو MaxNegativeCacheTtl تحت HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters، والافتراضي 5 ثوانٍ.¹⁵ هذا سبب استمرار حاسوب في إعادة إخفاقات لثوانٍ قليلة حتّى مباشرة بعد إضافة سجلّ إلى DNS.

3.3 TTL و«بعض الحواسيب فقط قديمة»

تبقى الردود الإيجابيّة أيضاً لمدّة TTL. حاسوب حلّ الاسم قبل تغيير عنوان IP للخادم يواصل استخدام الجواب القديم، بينما حاسوب يحلّه لأوّل مرّة بعد التغيير يحصل على الجديد. وحتّى مع خادم DNS نفسه، تختلف النتيجة عندما يختلف وقت البحث.⁵

يتصرّف Clear-DnsClientCache كـ ipconfig /flushdns ويحذف محتويات الذاكرة المؤقّتة كلّها، بما فيها الردود السلبيّة.¹⁶ بـ Get-DnsClientCache، يمكنك استرداد الذاكرة المؤقّتة كائنات وفحص نوع السجلّ وTTL المتبقّي.¹⁷

# هل اسم معيّن في الذاكرة المؤقّتة، وكم ثانية TTL تبقى؟
Get-DnsClientCache -Entry 'app01.corp.example.com' |
    Select-Object Entry, Type, Status, TimeToLive, Data

# افحص محتويات hosts والذاكرة المؤقّتة معاً
ipconfig /displaydns | Select-String -Pattern 'app01' -Context 0,6

# اطرح الذاكرة المؤقّتة (بما فيها الردود السلبيّة)
Clear-DnsClientCache

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

4. الطبقة 2 ── استعلام خادم DNS

إن لم يكن للطبقة 1 جواب، يمضي التحليل إلى DNS. هنا، فكّر منفصلاً في أيّ اسم يُرسَل، وإلى أيّ خادم، وبأيّ توقيت.

4.1 الأسماء أحاديّة الوسم واللواحق

أوّلاً، افحص شكل الاسم الذي مرّره التطبيق.⁵

اللاحقة هي جزء المجال المُلحَق بعد اسم قصير. إلحاق corp.example.com بـ app01 يجعل الاسم المستعلَم app01.corp.example.com.

عندما توجد قائمة بحث

تُلحَق لواحق قائمة البحث بلاحقة DNS بالترتيب من الأعلى، ويُرسَل الاسم بنقطة ختاميّة. متى كُوِّنت قائمة بحث، تُستخدَم تلك القائمة فقط. لا تُستخدَم اللاحقة الأوّليّة واللواحق الخاصّة بالاتّصال وتفكيك الاسم.¹⁸

عندما لا توجد قائمة بحث

تُلحَق لاحقة DNS الأوّليّة. إن فُعِّل تفكيك الاسم، يُسقَط الوسم الأيسر بعد كلّ فشل ويُجرَّب الاسم مجدّداً؛ مثلاً، من www.test.contoso.com إلى www.contoso.com. إن كان لمحوّل لاحقة DNS خاصّة بالاتّصال، تُلحَق تلك أيضاً وتُرسَل.⁵

لهذا السبب، يتوسّع server01 نفسه على نحو مختلف في بيئة يوزّع فيها نهج المجموعة قائمة بحث وفي بيئة يوفّر فيها الانضمام إلى المجال لاحقة أوّليّة.

قائمة طويلة تزيد الانتظار أيضاً

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

# الإعدادات الكلّيّة: قائمة البحث والتفكيك
Get-DnsClientGlobalSetting

# لكلّ واجهة: اللاحقة الخاصّة بالاتّصال وإعدادات التسجيل
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering

# خوادم DNS لكلّ واجهة (IPv4 وIPv6 كلاهما)
Get-DnsClientServerAddress | Where-Object ServerAddresses | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

يعيد Get-DnsClientGlobalSetting الإعدادات الكلّيّة مثل قائمة البحث وما إذا فُعِّل التفكيك وإلى أيّ مستوى؛ ويعيد Get-DnsClient الإعدادات لكلّ واجهة.¹⁹²⁰

4.2 ترتيب خوادم DNS المتعدّدة والمهل

عندما «لا يفشل، لكن هناك انتظار ثوانٍ عدّة»، اشتبه بإعادات إرسال إلى خادم DNS لا يردّ. لخوادم DNS المكوَّنة على NIC واحدة، يصطفّ توقيت إعادة الإرسال الافتراضي كما يلي.²¹

هذا جدول حالة لا ردّ فيها. خصوصاً، لا تخلط الاثنين التاليين.

عندما «أوقفنا واحداً منها لكنّه لا ينتقل»، إن استمرّ خادم يحمل منطقة قديمة في العمل وأعاد ردوداً سلبيّة، لا ينتقل التحليل إلى الخادم التالي.²¹

الخوادم الرابعة فما بعد لا تُبلَغ حتّى مرور 4 ثوانٍ

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

في مثال Microsoft أيضاً، تكوين يكون فيه واحد فقط من أربعة خوادم قابلاً للوصول يستغرق نحو 4 ثوانٍ ليكتمل. يمكنك قياس الوقت المنقضي بـ Measure-Command، وتعامل الوثيقة نفسها أقلّ من ثانية مقبولاً.³

# اسأل خادماً معيّناً مباشرة، DNS فقط، واحصل على الوقت المنقضي بالميلّي ثانية
(Measure-Command {
    Resolve-DnsName -Name 'app01.corp.example.com' -Server 10.0.1.2 -DnsOnly
}).TotalMilliseconds

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

لاحظ أنّ عميل DNS يرفع الخوادم الأسرع ردّاً، ويتذكّر الخوادم التي لا تردّ، ويعيد تجربتها دوريّاً. تُعدَّل المهلة الأوّليّة أيضاً ضمن مدى 25 إلى 1,000 ميلّي ثانية استناداً إلى الأداء السابق. الجدول أعلاه هو الهيكل الافتراضي، ولهذا تنحرف القياسات الفعليّة عنه.⁵

4.3 عدّة NIC و«تحليل الأسماء الذكي متعدّد المنازل»

على حاسوب بسلكي وWi-Fi، أو حاسوب يُضاف إليه محوّل VPN، افحص لا قائمة خوادم DNS فحسب بل أيضاً الاستعلام عبر الشبكات واختيار الاستجابة.

إعادة الإرسال إلى محوّلات متعدّدة

في إجراء استعلام Microsoft، يذهب الاستعلام إلى خادم DNS الأوّل للمحوّل المفضَّل، بانتظار ثانية واحدة. إن لم يكن هناك ردّ، يذهب إلى الخادم الأوّل لكلّ محوّل ما زال في مجموعة المرشّحين، بانتظار ثانيتين، وبعد ذلك إلى جميع خوادم جميع المحوّلات، بانتظار 2 و4 و8 ثوانٍ. عندما يعيد خادم على محوّل ردّاً سلبيّاً، تُزال الخوادم الأخرى لذلك المحوّل من المرشّحين.⁵

النهج الذي يتحكّم في الاستعلام المتوازي

يتحكّم إعداد نهج المجموعة «Turn off smart multi-homed name resolution» في السلوك التالي.⁴

لأنّ النهج اسمه «Turn off»، لاحظ أنّ تفعيل النهج يعطّل التحسين.

مثال تتغيّر فيه النتيجة بـ VPN

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

مع ردّين إيجابيّين، يُحسَم الاعتماد بترتيب الربط. على Windows الحالي، تُقرَّر هذه الأولويّة بمقياس الواجهة؛ كلّما صغر InterfaceMetric الذي يعرضه Get-NetIPInterface، ارتفعت الأولويّة. فروق هذا الترتيب من حاسوب إلى آخر تصير فروقاً في النتيجة.²²

إن أعاد جانب المنزل، من جهة أخرى، ردّاً سلبيّاً، يُزال ذلك المحوّل من المرشّحين ويُستخدَم جواب جانب VPN.⁵ توزّع منتجات VPN NRPT أو «Turn off smart multi-homed name resolution» بالضبط للتحكّم في هذه الفروق.

4.4 NRPT ── تغيير وجهة الاستعلامات لكلّ مساحة أسماء

NRPT (Name Resolution Policy Table) جدول يحدّد، لكلّ مساحة أسماء مثل .corp.contoso.com، أيّ خوادم DNS تُستخدَم وإعدادات DirectAccess وDNSSEC. تكتب ملفّات تعريف DirectAccess وAlways On VPN قواعد فيه لتنتج سلوكاً مثل «أرسل الأسماء الداخليّة فقط إلى DNS الداخلي».²³⁶

يعرض Get-DnsClientNrptPolicy -Effective القواعد السارية فعلاً.

# قواعد NRPT السارية فعلاً
Get-DnsClientNrptPolicy -Effective

# اعرض قواعد مساحة أسماء معيّنة فقط. -Namespace يرشّح فقط على خاصّيّة Namespace؛ لا يطابق اسماً.
# تمرير 'app01.corp.example.com' لا يعيد قاعدة اللاحقة لـ '.corp.example.com'.
# لمعرفة أيّ قاعدة تسري على اسم، عدِّد القواعد وطابقها بنفسك، كما في الخطوة 4 من الفصل 8
Get-DnsClientNrptPolicy -Effective -Namespace '.corp.example.com'

يسري NRPT فقط على تطبيقات تستخدم Windows DNS API. تطبيقات بتحقيق DNS خاصّ تتجاوز ذلك المسار. تستشهد وثائق VPNv2 CSP بـ nslookup مثالاً وتشترط Resolve-DnsName لفحص NRPT. محلّل المتصفّح المضمَّن وDoH أيضاً خارج Windows DNS API.⁶

5. الطبقة 3 ── مسارات الهروب للأسماء أحاديّة الوسم: LLMNR وNetBIOS ثمّ mDNS

5.1 كيف تختلف البروتوكولات الثلاثة

LLMNR وNetBIOS over TCP/IP (NetBT) وسيلتان بديلتان لحلّ اسم أحادي الوسم مثل app01. افتراضيّاً يعملان على التوازي مع DNS، ويمكن اعتماد ردّ محلّي للرابط حتّى عندما يعيد DNS ردّاً إيجابيّاً. يصيران متسلسلين بعد فشل DNS فقط عندما عُطِّل تحليل الأسماء الذكي متعدّد المنازل.⁴

mDNS منفصل عن هذين؛ هو مسار إضافي لأسماء .local. ليس مساراً شاملاً ينطلق بعد فشل تحليل DNS لاسم أحادي الوسم.²⁴

وحتّى لـ .local، لا تتخطَّ فحص DNS

.local لا يصير mDNS فقط. إن كان مجال Active Directory شيئاً مثل corp.local، يواصل ذلك الاسم حلّه بخوادم DNS المكوَّنة وNRPT أيضاً. يسمح RFC 6762 أيضاً بالتعايش مع DNS أحادي البث. عند التحقيق في أسماء .local، افحص سياسات DNS وVPN أيضاً.²⁴

يعتمد NetBT على ما إذا وُجد WINS وعلى نوع العقدة

بلا WINS مكوَّن الافتراضي B-node؛ مع خادم WINS واحد حتّى مكوَّن، الافتراضي H-node.²⁹ لا تعبر بثوث LLMNR وNetBT الشبكات الفرعيّة، لكن استعلامات WINS أحاديّة البث ولذلك يمكنها.

يعرض nbtstat -c ذاكرة أسماء NetBIOS المؤقّتة، ويمسح nbtstat -R الذاكرة المؤقّتة ويعيد تحميل LMHOSTS.³¹

5.2 أيّها يتقدّم

أيّ استجابة تتقدّم بعد الاستعلامات المتوازية يُحكَم أيضاً بنهج.⁴

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

5.3 اتّجاه Microsoft: الاتّساق على mDNS

في أبريل 2022، أعلنت Microsoft اتّجاهاً للاتّساق على mDNS وتقليص تحليل أسماء NetBIOS وLLMNR تدريجيّاً.²⁷ أُهملت أيضاً بروتوكولات اكتشاف أجهزة قديمة وغير آمنة مثل Computer Browser.³² التصاميم التي تكمّل الأسماء أحاديّة الوسم ببث متعدّد أو بث في طريقها إلى الخروج.

تسرد معلومات Microsoft عن ثغرة LLMNR، بوصفها حلولاً بديلة، حظر TCP/UDP 5355 وتفعيل إعداد نهج المجموعة «Turn off multicast name resolution». تنصّ أيضاً على أنّه نتيجة لذلك قد يصير الحاسوب غير مرئي لحواسيب أخرى.²⁵ تفعيل هذا النهج يعطّل LLMNR على جميع محوّلات عميل DNS.⁴

قرار تعطيلهما نفسه صحيح، لكن يجب توفير بديل للمسار الذي يختفي في DNS. لأجهزة غير مسجَّلة في DNS، سجّل سجلات A أو فعِّل التسجيل الديناميكي عبر DHCP، وغيّر الوجهات إلى FQDN. يمكن لأجهزة تدعم mDNS استخدام أسماء .local، لكن المدى مقصور على حيث يمرّ البث المتعدّد.

5.4 حالة «بعض الحواسيب فقط لا تتّصل» النموذجيّة: الأسماء أحاديّة الوسم

عندما يحتوي ملف تكوين أو اختصار \\fileserver01 أو http://app01/، ينتج الاسم نفسه الفروق التالية.

ما يخبرك به Resolve-DnsName app01 -LlmnrOnly هو «ما إذا كان يمكن حلّه عبر LLMNR». لا يخبرك من أين جاء الجواب المعتمَد في الاستعلامات اليوميّة. تُجرى المقارنة بالنتيجة بلا مفاتيح، والتقاطات، في الخطوة 5 من الفصل 8.⁸

الإصلاح الجذري هو FQDN وتسجيل DNS

غيّر الوجهات التي تعتمد على أسماء أحاديّة الوسم إلى FQDN، ووحِّد تحليل الأسماء على DNS.

تتّصل SMB2 فما بعده مباشرة على TCP 445 ولا تستخدم جلسات NetBIOS.³³ غير أنّ ذلك شأن نقل. في مرحلة حلّ الاسم في وجهة مثل \\fileserver01\share، قد يُستخدَم LLMNR أو NetBT. حدِّد FQDN، كما في \\fileserver01.corp.example.com\share، لإزالة الاعتماد على مسار الاسم أحادي الوسم.

تبقى بعض التحفّظات حتّى مع FQDN، مع ذلك. يُجرَّب FQDN بلا نقطة ختاميّة أيضاً بلواحق إن فُعِّل النهج الذي يلحق لواحق بأسماء متعدّدة الوسوم. قد يستخدم اسم ينتهي بـ .local mDNS إلى جانب DNS. الشكل الذي يثبّت الاسم بلا شرط هو الاسم المطلق بنقطة ختاميّة. مقدّمة معاملة «FQDN مثبَّت على DNS» صحيحة عمليّاً أنّ النهج أعلاه معطَّل وأنّ اسم المجال الداخلي لا يستخدم .local.

6. النقل إلى خادم DNS ── DoH لا يغيّر الترتيب

6.1 DoH على Windows 11 / Windows Server 2022

DoH في Windows ميزة ترسل استعلامات إلى خادم DNS عبر HTTPS. يندمج مع hosts والذاكرة المؤقّتة وNRPT القائمين، ومع إعدادات المحلّل لكلّ محوّل ولكلّ ملف تعريف؛ لا يستبدل الترتيب الموصوف في الفصلين 3 و4.⁹

يدعم عميل DNS في Windows 11 DoH، وتدعم الإصدارات الأحدث أيضاً DoT (DNS over TLS). غير أنّ وصف Microsoft لا ينصّ على أيّ إصدارات تدعم DoT، لذا لا يُضمَن توفّره على كلّ بيئة تفترضها هذه المقالة. ما يلي يغطّي DoH.⁹

أوّلاً، افحص قائمة خوادم DoH المعروفة

ما لم يُفعَّل DDR، لا يمكن استخدام إلا الخوادم في قائمة خوادم DoH المعروفة. تحتوي القائمة الافتراضيّة على Cloudflare وGoogle وQuad9، ويمكن فحصها بـ Get-DnsClientDohServerAddress. لخادم DNS داخلي وما شابه، سجّل قالب DoH مع إعدادات الرجوع والترقية التلقائيّة.¹³⁴

# قائمة خوادم DoH المعروفة
Get-DnsClientDohServerAddress

# سجّل خادم DNS الداخلي خادم DoH (بلا رجوع إلى النصّ الصريح، مع ترقية تلقائيّة)
Add-DnsClientDohServerAddress -ServerAddress '10.0.1.2' `
    -DohTemplate 'https://dns.corp.example.com/dns-query' `
    -AllowFallbackToUdp $false -AutoUpgrade $true

التسجيل ممكن أيضاً بـ netsh dnsclient add encryption. الإعداد الكلّي netsh dnsclient set global doh=yes|no|auto إعداد منفصل عن autoupgrade لكلّ خادم.³⁵

auto وحده لا يحظر الرجوع إلى النصّ الصريح. ما إذا يُرجَع إلى UDP عند الفشل يُقرَّر منفصلاً بـ udpfallback لكلّ خادم، أو -AllowFallbackToUdp في PowerShell. لتقييد التحليل بالنقل المشفَّر فقط، عطِّل الرجوع أيضاً.³⁵

مع DDR مفعَّلاً، يوجد أيضاً مسار اكتشاف ديناميكي

على إصدارات تدعم DDR (Discovery of Designated Resolvers)، يمكن لمحلّل مكوَّن بنصّ صريح الإعلان عن نقاط نهاية DNS المشفَّرة. لأنّ الاتّصال يمكن ترقيته إلى التشفير بلا تسجيل في القائمة الثابتة، لا تستطيع القول «ليس في القائمة، لذا ليس DoH».³⁵

ليعمل DDR، يلزم كلا netsh dnsclient set global ddr=yes الكلّي وset interface <name> ddr=yes لكلّ محوّل. ما إذا يُرجَع إلى النصّ الصريح عندما يفشل تحليل مشفَّر حاصل عبر DDR يُقرَّر بـ ddrfallback، وهو معطَّل افتراضيّاً.

في تحقيق، إلى جانب القائمة المعروفة، افحص netsh dnsclient show global وnetsh dnsclient show state، والقيم المضبوطة بـ set interface على محوّلات لها خوادم DNS. أوامر show الفرعيّة المعرَّفة في الوثائق هي encryption وglobal وstate؛ لا يوجد أمر show فرعي خاصّ بالمحوّل.³⁵

افصل «السماح» و«الاشتراط» والرجوع إلى النصّ الصريح

في تطبيق الإعدادات، اضبط إعدادات DNS يدوياً؛ يمكن اختيار «Preferred DNS encryption» فقط عندما يكون خادم DNS المفضَّل في القائمة المعروفة. هناك ثلاثة خيارات.¹

لإعداد نهج المجموعة «Configure DNS over HTTPS (DoH) name resolution» Allow وProhibit وRequire. مع Allow، يُستخدَم DoH عندما، بالإضافة إلى تسجيل في القائمة المعروفة، تُستوفى شروط مثل الترقية التلقائيّة أو إعداد تشفير المحوّل أو doh=auto الكلّي. مع «Require»، يفشل تحليل الأسماء نفسه تجاه خوادم لا تدعم DoH.¹³⁵

لا تطبِّق «Require DoH» على حواسيب منضمّة إلى مجال. تحذّر Microsoft من هذا صراحة. تعتمد خدمات مجال Active Directory بشدّة على DNS، وخدمة DNS Server التي تشحن مع Windows Server لا تدعم استعلامات DoH.¹

في التقاط، اقرأ الإعدادات والحركة الفعليّة منفصلتين

الاستعلامات المرسلة فعلاً عبر DoH تمضي داخل TLS على المنفذ 443 لا UDP 53. غير أنّه حتّى مع «Allow DoH»، تسري استعلامات خوادم ليست في القائمة المعروفة، والرجوع بعد فشل تشفير، بنصّ صريح. كون DoH مكوَّناً لا يجعل حركة المنفذ 53 تختفي.

إن لم تكن استعلامات DNS مرئيّة، افحص DoH وDoT (المنفذ 853) بالإضافة إلى hosts والذاكرة المؤقّتة. لكيفيّة التقاط، انظر مقالة التقاط الحزم.

6.2 DoH في المتصفّح منفصل عن نظام التشغيل

يسهل فهم عميل DNS المضمَّن في Edge وتغيير وجهة الاستعلام عبر Secure DNS عندما يُقسَمان إلى مرحلتين.

يُتحكَّم في العميل المضمَّن بـ BuiltInDnsClientEnabled، وتُجرى استعلامات DoH دائماً بالمحلّل المضمَّن.⁷ Secure DNS معطَّل افتراضيّاً على حواسيب تديرها منظّمة ويُكوَّن بـ DnsOverHttpsMode (off / automatic / secure) وDnsOverHttpsTemplates.³⁶³⁷

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

الخلاصة: لا تعامل نجاح المتصفّح ونجاح تطبيق الأعمال دليلاً عن المسار نفسه. افحص مسار نظام التشغيل بـ Resolve-DnsName أو ping.

7. أيّ مسار يسلكه التطبيق؟

قبل اختيار أدوات تحقيق، وافق المسار الذي تنظر إليه.

المفاتيح الرئيسة لـ Resolve-DnsName، منظَّمة حسب غرض التحقيق، كما يلي.⁸

7.1 A وAAAA: IPv6 يعود أوّلاً

حتّى عندما ينجح تحليل الأسماء، يمكن لاختيار العنوان الذي يلي أن يجعل الاتّصال بطيئاً.

يستعلم عميل DNS كلاً من A (IPv4) وAAAA (IPv6). في التقاط أيضاً، يظهر الاستعلامان زوجاً.³ بعد عودة الأجوبة، تختار getaddrinfo ومكدّس الاتّصال العنوان المستخدَم. يستخدم Windows Vista فما بعده جدول بادئة RFC 3484، ويفضّل افتراضيّاً البث الأحادي العام لـ IPv6 على IPv4.³⁸

غير أنّ جواب AAAA وحده لا يعني أنّ اتّصال IPv6 يُحاوَل دائماً. يطرح اختيار الوجهة أوّلاً الوجهات غير القابلة للاستخدام، مثل تلك بلا عنوان مصدر IPv6 أو مسار، ثمّ يرتّب المرشّحين.³⁹

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

لا توصي Microsoft بتعطيل IPv6 علاجاً، لأنّ بعض مكوّنات Windows تتوقّف عن العمل. بدلاً من ذلك، تصف ضبط DisabledComponents على 0x20 لتفضيل IPv4 في سياسة البادئة.³⁸ الحالة التي يحلّ فيها localhost إلى ::1 ويتعارض مع تحقيق افترض 127.0.0.1 مشمولة أيضاً في مقالة التقاط الحزم.

8. إجراء العزل ── اقشر الطبقات من الأعلى

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

الخطوة 1: افحص شكل الاسم

افحص، في سجلّ أو ملف تكوين، الاسم الذي يمرّره التطبيق فعلاً. يتغيّر المسار حسب ما إذا كان اسماً أحادي الوسم، أو ينتهي بـ .local، أو له نقطة ختاميّة. لاسم قصير مثل http://app01/، ابدأ من الإكمال في القسم 4.1 والفروق لكلّ حاسوب في القسم 5.4.

الخطوة 2: هل يمكن حلّه من الذاكرة المؤقّتة وhosts وحدهما؟

Resolve-DnsName -Name 'app01.corp.example.com' -CacheOnly
Get-DnsClientCache -Entry 'app01.corp.example.com'
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String -Pattern 'app01'

يقيّد -CacheOnly هذا البحث بالذاكرة المؤقّتة المحلّيّة فقط. إن تُعلِّم جواب خاطئ من خادم DNS، تعود القيمة نفسها بعد الطرح. كونُه في الذاكرة المؤقّتة ليس دليلاً على أنّ خادم DNS غير مرتبط.⁸

الخطوة 3: هل يمكن حلّه عبر DNS وحده؟

# استبعد hosts، ولا ترسل LLMNR/NetBIOS، واستعلم خوادم DNS المكوَّنة فقط
Resolve-DnsName -Name 'app01.corp.example.com' -NoHostsFile -DnsOnly

إن لم يكن للخطوة 2 جواب ونجحت هذه الخطوة فحسب، فذلك عادة غياب عادي من الذاكرة المؤقّتة. يمكنك تسميتها مشكلة ذاكرة مؤقّتة أو hosts فقط عندما أظهرت الخطوة 2 جواباً قديماً أو خاطئاً أو قيد ذاكرة مؤقّتة سلبيّة.

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

• Get-DnsClientNrptPolicy -Effective: هل توجد قاعدة توجّه الاسم إلى خادم DNS مختلف؟
• Get-DnsClientDohServerAddress ونهج مجموعة DoH: هل ضُبط «Require DoH» تجاه خادم لا يدعمه؟

إن وُجد NRPT، تتغيّر الخوادم المستهدفة في الخطوة 4. إن كان «Require DoH» السبب، يفشل تحليل الأسماء فقط بينما المسار والخادم كلاهما سليم. أنهِ فحوصات القسمين 4.4 و6.1 أوّلاً.

الخطوة 4: اسأل كلّ خادم مباشرة

اجمع خوادم DNS للمحوّلات المتّصلة، وإن سرت قاعدة NRPT على الاسم المستهدف، استبدلها بخوادم تلك القاعدة. ضمّن خوادم DNS المكوَّنة لـ IPv6 فقط أيضاً.

$name = 'app01.corp.example.com'
# اجمع خوادم DNS للواجهات المتّصلة من IPv4 وIPv6 كليهما.
# خوادم متروكة في إعدادات VPN أو مبدّل افتراضي مقطوع ليست جزءاً من مسار التحليل الحالي، لذا استبعدها (لا تُفلت خوادم مكوَّنة لـ IPv6 فقط)
$connected = @((Get-NetIPInterface -ConnectionState Connected).ifIndex | Select-Object -Unique)
$servers = @((Get-DnsClientServerAddress |
    Where-Object { $_.ServerAddresses -and ($connected -contains $_.InterfaceIndex) }).ServerAddresses)
# خوادم قاعدة NRPT التي تسري على هذا الاسم (يكتبها Always On VPN أو DirectAccess) لا تظهر في إعدادات المحوّل، لذا اخترها من النهج الفعّال.
# معامل -Namespace لـ Get-DnsClientNrptPolicy يرشّح فقط على خاصّيّة Namespace للقاعدة؛ لا يطابق الاسم.
# لذا طابق قاعدة Any (.) وقواعد اللاحقة (نقطة بادئة؛ تسري على مساحة الأسماء نفسها والنطاقات الفرعيّة) وقواعد FQDN وقواعد البادئة (جزء اسم المضيف؛ أحرف بدل مثل web* مسموحة) بنفسك،
# واعتمد القاعدة الأكثر تخصيصاً (الأطول). قاعدة Any هي الأقصر، لذا تُختار فقط عندما لا تطابق قاعدة أخرى
# Namespace مجموعة سلاسل (تُعرَض Namespace : {.corp.example.com})، لذا وسِّع عناصر كلّ قاعدة للمطابقة ورتِّب بطول مساحة الأسماء المطابقة
# لاسم مطلق بنقطة ختاميّة (app01.corp.example.com.)، انزع النقطة للمطابقة فقط. مرِّر $name الأصلي إلى Resolve-DnsName
$matchName = $name.TrimEnd('.')
$label = $matchName.Split('.')[0]
$matched = foreach ($policy in @(Get-DnsClientNrptPolicy -Effective)) {
    foreach ($ns in @($policy.Namespace)) {
        if (-not $ns) { continue }
        $hit = if ($ns -eq '.') { $true }
               elseif ($ns.StartsWith('.')) { $matchName.Equals($ns.TrimStart('.'), [System.StringComparison]::OrdinalIgnoreCase) -or $matchName.EndsWith($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               elseif ($ns.Contains('.')) { $matchName.Equals($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               else { $label -like $ns }
        if ($hit) { [pscustomobject]@{ Namespace = $ns; Policy = $policy } }
    }
}
$rule = $matched | Sort-Object { $_.Namespace.Length } -Descending | Select-Object -First 1
$policyServers = @()
if ($rule) { $policyServers = @(@($rule.Policy.NameServers) + @($rule.Policy.DirectAccessDnsServers) | Where-Object { $_ }) }
if ($policyServers.Count -gt 0) {
    # إن حدّد NRPT خوادم لمساحة الأسماء هذه، يذهب استعلام الخطوة 3 إلى تلك الخوادم. خوادم المحوّل خارج المسار، لذا استبدلها
    $servers = $policyServers
}
$servers = $servers | Where-Object { $_ } | Select-Object -Unique
foreach ($server in $servers) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $r = Resolve-DnsName -Name $name -Server $server -DnsOnly -ErrorAction Stop
        $status = 'OK'
        # يمكن أن تعود سجلات متعدّدة بترتيب مختلف لكلّ استجابة، لذا رتِّب قبل المقارنة
        $answer = ($r.IPAddress | Sort-Object) -join ','
    } catch {
        # الردود السلبيّة (الاسم غير موجود) وSERVFAIL والمهل تقع هنا. احتفظ بالسبب بدلاً من طرحه
        $status = $_.Exception.Message
        $answer = ''
    }
    [pscustomobject]@{ Server = $server; Status = $status; Answer = $answer; Milliseconds = [int]$sw.ElapsedMilliseconds }
}

أوّلاً، صفّ الخوادم للمقارنة

قد لا يظهر NameServers وDirectAccessDnsServers لـ NRPT في إعدادات DNS للمحوّل. إن سألت الخطوة 3 خوادم NRPT لكن الخطوة 4 تفحص خوادم المحوّل فقط، ينتهي بك الأمر مقارنة مسارات مختلفة.

لـ NRPT أنواع قواعد مثل اللاحقة وFQDN والبادئة وAny (.) ، وتتقدّم القواعد الأكثر تخصيصاً.⁴⁰ يرشّح -Namespace فقط على خاصّيّة القاعدة؛ لا يطابق اسم المضيف. لهذا توسّع الشيفرة أعلاه مساحات أسماء القواعد وتطابقها بالاسم المستهدف.²³

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

ثانياً، اقرأ النتائج منفصلة

إن اختلفتا مجموعات أيضاً، افحص محتويات المنطقة والأرقام التسلسليّة. كذلك، هذا قياس بالوجهة مثبَّتة بـ -Server. التأخير الناجم عن موضع القائمة، «4 ثوانٍ حتّى تُبلَغ الخوادم الرابعة فما بعد» من القسم 4.2، يُفحَص في الخطوة 3 أو في التقاطها.

الخطوة 5: افحص الطبقة المحلّيّة للرابط

Resolve-DnsName -Name 'app01' -LlmnrOnly          # LLMNR فقط
Resolve-DnsName -Name 'app01' -LlmnrNetbiosOnly   # LLMNR أو NetBIOS فقط (بلا DNS)
nbtstat -c                                        # ذاكرة أسماء NetBIOS المؤقّتة

يستهدف هذا الفحص الأسماء أحاديّة الوسم. يرجع -NetbiosFallback إلى NetBIOS فقط عندما يفشل DNS، لذا لاسم يستطيع DNS حلّه ليس فحص NetBIOS.⁸

اقرأ النتائج كما يلي.

يُميَّز أيّ بروتوكول أجاب في التقاط بـ UDP 5355 (LLMNR) مقابل UDP 137 (NetBT). لتأكيد مسار التحليل اليومي، قارن أيضاً بالعنوان الذي يعيده Resolve-DnsName بلا مفاتيح، وإن اختلفا، افحص الاستجابة المعتمَدة في التقاط، لأنّ DNS يُستعلَم افتراضيّاً على التوازي أيضاً.

الخطوة 6: قارن تفريغات الإعدادات

في تحقيق «بعض الحواسيب فقط»، نفِّذ السكربت نفسه على حاسوب يعمل وآخر يفشل وقارن.

# name-resolution-dump.ps1 -- نفِّذ بصلاحيات مسؤول وقارن ملفّي خرج الآلتين جنباً إلى جنب
$out = "$env:COMPUTERNAME-name-resolution.txt"
$sections = [ordered]@{
    'Get-DnsClientServerAddress' = { Get-DnsClientServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'Get-DnsClientGlobalSetting' = { Get-DnsClientGlobalSetting | Format-List | Out-String }
    'Get-DnsClient'              = { Get-DnsClient | Format-Table InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering -AutoSize | Out-String -Width 200 }
    'Get-DnsClientNrptPolicy'    = { Get-DnsClientNrptPolicy -Effective | Format-List | Out-String }
    'Get-DnsClientDohServerAddress' = { Get-DnsClientDohServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'netsh dnsclient show state' = { netsh dnsclient show state 2>&1 | Out-String }
    'Get-NetIPInterface'         = { Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table InterfaceAlias, AddressFamily, InterfaceMetric, ConnectionState, Dhcp -AutoSize | Out-String -Width 200 }
    'DNSClient policy registry'  = { Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue | Format-List | Out-String }
    'ipconfig /all'              = { ipconfig /all | Out-String }
}
$sections.GetEnumerator() | ForEach-Object {
    "===== $($_.Key) ====="
    try { & $_.Value } catch { "ERROR: $($_.Exception.Message)" }  # اترك البنود الناقصة (مثل DoH على Windows 10) مسجَّلة أخطاء
} | Set-Content -Path $out -Encoding UTF8
Write-Host "wrote $out"

ما تقارنه هو ترتيب خوادم DNS، وقائمة البحث، واللواحق الخاصّة بالاتّصال، وNRPT، وDoH، ومقاييس الواجهة، وقيم النهج.

يحمل HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient EnableMulticast لـ «Turn off multicast name resolution»، وDisableSmartNameResolution لـ «Turn off smart multi-homed name resolution»، وقائمة البحث، واللاحقة الأوّليّة، وما إلى ذلك.⁴ افحص الفرق مقابل عمل كلّ طبقة المنظَّم حتّى الآن.

الخطوة 7: عزِّزه بالتقاط حزم

يبدأ إجراء جمع بيانات Microsoft netsh trace start capture=yes على العميل والخادم كليهما، ويطرح الذاكرة المؤقّتة بـ ipconfig /flushdns، ويعيد إنتاج المشكلة، ويتوقّف بـ netsh trace stop.⁴¹

في Wireshark، رشِّح بـ dns.qry.name == "app01.corp.example.com" أو dns.qry.name contains "app01" لترى أيّ خادم سُئل عمّا، وما عاد.

إن حظر الجدار الناري في جانب الإرسال UDP 53، يبلغ Resolve-DnsName المهلة ولا يظهر استعلام DNS في التقاط أيضاً. اعزل لا الحالة التي ينجح فيها تحليل الأسماء ولا تخرج حركة فحسب، بل أيضاً الحالة التي يفشل فيها ولا تخرج حركة.³

إلى جانب DNS، افحص 5355 لـ LLMNR، وUDP 5353 لـ mDNS، وUDP 137 لخدمة أسماء NetBT. DoH هو 443 وDoT هو 853. كيفيّة التقاط وقراءة التقاطات مجمَّعة في مقالة التقاط الحزم.

9. التصميم في جانب تطبيق الأعمال ── جعله متيناً تجاه تحليل الأسماء

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

احمل الوجهات FQDN ولا تعتمد على hosts

اجعل الافتراضيّات في ملفّات التكوين والاختصارات ومسارات UNC FQDN. هذا يزيل الاعتماد على إكمال لاحقة الأسماء أحاديّة الوسم وعلى LLMNR وNetBT. غير أنّ تحفّظات القسم 5.4 تبقى: mDNS إلى جانب DNS لأسماء .local، والنهج الذي يلحق لواحق بأسماء بلا نقطة ختاميّة.

hosts مريح لتجاوز مؤقّت أثناء التطوير، لكنّه يتطلّب صلاحيات مسؤول وعملاً يدويّاً. التوزيع وتاريخ التغيير صعب الإدارة، وبعض المحلّلات لا تستشيره أصلاً (nslookup لا يفعل¹²). بدِّل الوجهات عبر ملفّات التكوين.

سجّل نتيجة تحليل الأسماء والوقت وسبب الفشل

عند البدء ونقاط مشابهة، سجّل عناوين IPv4 وIPv6 والوقت المنقضي للوجهات الرئيسة. لأنّ Dns.GetHostAddresses يعيد النتيجة نفسها لـ getaddrinfo، يمكنك تتبّع «على أيّ حاسوب، منذ متى، إلى ماذا حُلّ».¹¹

// سجّل نتائج تحليل أسماء الوجهات الرئيسة عند البدء (.NET 6 فما بعده)
static async Task LogNameResolutionAsync(ILogger logger, string host)
{
    var sw = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        var addresses = await System.Net.Dns.GetHostAddressesAsync(host);
        logger.LogInformation("تحليل الأسماء {Host} -> {Addresses} ({Elapsed} ms)",
            host, string.Join(",", addresses.Select(a => a.ToString())), sw.ElapsedMilliseconds);
    }
    catch (System.Net.Sockets.SocketException ex)
    {
        logger.LogError(ex, "فشل تحليل الأسماء {Host} خطأ {Code} ({Elapsed} ms)",
            host, ex.SocketErrorCode, sw.ElapsedMilliseconds);
        throw;
    }
}

سجّل الإخفاقات وأعد الرمي. التبديل صامتاً إلى اسم مختلف أو IP ثابت يجعل المسار الفعلي غير قابل للمعرفة أثناء تحقيق. مع رمز الخطأ والوقت المنقضي، يستطيع موظّفو تقنية المعلومات تقرير أين يبدأون في الخطوات 2 إلى 4.

اسمح للمهل وأجوبة IPv6

يقضي عميل DNS حتّى 10 ثوانٍ لكلّ مرشّح مستعلَم تجاه خوادم لا تردّ.²¹ إن أنتجت بحث اللاحقة عدّة مرشّحين، يمكن أن يتجاوز المجموع 10 ثوانٍ.

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

كذلك، عندما يعود جواب AAAA ويوجد عنوان مصدر IPv6 ومسار، يفضّل Windows IPv6 افتراضيّاً.³⁸ شيفرة اتّصال تفترض IPv4 فقط قد تفشل في الاتّصال رغم نجاح تحليل الأسماء. افصل نجاح تحليل الأسماء عن نجاح الاتّصال، وعالج نوعي العنوان كليهما.

10. الخلاصة

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

تجيب الذاكرة المؤقّتة وhosts أوّلاً، وللأسماء أحاديّة الوسم يعمل DNS وLLMNR/NetBT على التوازي افتراضيّاً. لـ .local، ينضمّ mDNS. متى انتقل التحليل إلى DNS، تغيّر اللواحق وتوقيت إعادة الإرسال وعدّة NIC وNRPT النتيجة. DoH ميزة تبدّل ذلك النقل، وتُعتبَر منفصلة عن محلّل المتصفّح المضمَّن.

يقيّد التحقيق المسار بترتيب -CacheOnly، ثمّ -NoHostsFile -DnsOnly، ثمّ -Server، ثمّ -LlmnrOnly، ويؤكّد بفرق إعدادات والتقاط. ما يهمّ ألا تغفل الذاكرة المؤقّتة السلبيّة، والفرق بين لا ردّ وردّ سلبي، ونهج جانب العميل.

عندما «هذا الحاسوب وحده لا يتّصل»، افحص أوّلاً هذين الأمرين.

بأيّ شكل يُمرَّر الاسم؟ على ذلك الحاسوب، أيّ مسار يجيب؟

بهذين مثبتين، يمكنك تضييق أين تنظر.

مقالات ذات صلة

• التقاط الحزم على Windows عمليًّا — الاختيار بين pktmon وnetsh trace وWireshark
• الوكيل المؤسسي وتطبيقات ويندوز — ترتيب حلّ الوكيل في WinINET وWinHTTP و.NET
• لا تُحِط HttpClient بـ using ── الممارسة العملية لاتصال HTTP في تطبيقات C# للأعمال (أنماط الإنشاء والمهلة وإعادة المحاولة)
• جدار حماية Windows وتطبيقات الأعمال ── سجِّلوا القواعد الواردة من المثبِّت
• مطبّات محرّك الشبكة ومسار UNC ── التعامل العملي مع خادم الملفّات (المجلّد المشترك) في تطبيقات الأعمال
• شرح NTLM وKerberos بالرسوم ── لماذا يسقط التوثيق إلى NTLM
• مجموعة أوامر PowerShell العمليّة ── إضافة وظائف صغيرة شائعة الاستخدام في العمل اليوميّ

مجالات الاستشارة ذات الصلة

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

• تحقيق الأعطال وتحليل الأسباب
• الاستشارة التقنيّة ومراجعة التصميم
• تطوير تطبيقات Windows
• التواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

حرّرت ملف hosts لكن التغيير لا يسري. لماذا؟

على Windows تُحمَّل محتويات ملف hosts إلى الذاكرة المؤقّتة عند بدء خدمة DNS Client، ويمضي تحليل الأسماء بترتيب الذاكرة المؤقّتة، ثمّ hosts، ثمّ خادم DNS. عندما لا يسري تغيير، افحص أوّلاً قيد ذلك الاسم بـ ipconfig /displaydns، وإن بقي جواب قديم فاطرحه بـ ipconfig /flushdns. ثانياً، اسأل ما إذا كانت الأداة التي تختبر بها تمرّ بمحلّل Windows أصلاً. لا يستخدم nslookup محلّل نظام التشغيل؛ يتجاوز الذاكرة المؤقّتة وhosts وNRPT ويستعلم خادم DNS مباشرة، لذا لا ينعكس شيء من hosts في خرجه. لرؤية نتيجة التحليل الفعليّة بما فيها hosts، استخدم Resolve-DnsName أو ping. إن لم يسرِ بعد ذلك، افحص ما إذا كان للتطبيق، مثل متصفّح، محلّل خاصّ أو DoH.

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

الأرجح أنّ المتصفّح والتطبيق يحلّان الاسم عبر مسارين مختلفين. افتراضيّاً يتحدّث Microsoft Edge إلى خادم DNS بعميل DNS مضمَّن لا بعميل DNS لنظام التشغيل، وإن اختير موفِّر مختلف تحت Secure DNS (DoH)، يستعلم محلّلاً خارجيّاً. من جهة أخرى، Dns.GetHostAddresses في .NET، وHttpClient يتّصل مباشرة بالوجهة، يمرّان عبر getaddrinfo لنظام التشغيل، لذا يخضعان لـ hosts والذاكرة المؤقّتة لـ DNS وNRPT وقائمة البحث بلاحقة DNS (للطلبات التي تمرّ عبر وكيل HTTP، يُحلّ اسم الوجهة في جانب الوكيل). عندما يعيد الاثنان جوابين مختلفين، أقصر طريق هو مطابقة أيّ مسار سأل أيّ خادم DNS عمّا، باستخدام Resolve-DnsName والتقاط حزم.

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

قارن شكل الاسم والطبقة التي يحصل عندها كلّ حاسوب على جوابه. اسم أحادي الوسم (اسم بلا نقطة، مثل server01) يُكمَل بقائمة البحث بلاحقة DNS للحاسوب أو اللاحقة الخاصّة بالاتّصال ويُرسَل إلى DNS، وافتراضيّاً يُرسَل أيضاً، على التوازي، إلى آليّات مقصورة على الشبكة الفرعيّة نفسها مثل بث LLMNR وNetBIOS (تُجرَّب بالتتابع بعد فشل DNS فقط عندما عُطِّل التحسين؛ إن كُوِّن WINS يستخدم NetBIOS البث الأحادي ويمكنه عبور الشبكات الفرعيّة). قد يحلّ حاسوب منضمّ إلى مجال الاسم لأنّ اللاحقة تكمّله إلى FQDN، بينما حاسوب على VPN أو على شبكة فرعيّة أخرى، أو حاسوب عُطِّل فيه LLMNR وNetBIOS، لا يستطيع حلّ الاسم نفسه. الطريقة الموثوقة جمع خرج Get-DnsClientServerAddress وGet-DnsClientGlobalSetting وGet-DnsClient وGet-DnsClientNrptPolicy -Effective على حاسوب يعمل وآخر يفشل ومقارنتهما. الإصلاح الجذري جعل الوجهات في ملفّات التكوين والاختصارات FQDN.

تحليل الأسماء لا يفشل؛ يستغرق ثواني عدّة قبل أن يمرّ الاتّصال أخيراً. ما السبب؟

هذه آليّة المهلة وإعادة الإرسال لعميل DNS تظهر. تجاه خادم DNS لا يردّ، يعيد Windows الإرسال عند 1 و2 و4 و8 ثوانٍ من البداية ويتخلّى عند 10 ثوانٍ. وحتّى مع عدّة خوادم DNS مكوَّنة، إن كان الذي يردّ رابعاً فما بعد في القائمة، ينتظر Windows 4 ثوانٍ على الأقلّ قبل أن يستعلم ذلك الخادم. قائمة بحث بلاحقة DNS طويلة تكدّس تأخيراً أيضاً، لأنّ اسماً أحادي الوسم يُجرَّب مع كلّ لاحقة بالتتابع. قِس كم يستغرق Resolve-DnsName بـ Measure-Command، وطبق مرشّح dns.qry.name في Wireshark لترى استعلامات أيّ خادم تبقى بلا جواب.

عطّلنا LLMNR وNetBIOS إجراءً أمنيّاً، والآن لم يعد يمكن الوصول إلى بعض الأجهزة بالاسم.

ذلك أثر جانبي متوقَّع. LLMNR وNetBIOS over TCP/IP وسيلتان ثانويّتان لحلّ الأسماء أحاديّة الوسم لأجهزة غير مسجَّلة في DNS ضمن الشبكة الفرعيّة نفسها، وتعطيلهما يزيل ذلك المسار. أعلنت Microsoft نفسها في 2022 اتّجاهاً للاتّساق على mDNS وتقليص تحليل أسماء NetBIOS وLLMNR تدريجيّاً، لذا قرار تعطيلهما نفسه صحيح. العلاج توحيد تحليل الأسماء على DNS: سجّل سجلات A للأجهزة في DNS الداخلي، أو فعِّل التسجيل الديناميكي عبر DHCP، وأعد كتابة وجهات التطبيقات والمشاركات إلى FQDN. يمكن حلّ الأجهزة التي تدعم mDNS بأسماء .local، لكن ذلك المسار أيضاً مقصور على المدى الذي يبلغه البث المتعدّد.

ماذا يحدث لتحليل الأسماء الداخلي عندما أفعّل DoH (DNS over HTTPS) على Windows 11؟

DoH ميزة تبدّل النقل إلى HTTPS عندما يستعلم عميل DNS خوادم DNS المكوَّنة؛ يبقى ترتيب hosts والذاكرة المؤقّتة وNRPT القائم كما هو. ما لم يُفعَّل DDR (Discovery of Designated Resolvers)، لا يمكن استخدام DoH إلا عندما يكون الخادم في قائمة خوادم DoH المعروفة، لذا إن أردت استخدام خادم DNS داخلي، يجب أن يسجّله مسؤول بـ Add-DnsClientDohServerAddress. إن ضُبط إعداد نهج المجموعة «Configure DNS over HTTPS (DoH) name resolution» على «Require DoH»، يفشل تحليل الأسماء نفسه تجاه خوادم لا تدعم DoH. تقول Microsoft صراحة ألا تفعّل هذا الإعداد على حواسيب منضمّة إلى مجال، لأنّ خدمة DNS Server التي تشحن مع Windows Server، والتي يعتمد عليها Active Directory، لا تدعم استعلامات DoH.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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