امتدادات أمان نظام اسم النطاق

الموسوعة الحرة

بروتوكولات أمن الإنترنت
إدارة المفاتيح
طبقة التطبيق
نظام اسم النطاق
طبقة الانترنت
  • ف
  • ت
  • هـ

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

ملخص

لم يتضمن التصميم الأصلي لنظام أسماء النطاقات أي ميزات أمان. فقد تم تصميمه فقط كنظام موزع قابل للتطوير. تحاول امتدادات أمان نظام أسماء النطاقات (DNSSEC) إضافة الأمان، مع الحفاظ على التوافق مع الإصدارات السابقة . توثق RFC  3833 لعام 2004 بعض التهديدات المعروفة لنظام أسماء النطاقات، وحلولها في DNSSEC.

تم تصميم DNSSEC لحماية التطبيقات التي تستخدم DNS من قبول بيانات DNS المزورة أو التي تم التلاعب بها، مثل تلك التي تم إنشاؤها بواسطة تسميم ذاكرة التخزين المؤقت DNS . يتم توقيع جميع الإجابات من المناطق المحمية بواسطة DNSSEC رقميًا . [1] من خلال التحقق من التوقيع الرقمي، يتمكن محلل DNS من التحقق مما إذا كانت المعلومات متطابقة (أي غير معدلة وكاملة) مع المعلومات المنشورة بواسطة مالك المنطقة والمقدمة على خادم DNS المعتمد. في حين أن حماية عناوين IP هي الشغل الشاغل للعديد من المستخدمين، يمكن لـ DNSSEC حماية أي بيانات منشورة في DNS، بما في ذلك سجلات النصوص (TXT) وسجلات تبادل البريد (MX)، ويمكن استخدامها لتمهيد أنظمة أمان أخرى تنشر مراجع إلى شهادات تشفير مخزنة في DNS مثل سجلات الشهادات ( سجلات CERT ، RFC  4398)، وبصمات SSH ( SSHFP ، RFC  4255)، ومفاتيح IPSec العامة (IPSECKEY، RFC  4025)، ومثبتات ثقة TLS ( TLSA ، RFC  6698)، أو Encrypted Client Hello (سجلات SVCB/HTTPS لـ ECH [2] [3] ).

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

تُستخدم معايير أخرى (غير DNSSEC) لتأمين البيانات الضخمة (مثل نقل منطقة DNS ) المرسلة بين خوادم DNS. وكما هو موثق في RFC  4367، فإن بعض المستخدمين والمطورين يفترضون بشكل خاطئ أسماء DNS، مثل افتراض أن الاسم الشائع للشركة بالإضافة إلى ".com" هو دائمًا اسم المجال الخاص بها. لا يمكن لـ DNSSEC الحماية من الافتراضات الخاطئة؛ فهو لا يستطيع إلا التحقق من أن البيانات صادرة حقًا من مالك المجال أو غير متاحة منه. [ بحاجة لمصدر ]

تصف مواصفات DNSSEC (المسماة DNSSEC-bis ) بروتوكول DNSSEC الحالي بتفصيل كبير. راجع RFC  4033 و RFC  4034 و RFC  4035. مع نشر هذه RFCs الجديدة (مارس 2005)،  أصبح RFC 2535 السابق قديمًا. تم جمع المجموعة الكاملة من RFCs التي تحدد DNSSEC في RFC 9364  ، وهو أيضًا BCP 237.

من المعتقد على نطاق واسع [4] أن تأمين DNS مهم للغاية لتأمين الإنترنت ككل، ولكن نشر DNSSEC على وجه التحديد قد أعاقه (اعتبارًا من 22 يناير 2010 ) العديد من الصعوبات:

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

عملية

يعمل DNSSEC عن طريق التوقيع الرقمي على السجلات للبحث في DNS باستخدام تشفير المفتاح العام . يتم مصادقة سجل DNSKEY الصحيح عبر سلسلة من الثقة ، بدءًا بمجموعة من المفاتيح العامة التي تم التحقق منها لمنطقة جذر DNS والتي تعد الطرف الثالث الموثوق به . يقوم مالكو النطاق بإنشاء مفاتيحهم الخاصة، وتحميلها باستخدام لوحة تحكم DNS الخاصة بهم لدى مسجل اسم النطاق الخاص بهم، والذي بدوره يدفع المفاتيح عبر secDNS إلى مشغل المنطقة (على سبيل المثال، Verisign لـ .com) الذي يوقعها وينشرها في DNS.

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

يتم تنفيذ DNS باستخدام العديد من سجلات الموارد. لتنفيذ DNSSEC، تم إنشاء العديد من أنواع سجلات DNS الجديدة أو تعديلها لاستخدامها مع DNSSEC:

RRSIG (توقيع سجل الموارد)
يحتوي على توقيع DNSSEC لمجموعة سجلات. يتحقق محللو DNS من التوقيع باستخدام مفتاح عام، يتم تخزينه في سجل DNSKEY.
مفتاح DNS
يحتوي على المفتاح العام الذي يستخدمه محلل DNS للتحقق من توقيعات DNSSEC في سجلات RRSIG.
DS (موقع التفويض)
يحمل اسم المنطقة المفوضة. يشير إلى سجل DNSKEY في المنطقة المفوضة الفرعية. يتم وضع سجل DS في المنطقة الأصلية مع سجلات NS المفوضة.
NSEC (السجل الآمن التالي)
يحتوي على رابط لاسم السجل التالي في المنطقة ويسرد أنواع السجلات الموجودة لاسم السجل. تستخدم حلول DNS سجلات NSEC للتحقق من عدم وجود اسم سجل ونوعه كجزء من التحقق من صحة DNSSEC.
NSEC3 (الإصدار الثالث من السجل الآمن التالي)
يحتوي على روابط لاسم السجل التالي في المنطقة (بترتيب فرز الأسماء المجزأة) ويسرد أنواع السجلات الموجودة للاسم المغطى بقيمة التجزئة في الملصق الأول لاسم سجل NSEC3 نفسه. يمكن للمحللين استخدام هذه السجلات للتحقق من عدم وجود اسم ونوع سجل كجزء من التحقق من صحة DNSSEC. سجلات NSEC3 مشابهة لسجلات NSEC، لكن NSEC3 يستخدم أسماء سجلات مجزأة تشفيريًا لتجنب تعداد أسماء السجلات في منطقة.
NSEC3PARAM (معلمات الإصدار 3 من السجل الآمن التالي)
تستخدم خوادم DNS المعتمدة هذا السجل لحساب وتحديد سجلات NSEC3 التي يجب تضمينها في الاستجابات لطلبات DNSSEC للأسماء/الأنواع غير الموجودة.

عند استخدام DNSSEC، تحتوي كل إجابة على بحث DNS على سجل DNS RRSIG، بالإضافة إلى نوع السجل المطلوب. سجل RRSIG هو توقيع رقمي لمجموعة سجلات موارد DNS للإجابة . يتم التحقق من التوقيع الرقمي من خلال تحديد المفتاح العام الصحيح الموجود في سجل DNSKEY. يتم استخدام سجلات NSEC وNSEC3 لتوفير دليل تشفيري على عدم وجود أي سجل موارد (RR). يتم استخدام سجل DS في مصادقة DNSKEYs في إجراء البحث باستخدام سلسلة الثقة. يتم استخدام سجلات NSEC وNSEC3 للمقاومة القوية ضد التزييف.

الخوارزميات

تم تصميم DNSSEC ليكون قابلاً للتوسيع بحيث عندما يتم اكتشاف الهجمات ضد الخوارزميات الموجودة، يمكن تقديم خوارزميات جديدة بطريقة متوافقة مع الإصدارات السابقة كما هو موضح في RFC  8624. يحدد الجدول التالي، اعتبارًا من يونيو 2019، خوارزميات الأمان الأكثر استخدامًا أو كانت الأكثر استخدامًا: [5]

مجال الخوارزمية خوارزمية مصدر توقيع DNSSEC التحقق من صحة DNSSEC
1 RSA / MD5 لا يجب التنفيذ لا يجب التنفيذ
3 DSA / SHA-1 لا يجب التنفيذ لا يجب التنفيذ
5 RSA/SHA-1 طلب التعليقات رقم  3110 غير موصى به مطلوب
6 دي إس إيه-إن إس إي سي 3-إس إتش إيه 1 لا يجب التنفيذ لا يجب التنفيذ
7 RSASHA1-NSEC3-SHA1 طلب التعليقات رقم  5155 غير موصى به مطلوب
8 RSA/ SHA-256 طلب التعليقات رقم  5702 مطلوب مطلوب
10 RSA/ SHA-512 غير موصى به مطلوب
12 المعيار الروسي رقم 34.10-2001 طلب التعليقات رقم  5933 لا يجب التنفيذ خياري
13 ECDSA P-256/ SHA-256 طلب التعليقات رقم  6605 مطلوب مطلوب
14 ECDSA P-384/ SHA-384 خياري مُستَحسَن
15 إد25519 RFC  8080 مُستَحسَن مُستَحسَن
16 إد448 خياري مُستَحسَن
حقل الملخص هضم مصدر وفد DNSSEC التحقق من صحة DNSSEC
1 شا-1 طلب التعليقات رقم  3658 لا يجب التنفيذ مطلوب
2 إس إتش إيه-256 طلب التعليقات رقم  4509 مطلوب مطلوب
3 المعيار الروسي رقم 34.10-2001 طلب التعليقات رقم  5933 لا يجب التنفيذ خياري
4 إس إتش إيه-384 طلب التعليقات رقم  6605 خياري مُستَحسَن

إجراء البحث

من نتائج البحث في DNS، يمكن لمحلل DNS الذي يراعي الأمان تحديد ما إذا كان خادم الاسم المعتمد للنطاق الذي يتم الاستعلام عنه يدعم DNSSEC، وما إذا كانت الإجابة التي يتلقاها آمنة، وما إذا كان هناك نوع من الخطأ. يختلف إجراء البحث بالنسبة لخوادم الأسماء المتكررة مثل تلك الخاصة بالعديد من موفري خدمة الإنترنت ، وبالنسبة لمحللات الاختصارات مثل تلك المضمنة افتراضيًا في أنظمة التشغيل الرئيسية. يستخدم Microsoft Windows محللًا اختصارًا، ويستخدم Windows Server 2008 R2 وWindows 7 على وجه الخصوص محللًا اختصارًا غير صالح ولكنه يراعي DNSSEC. [6] [7]

خوادم الأسماء المتكررة

باستخدام نموذج سلسلة الثقة ، يمكن استخدام سجل توقيع التفويض (DS) في المجال الرئيسي ( منطقة DNS ) للتحقق من سجل DNSKEY في المجال الفرعي ، والذي يمكن أن يحتوي بعد ذلك على سجلات DS أخرى للتحقق من المجالات الفرعية الأخرى. لنفترض أن مُحللًا متكررًا مثل خادم اسم مزود خدمة الإنترنت يريد الحصول على عناوين IP ( سجل A و/أو سجلات AAAA ) للمجال "www. example.com ".

  1. تبدأ العملية عندما يقوم محلل أمان بتعيين بت العلم "DO" ("DNSSEC OK") في استعلام DNS. نظرًا لأن بت DO موجود في بتات العلم الممتدة المحددة بواسطة آليات التمديد لـ DNS (EDNS) ، RFC  6891، فيجب أن تدعم جميع معاملات DNSSEC EDNS. كما يلزم دعم EDNS للسماح بأحجام الحزم الأكبر بكثير التي تتطلبها معاملات DNSSEC.
  2. عندما يتلقى المُحلل إجابة عبر عملية البحث العادية في DNS، فإنه يتحقق بعد ذلك للتأكد من صحة الإجابة. ومن الناحية المثالية، سيبدأ المُحلل الذي يدرك الأمان بالتحقق من سجلات DS وDNSKEY في جذر DNS . ثم يستخدم سجلات DS للنطاق الأعلى مستوى "com" الموجود في الجذر للتحقق من سجلات DNSKEY في منطقة "com". ومن هناك، سيتحقق مما إذا كان هناك سجل DS للنطاق الفرعي "example.com" في منطقة "com"، وإذا كان موجودًا، فسيستخدم سجل DS للتحقق من سجل DNSKEY الموجود في منطقة "example.com". وأخيرًا، سيتحقق من سجل RRSIG الموجود في الإجابة للسجلات A لـ "www.example.com".

هناك عدة استثناءات للمثال المذكور أعلاه.

أولاً، إذا لم يدعم "example.com" DNSSEC، فلن يكون هناك سجل RRSIG في الإجابة ولن يكون هناك سجل DS لـ "example.com" في منطقة "com". إذا كان هناك سجل DS لـ "example.com"، ولكن لا يوجد سجل RRSIG في الرد، فهناك خطأ ما وربما يكون هناك هجوم رجل في المنتصف ، يجرد معلومات DNSSEC ويعدل سجلات A. أو، قد يكون خادم أسماء معطلاً لا يراعي الأمان على طول الطريق والذي جرد بت علم DO من الاستعلام أو سجل RRSIG من الإجابة. أو، قد يكون خطأ في التكوين.

بعد ذلك، قد لا يكون هناك اسم نطاق باسم "www.example.com"، وفي هذه الحالة بدلاً من إرجاع سجل RRSIG في الإجابة، سيكون هناك إما سجل NSEC أو سجل NSEC3. هذه هي سجلات "الآمنة التالية" التي تسمح للمحلل بإثبات عدم وجود اسم نطاق. تحتوي سجلات NSEC/NSEC3 على سجلات RRSIG، والتي يمكن التحقق منها كما هو موضح أعلاه.

أخيرًا، قد يكون الأمر أن منطقة "example.com" تطبق DNSSEC، ولكن منطقة "com" أو منطقة الجذر لا تفعل ذلك، مما يؤدي إلى إنشاء "جزيرة أمان" تحتاج إلى التحقق من صحتها بطريقة أخرى. اعتبارًا من 15 يوليو 2010 ، تم الانتهاء من نشر DNSSEC على الجذر. [8] تم توقيع نطاق .com بمفاتيح أمان صالحة وتمت إضافة التفويض الآمن إلى منطقة الجذر في 1 أبريل 2011. [9]

حلول القطع

إن أجهزة حل البيانات المؤقتة هي "أجهزة حل بيانات DNS بسيطة تستخدم وضع الاستعلام المتكرر لتفريغ معظم عمل حل بيانات DNS إلى خادم أسماء متكرر." [10] ستقوم أجهزة حل البيانات المؤقتة ببساطة بإعادة توجيه الطلب إلى خادم أسماء متكرر، واستخدام بت البيانات المصادق عليها (AD) في الاستجابة كـ "تلميح لمعرفة ما إذا كان خادم الأسماء المتكرر قادرًا على التحقق من صحة التوقيعات لجميع البيانات في أقسام الإجابة والسلطة في الاستجابة." [11] تستخدم Microsoft Windows جهاز حل بيانات مؤقت، ويستخدم Windows Server 2008 R2 وWindows 7 على وجه الخصوص جهاز حل بيانات مؤقت غير مصادق ولكنه يدرك بت AD. [6] [7]

يمكن لمحلل البوت التحققي أيضًا أن يقوم بالتحقق من صحة التوقيع الخاص به عن طريق تعيين بت تعطيل الفحص (CD) في رسائل الاستعلام الخاصة به. [11] يستخدم محلل البوت التحققي بت CD لإجراء المصادقة المتكررة الخاصة به. إن استخدام مثل هذا المحلل البوت التحققي يمنح العميل أمان DNS من البداية إلى النهاية للمجالات التي تنفذ DNSSEC، حتى إذا لم يكن مزود خدمة الإنترنت أو الاتصال به موثوقًا به.

يجب أن تعتمد حلول القطع غير المعتمدة على خدمات التحقق من صحة DNSSEC الخارجية، مثل تلك التي يتحكم فيها مزود خدمة الإنترنت الخاص بالمستخدم أو خادم الأسماء المتكرر العام ، وقنوات الاتصال بينها وبين خوادم الأسماء هذه، باستخدام طرق مثل DNS عبر TLS . [11] [12]

نقاط الثقة وسلاسل المصادقة

لكي تتمكن من إثبات صحة إجابة DNS، يتعين عليك معرفة مفتاح أو سجل DS واحد على الأقل صحيح من مصادر أخرى غير DNS. تُعرف نقاط البداية هذه باسم نقاط الثقة ويتم الحصول عليها عادةً باستخدام نظام التشغيل أو عبر بعض المصادر الموثوقة الأخرى. عندما تم تصميم DNSSEC في الأصل، كان يُعتقد أن نقطة الثقة الوحيدة المطلوبة هي لجذر DNS . نُشرت نقاط الثقة الجذرية لأول مرة في 15 يوليو 2010. [13]

سلسلة المصادقة عبارة عن سلسلة من سجلات DS وDNSKEY المرتبطة، تبدأ بنقطة اتصال ثقة بخادم الاسم المعتمد للنطاق المعني. بدون سلسلة مصادقة كاملة، لا يمكن المصادقة بشكل آمن على إجابة بحث DNS.

التوقيعات وتوقيع المنطقة

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

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

إدارة المفاتيح

يتضمن DNSSEC العديد من المفاتيح المختلفة، المخزنة في سجلات DNSKEY، ومن مصادر أخرى لتشكيل نقاط ثقة .

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

يمكن استخدام المفاتيح في سجلات DNSKEY لأمرين مختلفين وعادةً ما يتم استخدام سجلات DNSKEY مختلفة لكل منهما. أولاً، توجد مفاتيح توقيع المفتاح (KSK) التي تُستخدم لتوقيع سجلات DNSKEY الأخرى التي تحتوي على مفاتيح توقيع المنطقة (ZSK)، والتي تُستخدم لتوقيع سجلات أخرى. ونظرًا لأن مفاتيح ZSK تخضع لسيطرة كاملة وتستخدمها منطقة DNS واحدة معينة ، فيمكن تبديلها بسهولة أكبر وبشكل متكرر. ونتيجة لذلك، يمكن أن تكون مفاتيح ZSK أقصر كثيرًا من مفاتيح KSK ولا تزال توفر نفس مستوى الحماية مع تقليل حجم سجلات RRSIG/DNSKEY.

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

المبدأ المرتبط ارتباطًا وثيقًا هو مبدأ نقل الخوارزمية ، والذي يتضمن ترحيل منطقة من خوارزمية توقيع واحدة إلى أخرى. ومن الأمثلة الجيدة على ذلك الترحيل من الخوارزمية 8 (RSA/SHA-256) إلى الخوارزمية 13 (ECDSA/SHA-256). وقد هاجرت بالفعل العديد من نطاقات المستوى الأعلى للرمز بما في ذلك .at و .br و .cz و .ch و .fr و .ie و . nl [14] و .ph . قامت شركة Verisign بنقل .com و.net و.edu إلى الخوارزمية 13 في أواخر عام 2023. [15] [16] ويجري حاليًا التخطيط لترحيل النطاق الجذر من الخوارزمية 8 إلى الخوارزمية 13 اعتبارًا من أوائل عام 2024. [17]

مجموعة عمل DANE

مصادقة الكيانات المسماة القائمة على DNS (DANE) هي مجموعة عمل IETF [18] تهدف إلى تطوير البروتوكولات والتقنيات التي تسمح لتطبيقات الإنترنت بإنشاء اتصالات مؤمنة تشفيريًا مع TLS و DTLS و SMTP و S/MIME استنادًا إلى DNSSEC.

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

تم تمكين دعم شهادات DNSSEC المضمنة في Google Chrome 14، [19] ولكن تمت إزالته لاحقًا. [20] بالنسبة لمتصفح Mozilla Firefox ، تم توفير الدعم من خلال وظيفة إضافية [21] بينما ينتظر الدعم الأصلي حاليًا شخصًا ما لبدء العمل عليه. [22]

تاريخ

إن DNS هي خدمة إنترنت أساسية وحاسمة، ولكن في عام 1990 اكتشف ستيف بيلوفين ثغرات أمنية خطيرة فيها. بدأت الأبحاث في تأمينها، وتطورت بشكل كبير عندما تم نشر ورقته في عام 1995. [23] تم نشر RFC 2065 الأولي بواسطة IETF في عام 1997، وأدت المحاولات الأولية لتنفيذ هذه المواصفات إلى مواصفات منقحة (وكان يعتقد أنها قابلة للتطبيق تمامًا) في عام 1999 باسم IETF RFC 2535. تم وضع الخطط لنشر DNSSEC بناءً على RFC 2535.

لسوء الحظ، واجهت مواصفات IETF RFC 2535 مشاكل كبيرة للغاية عند توسيع نطاقها لتشمل الإنترنت بالكامل؛ وبحلول عام 2001 أصبح من الواضح أن هذه المواصفات غير قابلة للاستخدام في الشبكات الكبيرة. ففي التشغيل العادي، غالبًا ما تخرج خوادم DNS عن المزامنة مع خوادمها الأصلية. ولا تشكل هذه المشكلة عادةً، ولكن عند تمكين DNSSEC، يمكن أن يكون لهذه البيانات غير المتزامنة تأثير رفض الخدمة الذاتي الخطير. يتطلب DNSSEC الأصلي بروتوكولًا معقدًا من ست رسائل والعديد من عمليات نقل البيانات لإجراء تغييرات رئيسية لخادم فرعي (كان على مناطق DNS الفرعية إرسال جميع بياناتها إلى الخادم الأصلي، وجعل الخادم الأصلي يوقع على كل سجل، ثم إرسال هذه التوقيعات مرة أخرى إلى الخادم الفرعي لتخزينها في سجل SIG). كما يمكن أن يكون لتغييرات المفتاح العام تأثيرات سخيفة؛ على سبيل المثال، إذا غيرت منطقة ".com" مفتاحها العام، فسيتعين عليها إرسال 22 مليون سجل (لأنها ستحتاج إلى تحديث جميع التوقيعات في جميع خوادمها الفرعية). وعليه، فإن DNSSEC كما هو محدد في RFC 2535 لا يمكن توسيعه ليشمل الإنترنت.

لقد قامت IETF بتعديل DNSSEC بشكل أساسي، والذي يُطلق عليه DNSSEC-bis عند الضرورة لتمييزه عن نهج DNSSEC الأصلي في RFC 2535. يستخدم هذا الإصدار الجديد "سجلات موارد توقيع التفويض (DS)" لتوفير مستوى إضافي من الالتباس عند نقاط التفويض بين منطقة الأصل ومنطقة الطفل. في النهج الجديد، عندما يتغير المفتاح العام الرئيسي للطفل، بدلاً من وجود ست رسائل لكل سجل في الطفل، توجد رسالة واحدة بسيطة: يرسل الطفل المفتاح العام الجديد إلى والده (موقّعًا، بالطبع). يقوم الآباء ببساطة بتخزين مفتاح عام رئيسي واحد لكل طفل؛ وهذا أكثر عملية بكثير. وهذا يعني أنه يتم دفع القليل من البيانات إلى الوالد، بدلاً من تبادل كميات هائلة من البيانات بين الوالد والأطفال. وهذا يعني أن العملاء يجب أن يقوموا بمزيد من العمل عند التحقق من المفاتيح. وبشكل أكثر تحديدًا، يتطلب التحقق من مجموعة RRset الرئيسية لمنطقة DNS إجراء عمليتين للتحقق من التوقيع بدلاً من العملية المطلوبة في RFC 2535 (لا يوجد تأثير على عدد التوقيعات التي تم التحقق منها لأنواع أخرى من مجموعات RRsets). ويرى معظم الناس أن هذا ثمن زهيد، لأنه يجعل نشر DNSSEC أكثر عملية. تم نشر الإصدار الجديد في RFC4033-4035.

في يناير 2024، تم الإعلان عن هجوم رفض الخدمة "KeyTrap" لجميع محددات DNSSEC المحترمة للمواصفات. تحدد مواصفات DNSSEC (RFC4033-4035) أنه عند استلام محدد حزمة موقعة من المنبع، يجب أن يجرب جميع المفاتيح ذات "العلامة" الصحيحة على جميع التوقيعات حتى يتم التحقق من إحدى التركيبات بنجاح. من خلال وضع العديد من المفاتيح بنفس "العلامة" والعديد من التوقيعات المقابلة لتلك "العلامة" في حزمة، يمكن للباحثين إبطاء محدد بعامل 2 مليون. واستجابة لذلك، بدأت المحددات في وضع حدود على عدد أخطاء التحقق، وتصادمات علامات المفاتيح، وحسابات التجزئة. [24]

مصادقة استجابات NXDOMAIN وNSEC

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

كان الحل الأولي هو إنشاء سجلات NSEC لكل زوج من المجالات في منطقة. وبالتالي، إذا استفسر العميل عن سجل في المجال غير الموجود k.example.com، فسيستجيب الخادم بسجل NSEC يفيد بعدم وجود شيء بين a.example.comو z.example.com. ومع ذلك، فإن هذا يتسبب في تسريب معلومات أكثر حول المنطقة مقارنة بأخطاء NXDOMAIN غير المصادق عليها التقليدية لأنه يكشف عن وجود مجالات حقيقية.

منع التنقل عبر النطاق

تم إنشاء سجلات NSEC3 (RFC 5155) كبديل يقوم بتجزئه الاسم بدلاً من إدراجه بشكل مباشر. بمرور الوقت، أدى التقدم في التجزئة باستخدام وحدات معالجة الرسوميات والأجهزة المخصصة إلى إمكانية إجبار استجابات NSEC3 على الهجوم باستخدام هجمات القاموس غير المتصلة بالإنترنت. تم اقتراح NSEC5 للسماح للخوادم المعتمدة بتوقيع استجابات NSEC دون الحاجة إلى الاحتفاظ بمفتاح خاص يمكن استخدامه لتعديل المنطقة. وبالتالي فإن سرقة NSEC5KEY لن يؤدي إلا إلى القدرة على ترقيم المنطقة بسهولة أكبر. [25]

بسبب التطور الفوضوي للبروتوكول والرغبة في الحفاظ على التوافق مع الإصدارات السابقة، فإن خوادم توقيع DNSSEC عبر الإنترنت تعيد "كذبة بيضاء" بدلاً من مصادقة إنكار الوجود بشكل مباشر. تعيد التقنية الموضحة في RFC 4470 سجل NSEC حيث توجد أزواج المجالات المحيطة معجميًا بالمجال المطلوب. على سبيل المثال، k.example.comسيؤدي طلب for إلى سجل NSEC يثبت عدم وجود أي شيء بين المجالات (الخيالية) j.example.comو l.example.com. وهذا ممكن أيضًا مع سجلات NSEC3. [26]

كانت CloudFlare رائدة في زوج من الأساليب البديلة، والتي تمكنت من تحقيق نفس النتيجة في ثلث حجم الاستجابة. [27] الأول هو أحد أشكال أسلوب "الأكاذيب البيضاء"، والذي يُسمى "الأكاذيب السوداء"، والذي يستغل سلوك عميل DNS الشائع للإشارة إلى عدم الوجود بشكل أكثر إحكامًا. [28] يختار الأسلوب الثاني بدلاً من ذلك إثبات أن "السجل موجود ولكن نوع السجل المطلوب غير موجود"، والذي يطلقون عليه "DNS shotgun". [29] [27]

النشر

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

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

يمكن أن يضيف تنفيذ DNSSEC حمولة كبيرة إلى بعض خوادم DNS. تكون الاستجابات المشتركة الموقعة بواسطة DNSSEC أكبر بكثير من حجم UDP الافتراضي البالغ 512 بايت. من الناحية النظرية، يمكن التعامل مع هذا من خلال شظايا IP متعددة، ولكن العديد من "الصناديق الوسطى" في هذا المجال لا تتعامل معها بشكل صحيح. يؤدي هذا إلى استخدام TCP بدلاً من ذلك. ومع ذلك، تخزن العديد من تطبيقات TCP الحالية قدرًا كبيرًا من البيانات لكل اتصال TCP؛ يمكن أن تنفد موارد الخوادم المحملة بكثافة لمجرد محاولة الاستجابة لعدد أكبر من طلبات DNSSEC (الزائفة ربما). تم تطوير بعض ملحقات البروتوكول، مثل معاملات ملفات تعريف الارتباط TCP ، لتقليل هذا التحميل. [31] لمعالجة هذه التحديات، يتم بذل جهود كبيرة لنشر DNSSEC، لأن الإنترنت حيوي للغاية للعديد من المنظمات.

النشر المبكر

تشمل الدول التي تبنت هذه التقنية في وقت مبكر البرازيل ( .br )، وبلغاريا ( .bg )، وجمهورية التشيك ( .cz )، وناميبيا ( .na ) [32] وبورتوريكو ( .pr ) والسويد ( .se )، التي تستخدم DNSSEC لنطاقات المستوى الأعلى لرمز الدولة الخاصة بها ؛ [33] و RIPE NCC ، التي وقعت على جميع سجلات البحث العكسي (in-addr.arpa) المفوضة إليها من هيئة أرقام الإنترنت المخصصة (IANA). [34] كما توقع ARIN مناطقها العكسية. [35] في فبراير 2007، أصبحت TDC أول مزود خدمة إنترنت سويدي يبدأ في تقديم هذه الميزة لعملائها. [36]

قامت IANA باختبار جذر موقّع علنًا منذ يونيو 2007. وخلال هذه الفترة التي سبقت التوقيع الإنتاجي للجذر، كانت هناك أيضًا العديد من نقاط الثقة البديلة. قدمت IKS Jena واحدة في 19 يناير 2006، [37] وقدم اتحاد أنظمة الإنترنت نقطة ثقة أخرى في 27 مارس من نفس العام، [38] بينما أعلنت ICANN نفسها عن نقطة ثقة ثالثة في 17 فبراير 2009. [39]

في 2 يونيو 2009، قامت شركة Afilias ، وهي مزود خدمة التسجيل لمنطقة .org التابعة لسجل المصلحة العامة، بتوقيع نطاق المستوى الأعلى .org. [40] كما أوضحت شركة Afilias وPIR في 26 سبتمبر 2008 أن المرحلة الأولى، التي تشمل مسجلين كبارًا تربطها بهم علاقة عمل قوية ("الأصدقاء والعائلة") ستكون الأولى التي ستتمكن من توقيع نطاقاتها، بدءًا من "أوائل عام 2009". [41] في 23 يونيو 2010، تم إدراج 13 مسجلاً على أنهم يقدمون سجلات DNSSEC لنطاقات .ORG. [42]

أدارت شركة VeriSign مشروعًا تجريبيًا للسماح لنطاقات .com و.net بتسجيل نفسها لغرض تجربة NSEC3. في 24 فبراير 2009، أعلنت أنها ستنشر DNSSEC عبر جميع نطاقات المستوى الأعلى الخاصة بها (.com و.net وما إلى ذلك) في غضون 24 شهرًا، [43] وفي 16 نوفمبر من نفس العام، قالت إن نطاقات .com و.net سيتم توقيعها بحلول الربع الأول من عام 2011، بعد التأخيرات الناجمة عن الجوانب الفنية للتنفيذ. [44] تم تحقيق هذا الهدف في الموعد المحدد [45] وفاز نائب رئيس DNSSEC في VeriSign، مات لارسون، بجائزة القيادة التكنولوجية من InfoWorld لعام 2011 لدوره في تطوير DNSSEC. [46] [47]

النشر في جذر DNS

تم نشر DNSSEC لأول مرة على مستوى الجذر في 15 يوليو 2010. [48] ومن المتوقع أن يؤدي هذا إلى تبسيط نشر مُحللات DNSSEC بشكل كبير، حيث يمكن استخدام مرساة الثقة الجذرية للتحقق من صحة أي منطقة DNSSEC بها سلسلة ثقة كاملة من الجذر. نظرًا لأنه يجب تتبع سلسلة الثقة إلى جذر موثوق به دون انقطاع للتحقق من الصحة، فلا يزال يتعين تكوين مرساة الثقة للمناطق الآمنة إذا لم تكن أي من المناطق أعلاه آمنة. على سبيل المثال، إذا تم تأمين المنطقة "signed.example.org" ولكن المنطقة "example.org" لم تكن كذلك، فحتى لو تم توقيع المنطقة ".org" والجذر، فيجب نشر مرساة الثقة للتحقق من صحة المنطقة.

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

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

تخطيط

في سبتمبر 2008، نشرت كل من ICANN وVeriSign مقترحات التنفيذ [49] وفي أكتوبر، طلبت الإدارة الوطنية للاتصالات والمعلومات (NTIA) من الجمهور تقديم تعليقات. [50] ومن غير الواضح ما إذا كانت التعليقات الواردة قد أثرت على تصميم خطة النشر النهائية.

في 3 يونيو 2009، أعلن المعهد الوطني للمعايير والتكنولوجيا (NIST) عن خطط لتوقيع الجذر بحلول نهاية عام 2009، بالتعاون مع ICANN و VeriSign وNTIA. [51]

في 6 أكتوبر 2009، في اجتماع مؤتمر RIPE التاسع والخمسين ، أعلنت ICANN وVeriSign عن الجدول الزمني المخطط لنشر DNSSEC داخل منطقة الجذر. [52] في الاجتماع، أُعلن أنه سيتم نشره بشكل تدريجي على خادم اسم جذر واحد شهريًا، بدءًا من 1 ديسمبر 2009، مع قيام خادم اسم الجذر النهائي بخدمة منطقة موقعة DNSSEC في 1 يوليو 2010، وسيتم توقيع منطقة الجذر باستخدام RSA / SHA256 DNSKEY. [52] أثناء فترة الطرح التدريجي، ستخدم منطقة الجذر منطقة جذر غير قابلة للتحقق عمدًا (DURZ) تستخدم مفاتيح وهمية، مع عدم توزيع سجل DNSKEY النهائي حتى 1 يوليو 2010. [53] وهذا يعني أن المفاتيح التي تم استخدامها لتوقيع استخدام المنطقة غير قابلة للتحقق عمدًا؛ كان سبب هذا النشر هو مراقبة التغييرات في أنماط حركة المرور الناجمة عن الاستجابات الأكبر للاستعلامات التي تطلب سجلات موارد DNSSEC.

تم توقيع نطاق المستوى الأعلى .org مع DNSSEC في يونيو 2010، تبعه .com و .net و .edu لاحقًا في عامي 2010 و2011. [54] [55] تمكنت نطاقات المستوى الأعلى التي تحمل رمز الدولة من إيداع المفاتيح بدءًا من مايو 2010. [56] اعتبارًا من نوفمبر 2011، تم توقيع أكثر من 25٪ من نطاقات المستوى الأعلى مع DNSSEC. [57]

تطبيق

في 25 يناير 2010، بدأ خادم الجذر L (ell) في خدمة منطقة جذر غير قابلة للتحقق عمدًا (DURZ). تستخدم المنطقة توقيعات تجزئة SHA-2 (SHA-256) تم إنشاؤها باستخدام خوارزمية RSA ، كما هو محدد في RFC  5702. اعتبارًا من مايو 2010، بدأت جميع خوادم الجذر الثلاثة عشر في خدمة DURZ. [53] في 15 يوليو 2010، تم توقيع أول منطقة جذر إنتاجية كاملة لـ DNSSEC، برقم SOA التسلسلي 2010071501. تتوفر نقاط ثقة الجذر من IANA. [48]

النشر على مستوى TLD

توجد أسفل الجذر مجموعة كبيرة من النطاقات ذات المستوى الأعلى التي يجب توقيعها لتحقيق نشر DNSSEC الكامل. توفر قائمة النطاقات ذات المستوى الأعلى على الإنترنت تفاصيل حول أي من النطاقات ذات المستوى الأعلى الموجودة تم توقيعها وربطها بالجذر.

التحقق من صحة DNSSEC Lookaside - تاريخي

في مارس 2006، قدم اتحاد أنظمة الإنترنت سجل التحقق من صحة DNSSEC Lookaside. [58] كان الهدف من DLV هو تسهيل نشر DNSSEC في غياب مرساة الثقة الجذرية. في ذلك الوقت، كان من المتصور أن المحقق قد يضطر إلى الاحتفاظ بأعداد كبيرة من مرساة الثقة المقابلة للأشجار الفرعية الموقعة من DNS. [59] كان الغرض من DLV هو السماح للمحققين بتخفيف جهد إدارة مستودع مرساة الثقة إلى طرف ثالث موثوق به. احتفظ سجل DLV بقائمة مركزية لمرساة الثقة، بدلاً من أن يكرر كل محقق عمل الحفاظ على قائمته الخاصة.

لاستخدام DLV، كان هناك حاجة إلى مُحقق يدعمه، مثل BIND أو Unbound ، مُهيأ بمرساة ثقة لمنطقة DLV. تحتوي هذه المنطقة على سجلات DLV؛ [60] كانت لها نفس تنسيق سجلات DS تمامًا، ولكن بدلاً من الإشارة إلى منطقة فرعية مُفوضة، كانت تشير إلى منطقة في مكان آخر في شجرة DNS. عندما لم يتمكن المُحقق من العثور على سلسلة ثقة من الجذر إلى RRset التي يحاول التحقق منها، فقد بحث عن سجل DLV يمكن أن يوفر سلسلة ثقة بديلة. [61]

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

أوقفت ISC تسجيل DLV الخاص بها في عام 2017. [62] تم إيقاف دعم DLV في BIND 9.12 وتم إزالته تمامًا من BIND 9.16. [63] قامت إصدار Unbound 1.5.4 (يوليو 2015) بتمييز DLV على أنه تم إيقاف تشغيله في صفحة تكوين المثال والدليل. [64] لم ينفذ Knot Resolver وPowerDNS Recursor DLV مطلقًا.

في مارس 2020، نشرت IETF RFC  8749، مما أدى إلى إيقاف DLV كمعيار ونقل RFC 4432 وRFC 5074 إلى حالة "تاريخية". [65]

مبادرة نشر DNSSEC من قبل الحكومة الفيدرالية الأمريكية

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

وقد وردت أنباء [66] تفيد بأن وزارة الأمن الداخلي الأميركية اقترحت في الثلاثين من مارس/آذار 2007 "أن يكون المفتاح اللازم لتوقيع منطقة الجذر لنظام أسماء النطاقات في أيدي الحكومة الأميركية". ولكن لم يكن أي من مسؤولي الحكومة الأميركية حاضراً في غرفة الاجتماعات، وكان التعليق الذي أثار شرارة المقال صادراً عن طرف آخر. وفي وقت لاحق، علقت وزارة الأمن الداخلي [67] [68] على سبب اعتقادها بأن آخرين توصلوا إلى الاستنتاج الخاطئ بأن الحكومة الأميركية قدمت مثل هذا الاقتراح: "إن وزارة الأمن الداخلي الأميركية تمول تطوير خطة فنية لتطبيق نظام أسماء النطاقات، وفي أكتوبر/تشرين الأول الماضي وزعت مسودة أولية منها على قائمة طويلة من الخبراء الدوليين للتعليق عليها. وتحدد المسودة سلسلة من الخيارات بشأن من يمكن أن يكون حاملاً أو "مشغلاً" لمفتاح منطقة الجذر، وهو ما يعني في الأساس وكالة حكومية أو متعاقداً. وقال ماوجان، مدير أبحاث وتطوير الأمن السيبراني في وزارة الأمن الداخلي: "لا نطرح في أي مكان من الوثيقة أي اقتراح بشأن هوية مشغل المفتاح الجذر".

نشر DNSSEC في الحكومة الفيدرالية الأمريكية

نشر المعهد الوطني للمعايير والتكنولوجيا (NIST) دليل نشر نظام أسماء النطاقات الآمن (DNS) الخاص بـ NIST رقم 800-81 في 16 مايو 2006، مع إرشادات حول كيفية نشر DNSSEC. كان المعهد الوطني للمعايير والتكنولوجيا يعتزم إصدار متطلبات قانون إدارة أمن المعلومات الفيدرالية (FISMA) الجديدة الخاصة بـ DNSSEC في NIST SP800-53-R1، بالإشارة إلى دليل النشر هذا. كان لدى الوكالات الأمريكية بعد ذلك عام واحد بعد النشر النهائي لـ NIST SP800-53-R1 لتلبية متطلبات FISMA الجديدة هذه. [69] ومع ذلك، في ذلك الوقت لم يتم الانتهاء من NSEC3. اقترح المعهد الوطني للمعايير والتكنولوجيا استخدام المجالات المنقسمة، وهي تقنية معروفة بإمكانيتها ولكن من الصعب نشرها بشكل صحيح، ولديها نقاط الضعف الأمنية المذكورة أعلاه.

في 22 أغسطس 2008، أصدر مكتب الإدارة والميزانية (OMB) مذكرة تلزم الوكالات الفيدرالية الأمريكية بنشر DNSSEC عبر مواقع .gov؛ يجب توقيع جذر .gov بحلول يناير 2009، ويجب توقيع جميع النطاقات الفرعية تحت .gov بحلول ديسمبر 2009. [70] وبينما تركز المذكرة على مواقع .gov، تقول وكالة أنظمة معلومات الدفاع الأمريكية إنها تنوي تلبية متطلبات DNSSEC الخاصة بمكتب الإدارة والميزانية في نطاق .mil (الجيش الأمريكي) أيضًا. ذكرت كارولين دافي مارسان من NetworkWorld أن DNSSEC "لم يتم نشره على نطاق واسع لأنه يعاني من معضلة الدجاجة والبيضة الكلاسيكية ... مع تفويض مكتب الإدارة والميزانية، يبدو أن البيضة قد تكسرت." [71]

النشر في المحللات

بدأت العديد من شركات تقديم خدمة الإنترنت في نشر حلول DNS المتكررة المعتمدة على DNSSEC. وأصبحت شركة Comcast أول شركة تقديم خدمة إنترنت كبرى تقوم بذلك في الولايات المتحدة، حيث أعلنت عن نواياها في 18 أكتوبر 2010 [72] [73] وأكملت النشر في 11 يناير 2012. [74]

وفقًا لدراسة أجريت في APNIC ، ارتفعت نسبة العملاء الذين يستخدمون حصريًا مُحللات DNS التي تقوم بالتحقق من صحة DNSSEC إلى 8.3% في مايو 2013. [75] كان حوالي نصف هؤلاء العملاء يستخدمون مُحلل DNS العام من Google .

في سبتمبر 2015، أعلنت شركة Verisign عن خدمة حل DNS العامة المجانية، [76] وعلى الرغم من عدم ذكرها في بياناتها الصحفية، إلا أنها تقوم أيضًا بالتحقق من صحة DNSSEC.

بحلول بداية عام 2016، أظهرت مراقبة APNIC أن نسبة العملاء الذين يستخدمون حصريًا مُحللات DNS التي تقوم بالتحقق من صحة DNSSEC قد زادت إلى حوالي 15%. [77]

دعم DNSSEC

قام خادم DNS العام المتكرر الخاص بشركة Google بتمكين التحقق من صحة DNSSEC في 6 مايو 2013. [78]

يتيح BIND ، برنامج إدارة DNS الأكثر شهرة، دعم DNSSEC بشكل افتراضي منذ الإصدار 9.5.

لقد أجرى نظام DNS المتكرر العام Quad9 التحقق من صحة DNSSEC على عنوانه الرئيسي 9.9.9.9 منذ إنشائه في 11 مايو 2016. كما يوفر Quad9 خدمة بديلة لا تقوم بالتحقق من صحة DNSSEC، بشكل أساسي من أجل تصحيح الأخطاء. [79]

النشر في البنية التحتية

في سبتمبر 2023، أعلنت شركة Microsoft أنها ستستخدم DNSSEC (عبر DANE ) للتحقق من صحة الشهادات أثناء اتصالات SMTP. [80]

استقبال

وقد زعم جيف هوتسون أنه ينبغي التخلي عن نشر DNSSEC. [81]

منشورات IETF

أدوات

يتطلب نشر DNSSEC وجود برامج على جانب الخادم والعميل. تتضمن بعض الأدوات التي تدعم DNSSEC ما يلي:

  • يتضمن Windows 7 و Windows Server 2008 R2 أداة حل مؤقتة "مدركة للأمان" قادرة على التمييز بين الاستجابات الآمنة وغير الآمنة بواسطة خادم أسماء متكرر. يتوافق DNSSEC الخاص بـ Windows Server 2012 مع التحديثات الديناميكية الآمنة مع المناطق المتكاملة مع Active Directory، بالإضافة إلى تكرار مفاتيح الربط في Active Directory إلى خوادم أخرى مماثلة. [82] [83]
  • BIND ، خادم أسماء DNS الأكثر شهرة (والذي يتضمن dig )، يدمج بروتوكول DNSSEC-bis (سجلات DS) الأحدث بالإضافة إلى دعم سجلات NSEC3.
  • Unbound هو خادم أسماء DNS تم كتابته من الألف إلى الياء ليكون مصممًا حول مفاهيم DNSSEC.
  • mysqlBind ، برنامج إدارة DNS GPL لـ DNS ASPs، يدعم الآن DNSSEC.
  • OpenDNSSEC هي أداة توقيع DNSSEC مخصصة تستخدم PKCS#11 للتفاعل مع وحدات أمان الأجهزة .
  • أضافت Knot DNS الدعم لتسجيل الدخول التلقائي لـ DNSSEC في الإصدار 1.4.0.
  • يدعم PowerDNS DNSSEC بشكل كامل اعتبارًا من الإصدار 3.0 في الوضعين الموقّع مسبقًا والمباشر.
  • DNSSEC : ما هو ولماذا من المهم تنفيذه لفترة طويلة؟ — Check it مبادرة من مجتمع الإنترنت والحكومة الهولندية

انظر أيضا


مراجع

  1. ^ هيرزبيرج، أمير؛ شولمان، هيا (2014). "إعادة تركيب الأمان في بروتوكولات الشبكة: حالة DNSSEC". IEEE Internet Computing . 18 (1). ص. 66-71. doi :10.1109/MIC.2014.14. ISSN  1089-7801. S2CID  12230888.
  2. ^ ربط الخدمة وتحديد المعلمات عبر DNS (DNS SVCB و HTTPS RRS).
  3. ^ عميل TLS المشفر مرحباً.
  4. ^ مقابلة مع دان كامينسكي حول DNSSEC (25 يونيو 2009) مقابلة كامينسكي: DNSSEC يتناول الثقة والأمان بين المنظمات
  5. ^ "أرقام خوارزمية أمان نظام أسماء النطاقات (DNSSEC)". IANA . 2010-07-12 . تم الاسترجاع في 2010-07-17 .
  6. ^ ab "Understanding DNSSEC in Windows". Microsoft . 7 أكتوبر 2009. عميل DNS لنظام Windows هو مُحلل مؤقت...
  7. ^ ab "امتدادات أمان DNS (DNSSEC)". Microsoft . 21 أكتوبر 2009. عميل DNS في Windows Server 2008 R2 وWindows® 7 هو مُحلل مؤقت غير صالح ومدرك للأمان.
  8. ^ "جذر DNSSEC".
  9. ^ "الحوسبة - المصدر الرائد في المملكة المتحدة لتحليل تكنولوجيا الأعمال".
  10. ^ روز، سكوت؛ لارسون، مات؛ ماسي، دان؛ أوستين، روب؛ أريندز، روي (مارس 2005). RFC 4033: مقدمة ومتطلبات أمان DNS. جمعية الإنترنت . ص. 11. doi :10.17487/RFC4033. أجهزة حل Stub، بحكم التعريف، هي أجهزة حل DNS بسيطة تستخدم وضع الاستعلام المتكرر لتفريغ معظم عمل حل DNS إلى خادم أسماء متكرر. تم تقديم تعريف سابق في RFC سابق: Robert Braden (أكتوبر 1989). Braden, R. (محرر). RFC 1123 - متطلبات مضيفات الإنترنت -- التطبيق والدعم. IETF ( فريق عمل هندسة الإنترنت ). ص. 74. doi :10.17487/RFC1123. يعتمد "محلل البادئة" على خدمات خادم الأسماء المتكرر [...]
  11. ^ abc Rose, Scott; Larson, Matt; Massey, Dan; Austein, Rob; Arends, Roy (مارس 2005). RFC 4033: مقدمة ومتطلبات أمان DNS. جمعية الإنترنت . ص. 12. doi :10.17487/RFC4033.
  12. ^ مونيوز ميرينو ، بيدرو جيه. غارسيا مارتينيز، ألبرتو؛ أورجانيرو، ماريو مونيوز؛ كلوس، كارلوس دلجادو (2006). ميرزمان، روبرت؛ طاري، زاهر؛ هيريرو، هيريرو مارتن (محرران). تمكين مصادقة IPsec العملية للإنترنت (PDF) . حول الانتقال إلى أنظمة إنترنت هادفة 2006: ورش عمل OTM 2006. المجلد. 1. سبرينغر . مؤرشفة من الأصلي (PDF) بتاريخ 26-04-2012.
  13. ^ المراسي الجذرية
  14. ^ Ubbink, Stefan. "خوارزمية DNSSEC جديدة لـ .nl". www.sidn.nl . تم الاسترجاع في 29 يناير 2024 .
  15. ^ Wessels, Duane (10 أغسطس 2023). "Verisign Will Help Strengthen Security with DNSSEC Algorithm Update". مدونة Verisign . تم الاسترجاع في 29 يناير 2024 .
  16. ^ Wessels, Duane. "Transitioning Verisign's TLDs to Elliptic Curve DNSSEC". DNS-OARC . تم الاسترجاع في 29 يناير 2024 .
  17. ^ "Root Zone KSK Algorithm Rollover - ICANN". www.icann.org . تم الاسترجاع في 29 يناير 2024 .
  18. ^ IETF: المصادقة القائمة على DNS للكيانات المسماة (dane)
  19. ^ "ImperialViolet" . تم الاسترجاع في 2011-11-26 .
  20. ^ "chromium git" . تم الاسترجاع في 2013-03-09 .
  21. ^ "مُحقق DNSSEC/TLSA".
  22. ^ Bugzilla@Mozilla: Bug 672600 - استخدام سلسلة DNSSEC/DANE المضمنة في مصافحة TLS في التحقق من صحة سلسلة الشهادات
  23. ^ "استخدام نظام اسم النطاق لاختراق النظام" بقلم ستيف بيلوفين، 1995
  24. ^ إلياس هيفتريج؛ هايا شولمان؛ نيكلاس فوجل؛ مايكل وايدن. "هجمات التعقيد الخوارزمي لرفض الخدمة باستخدام KeyTrap على إصدار DNS: يناير 2024" (PDF) . أثينا .(بيان صحفي)
  25. ^ "NSEC5: منع تعداد مناطق DNSSEC بشكل مؤكد".
  26. ^ إنكار الوجود المعتمد في DNS. doi : 10.17487/RFC7129 . RFC 7129.
  27. ^ "الاقتصاد مع الحقيقة: جعل إجابات DNSSEC رخيصة". 2016-06-24.
  28. ^ "الأكاذيب السوداء". إنكار وجود DNSSEC أو الأكاذيب السوداء. القسم 2. معرف draft-valsorda-dnsop-black-lies.
  29. ^ "DNSSEC تم بشكل صحيح". 2015-01-29.
  30. ^ الاستراتيجية الوطنية الأمريكية لتأمين الفضاء الإلكتروني، ص 30 فبراير 2003
  31. ^ ميتزجر، بيري؛ ويليام ألين سيمبسون وبول فيكسي. "تحسين أمان TCP باستخدام ملفات تعريف الارتباط القوية" (PDF) . Usenix . تم الاسترجاع في 17 ديسمبر 2009 .
  32. ^ https://ccnso.icann.org/de/node/7603 [ رابط PDF فارغ ]
  33. ^ مركز معلومات الخصوصية الإلكترونية (EPIC) (27 مايو 2008). DNSSEC
  34. ^ سياسة DNSSEC الخاصة بـ RIPE NCC محفوظ في 22 أكتوبر 2007 على موقع Wayback Machine
  35. ^ خطة نشر ARIN DNSSEC
  36. ^ Eklund-Löwinder, Anne-Marie (12 فبراير 2012). "[dns-wg] أغنية مقدم خدمة الإنترنت السويدي TCD تتبنى DNSSEC". قائمة بريدية dns-wg . RIPE NCC . تم الاسترجاع في 2 ديسمبر 2012 .
  37. ^ أرشيف dns-wg: قائمة المناطق الموقعة محفوظ في 5 مارس 2007 على موقع Wayback Machine
  38. ^ ISC تطلق سجل DLV لبدء نشر DNSSEC على مستوى العالم محفوظ في 18 نوفمبر 2008، على موقع Wayback Machine
  39. ^ مستودع الثقة المؤقتة
  40. ^ .ORG هو أول نطاق TLD مفتوح تم توقيعه مع DNSSEC
  41. ^ شون مايكل كيرنر. ".ORG المجال الأكثر أمانًا؟". internetnews.com . تم الاسترجاع في 2008-09-27 .
  42. ^ "قائمة مسجلي .ORG — مع تمكين DNSSEC في الأعلى" . تم الاسترجاع في 2010-06-23 .
  43. ^ VeriSign: سندعم أمان DNS في عام 2011 محفوظ في 3 مارس 2009، على موقع Wayback Machine
  44. ^ "VeriSign: تحديث رئيسي لأمن الإنترنت بحلول عام 2011". مؤرشف من الأصل في 19 نوفمبر 2009. تم الاسترجاع في 18 نوفمبر 2009 .
  45. ^ المجال .com أصبح آمنًا أخيرًا
  46. ^ مات لارسون من شركة Verisign يفوز بجائزة InfoWorld للريادة التكنولوجية لعام 2011
  47. ^ جوائز إنفوورلد للريادة التكنولوجية 2011
  48. ^ من "أرشيف مشروع DNSSEC".
  49. ^ سينجل، رايان (8 أكتوبر/تشرين الأول 2006). "الحكومة الفيدرالية تبدأ التحرك بشأن ثغرة أمن الشبكة". Wired News . CondéNet . تم الاسترجاع في 9 أكتوبر /تشرين الأول 2008 .
  50. ^ "بيان صحفي: إدارة تكنولوجيا المعلومات والاتصالات الوطنية تطلب تعليقات عامة بشأن نشر تكنولوجيا الأمن داخل نظام أسماء النطاقات على الإنترنت" (بيان صحفي). إدارة الاتصالات والمعلومات الوطنية، وزارة التجارة الأمريكية. 9 أكتوبر 2008. مؤرشف من الأصل في 13 أكتوبر 2008. تم استرجاعه في 09 أكتوبر 2008 .
  51. ^ "وزارة التجارة تعمل مع ICANN وVeriSign لتعزيز أمن واستقرار نظام أسماء النطاقات وعناوين الإنترنت" (بيان صحفي). المعهد الوطني للمعايير والتكنولوجيا. 3 يونيو 2009. مؤرشف من الأصل في 29 يونيو 2011. تم الاسترجاع 13 يوليو 2017 .
  52. ^ "DNSSEC لمنطقة الجذر" (PDF) .
  53. ^ ab Hutchinson, James (6 May 2010). "ICANN, Verisign place last puzzle pieces in DNSSEC saga". NetworkWorld . مؤرشف من الأصل في 20 ديسمبر 2013 . تم الاسترجاع في 17 مايو 2010 .
  54. ^ "DNSSEC سيصبح معيارًا على نطاقات .ORG بحلول نهاية يونيو". مؤرشف من الأصل في 2010-03-15 . تم الاسترجاع في 2010-03-24 .
  55. ^ The Inquirer: Verisign تنشر DNSSEC على نطاق المستوى الأعلى .com
  56. ^ مزيد من الأمان لخوادم DNS الجذرية Heise Online، 24 مارس 2010
  57. ^ CircleID: تحديث DNSSEC من ICANN 42 في داكار
  58. ^ ISC تطلق سجل DLV لبدء نشر DNSSEC في جميع أنحاء العالم محفوظ في 14 يونيو 2011، على موقع Wayback Machine
  59. ^ RFC 5011، "التحديثات التلقائية لمرسيات الثقة الخاصة بأمان DNS (DNSSEC)"
  60. ^ RFC 4431، "سجل موارد DNS للتحقق من صحة DNSSEC Lookaside (DLV)"
  61. ^ RFC 5074، "التحقق من صحة DNSSEC (DLV)"
  62. ^ "استبدال DLV بمنطقة فارغة موقعة - اتحاد أنظمة الإنترنت". isc.org . 30 سبتمبر 2017 . تم الاسترجاع في 2020-06-05 .
  63. ^ "BIND 9.16.0، فرع مستقر لعام 2020 وما بعده - اتحاد أنظمة الإنترنت". isc.org . 20 فبراير 2020 . تم الاسترجاع في 2020-06-05 .
  64. ^ "تغييرات Unbound 1.5.4". NLnet Labs . تم الاسترجاع في 2020-06-05 .
  65. ^ Mekking, W.; Mahoney, D. (مارس 2020). نقل التحقق من صحة DNSSEC Lookaside (DLV) إلى الحالة التاريخية. IETF . doi : 10.17487/RFC8749 . RFC 879 . تم الاسترجاع في 3 يونيو 2020 .
  66. ^ وزارة الداخلية والأمن تريد مفتاحًا رئيسيًا لنظام أسماء النطاقات (DNS) محفوظ في 6 أبريل 2007، على موقع Wayback Machine، Heise News، 30 مارس 2007
  67. ^ تحليل: امتلاك مفاتيح الإنترنت UPI ، 21 أبريل 2007
  68. ^ تحليل UPI: امتلاك مفاتيح الإنترنت 24 مارس 2011 - الرابط الأول معطل، ويُعتقد أن هذا هو نفس المحتوى
  69. ^ نشرة مبادرة نشر DNSSEC - المجلد 1، العدد 2، أرشيف 22 نوفمبر 2007، على موقع Wayback Machine ، يونيو 2006
  70. ^ مذكرة إلى كبار مسؤولي المعلومات محفوظ في 16 سبتمبر 2008 على موقع واي باك مشين المكتب التنفيذي للرئيس — مكتب الإدارة والميزانية، 22 أغسطس 2008
  71. ^ الحكومة الفيدرالية تشدد الإجراءات الأمنية على نطاق .gov أرشيف 25 سبتمبر 2008، على موقع واي باك مشين Network World، 22 سبتمبر 2008
  72. ^ مدونة Comcast - بدء طرح أمان DNS، 18 أكتوبر 2010
  73. ^ تم أرشفة فيديو إعلان الخدمة العامة لـ Comcast DNSSEC في 2010-10-21 على موقع Wayback Machine ، 18 أكتوبر 2010
  74. ^ Comcast تكمل نشر DNSSEC، 11 يناير 2012
  75. ^ جيف هيوستن: DNS وDNSSEC وخدمة DNS العامة من Google (CircleID)
  76. ^ تقديم خدمة Verisign Public DNS
  77. ^ استخدام التحقق من صحة DNSSEC للعالم (XA)
  78. ^ يدعم DNS العام من Google الآن التحقق من DNSSEC مدونة Google Code، 1 يونيو 2013
  79. ^ "Quad9 FAQ". Quad9 . تم الاسترجاع في 7 يوليو 2018 .
  80. ^ "تنفيذ بروتوكول SMTP DANE الوارد مع DNSSEC لتدفق البريد عبر الإنترنت في Exchange". TECHCOMMUNITY.MICROSOFT.COM . تم الاسترجاع في 2024-05-28 .
  81. ^ هيوستن، جيف (2024-05-28). "وقت الاتصال على DNSSEC؟". مدونة APNIC . تم الاسترجاع في 2024-05-28 .
  82. ^ Seshadri, Shyam (11 نوفمبر 2008). "DNSSEC على عميل DNS في نظام التشغيل Windows 7". المنفذ 53. مايكروسوفت.
  83. ^ DNSSEC في Windows Server

قراءة إضافية

  • H. Yang؛ E. Osterweil؛ D. Massey؛ S. Lu؛ L. Zhang (8 أبريل 2010). "نشر التشفير في أنظمة بمقياس الإنترنت: دراسة حالة حول DNSSEC". معاملات معهد مهندسي الكهرباء والإلكترونيات بشأن الحوسبة الموثوقة والآمنة . 8 (5). ص. 656-669. CiteSeerX  10.1.1.158.1984 . doi :10.1109/TDSC.2010.10. S2CID  14887477.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Domain_Name_System_Security_Extensions&oldid=1229885175"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate