Skip to main content
Resources

ما هي امتدادات DNSSEC وما أهميتها؟

هذه الصفحة متوفرة باللغات:

وصف موجز لكيفية عمل نظام اسم النطاق DNS

لفهم الامتدادات الأمنية لنظام اسم النطاق (DNSSEC)، من المفيد أن يكون لديك فهم أساسي لنظام اسم النطاق (DNS).

يعتمد التشغيل السليم للإنترنت بشكل أساسي على DNS. كل صفحة ويب تمت زيارتها، وكل رسالة بريد إلكتروني يتم إرسالها، وكل صورة يتم استردادها من وسائل التواصل الاجتماعي: تستخدم كل هذه التفاعلات DNS لترجمة أسماء النطاق الملائمة للإنسان (مثل icann.org) إلى عناوين بروتوكول الإنترنت IP (مثل 192.0.43.7 و 2001:500:88:200::7) التي تحتاجها الخوادم وأجهزة التوجيه وأجهزة الشبكة الأخرى لتوجيه حركة البيانات خلال الشبكات إلى الوجهة المناسبة.

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

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

يعتبر DNS بحد ذاته غير آمن

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

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

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

امتدادات أمان DNS أي (DNSSEC)

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

تقوّي DNSSEC المصادقة في DNS باستخدام التواقيع الرقمية القائمة على تشفير المفتاح العام. مع امتدادات DNSSEC، لاتكن استعلامات DNS والاستجابات التي تم توقيعها بنفسها مشفرة، ولكن بيانات DNS نفسها موقعة من مالك البيانات.

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

تضيف DNSSEC ميزتين مهمتين إلى بروتوكول DNS:

  • تسمح مصادقة منشأ البيانات لوحدة الحل بالتحقق بشكل تشفيري من أن البيانات التي تلقاها جاءت فعلباُ من المنطقة التي تعتقد أن البيانات قد تم إصدارها منها.
  • تتيح حماية تكامل البيانات لوحدة الحل معرفة أن البيانات لم يتم تعديلها أثناء النقل حيث تم توقيعها في الأصل بواسطة مالك المنطقة باستخدام المفتاح الخاص بالمنطقة.

الثقة بمفاتيح DNSSEC

تنشر كل منطقة المفتاح العمومي الخاص بها، والذي تسترده وحدة الحل التكراري للتحقق من صحة البيانات في المنطقة. ولكن كيف يمكن لوحدة الحل أن تضمن أن المفتاح العام للمنطقة هو مفتاح حقيقي؟ يتم توقيع المفتاح العام للمنطقة، تماماً مثل البيانات الأخرى الموجودة في المنطقة. ومع ذلك، لا يتم توقيع المفتاح العمومي بواسطة المفتاح الخاص للمنطقة، ولكن بواسطة المفتاح الخاص للمنطقة الأصل. على سبيل المثال، يتم توقيع المفتاح العمومي لمنطقة icann.org بواسطة المنطقة org. تماماً مثلما يكون أصل منطقة DNS مسؤولًا عن نشر قائمة خوادم الأسماء الرسمية لمنطقة تابعة، فإن أصل المنطقة مسؤول أيضاً عن ضمان صحة المفتاح العمومي للمنطقة التابعة. يتم التوقيع على المفتاح العمومي لكل منطقة من قِبل المنطقة الأم، باستثناء منطقة الجذر: ليس لها أصل لتوقيع مفتاحها.

لذلك يعد المفتاح العمومي لمنطقة الجذر نقطة انطلاق مهمة للتحقق من صحة بيانات DNS. إذا كانت وحدة حل ما تثق بالمفتاح العمومي لمنطقة الجذر، فيمكنه الوثوق بالمفاتيح العامة لمناطق المستوى الأعلى الموقعة بالمفتاح الخاص للجذر، مثل المفتاح العمومي للمنطقة org. ولأن وحدة الحل يمكنها الوثوق بالمفتاح العمومي لمنطقة org، فإنها يمكنها الوثوق بالمفاتيح العامة التي تم توقيعها بواسطة المفتاح الخاص بكل منها، مثل المفتاح العمومي لـ icann.org. (في الممارسة الفعلية، لا تقوم المنطقة الأم بتوقيع مفتاح منطقة الطفل (الفرع) مباشرةً - تكون الآلية الفعلية أكثر تعقيداً - ولكن التأثير يكون نفسه كما لو كان المنطقة الأصل قد وقَّعت مفتاح المنطقة الفرعية).

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

التحقق من صحة DNSSEC وتوقيعها

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

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

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

لكي ينشر مالك المنطقة DNSSEC من خلال التوقيع على بيانات المنطقة الخاصة به، يجب أيضًا توقيع أصل هذه المنطقة الرئيسية والجهة التابعة لها، وصولاً إلى منطقة الجذر، حتى تكون DNSSEC فعالة قدر الإمكان. تسمح السلسلة المستمرة من المناطق الموقعة والتي تبدأ من منطقة الجذر لوحدة الحل إنشاء سلسلة ثقة من منطقة الجذر للتحقق من صحة البيانات. على سبيل المثال، لنشر DNSSEC بفاعلية في منطقة icann.org، يجب أن يتم توقيع منطقة المؤسسة وكذلك منطقة الجذر. لحسن الحظ، تم توقيع منطقة جذر DNS منذ عام 2010، كما تم توقيع جميع gTLDs والعديد من ccTLDs.

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

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

الخطوات التالية لامتدادات DNSSEC

مع نمو نشر DNSSEC، يمكن أن يصبح DNS أساساً للبروتوكولات الأخرى التي تتطلب طريقة لتخزين البيانات بشكل آمن. تم تطوير بروتوكولات جديدة تعتمد على DNSSEC وبالتالي تعمل فقط في المناطق الموقعة. على سبيل المثال، تسمح مصادقة الكيانات المسماة (DANE) المستندة إلى DNS بنشر مفاتيح أمن طبقة النقل (TLS) في مناطق للتطبيقات مثل نقل البريد. يوفر DANE طريقة للتحقق من صحة المفاتيح العامة التي لا تعتمد على هيئة منح الشهادات. ستتمكن طرق جديدة لإضافة الخصوصية إلى استعلامات DNS من استخدام DANE في المستقبل أيضاً.

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

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."