نظرة عامة على مناطق وسجلات DNS

  • مقالة

توضح هذه المقالة المفاهيم الرئيسة للمجالات ومناطق DNS وسجلات DNS ومجموعات السجلات. يمكنك معرفة كيفية دعمها في Azure DNS.

أسماء المجال

نظام اسم المجال هو التسلسل الهرمي للمجالات. يبدأ التسلسل الهرمي من root المجال، الذي يكون اسمه ببساطة '.'. أسفل هذا تأتي مجالات المستوى الأعلى، مثل comأو netukorgjp. أسفل مجالات المستوى الأعلى توجد مجالات من المستوى الثاني، مثل org.uk أو co.jp. يتم توزيع المجالات في التسلسل الهرمي DNS عمومياً، مستضافة بواسطة خوادم أسماء DNS حول العالم.

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

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

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

{1}مناطق DNS{2}

يتم استخدام منطقة DNS لاستضافة سجلات DNS لمجال معين. لبدء استضافة المجال الخاص بك في Azure DNS، تحتاج إلى إنشاء منطقة DNS لاسم المجال هذا. يتم بعد ذلك إنشاء كل سجل DNS لمجالك داخل منطقة DNS هذه.

على سبيل المثال، قد يحتوي المجال 'contoso.com' على عدة سجلات DNS، مثل 'mail.contoso.com' (لخادم بريد) و'www.contoso.com' (لموقع ويب).

عند إنشاء منطقة DNS في Azure DNS:

  • يجب أن يكون اسم المنطقة فريداً ضمن مجموعة الموارد، ويجب ألا تكون المنطقة موجودة بالفعل. وإلا، فستفشل العملية.
  • يمكن إعادة استخدام نفس اسم المنطقة في مجموعة موارد مختلفة أو اشتراك Azure مختلف.
  • عندما تشترك مناطق متعددة في نفس الاسم، يتم تعيين عناوين خادم بأسماء مختلفة لكل مثيل. يمكن تكوين مجموعة واحدة فقط من العناوين باستخدام مسجل اسم المجال.

إشعار

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

للمزيد من المعلومات، راجع تفويض مجال إلى DNS Azure.

سجلات DNS

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

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

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

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

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

يدعم Azure DNS جميع أنواع سجلات DNS الشائعة: A وAAA وCAA وCNAME وMX وNS وPTR وSA وSRV وTXT. لاحظ أن سجلات SPF يتم تمثيلها باستخدام سجلات TXT.

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

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

www.contoso.com.        3600    IN    A    134.170.185.46
www.contoso.com.        3600    IN    A    134.170.188.221

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

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

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

مدة البقاء

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

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

سجلات البدل

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

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

سجلات CAA

يسمح سجل CAA لمالكي المجال أن يحددوا مع مزودي DNS الخاص بهم أي مراجع مصدقة معتمدة لإصدار شهادات لنطاقهم. يسمح هذا السجل ل CAs بتجنب سوء إصدار الشهادات في بعض الحالات. سجلات CAA لها ثلاثة خصائص:

  • العلامات: هذا الحقل عبارة عن عدد صحيح بين 0 و255، يستخدم لتمثيل العلامة الهامة التي لها معنى خاص لكل RFC6844
  • العلامة: سلسلة ASCII التي يمكن أن تكون واحدة مما يلي:
    • issue: إذا كنت تريد تحديد المراجع المصدقة (CA) المسموح لها بإصدار الشهادات (جميع الأنواع)
    • issuewild: إذا كنت تريد تحديد CAs المسموح لها بإصدار شهادات (شهادات wildcard فقط)
    • iodef: تحديد عنوان بريد إلكتروني أو اسم مضيف يمكن لـ CAs إخطاره بطلبات إصدار الشهادات غير المصرح بها
  • Value: قيمة العلامة المحددة التي تم اختيارها

سجلات CNAME

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

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

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

سجلات NS

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

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

ينطبق هذا التقييد فقط على سجل NS الذي تم تعيينه في قمة المنطقة. يمكن إنشاء مجموعات سجلات NS أخرى في منطقتك (كما تستخدم لتفويض المناطق التابعة) وتعديلها وحذفها دون قيد.

سجلات SOA

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

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

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

إشعار

لا يدعم Azure DNS حاليا استخدام نقطة (.) قبل '@' في إدخال علبة بريد مسؤول المضيف SOA. على سبيل المثال: john.smith@contoso.xyz (تم تحويله إلى john.smith.contoso.xyz) وغير john\.smith@contoso.xyz مسموح به.

سجلات SPF

تُستخدم سجلات إطار عمل سياسة المرسل (SPF) لتحديد خوادم البريد الإلكتروني التي يمكنها إرسال بريد إلكتروني نيابة عن اسم المجال. يعد التكوين الصحيح لسجلات نظام التعرف على هوية المرسل (SPF) أمرًا مهمًا لمنع المستلمين من تمييز بريدك الإلكتروني كبريد غير هام.

قدمت DNS RFCs في الأصل نوع سجل جديد لنظام التعرف على هوية المرسل (SPF) لدعم هذا السيناريو. لدعم خوادم الأسماء القديمة، سمحوا أيضًا باستخدام نوع سجل TXT لتحديد سجلات نظام التعرف على هوية المرسل (SPF). أدى هذا الغموض إلى الارتباك، والذي تم حله بواسطة RFC 7208. ينص على أنه يجب إنشاء سجلات SPF باستخدام نوع سجل TXT. كما ينص على أن نوع سجل SPF مهمل.

يتم دعم سجلات SPF بواسطة Azure DNS ويجب إنشاؤها باستخدام نوع سجل TXT. نوع سجل SPF القديم غير معتمد. عند استيراد ملف منطقة DNS، يتم تحويل أي سجلات SPF تستخدم نوع سجل SPF إلى نوع سجل TXT.

سجلات SRV

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

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

سجلات TXT

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

تسمح معايير 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 ينجح فقط إذا كان المورد غير موجود

الحدود

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

مناطق DNS العامة

مورد حد
مناطق DNS العامة لكل اشتراك 250 1
مجموعات السجلات لكل منطقة DNS من المناطق العامة 10,000 1
تعيين سجلات كل سجل في مناطق DNS العامة 20
عدد سجلات الاسم المستعار لمورد Azure واحد 20

1 إذا كنت بحاجة إلى زيادة هذه الحدود، فاتصل بفريق دعم المُختص في Azure.

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