المنتديات

مجالات بحث DNS لا تعمل / يتم تجاهلها

الخامس

v654321

ملصق أصلي
6 أغسطس 2011
فيلفورد ، بلجيكا
  • 22 مايو 2021
أواجه مشكلة تتعلق بمجالات بحث DNS التي لا تعمل و / أو يتم تجاهلها. لقد كنت أحاول استكشاف المشكلة وإصلاحها / تحديد المشكلة ولكن للأسف دون جدوى. لقد بحثت في goog بشكل مكثف إلى حد ما وجربت خيارات متعددة مثل مسح ذاكرة التخزين المؤقت لنظام أسماء النطاقات وإعادة تعيين إعداد الشبكة بالكامل وإضافة ملفات / etc / وحدة الحل / lan وما إلى ذلك ، ولكن لا شيء يبدو أنه يعمل. آمل أن يرشدني أحدكم إلى الاتجاه الصحيح أو التحدث من منطلق خبرته حول كيفية إصلاحه. أنا في حيرة لأن تكوين dhcp / dns يعمل بشكل كامل خارج الصندوق على جميع أجهزة Linux / Windows الأخرى ، لكن MBP الخاص بي لا يحب دقة اسم المضيف الداخلي.

بيان المشكلة: يحصل MBP الخاص بي على عنوان IP يتم تعيينه عبر DHCP ، باستخدام Pi-hole ، مع محلل DNS غير منضم. أستخدم اسم المجال الداخلي 'home.arpa' والذي تتم إضافته كمجال بحث DNS ، بما في ذلك عنوان IP لخادم DNS الخاص بي (192.168.1.4). كل جهاز على شبكتي له اسم مضيف.

على أجهزة Linux و Windows الخاصة بي ، يمكنني اختبار اتصال نفس الجهاز تمامًا باستخدام FQDN (على سبيل المثال. ap12.home.arpa أو kodi.home.arpa) واسم المضيف نفسه (على سبيل المثال. ap12 أو kodi) حيث تتم إضافة مجال البحث تلقائيًا . ومع ذلك ، في MBP الخاص بي ، فإنه ببساطة لا يعمل ، كما لو أن مجال البحث ليس موجودًا / يتم تجاهله. يمكنني تنفيذ الأمر ping على FQDN ولكن اسم المضيف نفسه يفشل دائمًا. لم أقم بتزويد ملفي / private / etc / hosts بأسماء المضيف هذه أو FQDN حيث يجب أن يعتني تكوين DNS بذلك (وهو يفعل على أجهزتي التي لا تعمل بنظام MacOS). لقد حاولت حتى مع تكوين IP الثابت (كل من مجالات بحث IP و DNS و DNS الثابتة) ولكن لا فرق.

أعتذر إذا لم يتم تقدير ذلك ، لكنني أضفت بعض لقطات الشاشة لكل من Windows و Linux و MacOS Big Sur مع نتائج التكوين و ping الخاصة بهم:

نظام التشغيل Windows 10:
عرض عنصر الوسائط '>

لينكس:

عرض عنصر الوسائط '>

ماكوس بيج سور:

عرض عنصر الوسائط '>


مما كشفه موقع googling الخاص بي ، يبدو أن مجال البحث يمثل مشكلة ظهرت في الماضي للعديد من المستخدمين ، لكنني لم أجد أي سلاسل رسائل جعلت هذه مشكلة هيكلية. كان مرتبطًا في معظم الأحيان بـ VPN (DNS المقسم للنفق) أو نطاقات البحث المفقودة / الخاطئة. جعلني أستنتج أنه مع التكوين المناسب ، تم اعتبار كل شيء يعمل.

آمل بصمت أن يتمكن بعضكم من توجيه / مساعدتي في اكتشاف الخطأ الذي قد يكون أو ما يمكنني فعله للتخفيف من حدة ذلك. من الواضح أنني أستطيع ترميز أسماء المضيفين / FQDN في الملف / private / etc / hosts ، ولكن بما أنني ألعب مع الكثير من أجهزة الكمبيوتر وأجهزة VM ، أود أن أكون قادرًا على الاعتماد على حل DNS المؤتمت بالكامل.

شكرًا مقدمًا على اهتمامك / مشاركتك المحتملة!

HenryAZ

9 يناير 2010


الكونغرس الجنوبي من الألف إلى الياء
  • 22 مايو 2021
قال v654321: بيان المشكلة: تحصل MBP على عنوان IP مخصص عبر DHCP ، باستخدام Pi-hole ، مع محلل DNS غير منضم. أستخدم اسم المجال الداخلي 'home.arpa' والذي تتم إضافته كمجال بحث DNS ، بما في ذلك عنوان IP لخادم DNS الخاص بي (192.168.1.4). كل جهاز على شبكتي له اسم مضيف.

هل لديك منطقة محلية مهيأة لـ home.arpa غير منضم على 192.168.1.4؟ الخامس

v654321

ملصق أصلي
6 أغسطس 2011
فيلفورد ، بلجيكا
  • 23 مايو 2021
شكرا لك HenryAZ على مشاركتك!

يتم تكوين المجال الداخلي home.arpa في واجهة الويب pihole. ربما لم يكن وصف الإعداد الأصلي الخاص بي كاملاً. اعتذاري لهذا.

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

يعمل تشغيل الأمر التالي على Linux بشكل مثالي (يتم توسيع kodi تلقائيًا مع مجال البحث بحيث يصبح kodi.home.arpa:
$ ping kodi PING kodi.home.arpa (192.168.1.35) 56(84) bytes of data. 64 bytes from kodi.home.arpa (192.168.1.35): icmp_seq=1 ttl=64 time=0.733 ms 64 bytes from kodi.home.arpa (192.168.1.35): icmp_seq=2 ttl=64 time=0.718 ms

ينتج عن هذا السجلات التالية على ثقب:
May 23 13:34:14 dnsmasq[10080]: query[A] kodi.home.arpa from 192.168.1.11 May 23 13:34:14 dnsmasq[10080]: /etc/pihole/custom.list kodi.home.arpa is 192.168.1.35 May 23 13:34:14 dnsmasq[10080]: query[PTR] 35.1.168.192.in-addr.arpa from 192.168.1.11 May 23 13:34:14 dnsmasq[10080]: /etc/pihole/custom.list 192.168.1.35 is kodi.home.arpa

ومع ذلك ، أفعل الشيء نفسه من MBP الخاص بي:
% ping kodi ping: cannot resolve kodi: Unknown host % ping kodi.home.arpa PING kodi.home.arpa (192.168.1.35): 56 data bytes 64 bytes from 192.168.1.35: icmp_seq=0 ttl=64 time=4.889 ms 64 bytes from 192.168.1.35: icmp_seq=1 ttl=64 time=5.530 ms

ينتج عن هذا السجلات التالية على ثقب:
May 23 13:35:26 dnsmasq[10080]: query[A] kodi from 192.168.1.78 May 23 13:35:26 dnsmasq[10080]: config kodi is NODATA-IPv4 May 23 13:35:30 dnsmasq[10080]: query[A] kodi.home.arpa from 192.168.1.78 May 23 13:35:30 dnsmasq[10080]: /etc/pihole/custom.list kodi.home.arpa is 192.168.1.35

يوضح هذا أنه على MBP فشلت محاولة اختبار الاتصال الأولى لأنه لا تتم إضافة مجال البحث تلقائيًا ليصبح FQDN (kodi.home.arpa) بينما يتم معالجة الطلب الثاني بشكل صحيح. يصل كلا الطلبين إلى الحفرة ، لكن لم يتم تطبيق مجال البحث على الرغم من وجوده في تكوين IP على النحو المنصوص عليه من قبل DHCP.

ما لم أفقد شيئًا آخر ، سأجرؤ على استنتاج أنه بالنظر إلى كل من مضيف Linux و MBP يحصلان على معلومات IP و DNS الخاصة بهما من نفس DHCP ، وأنهما يتصلان بخادم DNS نفسه (pihole) وأنه يعمل بشكل مثالي على مضيف Linux الخاص بي (ليس pihole) ولكن ليس على MBP ، لا يتم تطبيق مجال بحث DNS على مضيف أمر ping فقط. ليس لدي أي فكرة حقًا عما يمكنني تغييره لإنجاح هذا العمل.

HenryAZ

9 يناير 2010
الكونغرس الجنوبي من الألف إلى الياء
  • 23 مايو 2021
قال v654321: ما لم أفتقد شيئًا آخر ، سأجرؤ على الاستنتاج أنه بالنظر إلى كل من مضيف Linux و MBP يحصلون على معلومات IP و DNS الخاصة بهم بشكل متماثل من نفس DHCP ، وأنهم يتصلون بنفس خادم DNS (pihole) وأن إنه يعمل بشكل مثالي على مضيف Linux الخاص بي (وليس pihole) ولكن ليس على MBP ، لا يتم تطبيق DNS Search Domain على مضيف فقط أمر ping. ليس لدي أي فكرة حقًا عما يمكنني تغييره لإنجاح هذا العمل.

سأخاطر بتخمين أن تطبيق macOS لـ NetBIOS ليس قويًا مثل التطبيقين الآخرين ، القادرة على حل اسم المضيف فقط. هل تم تمكين NetBIOS على جهاز Mac الخاص بك؟ بشكل افتراضي. لا أعتقد أن مسار البحث مهم حقًا ، حيث يقوم نظاما التشغيل Windows و Linux بتحليل اسم NetBIOS لاسم المضيف للحصول على عنوان IP الخاص به ، بدلاً من DNS.

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