تُشغّل خادمًا ثالثًا، وتحتاج إلى أن تصل الأجهزة إلى بعضها بالاسم بدلًا من عنوان IP، فتبحث عن "private DNS VPS". تظهر ثلاث نتائج وهي غير متوافقة. إحداها إعداد في Android يشفّر استعلامات هاتفك. وأخرى دليل cPanel لتخصيص خوادم الأسماء لنطاق ما. والثالثة مستند من AWS عن المناطق المستضافة الخاصة. في 20 يوليو 2026، أطلقت Cloudflare خدمة Internal DNS للإتاحة العامة ووصفتها بأنها "يُشار إليها أحيانًا باسم DNS الخاص"، وبذلك أصبح التداخل يأتي الآن من مزوّدي البنية التحتية أيضًا.
المصطلح محمّل بأكثر من معنى. تفصل هذه المقالة بين المعاني المختلفة، ثم تركّز على المعنى الشبكي الخاص بـ VPS: منطقة DNS داخلية للاتصال بين الخوادم. وبنهايتها ستتمكن من تحديد النظام الذي تحتاجه، وتقرير ما إذا كان أسطولك يحتاج إلى DNS خاص، وتجنّب أخطاء التصميم الشائعة.
الخلاصة السريعة
- "DNS الخاص" يسمّي ثلاثة أنظمة غير مترابطة على الأقل: منطقة DNS داخلية لشبكة خوادم، وميزة التشفير DNS-over-TLS في Android، وخوادم الأسماء المخصّصة في cPanel. تستخدم هذه المقالة المصطلح بالمعنى الأول: منطقة DNS داخلية لشبكة VPS.
- منطقة DNS خاصة على VPS هي مساحة أسماء داخلية محصورة بالشبكة تربط أسماء المضيفين مثل
db.internal.example.comبعناوين IP خاصة. ولا تُنشر سجلاتها في DNS العام. - لعدد قليل من الخوادم ذات عناوين IP ثابتة،
/etc/hostsيكفي فعلًا. ويبدأ خادم DNS الداخلي في إثبات جدواه عندما يكبر الأسطول، أو تتبدّل عناوين IP، أو تحتاج الخدمات إلى تحليل أسماء موثوق. - لمعظم شبكات VPS في الإنتاج، استخدم نطاقًا فرعيًا تملكه، مثل
internal.example.com. لا تستخدم مساحة الأسماء .internal إلا في إعداد معزول تكون فيه تصادمات الأسماء بين الشبكات، وإدارة الشهادات عبر سلطة تصديق خاصة، والتعامل الخاص مع DNSSEC أمورًا مقبولة. وتجنّب .local لأن mDNS يحجزها.
ما لا يغطّيه هذا المقال
تقتصر هذه المقالة على المعنى الشبكي لـ DNS الخاص في سياق VPS. وهي لا تتناول الاستخدامات غير المرتبطة لدى المستهلكين وعلامات الاستضافة:
- ضبط إعداد DNS الخاص أو DNS-over-TLS في Android على الهاتف.
- إعداد خوادم أسماء خاصة في cPanel لعلامة استضافة.
- شرح تثبيت كامل لـ BIND 9 أو Unbound أو dnsmasq أو CoreDNS. فالتنفيذ هنا يبقى على مستوى مرجعي، لا على مستوى الإعداد خطوة بخطوة.
- محلّلات الأسماء المشفّرة الموجّهة للمستهلك مثل 1.1.1.1 أو NextDNS، فيما يتجاوز تمييزها عن المعنى الشبكي.
ما الذي يعنيه "DNS الخاص" فعليًا؟
"DNS الخاص" ليس نظامًا واحدًا. فهو يسمّي ثلاثة أنظمة غير مترابطة على الأقل: منطقة DNS مقيّدة بالشبكة تحلّل أسماء المضيفين الداخلية داخل شبكة VPS أو VPC، وميزة التشفير DNS-over-TLS في Android، وخوادم الأسماء المرجعية المخصّصة بعلامة تجارية في cPanel. تتناول هذه المقالة الأول منها، أي المنطقة الداخلية التي تستعلم منها خوادمك لتجد بعضها. وهناك استخدام رابع فضفاض أيضًا: محلّلات عامة مشفّرة تُسوَّق على أنها "خاصة".
المعاني الأربعة تشترك في الاسم فقط لا غير:
| النظام | ما هو | من يستخدمه | ما لا يفعله |
|---|---|---|---|
| منطقة DNS داخلية (VPS/VPC) | مساحة أسماء محصورة بالشبكة تحلّل أسماء المضيفين الداخلية إلى عناوين IP خاصة | مشغّلو VPS وفرق DevOps ومنصات السحابة | لا يشفّر الاستعلامات بطبيعته ولا ينشر سجلاته في DNS العام |
| DNS الخاص في Android | مفتاح DNS-over-TLS يشفّر استعلامات الجهاز عبر المنفذ 853 (منذ Android 9) | مستخدمو الهواتف والأجهزة اللوحية | لا ينشئ أسماء مضيفين داخلية ولا منطقة خاصة |
| خوادم الأسماء الخاصة في cPanel | خوادم أسماء مرجعية بعلامة تجارية مخصّصة لنطاق ما (ns1.yourbrand.com) | شركات استضافة المواقع والموزّعون | لا ينشئ مساحة أسماء خاصة للاتصال بين الخوادم |
| محلّلات الأسماء المشفّرة للمستهلكين | محلّلات عامة تُسوَّق من أجل خصوصية الاستعلامات (1.1.1.1، NextDNS) | الأفراد الذين يريدون خصوصية في عمليات البحث عن الأسماء | لا ينشئ بذاته منطقة مرجعية داخلية |
إعلان Cloudflare عن الإتاحة العامة لخدمة Internal DNS هو مثال مُدار حديث على المعنى الأول، وأحد أسباب ظهور هذا التداخل الآن: صار مزوّد بنية تحتية يستخدم "DNS الخاص" مرادفًا لـ DNS الداخلي في نصوص إطلاقه. والنظام الذي يصفه، وهو Gateway Resolver إلى جانب Internal Authoritative DNS لعملاء Enterprise، ينتمي إلى الفئة نفسها من الأنظمة التي تبنيها بنفسك على أسطول VPS، لكن بصيغة مُدارة.
خلاصة القسم: الأنظمة الرئيسية التي تُسمّى "DNS الخاص" تشترك في التسمية لا في الوظيفة. حدّد المعنى قبل أن تتبع أي دليل إعداد.
كيف يعمل DNS الخاص على شبكة VPS؟
منطقة DNS خاصة على VPS هي مساحة أسماء محصورة بالشبكة يخدمها محلّل تُضبط خوادمك على استخدامه. وهي تربط أسماء المضيفين الداخلية مثل db.internal.example.com بعناوين IP خاصة ضمن نطاق تتحكم فيه. ولا تُنشر هذه السجلات في DNS العام، حتى وإن مرّت الاستعلامات عبر نفق خاص أو مستوى تحكّم DNS مُدار قبل أن تصل إلى المحلّل. هذا الفصل هو جوهر الفرق بين DNS الخاص و DNS العام: البروتوكول نفسه، لكن مدى ظهور المنطقة ونطاق الوصول إليها مختلفان.
ثلاثة أجزاء تقوم بالمهمة. خادم مرجعي أو مصدر منطقة يحتفظ بالمنطقة الداخلية وسجلاتها. ومحلّل يجيب عن الاستعلامات التي ترسلها خوادمك. وسجلات A و AAAA في المنطقة تربط أسماء المضيفين الداخلية بعناوين خاصة، وبذلك app.internal.example.com يُحلّ إلى طبقة التطبيق و db.internal.example.com يُحلّ إلى قاعدة البيانات. ويمكن لأنواع سجلات أخرى أن توفّر أسماء بديلة أو معلومات عن الخدمات. وعندما تُضبط المنطقة ومسار المحلّل بشكل صحيح، يجيب المحلّل عن الاستعلام الداخلي محليًا بدلًا من إرساله نحو جذر DNS العام.
تربط منصات السحابة ذلك بالشبكة لا بالجهاز، وهو نموذج مرجعي مفيد. المناطق المستضافة الخاصة في AWS Route 53 لا تعمل إلا عندما يكون لدى VPC كل من enableDnsHostnames و enableDnsSupport مضبوطين على true، ويجيب المحلّل من المنطقة الخاصة لأي VPC تربطه بها. المناطق الخاصة في Google Cloud محصورة بشبكات VPC المصرّح بها، وفي ترتيب التحليل القياسي في VPC تُفحص قبل DNS العام ما لم تغيّر سياسة خادم صادر هذا المسار. اقرأ ذلك بوصفه توضيحًا للنمط، لا دليلًا لمنصة بعينها: فخادم DNS داخلي تديره بنفسك هو الفكرة نفسها، لكن يعمل على VPS خاص بك.
إبقاء المنطقة خارج DNS العام ليس سوى نصف المهمة. اربط خدمة DNS بواجهة خاصة أو قيّد المنفذ 53 على UDP و TCP بشبكتك الخاصة أو بشبكة VPN. ولا تعرّض الخدمة التكرارية للإنترنت العام؛ فـ المحلّل المفتوح يمكن إساءة استخدامه في هجمات تضخيم DNS.
تستخدم المناطق الخاصة والعامة النموذج نفسه لسجلات DNS والتخزين المؤقت. فالسجلات تحمل قيمة TTL، وعادةً ما تعيد المحلّلات المخزِّنة استخدام الإجابة حتى تنتهي تلك المدة، وإن كانت إعدادات خاصة بكل محلّل قد تغيّر مدة التخزين الفعلية. وهذا السلوك مشروح في دليلنا لتوجيه نطاق إلى VPS، بما في ذلك أساسيات انتشار DNS و TTL، لذا لا يُعاد شرحه هنا.
متى تحتاج شبكة VPS لديك فعليًا إلى DNS خاص؟
لخادمين أو ثلاثة خوادم ثابتة، /etc/hosts يكفي فعلًا. ويثبت خادم DNS الداخلي جدواه عندما يكبر الأسطول، أو تتغيّر عناوين IP بانتظام، أو تحتاج التطبيقات إلى اكتشاف خدمات موثوق. والمحفّز الحقيقي هو التعقيد التشغيلي، لا عدد ثابت من الخوادم.
/etc/hosts هو خريطة ثابتة تربط أسماء المضيفين بعناوين IP وهي موجودة أصلًا على كل جهاز Linux. لا يحتاج إلى خدمة تعمل في الخلفية ولا إلى ملف منطقة، لكن النسخ القديمة أو غير المتسقة أنماط فشل حقيقية. أضف عنوان IP الخاص بكل خادم إلى الملف، وحافظ على تزامن النسخ، عندئذ تستطيع الأجهزة أن تجد بعضها بالاسم. وبالنسبة لأسطول صغير ومستقر فهذه هي الإجابة الصحيحة، أما اللجوء إلى BIND 9 بدلًا من ذلك فيضيف خدمة عليك صيانتها دون أي مكسب.
تتوقف هذه الطريقة عن الصمود في ثلاث حالات. فعندما تضيف الخوادم وتزيلها بكثرة، يتحوّل إبقاء ملف ثابت متسقًا على كل مضيف إلى عمل يدوي مرهق. وعندما تتغير عناوين IP، عبر التوسّع التلقائي أو إعادة البناء أو إعادة التخصيص من المزوّد، يصبح الملف قديمًا في صمت. وعندما لا ترث الحاويات أو بيئات التشغيل المعزولة مدخلات المضيف، يتوقف هذا الربط عن كونه شاملًا. أيّ من هذه الحالات هو المحفّز الحقيقي. أما عدد الخوادم وحده فمؤشّر تقريبي، لا الإشارة الفعلية.
خلاصة القسم: المحفّز هو معدّل التغيّر التشغيلي، لا عدد الخوادم. فأسطول ثابت من عشرة أجهزة يمكن أن يعيش على /etc/hosts؛ أما أسطول من ثلاثة أجهزة يُعاد بناؤه كل ليلة فالأرجح أنه لا ينبغي له ذلك.
ابنِ على خادم Linux VPS بوصول root وتخزين NVMe وقوة AMD EPYC.
عرض باقات Linuxأي خادم DNS ينبغي أن تشغّل: BIND 9 أم Unbound أم dnsmasq أم CoreDNS؟
اختر بحسب شكل أسطولك. يناسب dnsmasq الشبكات الصغيرة التي تريد DNS خفيفًا، ومعه DHCP من الخدمة نفسها عند الحاجة. أما Unbound فهو محلّل تكراري خفيف يتحقق من DNSSEC ويستطيع كذلك الإجابة عن منطقة محلية متواضعة. ويقدّم BIND 9 قدرات مرجعية وتكرارية واسعة مع أكبر مساحة إعدادات. ويناسب CoreDNS أساطيل الحاويات و Kubernetes حيث يكون DNS جزءًا من اكتشاف الخدمات.
| الأداة | الدور | الأنسب لـ | المقايضة |
|---|---|---|---|
| BIND 9 | مرجعي وتكراري بالكامل | الأساطيل التي تحتاج إلى وظائف DNS واسعة ومراجع وفيرة | أوسع مساحة إعدادات وأكبر تعقيد تشغيلي |
| Unbound | محلّل تكراري أو محوِّل مع دعم المناطق المحلية والتحقق من DNSSEC | الأساطيل الصغيرة التي تحتاج إلى التكرار مع منطقة داخلية ثابتة متواضعة | بيانات المنطقة المحلية بسيطة؛ أما السلوك المرجعي المعقّد فمن الأفضل التعامل معه عبر auth-zone أو خادم مرجعي مخصّص |
| dnsmasq | DNS خفيف مع DHCP معًا | الأساطيل الصغيرة الثابتة، أو الشبكات على غرار LAN التي تحتاج كذلك إلى DHCP | ميزات أقل كلما كبر الأسطول والمنطقة |
| CoreDNS | خادم DNS قائم على الإضافات | أساطيل الحاويات و Kubernetes وتلك التي تعتمد بكثافة على اكتشاف الخدمات | مرن، لكن سلوكه يتوقف على سلسلة الإضافات التي تضبطها |
منطق الاختيار قصير. إن كنت تحتاج إلى محلّل صغير يستند إلى ملف على غرار hosts، أو كنت توزّع بالفعل حجوزات DHCP، فإن dnsmasq يزيل قطعة متحركة من المنظومة. وإن كنت تحتاج أساسًا إلى محلّل يتحقق ويحوّل الاستعلامات إلى الخارج ويجيب عن منطقة داخلية متواضعة، فإن Unbound يوفّر تلك المجموعة الأضيق من الميزات دون نشر BIND 9 كاملًا. وإن كنت تحتاج إلى تحكّم مرجعي كامل وتفويض وأكبر كمّ من التوثيق تتكئ عليه في الثالثة فجرًا، فإن BIND 9 هو الخيار المحافظ رغم اتساع مساحة إعداداته. وإن كان DNS أصلًا جزءًا من منظومة اكتشاف خدمات قائمة على الحاويات أو Kubernetes، فإن CoreDNS يلتقي بها حيث هي. والقاعدة العامة أن تشغّل أصغر شيء يغطي شكل أسطولك.
في أسطول إنتاجي، لا تجعل نسخة DNS واحدة هي المسار الوحيد إلى كل اسم داخلي. شغّل نسختين اثنتين على الأقل من DNS قادرتين على الإجابة عن المنطقة، وضعهما في نطاقي فشل منفصلين حيثما أمكن، واضبط العملاء للوصول إلى كلتيهما. وإلا فإن انقطاعًا واحدًا في DNS قد يجعل خدمات سليمة تبدو معطّلة.
كيف ينبغي أن تسمّي نطاقك الداخلي: .internal أم .local أم نطاقًا فرعيًا؟
لمعظم شبكات VPS في الإنتاج، استخدم نطاقًا فرعيًا تملكه، مثل internal.example.com. لا تستخدم مساحة الأسماء .internal إلا في إعداد معزول تكون فيه تصادمات الأسماء بين الشبكات، وإدارة الشهادات عبر سلطة تصديق خاصة، والتعامل الخاص مع DNSSEC أمورًا مقبولة. وتجنّب .local لأن mDNS يحجزها.
مشكلة .local ملموسة. RFC 6762 يمنح الأسماء المنتهية بـ .local معالجة خاصة ضمن Multicast DNS، ولذلك قد تتعارض منطقة أحادية البث في BIND 9 أو Unbound تستخدم اللاحقة نفسها مع سلوك mDNS على أجهزة Apple وغيرها من الأنظمة التي تدعم mDNS. استخدم مساحة أسماء مختلفة بدل الاعتماد على حلول التفافية خاصة بكل عميل.
نصيحة احترافية: إن ورثت منطقة داخلية على .local فتعامل معها كدين تقني. فبعض العملاء يرسلون استعلامات .local إلى mDNS بدلًا من خادم DNS أحادي البث لديك، وهو ما قد ينتج عنه أعطال تختلف باختلاف العميل أو تبدو متقطّعة.
حجز مجلس إدارة ICANN بشكل دائم النطاق .internal ومنع تفويضه في جذر DNS العام في يوليو 2024، عقب توصية سابقة من SSAC. والأسماء المندرجة تحته لن تُحلّ عبر DNS العالمي بحكم التصميم. ويأتي ذلك بمقايضات: فأسماء .internal ليست فريدة عالميًا، ولا يُتوقع من سلطات التصديق العامة إصدار شهادات لها، وستفشل المحلّلات التي تتحقق من DNSSEC اعتمادًا على مرساة الثقة العالمية في تحليلها. وإن كنت تحتاج إلى HTTPS على .internal فخطّط لتشغيل سلطة تصديق خاصة.
ميّز هنا بين أمرين. حجز ICANN نهائي. وهناك بشكل منفصل مسودة إنترنت نشطة، draft-davies-internal-tld-06، نُشرت في 6 مايو 2026 لتوثيق مساحة الأسماء ومقارنتها بالعنونة الخاصة في RFC 1918. وهي لا تزال مسودة إنترنت قيد العمل لا وثيقة RFC منشورة، لذا صِف .internal بأنه نطاق أعلى مستوى للاستخدام الخاص محجوز من ICANN، لا معيارًا من IETF.
بالنسبة لمعظم أساطيل VPS، يظل النطاق الفرعي من نطاق تتحكم فيه هو الخيار الافتراضي الأكثر أمانًا. توصي ISC باعتماد تسلسل هرمي من النطاقات الفرعية، مثل نطاق فرعي داخلي ضمن نطاقك، بدلًا من صيانة نسختين منفصلتين وناقصتين، داخلية وعامة، من المنطقة الأصلية نفسها. وهذا التفضيل ليس مسألة أسلوب؛ فهو يمنع العطل المذكور في القسم التالي.
خلاصة القسم: قرار مساحة الأسماء قرار طويل الأمد. فالنطاق الفرعي الذي تتحكم فيه هو الخيار الافتراضي لمعظم بيئات الإنتاج لأنه يحافظ على التفرّد العالمي ويعمل مع البنية التحتية للمفاتيح العامة. واستخدم .internal حين تكون مساحة أسماء خاصة معزولة أنسب وتقبل بمقايضاتها في DNSSEC والشهادات والتصادمات.
DNS ذو الأفق المنقسم والأخطاء التي تعطّله
يقدّم DNS ذو الأفق المنقسم إجابة مختلفة لاسم المضيف نفسه بحسب الجهة السائلة: عنوان IP الخاص داخليًا، والعام خارجيًا. وغالبًا ما يتعطّل بسبب فخ NXDOMAIN ضمن النطاق نفسه، وبسبب محلّلات بديلة تتجاوز العرض المقصود، ومسارات DNS داخل الحاويات لا تصل إلى الخادم الأعلى المتوقّع. وضبط ذلك بشكل صحيح يتوقف على ثلاثة أمور معًا، لا على أمر واحد.
فخ NXDOMAIN هو تحديدًا العطل الذي تحذّر منه ISC مباشرة. فإذا كانت خوادمك الداخلية مرجعية للنطاق الأصلي، لكن نسختها من المنطقة لا تتضمّن سجلًا عامًا مثل مضيف www، فإن عميلًا داخليًا يستعلم عن ذلك الاسم سيتلقّى NXDOMAIN رغم وجوده في المنطقة العامة. فالمنطقة الداخلية مرجعية ولا ترتدّ إلى DNS العام بخصوص النطاق الأصلي. ولهذا السبب بالضبط يكون نهج التسلسل الهرمي للنطاقات الفرعية، المذكور في قسم التسمية، هو التصميم المفضّل لدى ISC.
نصيحة احترافية: قبل أن توجّه خوادمك إلى إعداد ذي أفق منقسم على النطاق نفسه، جرّب من داخل الشبكة تحليل اسم عام معروف ضمن ذلك النطاق. فالحصول على NXDOMAIN لاسم يُحلّ بلا مشكلة من الخارج هو بصمة هذا الفخ.
وثمة ثلاثة مزالق أخرى يسهل إغفالها. فمحلّل بديل مضبوط على مضيف أو حاوية قد يتجاوز هذا الفصل؛ وبحسب طريقة تنفيذ المحلّل قد يُستعلم منه بعد انتهاء المهلة أو بالتوازي، فتتباين الإجابات. والحاويات على جسر Docker الافتراضي تتلقى نسخة من إعدادات DNS الخاصة بالمضيف عند تشغيلها، بينما تستعلم الحاويات على الشبكات المخصّصة من محلّل Docker المدمج على العنوان 127.0.0.11. ويحوّل ذلك المحلّل الاستعلامات الخارجية إلى خوادم DNS المضبوطة للمضيف أو الحاوية، ولذلك يتوقف سلوك split-DNS على إعدادات Docker والمضيف لا على ملف المحلّل داخل الحاوية وحده. وإذا كانت خدمة داخلية خلف وكيل عكسي مثل مدير وكيل Nginx، فقد يفشل التحقق من الشهادة إذا لم تكن الشهادة تغطي اسم المضيف المطلوب أو إذا لم تكن سلطة التصديق التي أصدرتها موثوقة لدى العميل. ومجرد استخدام شهادة مختلفة داخليًا ليس خطأً بحد ذاته. فهذه ثغرات في الإعداد لا عيوب في الأدوات.
وقد يواجه العملاء البعيدون العطل نفسه عندما لا تدفع شبكة VPN مستضافة ذاتيًا استعلامات DNS ولا توجّهها إلى المحلّل الداخلي المقصود.
وهناك بُعد أمني كذلك. فإذا تسرّبت أسماء المضيفين الداخلية وعناوين IP الخاصة إلى سجلات DNS العامة، تكون قد كشفت جزءًا من مخطط التسمية والعنونة الداخلي لديك لأي شخص يستعلم عنه. والأفق المنقسم موجود جزئيًا لإبقاء تلك الخريطة داخلية، ومنطقة عامة سيئة الإعداد تُبطل ذلك بصمت.
خلاصة القسم: أعطال الأفق المنقسم هي مزالق إعداد لا عيوب في الأدوات. فالصحة تتوقف على انضباط التسمية، ومعرفة أي محلّل يستعلم منه كل عميل فعليًا، وضبط نطاق المنطقة بشكل سليم، لا على إعداد واحد بعينه.
الخلاصة: اختيار التصميم المناسب لـ DNS الخاص
صرت الآن قادرًا على تحديد أي نظام من أنظمة "DNS الخاص" تقصده فعلًا. ففي سياق شبكات VPS هو المنطقة الداخلية لـ DNS، لا إعداد DNS-over-TLS في Android ولا خوادم الأسماء المرجعية ذات العلامة التجارية. وإن كان أسطولك صغيرًا ومستقرًا، /etc/hosts يظل خيارًا مبرّرًا. وإن لم يكن كذلك، فاتخذ نطاقًا فرعيًا تملكه مساحةَ أسماء افتراضية، واختر أصغر خادم DNS يناسب أسطولك، وأبقِ الوصول والتكرار ونطاق المنطقة الداخلي مقابل العام أمورًا صريحة. ولا تستخدم .internal إلا حين تكون مساحة أسماء معزولة أنسب وتقبل بمقايضاتها في الشهادات و DNSSEC والتصادمات.
الأسئلة الشائعة
هل DNS الخاص في Android هو نفسه خادم DNS خاص على VPS؟
لا. فـ DNS الخاص في Android ميزة DNS-over-TLS (تشفير الاستعلامات على المنفذ 853، أُضيفت في Android 9) تحمي استعلامات الجهاز أثناء نقلها. أما خادم DNS خاص على VPS فيحلّل أسماء المضيفين الداخلية إلى عناوين IP خاصة عبر شبكة. الأول يشفّر الاستعلامات، والثاني ينشئ مساحة أسماء داخلية. وهما يعالجان مشكلتين غير مترابطتين.
ما الفرق بين DNS الخاص و DNS العام؟
يجعل DNS الخاص المنطقةَ متاحة فقط للعملاء المصرّح لهم على شبكة أو VPN أو بيئة سحابية بعينها. أما DNS العام فينشر سجلات يمكن لمحلّلات الإنترنت أن تستعلم عنها. وكلاهما يستخدم أنواع سجلات DNS نفسها ونموذج التخزين المؤقت نفسه؛ والفرق هو مَن يستطيع الوصول إلى المنطقة وأين تظهر سجلاتها.
ما الفرق بين DNS الخاص و DNS المشفّر؟
تحمي بروتوكولات DNS المشفّرة مثل DoT و DoH استعلامات DNS أثناء نقلها. أما DNS الخاص بالمعنى الشبكي فينشئ مساحة أسماء محصورة بالشبكة للأسماء الداخلية. التشفير يغيّر كيفية انتقال الاستعلام؛ والمنطقة الخاصة تغيّر أي الأسماء موجودة ومن يستطيع تحليلها.
هل استخدام .internal آمن لأسماء المضيفين الداخلية؟
نعم، مع تحفّظات. فقد حجزت ICANN النطاق .internal بشكل دائم بعيدًا عن التفويض العام في يوليو 2024، ومن ثم يمكنك تقديمه عبر محلّل خاص. غير أنه ليس فريدًا عالميًا، ولا يُتوقع من سلطات التصديق العامة إصدار شهادات له، وستفشل مدقّقات DNSSEC التي تعتمد على مرساة الثقة العالمية في تحليله. ولمعظم شبكات VPS في الإنتاج، يبقى النطاق الفرعي الذي تملكه هو الخيار الافتراضي الأكثر أمانًا.
هل تستخدم سجلات DNS الخاصة قيمة TTL والتخزين المؤقت نفسها المستخدمة في DNS العام؟
نعم. تستخدم المناطق الخاصة والعامة النموذج نفسه للتخزين المؤقت المعتمد على TTL: فالسجلات تحمل قيمة TTL، وعادةً ما تعيد المحلّلات المخزِّنة استخدام الإجابة حتى تنتهي تلك القيمة. ومع ذلك قد تغيّر إعدادات خاصة بكل محلّل مدة التخزين الفعلية. انظر انتشار DNS وسلوك TTL للاطلاع على الآليات الكامنة وراء ذلك.
النقاش
التعليقات
سجّل الدخول للمشاركة في النقاش.