Share via

تحليل الاسم للموارد في الشبكات الظاهرية لـ Azure

  • مقالة

تنبيه

تشير هذه المقالة إلى CentOS، وهو توزيع Linux يقترب من حالة نهاية العمر الافتراضي (EOL). يرجى مراعاة استخدامك والتخطيط وفقا لذلك. لمزيد من المعلومات، راجع إرشادات نهاية العمر الافتراضي CentOS.

يمكن استخدام Azure لاستضافة IaaS وPaaS والحلول المختلطة. لتسهيل الاتصال بين الأجهزة الظاهرية (VMs) والموارد الأخرى المنشورة في شبكة ظاهرية، قد يكون من الضروري السماح لها بالاتصال ببعضها البعض. استخدام الأسماء التي يمكن تذكرها بسهولة ودون تغيير يبسط عملية الاتصال، بدلا من الاعتماد على عناوين IP.

عندما تحتاج الموارد الموزعة في الشبكات الظاهرية إلى حل أسماء المجالات إلى عناوين IP الداخلية، يمكنها استخدام إحدى الطرق الأربع:

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

إشعار

تعد مناطق Azure DNS الخاصة الحل المفضل، وتمنحك المرونة في إدارة مناطق DNS وسجلاتك. لمزيد من المعلومات، راجع استخدام Azure DNS للمجالات الخاصة.

إشعار

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

السيناريو الحل لاحقة DNS
تحليل الاسم بين الأجهزة الظاهرية الموجودة في الشبكة الظاهرية نفسها، أو مثيلات دور خدمات سحابة Azure في نفس الخدمة السحابية. المناطق الخاصة لـ Azure DNS أو تحليل الاسم الموفر من Azure اسم المضيف أو FQDN
تحليل الاسم بين الأجهزة الظاهرية في الشبكات الظاهرية المختلفة أو مثيلات الدور في خدمات سحابية مختلفة. المناطق الخاصة لـ Azure DNS أو محلل خاص لـ Azure DNSأو خوادم DNS المدارة من قبل العميل تعيد توجيه الاستعلامات بين الشبكات الظاهرية للحل بواسطة Azure (وكيل DNS). راجع تحليل الاسم باستخدام خادم DNS الخاص بك. FQDN فقط
تحليل الاسم من Azure App Service (تطبيق ويب أو وظيفة أو بوت) باستخدام تكامل الشبكة الظاهرية لمثيلات الدور أو الأجهزة الظاهرية في نفس الشبكة الظاهرية. المحلل الخاص لـ Azure DNS أو خوادم DNS المدارة من قبل العميل تعيد توجيه الاستعلامات بين الشبكات الظاهرية للحل بواسطة Azure (وكيل DNS). راجع تحليل الاسم باستخدام خادم DNS الخاص بك. FQDN فقط
تحليل الاسم من تطبيقات ويب لخدمة التطبيقات إلى الأجهزة الظاهرية في الشبكة الظاهرية نفسها. المحلل الخاص لـ Azure DNS أو خوادم DNS المدارة من قبل العميل تعيد توجيه الاستعلامات بين الشبكات الظاهرية للحل بواسطة Azure (وكيل DNS). راجع تحليل الاسم باستخدام خادم DNS الخاص بك. FQDN فقط
تحليل الاسم من تطبيقات ويب خدمة التطبيقات في شبكة ظاهرية واحدة إلى الأجهزة الظاهرية في شبكة ظاهرية مختلفة. المحلل الخاص لـ Azure DNS أو خوادم DNS المدارة من قبل العميل تعيد توجيه الاستعلامات بين الشبكات الظاهرية للحل بواسطة Azure (وكيل DNS). راجع تحليل الاسم باستخدام خادم DNS الخاص بك. FQDN فقط
دقة الكمبيوتر المحلي وأسماء الخدمة من الأجهزة الظاهرية أو مثيلات الدور في Azure. محلل خاص لـ Azure DNS أو خوادم DNS التي يديرها العميل (وحدة تحكم بالمجال محلية أو وحدة تحكم المجال للقراءة فقط أو DNS ثانوي تتم مزامنته باستخدام عمليات نقل المنطقة، على سبيل المثال). راجع تحليل الاسم باستخدام خادم DNS الخاص بك. FQDN فقط
تحليل أسماء مضيفي Azure من أجهزة الكمبيوتر المحلية. إعادة توجيه الاستعلامات إلى خادم وكيل DNS يديره العميل في الشبكة الظاهرية المقابلة، يقوم خادم الوكيل بإعادة توجيه الاستعلامات إلى Azure للحل. راجع تحليل الاسم باستخدام خادم DNS الخاص بك. FQDN فقط
عكس DNS لعناوين IP الداخلية. مناطق Azure DNS الخاصة أو تحليل الاسم المقدم من Azure أو محلل خاص لـ Azure DNS أو تحليل الاسم باستخدام خادم DNS الخاص بك. غير قابل للتطبيق
تحليل الاسم بين الأجهزة الظاهرية أو مثيلات الدور الموجودة في خدمات سحابية مختلفة، وليس في شبكة ظاهرية. غير قابل للتطبيق. لا يتم دعم الاتصال بين الأجهزة الظاهرية ومثيلات الأدوار في خدمات سحابية مختلفة خارج شبكة ظاهرية. غير قابل للتطبيق

تحليل الاسم الموفر من Azure

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

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

إشعار

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

الميزات

يتضمن تحليل الاسم المتوفر في Azure الميزات التالية:

  • سهولة الاستخدام. لا يلزم التكوين.

  • قابلية الوصول العالية. لست بحاجة إلى إنشاء مجموعات من خوادم DNS الخاصة بك وإدارتها.

  • يمكنك استخدام الخدمة مع خوادم DNS الخاصة بك، لحل كل من الأسماء المحلية وأسماء مضيفي Azure.

  • يمكنك استخدام تحليل الاسم بين الأجهزة الظاهرية ومثيلات الدور داخل نفس الخدمة السحابية، دون الحاجة إلى اسم مجال مؤهل بالكامل.

  • يمكنك استخدام تحليل الاسم بين الأجهزة الظاهرية في الشبكات الظاهرية التي تستخدم نموذج توزيع Azure Resource Manager، دون الحاجة إلى اسم مجال مؤهل بالكامل. تتطلب الشبكات الظاهرية في نموذج التوزيع الكلاسيكي FQDN عند حل الأسماء في خدمات سحابية مختلفة.

  • يمكنك استخدام أسماء المضيفين التي تصف عمليات التوزيع الخاصة بك على أفضل نحو، بدلا من العمل مع الأسماء التي تم إنشاؤها تلقائيا.

الاعتبارات

النقاط التي يجب مراعاتها عند استخدام تحليل الاسم المقدم من Azure:

  • لا يمكن تعديل لاحقة DNS التي تم إنشاؤها بواسطة Azure.

  • يتم تحديد نطاق بحث DNS إلى شبكة ظاهرية. لا يمكن حل أسماء DNS التي تم إنشاؤها لشبكة ظاهرية واحدة من الشبكات الظاهرية الأخرى.

  • لا يمكنك تسجيل سجلاتك يدويا.

  • WINS وNetBIOS غير مدعومين. لا يمكنك رؤية الأجهزة الظاهرية في مستكشف Windows.

  • يتعين أن تكون أسماء المضيفين متوافقة مع DNS. يجب أن تستخدم الأسماء فقط من 0 إلى 9 و a-z و '-'، ولا يمكن أن تبدأ أو تنتهي ب '-'.

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

  • استخدم اسماً مختلفاً لكل جهاز ظاهري في شبكة ظاهرية لتجنب مشكلات دقة DNS.

  • يتم تسجيل الأجهزة الظاهرية فقط في أول 180 خدمة سحابية لكل شبكة ظاهرية في نموذج توزيع كلاسيكي. لا ينطبق هذا الحد على الشبكات الظاهرية في Azure Resource Manager.

  • عنوان IP لنظام Azure DNS هو 168.63.129.16. هذا العنوان هو عنوان IP ثابت ولا يتغير.

عكس اعتبارات DNS

يتم دعم DNS العكسي للأجهزة الظاهرية في جميع الشبكات الظاهرية المستندة إلى Azure Resource Manager. تتم إضافة سجلات DNS العكسية (PTR) المدارة من Azure للنموذج [vmname].internal.cloudapp.net تلقائيا عند بدء تشغيل جهاز ظاهري، وإزالتها عند إيقاف الجهاز الظاهري (إلغاء تخصيصه). راجع المثال التالي:

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

منطقة DNS العكسية internal.cloudapp.net هي مدارة من قبل Azure ولا يمكن عرضها أو تحريرها مباشرة. البحث للأمام على FQDN للنموذج [vmname].internal.cloudapp.net يحل إلى عنوان IP المعين للجهاز الظاهري.

إذا كانت منطقة Azure DNS الخاصة مرتبطة بالشبكة الظاهرية بارتباط شبكة ظاهرية وتم تمكين التسجيل التلقائي على هذا الارتباط، فإن استعلامات DNS العكسية ترجع سجلين. سجل واحد من النموذج [vmname].[ privatednszonename] والآخر هو من النموذج [vmname].internal.cloudapp.net. راجع المثال التالي:

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

عند إرجاع سجلي PTR كما هو موضح سابقا، يقوم البحث للأمام لأي من FQDN بإرجاع عنوان IP للجهاز الظاهري.

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

إشعار

لا يتم تخزين سجلات DNS العكسية (PTR) في منطقة DNS خاصة للأمام. يتم تخزين سجلات DNS العكسية في منطقة DNS عكسية (في addr.arpa). منطقة DNS العكسية الافتراضية المقترنة بشبكة ظاهرية غير قابلة للعرض أو التحرير.

يمكنك تعطيل دالة DNS العكسية في شبكة ظاهرية عن طريق إنشاء منطقة البحث العكسي الخاصة بك باستخدام مناطق Azure DNS الخاصة، ثم ربط هذه المنطقة بشبكتك الظاهرية. على سبيل المثال، إذا كانت مساحة عنوان IP للشبكة الظاهرية هي 10.20.0.0/16، فيمكنك إنشاء منطقة DNS خاصة فارغة 20.10.in-addr.arpa وربطها بالشبكة الظاهرية. تتجاوز هذه المنطقة مناطق البحث العكسي الافتراضية للشبكة الظاهرية. هذه المنطقة فارغة. ترجع DNS العكسية NXDOMAIN ما لم تقم بإنشاء هذه الإدخالات يدويا.

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

إشعار

نظرا لأن مناطق Azure DNS الخاصة عالمية، يمكنك إنشاء بحث DNS عكسي يمتد عبر شبكات ظاهرية متعددة. للقيام بذلك، قم بإنشاء منطقة خاصة ل Azure DNS لإجراء عمليات بحث عكسية ( منطقة in-addr.arpa )، وربطها بالشبكات الظاهرية. سيتعين عليك إدارة سجلات DNS العكسية للأجهزة الظاهرية يدويا.

تكوين عميل DNS

يغطي هذا القسم التخزين المؤقت من جانب العميل وإعادة المحاولة من جانب العميل.

التخزين المؤقت من جانب العميل

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

يحتوي عميل DNS الافتراضي لـ Windows على ذاكرة تخزين مؤقت DNS مضمنة. لا تتضمن بعض توزيعات Linux التخزين المؤقت بشكل افتراضي. إذا وجدت أنه لا توجد ذاكرة تخزين مؤقت محلية بالفعل، فأضف ذاكرة تخزين مؤقت DNS إلى كل جهاز Linux ظاهري.

هناك العديد من حزم التخزين المؤقت DNS المختلفة المتاحة (مثل dnsmasq). فيما يلي كيفية تثبيت dnsmasq على التوزيعات الأكثر شيوعاً:

RHEL/CentOS (يستخدم NetworkManager):

  1. تثبيت حزمة dnsmasq باستخدام الأمر التالي:

    sudo yum install dnsmasq

  2. تمكين خدمة dnsmasq باستخدام الأمر التالي:

    systemctl enable dnsmasq.service

  3. ابدأ تشغيل خدمة dnsmasq باستخدام الأمر التالي:

    systemctl start dnsmasq.service

  4. استخدم محرر نص لإضافته prepend domain-name-servers 127.0.0.1; إلى /etc/dhclient-eth0.conf:

  5. استخدم الأمر التالي لإعادة تشغيل خدمة الشبكة:

    service network restart

إشعار

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

عمليات إعادة المحاولة من جانب العميل

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

  • أنظمة تشغيل Windows تقوم بإعادة المحاولة بعد ثانية واحدة، ثم مرة أخرى بعد ثانيتين أخريين، وأربع ثوانٍ، وأربع ثوانٍ أخرى.
  • يعيد إعداد Linux الافتراضي المحاولة بعد خمس ثوانٍ. نوصي بتغيير مواصفات إعادة المحاولة إلى خمس مرات، على فترات زمنية مدتها ثانية واحدة.

تحقق من الإعدادات الحالية على جهاز Linux الظاهري باستخدام cat /etc/resolv.conf. انظر إلى سطر الخيارات، على سبيل المثال:

options timeout:1 attempts:5

يتم إنشاء الملف resolv.conf تلقائيا، ولا يجب تحريره. تختلف الخطوات المحددة لإضافة سطر الخيارات حسب التوزيع:

RHEL/CentOS (يستخدم NetworkManager):

  1. استخدم محرر نص لإضافة السطر RES_OPTIONS="options timeout:1 attempts:5" إلى الملف /etc/sysconfig/network-scripts/ifcfg-eth0.

  2. استخدم الأمر التالي لإعادة تشغيل خدمة NetworkManager:

    systemctl restart NetworkManager.service

تحليل الاسم الذي يستخدم خادم DNS الخاص بك

يغطي هذا القسم الأجهزة الظاهرية، ومثيلات الأدوار، وتطبيقات الويب.

إشعار

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

الأجهزة الظاهرية ومثيلات الأدوار

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

يُمكن لخوادم DNS الموجودة داخل شبكة ظاهرية إعادة توجيه استعلامات DNS للمُحللات المُتداخلة في Azure. يمكنك هذا الإجراء من حل أسماء المضيفين داخل تلك الشبكة الظاهرية. على سبيل المثال، يُمكن لوحدة تحكم مجال (DC) قيد التشغيل في Azure أن تستجيب لاستعلامات DNS لمجالاتها، وإعادة توجيه كافة الاستعلامات الأخرى إلى Azure. تسمح إعادة توجيه الاستعلامات للشبكات الظاهرية برؤية كل من مواردك الداخلية (عبر DC) وأسماء المضيفين المتوفرة من قبل Azure (عبر مُعيد التوجيه). يتوفر الوصول إلى المحللات المُتداخلة في Azure عبر عنوان IP الظاهري 168.63.129.16.

هام

إذا تم استخدام بوابة VPN في هذا الإعداد جنبا إلى جنب مع عنوان IP المخصص لخادم DNS على VNet، فيجب إضافة AZURE DNS IP (168.63.129.16) في القائمة أيضا للحفاظ على الخدمة غير الممزقة.

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

إشعار

يمكن لمثيل الدور تنفيذ تحليل الاسم للأجهزة الظاهرية داخل نفس الشبكة الظاهرية. يقوم بذلك باستخدام اسم مجال مؤهل بالكامل، والذي يتكون من اسم مضيف جهاز ظاهري ولاحقة DNS تسمى internal.cloudapp.net. ومع ذلك، في هذه الحالة، يكون تحليل الاسم ناجحاً فقط إذا كان مثيل الدور يحتوي على اسم الجهاز الظاهري المعرف في مخطط الدور (ملف ‎.cscfg). <Role name="<role-name>" vmName="<vm-name>">

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

رسم تخطيطي لـ DNS بين الشبكات الظاهرية

عند استخدام تحليل الاسم المقدم من Azure، يوفر بروتوكول تكوين المضيف الديناميكي Azure (DHCP) لاحقة DNS داخلية (.internal.cloudapp.net) لكل جهاز ظاهري. تمكّن هذه اللاحقة من تحليل اسم المضيف لأن سجلات اسم المضيف موجودة في منطقة internal.cloudapp.net. عند استخدام حل تحليل الاسم الخاص بك، لا يتم توفير هذه اللاحقة للأجهزة الظاهرية لأنها تتداخل مع بنيات DNS الأخرى (مثل السيناريوهات المرتبطة بالمجال). بدلا من ذلك، يوفر Azure عنصر نائب غير وظيفي (reddog.microsoft.com).

إذا لزم الأمر، يمكنك تحديد لاحقة DNS الداخلية باستخدام PowerShell أو واجهة برمجة التطبيقات:

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

إذا قمت بتوفير حل DNS الخاص بك، فإنه يحتاج إلى:

  • توفير تحليل مناسب لاسم المضيف، عبر DDNS، على سبيل المثال. إذا كنت تستخدم DDNS، فقد تحتاج إلى تعطيل مسح سجل DNS. عقود إيجار Azure DHCP طويلة، وقد يؤدي البحث عن سجلات DNS إلى إزالة سجلات DNS قبل الأوان.

  • قم بتوفير التحليل التكراري المناسب للسماح بحل أسماء المجالات الخارجية.

  • يمكن الوصول إليه (TCP وUDP على المنفذ 53) من العملاء الذين تخدمهم ويكون قادراً على الوصول إلى الإنترنت.

  • أن يكون مؤمَّناً ضد الوصول من الإنترنت للتخفيف من التهديدات التي تشكلها العوامل الخارجية.

إشعار

  • للحصول على أفضل أداء، عند استخدام أجهزة Azure الظاهرية كخوادم DNS، يجب تعطيل IPv6.
  • تعمل مجموعات أمان الشبكة كجدران حماية لنقاط نهاية محلل DNS. يجب تعديل قواعد أمان NSG أو تجاوزها للسماح بالوصول إلى منفذ UDP 53 (واختيارياً منفذ TCP 53) إلى نقاط نهاية وحدة الاستماع DNS. بمجرد تعيين خوادم DNS المخصصة على شبكة، فإن نسبة استخدام الشبكة عبر المنفذ 53 ستتجاوز مجموعة أمان الشبكة للشبكة الفرعية.

هام

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

لمزيد من المعلومات حول هذه المشكلة، راجع معاد التوجيه ومهلات حل معاد التوجيه الشرطي.

قد تنطبق هذه التوصية أيضا على الأنظمة الأساسية الأخرى لخادم DNS بقيمة مهلة إعادة التوجيه 3 ثوان أو أقل.

قد يؤدي عدم القيام بذلك إلى حل سجلات منطقة DNS الخاصة بعناوين IP العامة.

تطبيقات الويب

لنفترض أنك بحاجة إلى إجراء تحليل الاسم من تطبيق الويب لديك الذي تم إنشاؤه باستخدام App Service، المرتبط بشبكة ظاهرية، إلى الأجهزة الظاهرية في نفس الشبكة الظاهرية. بالإضافة إلى إعداد خادم DNS مخصص به معيد توجيه DNS يقوم بإعادة توجيه الاستعلامات إلى Azure (عنوان IP الظاهري 168.63.129.16)، قم بتنفيذ الخطوات التالية:

قم بتمكين تكامل الشبكة الظاهرية لتطبيق الويب، إذا لم يكن قد تم ذلك بالفعل، كما هو موضح في دمج تطبيقك مع شبكة ظاهرية.

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

لاستخدام خوادم DNS المخصصة:

  • قم بإعداد خادم DNS في الشبكة الظاهرية المستهدفة، على جهاز ظاهري يمكنه أيضاً إعادة توجيه الاستعلامات إلى المحلل التكراري في Azure (عنوان IP الظاهري 168.63.129.16). يتوفر مثال على معيد توجيه DNS في معرض قوالب التشغيل السريع في Azure وGitHub.

  • قم بإعداد معيد توجيه DNS في الشبكة الظاهرية المصدر على جهاز ظاهري. قم بتكوين معيد توجيه DNS هذا لإعادة توجيه الاستعلامات إلى خادم DNS في الشبكة الظاهرية المستهدفة.

  • قم بتكوين خادم DNS المصدر في إعدادات الشبكة الظاهرية المصدر.

  • قم بتمكين تكامل الشبكة الظاهرية لتطبيق الويب للارتباط بالشبكة الظاهرية المصدر، باتباع الإرشادات الواردة في دمج تطبيقك مع شبكة ظاهرية.

لاستخدام محلل Azure DNS الخاص، راجع ارتباطات مجموعة القواعد.

قم بتحديد خوادم DNS

عند استخدام خوادم DNS الخاصة بك، يتيح لك Azure تحديد خوادم DNS متعددة لكل شبكة ظاهرية. يمكنك أيضاً تحديد خوادم DNS متعددة لكل واجهة شبكة (لـ Azure Resource Manager)، أو لكل خدمة سحابية (لنموذج التوزيع الكلاسيكي). تتمتع خوادم DNS المحددة لواجهة الشبكة أو الخدمة السحابية بالأسبقية على خوادم DNS المحددة للشبكة الظاهرية.

إشعار

لا ينبغي تحرير خصائص اتصال الشبكة، مثل عناوين IP لخادم DNS، مباشرة داخل الأجهزة الظاهرية. هذا لأنه قد يتم محوها أثناء معالجة الخدمة عند استبدال محول الشبكة الظاهرية. ينطبق هذا على كل من أجهزة Windows وLinux الظاهرية.

عند استخدام نموذج توزيع Azure Resource Manager، يمكنك تحديد خوادم DNS لشبكة ظاهرية وواجهة شبكة اتصال. للحصول على التفاصيل، راجع إدارة شبكة ظاهرية وإدارة واجهة شبكة.

إشعار

إذا اخترت خادم DNS مخصصاً لشبكتك الظاهرية، يجب عليك تحديد عنوان IP واحد على الأقل لخادم DNS؛ وإلا، ستتجاهل الشبكة الظاهرية التكوين، وتستخدم DNS المقدم من Azure بدلاً من ذلك.

إشعار

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

الخطوات التالية

نموذج توزيع Azure Resource Manager: