حول الامتداد الآمن لنظام أسماء النطاقات

ماهو الامتداد الآمن؟

نظام أسماء النطاقات (Domain Name System- DNS) عبارة عن قاعدة بيانات موزعة هرميا على شبكة الإنترنت، ومن ضمن ما تحتويه بيانات حول أسماء الأجهزة وعناوينها الرقمية (IP addresses) لكل نطاق بحيث يتم تقسيم هذه البيانات إلى أجزاء تدار محليا والوصول إليها عبر شبكة الإنترنت باستخدام بروتوكول خاص بنظام أسماء النطاقات. ويستخدم نظام أسماء النطاقات نموذج الخادم والعميل (client server model) حيث يحتفظ كل خادم – ويسمى خادم أسماء النطاقات domain name server- بجزء بسيط من قاعدة البيانات ويوفرها للعميل (resolver). لذا فالمهمة الأساسية لنظام أسماء النطاقات هي ترجمة العناوين الأسمية (أسماء النطاقات) إلى عناوين رقمية (IP Addresses) والعكس. وهذا بدوره مكن من استبدال العناوين الرقمية صعبة التذكر (مثل 86.111.195.4) بأسماء نطاقات سهلة التذكر (مثل www.nic.sa)، والذي أدى إلى سهولة التعامل مع شبكة الإنترنت من قبل البشر.

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

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

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

• الرد الوارد هو في الواقع ما تم إرساله من قبل الخادم المستجيب (وذلك للتغلب على الهجمات المعروفة بمسمى "رجل في المنتصف" - man in the middle attacks)؛ و
• أن الخادم المستجيب هو في الحقيقة كما يدعي في إجابته الواردة.

مع العلم بأن الردود الصادرة من نظام الامتداد الآمن (DNSSEC) تكون موقعة رقميا، وهذا بدوره يمكن أجهزة الاستقصاء (resolvers) التحقق من كون أن المعلومات الواردة هي متطابقة (أي كاملة، ولم يتم العبث بها) للمعلومات المحفوظة على خادم أسماء النطاقات المعتمد (authoritative DNS server).

وباختصار وبلغة مبسطة فإن الخادم المعتمد (authoritative DNS server) لاسم النطاق بدلا من أن يقوم فقط بالرد بالمعلومة المطلوبة التي تخص أي استفسار يصل إليه، فانه يقوم أيضا بإرفاق توقيع رقمي مخصص لتلك المعلومة، وهذا بدوره يمكن الطرف المستفسر (DNS resolver) من التأكد من صحة تلك المعلومة ومن مصدرها. والذي يساعد على تحقيق ذلك هو استخدام أنظمة التعمية (التشفير) المبنية على تقنية المفتاح العمومي (public-key cryptography)، بحيث يقوم الخادم المعتمد لاسم النطاق باستخدام زوج من المفاتيح المرتبطة ببعضها البعض، يكون أحدهما "خاص" ويستخدم لتوليد التواقيع، والآخر "عام" يستخدم من قبل الطرف المستفسر لتحقق من صحة التوقيع وبالتالي من صحة المعلومة.

---

ما هي أهم فوائد الامتداد الآمن؟

أمن نظام أسماء النطاقات هو جزء أساسي لا يتجزأ من أمن كامل البنية التحتية للإنترنت، وحيث أن الامتداد الآمن يقدم طبقة إضافية من الأمن لحماية أجهزة الاستقصاء (DNS resolvers) من البيانات المزورة أو المتلاعب بها، فإن فوائده لن تكتمل الا بتبنيه من قبل الجميع (all resolvers) حتى نضمن زوال بعض أنواع الهجمات المتعلقة بنظام أسماء النطاقات وعلى رأسها هجمات "رجل في المنتصف" (man-in-the-middle).

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

وفيما يلي ملخص لأهم فوائد تطبيق الامتداد الآمن:

• إضافة ميزة التحقق من مصدر المعلومة ، وصحتها
• التحقق من وجود المعلومة من عدمها
• الحماية من بعض الاختراقات التي تتم على نظام أسماء النطاقات خصوصا عن طريق الهجمات التي تعرف باسم "رجل في المنتصف" (Man in the middle attack) أو "تلويث الحافظة" (Cache poisoning).

كما يجب التنبه على أن الامتداد الآمن لا يوفر سرية للبيانات ولا يحمي ضد هجمات تعطيل الخدمة (DOS attacks).

---

كيف يعمل الامتداد الآمن؟

في الأساس، ولغرض تبني الامتداد الآمن يقوم الخادم المعتمد (authoritative DNS server) باستخدام أسلوب التعمية (التشفير) بالمفتاح العمومي (public-key cryptography) وذلك لعمل التواقيع الرقمية على سجلات نظام أسماء النطاقات (DNS records)، مع العلم أن الامتداد الآمن لا يعتمد فقط على أن ملفات النطاقات (zone files) تم توقيعها قميا، ولكن يعتمد أيضا على أن تكون أجهزة الاستقصاء (resolvers) مهيئة للتحقق من المعلومات الناتجة من تبني الامتداد الآمن.

فقبل البدء في توقيع ملف النطاق (zone file) من خلال الامتداد الآمن، تقوم الجهة المعنية بهذا الملف بإنشاء زوج من مفاتيح التشفير (أحدهما خاص والآخر عام). بحيث يتم استخدام المفتاح الخاص (private key) للتوقيع رقميا على سجلات ملف النطاق، ويمكن التحقق منها فقط عن طريق فك التعمية بواسطة المفتاح العمومي (public key). وعليه فإن المفتاح العمومي يتم نشره في ملف النطاق وفق سجل المفاتيح (DNSKEY record)، وتقوم الجهة بتخزين المفتاح الخاص بشكل آمن. لذا يمكن أن يشار إلى أن ملف النطاق قد تم توقيعه من خلال إضافة سجل توثيق توقيع التفويض (DS record) في ملف النطاق الأعلى (parent zone).

وفي كل مرة يتم إنشاء ملف النطاق أو تحديثه، فإن سجلاته (مثل: A، AAAA، MX و CNAME، الخ ...) يتم توقيعها رقميا واحدا تلو الأخر ويتم تدوين ذلك في سجل التوقيع (RRSIG)، والذي يتم إنشاءه من خلال اختزال (hashing) معلومات سجل النطاق (resource record) المراد توقيعه ومن ثم تشفير نتيجة الاختزال باستخدام المفتاح الخاص (private key) لاسم النطاق. بعد ذلك ولأي استفسار حول أي سجل في ملف النطاق يتم إرسال سجل التوقيع جنبا إلى جنب مع سجل الرد. وحالما يستلم جهاز الاستقصاء (resolver) سجل الرد و سجل التوقيع المصاحب له، فإنه يقوم بطلب المفتاح العمومي لذلك النطاق لغرض التحقق من التوقيع عن طريق مقارنة نتيجة الاختزال لسجل الرد مع نتيجة فك تشفير سجل التوقيع. فإذا كانت النتيجة متساوية فهذا يعني أن التوقيع صحيح. وبهذه الطريقة يمكن لجهاز الاستقصاء التحقق من أن السجلات المطلوبة أتت من الخادم المعتمد ولم يمسها أي تغيير أو تزوير، مقارنة بما هو في السابق من احتمال الحصول على سجلات مزورة أو تم العبث بها ضمن هجمات ما يعرف بـ "رجل في المنتصف".

وقد أضاف الامتداد الآمن عدد من السجلات الجديدة لملف النطاق وذلك لغرض تسهيل التحقق من صحة التوقيع، منها :

1. سجل التوقيع (RRSIG) - ويحتوي على توقيع رقمي
2. سجل المفاتيح (DNSKEY) - ويحتوي على المفتاح العمومي
3. سجل توثيق توقيع التفويض (DS record) - ويحتوي على صيغة مختزلة لسجل المفاتيح
4. سجل توثيق النفي (NSEC/NSEC3) – وذلك لغرض البيان وبشكل صريح عدم وجود سجل في ملف النطاق

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

وقبل البدء في الخوض والشرح التفصيلي لهذه المهام والممارسات فإننا سوف نفترض وجود نوعين اثنين مستقلين من المفاتيح:

1. مفتاح لتوقيع ملف النطاق (يطلق عليه Zone Signing Key -ZSK) وهو مكون من زوج من مفاتيح التشفير (أحدهما خاص والآخر عام).
2. مفتاح لتوقيع المفاتيح (يطلق عليه Key Signing Key – KSK) وهو مكون أيضا من زوج من مفاتيح التشفير (أحدهما خاص والآخر عام)

مع العلم أنه يمكن في بعض الحالات استخدام مفتاح واحد فقط لكلا المهمتين، أي لتوقيع مجموعات السجلات (RRsets) و كذلك سجلات المفاتيح (DNSKEY). وبالرغم من ذلك فإنه من المستحسن على نطاق واسع الفصل بينهما لأن إجراء تحديث (أو تغيير) المفتاح الخاص بتوقيع المفاتيح (KSK) نوعا ما معقد ويتطلب بعضا من الوقت، في حين أن تغيير المفتاح الخاص بتوقيع ملف النطاق (ZSK) هو أسهل وأسرع من ذلك بكثير، لذا فإنه يسمح باستخدام مفاتيح (ZSKs) قصيرة نسبيا دون التضحية بسلامة أمن الخادم المعتمد (DNS authoritative server)، وهذا بدوره يؤدي إلى التقليل من كمية البيانات المتدفقة من الخادم عند إرسال الردود.

المهام والممارسات التابعة للامتداد الآمن:

1. تجميع سجلات ملف النطاق (RRsets)

يقوم الامتداد الآمن أولا بتجميع السجلات ذات النوع نفسه في مجموعة يطلق عليها مجموعة السجل (RRset)، فعلى سبيل المثال، إذا كان هناك 3 سجلات من نوع (MX) في ملف النطاق ، فإنها تجمع كلها في مجموعة واحدة تحت مجموعة سجل (MX RRset) ، ومن ثم يتم توقيعها رقميا.

2. توقيع ملف النطاق باستخدام مفتاح التوقيع (ZSK)

يستخدم الامتداد الآمن مفتاح توقيع ملف النطاق (ZSK) بكلا شقيه: الخاص والعمومي، بحيث يستخدم الجزء الخاص للتوقيع رقميا على كل مجموعة سجل (RRset) ضمن ملف النطاق على حدة ومن ثم نشر نتيجة التوقيع في سجل التوقيع (RRSIG) في نفس ملف النطاق. أما الجزء العمومي من مفتاح التوقيع (ZSK) فيتم نشره في ملف النطاق باستخدام سجل المفاتيح (DNSKEY)، حيث أنه سيستخدم في وقت لاحق من قبل أجهزة الاستقصاء (resolvers) للتحقق من صحة التوقيع.

وحالما يرسل جهاز الاستقصاء (resolver) طلب الاستعلام حول سجل ما (على سبيل المثال، MX)، فإن جهاز الخادم المستجيب يرد بالمعلومات حول السجل المطلوب مقترنة بسجل التوقيع (RRSIG) المقابل لذلك السجل. بعد ذلك، يطلب جهاز الاستقصاء من الجهاز المستجيب سجل المفاتيح (DNSKEY) والذي يحتوي على الجزء العمومي من المفتاح (ZSK). و إجمالا، يمكن القول أن مجموعة السجل (RRset) و سجل التوقيع (RRSIG) والجزء العمومي من (ZSK) يلعبون دورا مهما في التحقق من صحة الرد.

ولكن يبقى من الضروري التحقق من صحة الجزء العمومي من (ZSK) وأنه لم يتم العبث به أو تزويره من خلال سجل التواقيع الخاص به (RRSIG). ومن هنا يأتي دور الخطوة التالية.

3. توقيع مفاتيح التواقيع (DNSKEY) باستخدام مفتاح توقيع سجلات المفاتيح (KSK)

إلى جانب مفتاح توقيع ملف النطاق (ZSK)، يستخدم الامتداد الآمن مفتاح توقيع سجلات المفاتيح (KSK) والمكون من أيضا من شقين عمومي وخاص. وعلى غرار الجزء العمومي للمفتاح (ZSK)، فإنه أيضا يتم نشر الجزء العمومي للمفتاح (KSK) على شكل سجل المفاتيح (DNSKEY). كما يتم استخدام المفتاح (KSK) للتحقق من صحة سجلات المفاتيح (DNSKEY) بنفس الطريقة التي يستخدم بها المفتاح (ZSK) للتحقق من صحة مجموعة السجل (RRset). حيث أنه يستخدم الجزء الخاص من المفتاح (KSK) لتوقيع مجموعة السجل (RRset) الخاصة بسجل المفاتيح (DNSKEY) والذي يحتفظ بالأجزاء العمومية لكل المفاتيح (ZSK, KSK)، وينتج عن ذلك سجل التوقيع (RRSIG) الخاص بمجموعة سجل المفاتيح (DNSKEY RRset).

وعليه تكون الخطوة التالية قيام جهاز الاستقصاء (resolver) باستخدام الجزء العمومي من المفتاح (KSK) للتحقق من صحة الجزء العمومي من (ZSK) على النحو التالي نوعا ما:

• الاستعلام عن مجموعة السجل (RRset) المطلوبة، وسيأتي الرد متضمنا سجل التوقيع (RRSIG) المقابل للسجل المطلوب.
• الاستعلام عن مجموعة سجل المفاتيح (DNSKEY RRset) والتي تتضمن بالأجزاء العمومية لكل المفاتيح (ZSK, KSK)، وسيتضمن الرد أيضا سجل التوقيع (RRSIG) المقابل لمجموعة سجل المفاتيح (DNSKEY RRset).
• التحقق من صحة سجل التوقيع (RRSIG) لمجموعة السجل المطلوب (RRset) باستخدام الجزء العمومي من (ZSK).
• التحقق من صحة سجل التوقيع (RRSIG) لمجموعة سجل المفاتيح (DNSKEY RRset) باستخدام الجزء العمومي من (KSK).

كما يتضح من الخطوات السابقة فإن الجزء العمومي من (KSK) تم توقيعه ذاتيا (أي بنفس المفتاح KSK). وعليه، ومرة أخرى، هناك ضرورة للتحقق من صحة الجزء العمومي من المتاح (KSK)، ويتم ذلك من خلال ربط سلسلة الثقة (chain of trust) بالنطاق الأعلى التالي (parent zone).

4. وضع رابط الثقة (trust anchor) باستخدام سجل توثيق توقيع التفويض (DS)

يقوم الامتداد الآمن باستخدام سجل توثيق توقيع التفويض (DS) لربط سلسلة الثقة من النطاق الأعلى التالي (parent zone) إلى النطاق الفرعي، حيث يتم اختزال (hash) سجل التوقيع (DNSKEY) والذي يحتوي على الجزء العمومي من المفتاح (KSK) ومن ثم ارساله إلى الجهة المسؤولة عن النطاق الأعلى (parent zone) ليتم نشره ضمن ملفه باستخدام سجل توثيق توقيع التفويض (DS).

يقوم النطاق الأعلى التالي (parent zone) بتزويد جهاز الاستقصاء بسجل توثيق توقيع التفويض (DS) كل مرة يحيله إلى النطاق الفرعي التابع له، وهذا بدوره يشير على أن النطاق الفرعي يستخدم الامتداد الآمن. بعد ذلك، وللتحقق من صحة الجزء العمومي من المفتاح (KSK) الخاص بالنطاق الفرعي، فإن جهاز الاستقصاء يقوم باختزال قيمة سجل المفاتيح (DNSKEY) في النطاق الفرعي ومن ثم مقارنتها مع سجل (DS) الذي تم الحصول عليه من النطاق الأعلى التالي (parent zone). فإذا تطابقت القيمتان فذلك يشير إلى أن الجزء العمومي من (KSK) لم يتم العبث به، وهو ما يعني أنه يمكن الوثوق بكافة السجلات المنشورة في ملف النطاق الفرعي. وهذه هي طريقة الامتداد الآمن لتكوين سلسلة الثقة.

من المعلوم أن أي تعديل على المفتاح (KSK) يتطلب أيضا تحديثا في سجل توثيق توقيع التفويض (DS) لدى النطاق الأعلى التالي (parent zone) والذي يعتبر إجراء نوعا ما ثقيل ومعقد وقد يؤدي إلى حالة غير مستقرة لاسم النطاق. حيث أنه قد ينطوي الإجراء في البداية على إضافة السجل الجديد (DS) في ملف النطاق الأعلى التالي، ومن ثم الانتظار حتى انتهاء فترة TTL للسجل القديم (DS) قبل إزالته. وهذا أحد أسباب استخدام نوعين منفصلين من المفاتيح (ZSK، KSK)، بحيث من الأسهل بكثير تبديل ZSKs من KSKs.

5. سلسلة الثقة (كيف نثق في سجل توثيق توقيع التفويض DS)

بعد إضافة سجل توثيق توقيع التفويض (DS) إلى ملف النطاق الأعلى التالي (parent zone) يتم توقيعه بنفس الطريقة التي يتم فيها توقيع مجموعات السجلات (RRsets) الأخرى وحفظ نتيجة التوقيع في سجل التوقيع (RRSIG) في نفس ملف النطاق. وتكرر هذه العملية حتى نصل إلى الجزء العمومي للمفتاح (KSK) الخاص بالنطاق الأعلى التالي (parent zone)، وهو ما يحتم استخدام سجل DS الخاص بالنطاق الأعلى التالي (parent zone)، وهكذا نصعد في سلسلة الثقة حتى نصل إلى الملف الجذري (root zone).

وعند الوصول إلى الملف الجذري (root zone) ، فإن الجزء العمومي من مفتاح الجذر (root KSK) يتم الوثوق به دون الحاجة إلى مراجعة سجله (DS) حيث لا وجود له، حيث تنبثق هذه الثقة من الإجراءات الأمنية المتبعة من قبل آيكان ومراسيم إنشاء وحفظ الجزء الخاص بمفتاح الجذر (root KSK)، وكذلك حضور ومشاركة عدد من الأشخاص المختصين من جميع أنحاء العالم هذه المراسيم للشهادة على توقيع مجموعة سجلات المفاتيح (DNSKEY RRset ) والمسجلة صوتا وصورة والمدققة للغاية والتي تخص الملف الجذري (Root Zone). أيضا يقوم الحضور بمراقبة نشر سجل التوقيع (RRSIG) والذي يمكن استخدامه للتحقق من الجزء العمومي لكل من المفاتيح الجذرية (root ZSK and KSK).

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

6. كيفية التوثق عن عدم وجود المعلومة (الافصاح عن عدم وجود المعلومة)؟

في الوضع الحالي (أي من دون الامتداد الآمن) يقوم نظام أسماء النطاقات بالرد بإجابة فارغة لأي استعلام غير موجود. فعلى سبيل المثال، إذا طلب جهاز الاستقصاء (resolver) من خادم أسماء نطاق معتمد معلومات عن السجل (MX) لنطاق ما غير موجود، فإن الخادم يجيب بإجابة فارغة. وهذا النمط يسبب صعوبة بالغة للامتداد الآمن حيث ما هي الوسيلة الممكنة للامتداد الآمن أن يتخذها للتصديق (أي توقيعها رقميا) على جواب فارغ؟ وللتغلب على هذه المشكلة فإن الامتداد الآمن قام بإضافة نوع جديد من السجلات تعرف بسجلات توثيق النفي (NSEC, NSEC3) والتي تسمح بالإفصاح صراحة عن عدم وجود المعلومة.

يشير سجل توثيق النفي (NSEC/NSEC3) إلى "السجل الموثوق به التالي" في ملف النطاق. فعلى سبيل المثال، عرّف خادم أسماء نطاقات سجلت من النوع (A) لكل من الأسماء التالية: mail, secure, www (لاحظ أنه قد تم ترتيب السجلات أبجديا)، عند طلب جهاز استقصاء (resolver) معلومات حول "online"، فإن خادم أسماء النطاقات سوف يرد بسجل توثيق النفي (NSEC/NSEC3) مشيرا إلى أن "السجل الموثوق به التالي" هو "secure"، وهذه الإجابة تعني أنه لا يوجد سجلات بين "mail" و "secure"، وعليه فإن جهاز الاستقصاء سوف يفهم أن "online" غير موجود ويمكن التحقق من صحة ذلك من خلال التحقق من صحة سجل التوقيع (RRSIG) الخاص بسجل توثيق النفي (NSEC/NSEC3) بنفس الآلية التي تم توضيحها سابها للسجلات بشكل عام.

---

كيف يتم تفعيل الامتداد الآمن؟

يتم تفعيل الامتداد الآمن في جانبين رئيسيين: أ‌- للتوقيع في خادمات أسماء النطاقات المعتمدة (authoritative DNS servers)؛ ب‌- للتحقق من صحة التواقيع في أجهزة الاستقصاء (DNS resolvers).

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

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

أ‌- تفعيل الامتداد الآمن في خادم أسماء النطاقات المعتمد:

الغرض من تفعيل الامتداد الآمن في خادم أسماء النطاقات المعتمد (authoritative DNS servers) هو توقيع ملف النطاق (zone file). وهذا ينطوي على توليد سجلات التواقيع الرقمية (RRSIGs) وإضافة سجلات أخرى (على سبيل المثال. DNSKEY، NSEC3) في ملف النطاق (zone file) والتي تستخدم من قبل أجهزة الاستقصاء (التي تم تفعيل الامتداد الآمن بها) وذلك للتحقق من صحة الردود الواردة من الخادم المعتمد.

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

1. جهاز التوقيع

بشكل عام وفي معظم الحالات، فإنه لا يمكن الوصول لجهاز التوقيع من خلال شبكة الإنترنت، ويكون تواجده تقريبا بين جهاز توليد ملف النطاق (zone builder) وخادم أسماء النطاقات المعتمد. وعليه فإن جهاز توليد ملف النطاق (zone builder) يقوم بنقل ملف النطاق بعد إنشاءه إلى جهاز التوقيع (signer) باستخدام على سبيل المثال أحد الأوامر التالية: AXFR/IXRF أو SSH/SCP، وبعد التوقيع يقوم جهاز التوقيع (signer) بنقل الملف الموقع إلى الخادم المعتمد بنفس الطريقة.

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

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

هناك برامج من شأنها أن تساعد في أداء هذه المهام، على سبيل المثال، OpenDNSSEC وأحدث الإصدارات من BIND.

2. إنشاء وإدارة مفاتيح التواقيع

يعتبر إنشاء وإدارة مفاتيح التواقيع (ZSK وKSK) نواة لتجهيز وتفعيل بنية الامتداد الآمن، ولذلك يجب الاعتناء عناية خاصة بذلك لضمان ما يلي:

• أن تكون هناك عشوائية كافية عند إنشاء المفاتيح. ويمكن زيادة العشوائية باستخدام مولد أرقام عشوائية خارجي، متوفرة على سبيل المثال: كذاكرة USB، أو كجزء من أحدث المعالجات (مثل: RdRand).

• حفظ الجزء الخاص من مفاتيح التواقيع وحمايتها من الوصول إليها من غير المصرح لهم.

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

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

• اختيار خوارزمية تشفير آمنة ومدعومة جيدا، على سبيل المثال (اعتبارا من تاريخ كتابة هذا التقرير)، فإن خوارزمية RSA تعتبر خيارا مناسب ويستحب أن يكون طول المفتاح 2048 خانة ثنائية (bit). وتجدر الإشارة أنه من المفضل التأكد من أن جهاز التوقيع قادر على دعم خوارزميات منحنى إهليلجي (ECDSA) والتي من المحتمل أن تصبح هي المستخدمة في المستقبل القريب.

• استخدام خوارزمية قوية لعملية الاختزال (hash)، على سبيل المثال، SHA-256.

• استخدام مفتاحين مختلفين لعملية التوقيع: مفتاح توقيع المفاتيح (KSK) ويستخدم فقط لتوقيع سجلات المفاتيح (DNSKEY RRset)، ومفتاح توقيع ملف النطاق (ZSK) ويستخدم لتوقيع جميع السجلات في ملف النطاق. وبهذه الطريقة سوف يسمح باستبدال مفتاح توقيع ملف النطاق (ZSK) دون المساس بملف النطاق التابع للنطاق الأعلى التالي (parent zone). ويمكن تخويل جهاز التوقيع (signer) باستبدال مفتاح توقيع ملف النطاق (ZSK) مرتين أو 4 مرات في السنة، وهي تعتبر ممارسة جيدة. أما استبدال مفتاح توقيع المفاتيح (KSK) فيتطلب التواصل والتنسيق مع مشغل النطاق الأعلى التالي (parent zone)، وعليه هناك طريقتان لاستبداله:

  \1. استبدال مفتاح توقيع المفاتيح (KSK) فقط عند تحديث نظام التوقيع أو خوارزمية التشفير – هذا يتطلب استخدام مفتاح طويل نسبيا، على سبيل المثال، 4096 خانة ثنائية؛ \2. يجب أن تتم عملية الاستبدال بشكل دوري ومنتظم كل سنة أو سنتين.

3. اختيار قيم إعدادات الامتداد الآمن

تعرض كل من الوثائق التالية (RFC 6781 و RFC 7583) مجموعة من التوصيات المفيدة لاختيار بعض قيم الإعدادات والفترات الزمنية الخاصة بالامتداد الآمن. وهذه بعض الأفكار عند تحديد قيم الإعدادات:

• الدافع الأهم في اختيار الفترات الزمنية وتحديد قيم الإعدادات هو ضمان أن الأشخاص المسؤولين عن نظام أسماء النطاقات والامتداد الآمن لديهم الوقت الكافي لكشف وتحديد المشاكل قبل أن تنتهي صلاحية التواقيع في ملف النطاق أخذين عطلة نهاية الأسبوع والأعياد في عين الاعتبار. على سبيل المثال: في الوضع المعتاد تكون فترة الصلاحية للتوقيعات 14 يوما، وفترة التجديد تصل إلى 10 أيام، وهذا يعطي 10 أيام لاكتشاف وإصلاح الخطأ.
• التوقيع المنتظم يحافظ على تجديد التواقيع.
• يجب تعيين وقت انتهاء الصلاحية ملف النطاق (zone’s SOA expiry time) بقيمة أقل من فترة صلاحية التواقيع في الملف. وهذا بدوره يجعل صلاحية ملف النطاق تنتهي من على الخادم المعتمد قبل الرد بتواقيع منتهية الصلاحية. بحيث أنه في حالة انتهاء صلاحية ملف النطاق، فإن الخادم المعتمد يجيب على أجهزة الاستقصاء بالرد SERVFAIL، وعليه يقوم جهاز الاستقصاء بالاستفسار من خادم معتمد أخر . ولكن بالمقابل لو كانت صلاحية ملف المنطقة لا تنتهي قبل انتهاء مدة صلاحية التواقيع، فإن الخادم المعتمد سوف يرد بتواقيع منتهية الصلاحية إلى أجهزة الاستقصاء، مما يوقف عملية الاستفسار وإرجاع SERVFAIL لمقدم الطلب الأصلي.
• ينصح (لملفات النطاق الكبيرة) استخدام السجلات NSEC3 بدلا من السجلات NSEC لمنع اكتشاف محتويات ملف النطاق.

4. نشر سجل توثيق توقيع التفويض (DS)

لإنشاء سلسلة الثقة لملف النطاق فإنه يتحتم نشر سجل توثيق توقيع التفويض (DS) الخاص بمفتاح توقيع المفاتيح (KSK) في ملف النطاق الأعلى التالي (parent zone) ويوقع باستخدام مفتاح توقيع ملف النطاق (ZSK) التابع للنطاق الأعلى التالي.

5. المراقبة المستمرة

من المهم جدا مراقبة ملفات النطاقات الموقعة من قبل الامتداد الآمن. وهذه قائمة من الأمثلة التي يستحسن مراقبتها:

• التأكد من صحة ملف النطاق و صحة بيانات الامتداد الآمن للملف، وذلك بالاستعانة بنظام مراقبة يستفسر عن بعض النطاقات ويتأكد من أن الخانة AD (Authenticated Data) مفعلة في الردود الواردة إليه من الجهاز المسؤول عن ملف النطاق قبل نشره في الخوادم الرئيسية، ويمكن الاستعانة ببعض الملحقات الاضافية على برامج المراقبة والتي تدعم ذلك (مثل Nagios).
• الفترات الزمنية المتبقية لصحة التواقيع ينبغي أن تبدو وكأنها رسم بياني متعرج بنمط ثابت، أي، تكون منخفضة جدا عندما تصل قيمتها مساوية لقيمة تحديث التوقيع (على سبيل المثال، 10 أيام) وترتفع جدا عندما تصل فترة صلاحية التواقيع (على سبيل المثال، 14 يوما) عند حدوث عملية التجديد.
• آخر تحديث لملف النطاق: يجب تحديث ملف المنطقة بشكل دوري لضمان عدم انتهاء صلاحية التواقيع (يمكن التحقق من تغيير قيمة التسلسل الرقمي في سجل SOA ).
• نقل ملف النطاق بين جهاز التوقيع والخادم المعتمد (أو بين الخادم المعتمد الرئيسي والخوادم المعتمدة الثانوية).
• من الضروري، بعد توقيع ملف النطاق وقبل نقله لخوادم الأسماء المعتمدة، القيام بالتحقق الذاتي عن طريق التحقق من صحة السجلات الموقعة وأن سجل المفاتيح تم توقيعه باستخدام مفتاح توقيع المفاتيح (KSK) الذي له نسخة مختزلة على شكل سجل (DS) في ملف النطاق الأعلى التالي.

ب‌- تفعيل الامتداد الآمن في أجهزة الاستقصاء :

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

وبشكل عام ودون الخوض في التفاصيل الفنية، فإنه يمكن تقسيم تفعيل الامتداد الآمن في أجهزة الاستقصاء إلى الخطوات التالية:

1. إعداد المتطلبات

وهذا ينطوي على اختيار الإصدار المناسب من برنامج أسماء النطاقات والتي تدعم التحقق من صحة الامتداد الآمن، على سبيل المثال، BIND (الإصدار. 9.7.5 أو أحدث) و Unbound (الإصدار 1.4.16 أو أحدث). وتجدر الإشارة أنه وبسبب استخدام التشفير بالمفتاح العمومي فإن عمليات الامتداد الآمن تعتبر مكثفة حسابيا، لذلك ولغرض سلاسة وسرعة المعالجة يتطلب أن تكون قوة وحدة المعالجة المركزية أعلى من المتوسط، مع العلم بأن أغلب الأجهزة الحديثة للخادمات (والتي لا يزيد عمرها عن 5-7 سنوات) تعتبر قوية بما فيه الكفاية لتشغيل الامتداد الآمن في أجهزة الاستقصاء.

يلاحظ أن سجلات الامتداد الآمن زادت من حجم ردود أسماء النطاق بشكل ملحوظ والذي قد لا يمكن تضمينه في حزمة UDP بحجم 512 بايت. وبالتالي، فإن البنية التحتية للشبكة والجدران النارية تحتاج إلى فحص وضبط لدعم ردود الامتداد الأمن الطويلة على كل من UDP و TCP (وهو ما يعرف بدعم استخدام EDNS0).

2. الحصول والتحقق من صحة رابط الثقة

عند تفعيل خدمة الامتداد الآمن في أجهزة الاستقصاء فإنه ينبغي تزويدها برابط الثقة الجذري (root trust anchor) ليلعب دور نقطة البدء في سلسلة الثقة. وعليه فإنه من الأهمية بمكان التأكد من صحة وسلامة رابط الثقة الجذري قبل تجهيز جهاز الاستقصاء، وذلك من خلال أولا جلب نسخة من رابط الثقة الجذري من موقع آيانا (IANA) مع الحرص على جلبه خلال قناة آمنة (مثال: https). ومن ثم التأكد من أن معلومات رابط الثقة الجذري التي تم الحصول عليها من موقع آيانا يتوافق مع المفتاح العمومي لمنطقة الجذر والمنشور في الخادم الجذري. وينبغي كذلك التحقق من صحتها باستخدام آلية أخرى )على سبيل المثال، شبكة ثقة PGP).

3. الحفاظ على صحة ساعة التوقيت

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

4. المراقبة المستمرة

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

• ينبغي – عند الضرورة - دراسة وتحليل عدد الأخطاء ونوعها المنبثقة من عملية التحقق، على سبيل المثال، عن طريق زيادة الإسهاب (التفاصيل) في تسجيل وقائع (logging) برنامج خادم أسماء النطاق لجهاز الاستقصاء.
• توفر الإحصاءات لجهاز الاستقصاء (بما في ذلك أخطاء التحقق من الصحة) يعتمد على نوع البرنامج المستخدم. على سبيل المثال في نظام Unbound يمكنك تفريغ الإحصاءات باستخدام الأمر: 'unboundcontrol-stats’.
• يتطلب دراسة متأنية ما إذا كان من المناسب تسجيل الوقائع بشكل مستمر أم لا. مع ملاحظة أن تسجيل الوقائع بشكل مستمر يمكن، في أسوأ الأحوال، أن يزيد من الحمل على الجهاز بشكل كبير، وبالتالي فتح جبهة جديدة للهجوم.
• عدد الردود SERVFAIL.
• حالة انضباط (تزامن) ساعة جهاز الاستقصاء (على سبيل المثال، NTP تزامن).

---

منهجية المركز لتبني الامتداد الآمن (DNSSEC)

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

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

• المرحلة الأولى: كسب الخبرة المحلية
• مرحلة الثانية: التشغيل التجريبي
• مرحلة النهائية: التشغيل الفعلي

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

• إشراك المشغلين لتجريب توقيع أسماء نطاقاتهم لتجربة التعامل مع الامتداد الآمن وكسب الخبرة اللازمة.
• تطوير موقع مختص بالامتداد الآمن للعموم (باللغتين العربية والإنجليزية).
• تطوير أنظمة التسجيل استعدادا لتقديم الخدمات الخاصة بالامتداد الآمن للعملاء.
• تدشين مراسيم إنشاء المفاتيح الوطنية الخاصة بالامتداد.
• التوقيع الفعلي لكل من (.sa) و (.السعودية).

---

التسجيل وإدارة خدمة الامتداد الآمن لنطاق سعودي مسجل لدى المركز (DNSSEC)

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

• وسم المفتاح وهو عبارة عن رقم التمييز الخاص بالمفتاح
• خوارزميات المفتاح وهو المستخدمة لإنشاء المفتاح وهناك عدة معايير دوليه منها على سبيل المثال:
  • DSA/SHA-1
  • RSA/SHA-1
  • DSA-NSEC3/SHA1
  • RSA/SHA-256
  • RSA/SHA-512
  • GOST R 34.10-2001
  • ECDSA Curve P-256 with SHA-256
  • ECDSA Curve P-384 with SHA-384
  • Ed25519
  • Ed448
• نوع الاختزال وهو اسم الطريقة المستخدمة لاختزال الجزء العام للمفتاح، ومن ذلك:
  • SHA-1
  • SHA-256
• الاختزال وهي القيمة الفعلية لسجل توثيق توقيع التفويض (DS Records).

---

المعايير الدولية:

• RFC 2535 Domain Name System Security Extensions
  • https://tools.ietf.org/html/rfc2535
• RFC 3833 A Threat Analysis of the Domain Name System
  • https://tools.ietf.org/html/rfc3833
• RFC 4033: DNS Security Introduction and Requirements
  • http://tools.ietf.org/html/rfc4033
• RFC 4034: Resource Records for the DNS Security Extensions
  • https://tools.ietf.org/html/rfc4034
• RFC 4035: Protocol Modifications for the DNS Security Extensions
  • https://tools.ietf.org/html/rfc4035
• RFC 4398 Storing Certificates in the Domain Name System (DNS)
  • https://tools.ietf.org/html/rfc4398
• RFC 4470 Minimally Covering NSEC Records and DNSSEC On-line Signing
  • https://tools.ietf.org/html/rfc4470
• RFC 4509 Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
  • https://tools.ietf.org/html/rfc4509
• RFC 5155 DNSSEC Hashed Authenticated Denial of Existence
  • https://tools.ietf.org/html/rfc5155
• RFC 6781, DNSSEC Operational Practices, Version 2
  • https://tools.ietf.org/html/rfc6781
• RFC 6891, Extension Mechanisms for DNS (EDNS(0))
  • https://tools.ietf.org/html/rfc6891
• RFC 7583 DNSSEC Key Rollover Timing Considerations
  • https://tools.ietf.org/html/rfc7583
• RFC 7583, DNSSEC Key Timing Considerations
  • https://tools.ietf.org/html/rfc7583

---

مراجع للاستزادة حول الموضوع

• • https://www.cloudflare.com/dnssec/how-dnssec-works/
  • https://www.easydns.com/what-is-dnssec/
  • https://www.surf.nl/binaries/content/assets/surf/en/knowledgebase/2012/rapport_Deploying_DNSSEC_v20.pdf
  • https://www.cloudflare.com/dnssec/how-dnssec-works/
  • DNSSEC | Deploy360 Programme - Internet Society
  • DNSSEC - Wikipedia
  • DNSSEC - The DNS Security Extensions - Protocol Home Page
  • DNSSEC and BIND | Internet Systems Consortium
  • Overview of DNSSEC - TechNet - Microsoft