نظرة عامة على سجلات DNS الخاصة

توفر هذه المقالة معلومات حول دعم سجلات DNS في مناطق Azure Private DNS. للحصول على نظرة عامة حول مناطق DNS الخاصة، راجع: ما هي منطقة Azure Private DNS؟

سجلات DNS

أسماء السجلات

يتم تحديد السجلات باستخدام الأسماء النسبية. يتضمن اسم مجال المؤهل بالكامل (FQDN) اسم المنطقة، بينما لا يتضمن الاسم النسبي ذلك. على سبيل المثال، اسم السجل النسبي wwwفي المنطقةcontoso.com يعطي www.contoso.comاسم السجل المؤهل بالكامل .

سجل القمة هو سجل DNS في جذر (أو قمة) منطقة DNS. على سبيل المثال، في منطقة contoso.comDNS، لسجل القمة أيضاً اسم contoso.comمؤهل بالكامل (ويسمى أحياناً مجال مكشوف). وحسب الاصطلاح، يتم استخدام الاسم النسبي '@' لتمثيل سجلات القمة.

أنواع السجلات

كل سجل DNS له اسم ونوع. يتم تنظيم السجلات إلى أنواع مختلفة وفقا للبيانات التي تحتوي عليها. النوع الأكثر شيوعاً هو سجل 'A'، الذي يعين اسماً إلى عنوان IPv4. هناك نوع شائع آخر هو سجل "MX"، الذي يعين اسماً إلى خادم بريد.

يدعم Azure Private DNS أنواع سجلات DNS الشائعة التالية: A وAAA وCNAME وMX وPTR وSA وSRV وTXT.

إشعار

حقل المضيف في سجل SOA غير قابل للتحرير.

مجموعات السجلات

في بعض الأحيان، تحتاج إلى إنشاء أكثر من سجل DNS واحد مع اسم ونوع محددين. على سبيل المثال، افترض وجود موقع ويب "www.contoso.com" مستضاف على عنواني IP مختلفين. يتطلب الموقع سجلين مختلفين، أحدهما لكل عنوان IP. وفيما يلي مثال على مجموعة السجلات:

www.contoso.com.        3600    IN    A    10.10.1.5
www.contoso.com.        3600    IN    A    10.10.1.10

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

على سبيل المثال، افترض أنك قمت بالفعل بإنشاء سجل A 'www' في المنطقة 'contoso.com'، مشيرا إلى عنوان IP '10.10.1.5' (السجل الأول الموضح سابقا). لإنشاء السجل الثاني، يمكنك إضافة هذا السجل إلى مجموعة السجلات الموجودة، بدلاً من إنشاء مجموعة سجلات إضافية.

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

مدة البقاء

يحدد وقت البقاء أو TTL المدة التي يتم فيها تخزين كل سجل مؤقتا بواسطة العملاء قبل الاستعلام. في المثال السابق، يكون TTL 3600 ثانية أو ساعة واحدة.

في Azure DNS، يتم تحديد TTL لمجموعة السجلات، وليس لكل سجل، لذلك يتم استخدام نفس القيمة لجميع السجلات داخل مجموعة السجلات تلك. يمكنك تحديد أي قيمة TTL بين 1 و2,147,483,647 ثانية.

سجلات البدل

يدعم Azure DNS سجلات أحرف البدل. يتم إرجاع سجلات أحرف البدل استجابة لأي استعلام باسم مطابق، ما لم يكن هناك تطابق أقرب من مجموعة سجلات غير بطاقات. يدعم Azure DNS مجموعات سجلات البدل لجميع أنواع السجلات باستثناء NS وSOA.

لإنشاء مجموعة سجلات البدل، استخدم اسم مجموعة السجلات '*'. يمكنك أيضاً استخدام اسم مع '*' كتسميته الموجودة في أقصى اليسار، على سبيل المثال، '*.foo'.

سجلات CNAME

لا يمكن أن تتواجد مجموعات السجلات CNAME مع مجموعات السجلات الأخرى بنفس الاسم. على سبيل المثال، لا يمكنك إنشاء مجموعة سجلات CNAME بالاسم www النسبي وسجل A بالاسم www النسبي في نفس الوقت.

نظرا لأن قمة المنطقة (الاسم = '@') تحتوي دائما على مجموعات سجلات NS وSOA أثناء إنشاء المنطقة، فلا يمكنك إنشاء مجموعة سجلات CNAME في قمة المنطقة.

تنشأ هذه القيود من معايير DNS ولا تشكل قيوداً على Azure DNS.

سجلات SOA

يتم إنشاء مجموعة سجلات SOA تلقائياً في قمة كل منطقة (الاسم = '@')، ويتم حذفها تلقائياً عند حذف المنطقة. لا يمكن إنشاء سجلات SOA أو حذفها بشكل منفصل.

يمكنك تعديل كافة خصائص سجل SOA باستثناء الخاصية host . يتم تكوين هذه الخاصية مسبقا للإشارة إلى اسم خادم الاسم الأساسي الذي يوفره Azure DNS.

لا يتم تحديث الرقم التسلسلي للمنطقة في سجل SOA تلقائياً عند إجراء تغييرات على السجلات في المنطقة. ويمكن تحديثه يدوياً عن طريق تحرير سجل الـ SOA، إذا لزم الأمر.

سجلات SRV

تُستخدم سجلات SRV بواسطة خدمات متنوعة لتحديد مواقع الخادم. عند تحديد سجل SRV في Dns Azure:

  • يجب تحديد الخدمة والبروتوكول كجزء من اسم مجموعة السجلات، مسبوقا بتسطير أسفل السطر، مثل "_sip._tcp.name". للحصول على سجل في قمة المنطقة، ليست هناك حاجة لتحديد '@' في اسم السجل، ما عليك سوى استخدام الخدمة والبروتوكول، مثل '_sip._tcp'.
  • يتم تحديد الأولوية والوزن والمنفذ والهدف كمعلمات لكل سجل في مجموعة السجلات.

سجلات TXT

يتم استخدام سجلات TXT لتعيين أسماء المجالات إلى سلاسل نصية إجبارية. يتم استخدامها في تطبيقات متعددة.

تسمح معايير DNS لسجل TXT واحد باحتواء سلاسل متعددة، يمكن أن يصل طول كل منها إلى 255 حرفا. حيث يتم استخدام سلاسل متعددة، يتم تسلسلها بواسطة العملاء ويتم التعامل معها كسلسلة واحدة.

عند استدعاء API REST DNS Azure، تحتاج إلى تحديد كل سلسلة TXT بشكل منفصل. عند استخدام واجهات مدخل Microsoft Azure أو PowerShell أو CLI، يجب تحديد سلسلة واحدة لكل سجل. يتم تقسيم هذه السلسلة تلقائيا إلى مقاطع مكونة من 255 حرفا إذا لزم الأمر.

لا ينبغي الخلط بين سلاسل متعددة في سجل DNS مع سجلات TXT متعددة في مجموعة سجلات TXT. يمكن أن تحتوي مجموعة سجلات TXT على سجلات متعددة، يمكن أن يحتوي كل منها على سلاسل متعددة. يدعم Azure DNS طول سلسلة إجمالي يصل إلى 4096 حرفا* في كل مجموعة سجلات TXT (عبر جميع السجلات مجتمعة).

* يتوفر دعم 4096 حرفا حاليا فقط في Azure Public Cloud. تقتصر السحب الوطنية على 1024 حرفا حتى اكتمال إطلاق دعم 4k.

العلامات وبيانات التعريف

علامات

العلامات هي قائمة من أزواج قيمة الاسم وتستخدم من قبل Azure Resource Manager لتسمية الموارد. يستخدم Azure Resource Manager علامات لتمكين طرق العرض المصفاة لمشروع فاتورة Azure، كما يمكنك من تعيين نهج لعلامات معينة. لمزيد من المعلومات، راجع استخدام العلامات لتنظيم موارد Azure.

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

بيانات التعريف

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

Etags

افترض أن شخصين أو عمليتين تحاولان تعديل سجل DNS في نفس الوقت. من الذي سيفوز؟ وهل يعلم الفائز أنه قام بال الكتابة فوق التغييرات التي أنشأها شخص آخر؟

Dns Azure يستخدم Etags لمعالجة التغييرات المتزامنة إلى نفس المورد بأمان. تعتبر Etags منفصلة عن "علامات"Azure Resource Manager. كل مورد DNS (منطقة أو مجموعة سجلات) يحتوي على Etag مقترن به. كلما تم استرداد مورد، يتم استرداد Etag الخاص به أيضاً. عند تحديث مورد، يمكنك اختيار تمرير Etag مرة أخرى حتى يتمكن Azure DNS من التحقق من Etag على مطابقات الخادم. منذ كل تحديث إلى نتائج مورد في Etag يتم إعادة إنشائها، يشير عدم تطابق Etag إلى حدوث تغيير متزامن. يمكن أيضاً استخدام Etags عند إنشاء مورد جديد لضمان عدم وجود المورد بالفعل.

بشكل افتراضي، يستخدم Azure DNS PowerShell Etags لمنع التغييرات المتزامنة على المناطق ومجموعات السجلات. يمكن استخدام مفتاح التبديل -Overwrite الاختياري لمنع عمليات تحقق Etag، وفي هذه الحالة يتم الكتابة فوق أي تغييرات متزامنة حدثت.

على مستوى API REST DNS Azure، يتم تحديد Etags باستخدام رؤوس HTTP. يتم إعطاء سلوكهم في الجدول التالي:

الرأس سلوك
بلا PUT ينجح دائماً (لا الشيكات Etag)
إذا تطابق <etag> PUT ينجح فقط إذا كان المورد موجوداً ويطابق Etag
If-Match PUT ينجح فقط في حالة وجود المورد
إذا كان لا شيء مطابق PUT ينجح فقط إذا كان المورد غير موجود

الحدود

تنطبق الحدود الافتراضية التالية عند استخدام Azure Private DNS:

مناطق DNS الخاصة

Resource الحد
مناطق DNS الخاصة حسب الاشتراك 1000
مجموعات السجلات لكل منطقة DNS من المناطق الخاصة 25000
تعيين سجلات كل سجل في مناطق DNS الخاصة 20
ارتباطات الشبكة الظاهرية لكل منطقة DNS من المناطق الخاصة 1000
ارتباطات الشبكات الظاهرية لكل مناطق DNS خاصة مع تمكين التسجيل التلقائي 100
عدد مناطق DNS الخاصة التي يمكن ربط الشبكة الظاهرية بها مع تمكين التسجيل التلقائي 1
عدد مناطق DNS الخاصة التي يمكن ربط الشبكة الظاهرية بها 1000

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