نقل منطقة نظام أسماء النطاقات (DNS)

نقل نطاق نظام أسماء النطاقات (DNS) ، المعروف أيضاً باسم نوع استعلام DNS المُحفِّز AXFR ، هو أحد أنواع معاملات نظام أسماء النطاقات . وهو إحدى الآليات العديدة المتاحة للمسؤولين لنسخ قواعد بيانات نظام أسماء النطاقات عبر مجموعة من خوادم نظام أسماء النطاقات .

تستخدم عملية نقل المنطقة بروتوكول التحكم بالنقل (TCP) لنقل البيانات، ^{[ 1 ]}^{[ 2 ]} وتتخذ شكل معاملة بين العميل والخادم . قد يكون العميل الذي يطلب نقل المنطقة خادمًا ثانويًا يطلب البيانات من خادم رئيسي . ^{[ 3 ]} الجزء من قاعدة البيانات الذي يتم نسخه يُسمى منطقة .

عملية

تتألف عملية نقل النطاق من مقدمة، تليها عملية نقل البيانات الفعلية. تتضمن المقدمة البحث عن سجل موارد بدء السلطة (SOA) لـ "قمة النطاق"، وهي عقدة مساحة اسم نظام أسماء النطاقات (DNS) الموجودة في أعلى "النطاق". تحدد حقول سجل موارد SOA هذا، وخاصة "الرقم التسلسلي"، ما إذا كان نقل البيانات الفعلي ضروريًا أم لا. يقارن العميل الرقم التسلسلي لسجل موارد SOA مع الرقم التسلسلي في آخر نسخة لديه من هذا السجل. إذا كان الرقم التسلسلي للسجل المنقول أكبر، تُعتبر البيانات في النطاق قد "تغيرت" (بشكل ما)، ويشرع الخادم الثانوي في طلب نقل بيانات النطاق الفعلي. أما إذا كانت الأرقام التسلسلية متطابقة، فتُعتبر البيانات في النطاق لم "تتغير"، ويمكن للعميل الاستمرار في استخدام نسخة قاعدة البيانات الموجودة لديه، إن وجدت.

تبدأ عملية نقل البيانات الفعلية بإرسال العميل استعلامًا ( رمز العملية 0) من نوع الاستعلام الخاص AXFR (القيمة 252) عبر اتصال TCP إلى الخادم. على الرغم من أن نظام أسماء النطاقات (DNS) يدعم تقنيًا AXFR عبر بروتوكول بيانات المستخدم (UDP)، إلا أنه يُعتبر غير مقبول نظرًا لمخاطر فقدان الحزم أو انتحالها. ^{[ 2 ]}^{[ 1 ]} يستجيب الخادم بسلسلة من رسائل الاستجابة، تتضمن جميع سجلات الموارد لكل اسم نطاق في "المنطقة". تتضمن الاستجابة الأولى سجل موارد SOA لقمة المنطقة. تليها البيانات الأخرى دون ترتيب محدد. يُشير الخادم إلى نهاية البيانات بتكرار الاستجابة التي تحتوي على سجل موارد SOA لقمة المنطقة.

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

يصف ما سبق نقل المنطقة بالكامل. ويختلف نقل المنطقة التدريجي عن نقل المنطقة بالكامل في الجوانب التالية:

يستخدم العميل نوع QTYPE الخاص IXFR (القيمة 251) بدلاً من نوع QTYPE AXFR.
يرسل العميل سجل موارد SOA لقمة المنطقة التي يمتلكها حاليًا، إن وجدت، في رسالة IXFR، مما يتيح للخادم معرفة إصدار "المنطقة" الذي يعتقد أنه الإصدار الحالي.
على الرغم من أن الخادم قد يستجيب بالطريقة المعتادة لبروتوكول AXFR مع البيانات الكاملة للمنطقة، فإنه قد يستجيب أيضًا بنقل بيانات "تزايدي". يتضمن هذا الأخير قائمة التغييرات التي طرأت على بيانات المنطقة، مرتبةً حسب الرقم التسلسلي للمنطقة، بين إصدار المنطقة الذي أبلغ عنه العميل للخادم والإصدار الحالي للمنطقة على الخادم. تشمل التغييرات قائمتين، إحداهما لسجلات الموارد المحذوفة والأخرى لسجلات الموارد المُضافة. (يُمثل تعديل سجل الموارد بحذف متبوع بإضافة).

يتم نقل المناطق بالكامل من قِبل العميل. مع أن الخوادم تستطيع إرسال إشعار إلى العملاء (لإعلامهم) عند حدوث أي تغيير في بيانات المنطقة، إلا أن جدولة عمليات نقل المناطق تخضع كليًا لسيطرة العملاء. يقوم العملاء بجدولة عمليات نقل المناطق مبدئيًا، عندما تكون قواعد بياناتهم فارغة، ثم على فترات منتظمة، وفقًا لنمط تحدده القيم الموجودة في حقول "التحديث" و"إعادة المحاولة" و"الانتهاء" في سجل موارد SOA الخاص بقمة المنطقة.

القيود

على الرغم من أن نقل المنطقة الكاملة مُوحّد، حيث وُصف بأنه أحد آليات نسخ قواعد البيانات الممكنة في RFC 1034 وRFC 5936 (بينما وُصف نقل المنطقة التزايدي في RFC 1995)، إلا أن نقل المنطقة يُعدّ الأكثر محدودية بين آليات نسخ قواعد البيانات هذه. يعمل نقل المنطقة باستخدام سجلات الموارد " ذات التنسيق السلكي "، أي سجلات الموارد كما تُنقل باستخدام بروتوكول DNS. مع ذلك، قد لا يتطابق مخطط سجلات الموارد ذات التنسيق السلكي مع مخطط قاعدة البيانات الذي تستخدمه الخوادم الخلفية لخوادم DNS نفسها.

المشاكل التشغيلية

تغييرات الرقم التسلسلي

يعتمد الجزء التمهيدي من عملية نقل النطاق على الرقم التسلسلي فقط لتحديد ما إذا كانت بيانات النطاق قد تغيرت، وبالتالي ما إذا كان نقل البيانات الفعلي مطلوبًا. في بعض حزم خوادم نظام أسماء النطاقات (DNS)، يحتفظ المسؤولون يدويًا بالأرقام التسلسلية لسجلات موارد SOA. يتضمن كل تعديل على قاعدة البيانات إجراء تغييرين، أحدهما على السجل المراد تغييره والآخر على الرقم التسلسلي للنطاق. تتطلب هذه العملية دقة متناهية، فقد ينسى المسؤول تغيير الرقم التسلسلي أو يغيره بشكل خاطئ (يُقلل قيمته). توصي RFC 1912 (القسم 2.2 سجلات SOA) باستخدام القيمة YYYYMMDDnn كرقم (حيث YYYY = السنة، MM = الشهر، DD = اليوم، nn = رقم المراجعة). لن يحدث تجاوز لهذا الرقم حتى عام 4294.

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

علاوة على ذلك، فإن نموذج نسخ قواعد البيانات الذي صُمم من أجله فحص الرقم التسلسلي (ونقل النطاق نفسه)، والذي يتضمن خادم DNS مركزيًا واحدًا يحتفظ بالنسخة الأساسية من قاعدة البيانات، بينما تحتفظ جميع خوادم DNS الأخرى بنسخ منها، لا يتوافق ببساطة مع نموذج العديد من حزم خوادم DNS الحديثة. تسمح حزم خوادم DNS الحديثة المزودة بأنظمة قواعد بيانات خلفية متطورة، مثل خوادم SQL و Active Directory ، للمسؤولين بإجراء تحديثات على قاعدة البيانات في مواقع متعددة (تستخدم هذه الأنظمة النسخ المتعدد الرئيسي )، حيث تتولى آلية النسخ الخاصة بنظام قاعدة البيانات الخلفي عملية النسخ إلى جميع الخوادم الأخرى. هذا النموذج ببساطة لا يتوافق مع نموذج رقم مركزي واحد متزايد بشكل مطرد لتسجيل التغييرات، وبالتالي فهو غير متوافق مع نقل النطاق إلى حد كبير. غالبًا ما تقوم حزم خوادم DNS الحديثة المزودة بأنظمة قواعد بيانات خلفية متطورة بإنشاء رقم تسلسلي "وهمي"، لمحاكاة وجود موقع مركزي واحد تُجرى فيه التحديثات، ولكن هذا في أحسن الأحوال غير مثالي.

لحسن الحظ، لهذا السبب ولأسباب أخرى سيتم توضيحها لاحقًا، نادرًا ما تستخدم خوادم نظام أسماء النطاقات (DNS) التي تستخدم قواعد بيانات خلفية متطورة كهذه آلية نسخ قاعدة البيانات في المقام الأول، وعادةً ما تستخدم بدلاً من ذلك آليات نسخ قاعدة البيانات الموزعة المتفوقة للغاية التي توفرها قواعد البيانات الخلفية نفسها.

مقارنات الأرقام التسلسلية

تهدف مقارنات الأرقام التسلسلية إلى استخدام حساب الأرقام التسلسلية كما هو مُعرّف في RFC 1982. مع ذلك، لم يُحدد هذا بوضوح في RFC 1034، مما أدى إلى اختلاف طريقة فحص الرقم التسلسلي في مقدمة كل عميل. فبعض العملاء يكتفون بالتحقق من أن الرقم التسلسلي المُقدّم من الخادم يختلف عن الرقم المعروف لديهم، أو أنه ليس صفرًا. بينما يتحقق آخرون من أن الرقم التسلسلي المُقدّم من الخادم يقع ضمن نطاق مُحدد من الرقم التسلسلي المعروف لديهم. في حين أن بعض العملاء الآخرين يُجرون الفحص الأخير، بالإضافة إلى التحقق من أن الرقم التسلسلي المُقدّم من الخادم ليس صفرًا.

سجلات موارد متعددة

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

إجراء "معالجة إضافية للقسم" لتضمين أي مجموعات سجلات موارد "رابطة" في نفس الاستجابة مثل مجموعة سجلات موارد NS أو SRV أو MX
تجميع جميع مجموعات سجلات الموارد المتعلقة باسم نطاق واحد وإرسالها، إن أمكن، في رد واحد

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

كشف البيانات

قد تكون البيانات الموجودة في منطقة نظام أسماء النطاقات (DNS) حساسة من الناحية الأمنية التشغيلية. وذلك لأن معلومات مثل أسماء مضيفي الخوادم قد تصبح متاحة للعامة، مما قد يُستخدم للكشف عن معلومات تخص مؤسسة ما، بل وقد يُتيح مساحة هجوم أكبر . في يونيو 2017، قام مسجل النطاقات الروسي المسؤول عن نطاقات المستوى الأعلى بتفعيل نقل مناطق نظام أسماء النطاقات (DNS) عبر بروتوكول AXFR عن طريق الخطأ، مما أدى إلى كشف 5.6 مليون سجل عن طريق الخطأ. ^{[ 4 ]}

في عام 2008، قضت محكمة في ولاية داكوتا الشمالية بالولايات المتحدة الأمريكية بأن إجراء عملية نقل منطقة من قبل شخص خارجي غير مصرح له للحصول على معلومات غير متاحة للجمهور يشكل انتهاكًا لقانون ولاية داكوتا الشمالية. ^{[ 5 ]}

انظر أيضاً

قائمة أنواع سجلات نظام أسماء النطاقات (DNS)

مراجع

1 2 "أسماء النطاقات - التنفيذ والمواصفات" . IETF . نوفمبر 1987.
1 2 ديكنسون، جون؛ ديكنسون، سارة؛ بيليس، راي؛ مانكين، أليسون؛ ويسلز، دوان (مارس 2016). "نقل نظام أسماء النطاقات عبر بروتوكول TCP - متطلبات التنفيذ" . IETF .
↑ فوجيوارا، كازونوري؛ سوليفان، أندرو؛ هوفمان، بول (2019). "مصطلحات نظام أسماء النطاقات" . tools.ietf.org . doi : 10.17487/RFC8499 . تاريخ الاسترجاع: 21 يونيو 2020 .
↑ "تكوين ربط خاطئ يكشف القائمة الكاملة لنطاقات المستوى الأعلى الروسية على الإنترنت" . مدونة SecurityTrails . 14 مارس 2018. تاريخ الاطلاع: 10 أبريل 2018 .
↑ "تغريم شركة مكافحة البريد العشوائي بسبب الوصول إلى سجلات نظام أسماء النطاقات لشبكة خاصة" . صحيفة ذا إتش . 18 يناير 2008.

"كيف يعمل بروتوكول AXFR" . منشور على الإنترنت، دي جيه بيرنشتاين . تم الاطلاع عليه في 15 فبراير 2005 .
"فهم المناطق ونقل المناطق" . وثائق منتج Microsoft Windows Server 2003. 8 أكتوبر 2009. تم الاطلاع عليه بتاريخ 27 نوفمبر 2011 .
"كيفية عمل دعم نظام أسماء النطاقات (DNS) لـ Active Directory" . وثائق منتج Microsoft Windows Server 2003. تم الاطلاع عليها بتاريخ 27 نوفمبر 2011 .
"تكرار نطاق DNS في Active Directory" . وثائق منتج Microsoft Windows Server 2003. 8 أكتوبر 2009. تاريخ الاطلاع: 27 نوفمبر 2011 .
ماكلور، ستيوارت؛ سكامبراي، جويل؛ كورتز، جورج (2009). كشف أسرار الاختراق: أسرار وحلول أمن الشبكات ( الطبعة السادسة). ماكجرو هيل. ISBN 978-0-07-161374-3.

روابط خارجية

معلومات معايير الأمان

طلب تعليقات ذي صلة

بروتوكول نقل منطقة نظام أسماء النطاقات RFC 5936 (يحدد AXFR، ويحدث RFC 1034 أسماء النطاقات - المفاهيم والمرافق، وRFC 1035 أسماء النطاقات - التنفيذ والمواصفات)
RFC 1995 نقل المنطقة التدريجي في نظام أسماء النطاقات
RFC 1996 آلية للإخطار الفوري بتغييرات النطاق (DNS NOTIFY)
مسودة بروتوكول نقل منطقة نظام أسماء النطاقات (AXFR) - مسودة الإنترنت

[:0-1] 1 2 "أسماء النطاقات - التنفيذ والمواصفات" . IETF . نوفمبر 1987.

[:1-2] 1 2 ديكنسون، جون؛ ديكنسون، سارة؛ بيليس، راي؛ مانكين، أليسون؛ ويسلز، دوان (مارس 2016). "نقل نظام أسماء النطاقات عبر بروتوكول TCP - متطلبات التنفيذ" . IETF .

[3] فوجيوارا، كازونوري؛ سوليفان، أندرو؛ هوفمان، بول (2019). "مصطلحات نظام أسماء النطاقات" . tools.ietf.org . doi : 10.17487/RFC8499 . تاريخ الاسترجاع: 21 يونيو 2020 .

[4] "تكوين ربط خاطئ يكشف القائمة الكاملة لنطاقات المستوى الأعلى الروسية على الإنترنت" . مدونة SecurityTrails . 14 مارس 2018. تاريخ الاطلاع: 10 أبريل 2018 .

[5] "تغريم شركة مكافحة البريد العشوائي بسبب الوصول إلى سجلات نظام أسماء النطاقات لشبكة خاصة" . صحيفة ذا إتش . 18 يناير 2008.

[ 3 ]

[ 4 ]

[ 5 ]

اللغة	العربية (RTL)
روابط موسوعية	24 رابطاً
المصدر الأصلي	ويكيبيديا ↗