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

📅 آخر تحديث: ٢٩ يوليو ٢٠٢٦
✍️ نُشر في: ٢٩ يوليو ٢٠٢٦
📷 يحتوي على 1 صور
الموسوعة الحرة

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

ملخص

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

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

DNSSEC does not provide confidentiality of data; in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC does not protect against DoS attacks directly, though it indirectly provides some benefit (because signature checking allows the use of potentially untrustworthy parties).

Other standards (not DNSSEC) are used to secure bulk data (such as a DNS zone transfer) sent between DNS servers. As documented in RFC 4367, some users and developers make false assumptions about DNS names, such as assuming that a company's common name plus ".com" is always its domain name. DNSSEC cannot protect against false assumptions; it can only authenticate that the data is truly from or not available from the domain owner.

The DNSSEC specifications (called DNSSEC-bis) describe the current DNSSEC protocol in great detail. See RFC 4033, RFC 4034, and RFC 4035. With the publication of these new RFCs (March 2005), an earlier RFC, RFC 2535 has become obsolete. The full set of RFCs that specify DNSSEC are collected in RFC 9364, which is also BCP 237.

It is widely believed[4] that securing the DNS is critically important for securing the Internet as a whole, but deployment of DNSSEC specifically has been hampered (As of 22 January 2010) by several difficulties:

  • The need to design a backward-compatible standard that can scale to the size of the Internet
  • Prevention of "zone enumeration" where desired
  • Deployment of DNSSEC implementations across a wide variety of DNS servers and resolvers (clients)
  • Disagreement among implementers over who should own the top-level domain root keys
  • Overcoming the perceived complexity of DNSSEC and DNSSEC deployment

Adoption

اعتبارًا من مارس 2026، كان نظام DNSSEC يعمل فقط في 83 نطاقًا (45%) من نطاقات المستوى الأعلى لرموز الدول . [ 5 ] وقد جعلت مؤسسة ICANN نظام DNSSEC إلزاميًا لنطاقات المستوى الأعلى العامة الجديدة في عام 2014. [ 6 ] ولا تستخدم جميع نطاقات المستوى الأدنى نظام DNSSEC. فقد أفادت شركة Verisign أن نسبة استخدامه بلغت حوالي 5% في نطاقات المستوى الثاني .net وحوالي 4% في نطاق .com . [ 7 ] ويتجاوز استخدام نطاقات المستوى الثاني 50% في نطاقات .nl (هولندا)، و. cz (جمهورية التشيك)، و .no (النرويج)، و .se (السويد)، و .nu ( نيوي ، ولكن كان يُنطق سابقًا مثل "new"). [ 8 ] واعتبارًا من عام 2023، كانت نطاقات رئيسية مثل google.com و amazon.com و microsoft.com غير موقّعة. [ 9 ]

عملية

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

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

يتم تطبيق نظام أسماء النطاقات (DNS) باستخدام عدة سجلات موارد. ولتطبيق نظام أمان أسماء النطاقات (DNSSEC)، تم إنشاء أو تعديل عدة أنواع جديدة من سجلات DNS لاستخدامها مع نظام أمان أسماء النطاقات (DNSSEC).

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

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

الخوارزميات

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

مجال الخوارزميةالخوارزميةمصدرتوقيع DNSSECالتحقق من صحة DNSSEC
1RSA / MD5ممنوع التنفيذممنوع التنفيذ
3DSA / SHA-1RFC 2539 ممنوع التنفيذممنوع التنفيذ
5RSA/SHA-1RFC 3110 غير مُوصى بهمطلوب
6DSA-NSEC3-SHA1ممنوع التنفيذممنوع التنفيذ
7RSASHA1-NSEC3-SHA1RFC 5155 غير مُوصى بهمطلوب
8RSA/ SHA-256RFC 5702 مطلوبمطلوب
10RSA/ SHA-512غير مُوصى بهمطلوب
12GOST R 34.10-2001RFC 5933 ممنوع التنفيذخياري
13ECDSA P-256/ SHA-256RFC 6605 مطلوبمطلوب
14ECDSA P-384/ SHA-384خياريمُستَحسَن
15Ed25519RFC 8080 مُستَحسَنمُستَحسَن
16Ed448خياريمُستَحسَن
17SM2SM3RFC 9563 خياريخياري
23GOST R 34.10-2012RFC 9558 خياريخياري
مجال الهضمهضممصدرتفويض DNSSECالتحقق من صحة DNSSEC
1SHA-1RFC 3658 ممنوع التنفيذمطلوب
2SHA-256RFC 4509 مطلوبمطلوب
3GOST R 34.11-1994RFC 5933 ممنوع التنفيذخياري
4SHA-384RFC 6605 خياريمُستَحسَن
5GOST R 34.11-2012RFC 9563 خياريخياري
6SM3RFC 9558 خياريخياري

إجراء البحث

انطلاقًا من نتائج بحث نظام أسماء النطاقات (DNS)، يستطيع مُحلِّل أسماء النطاقات المُدرك للأمان تحديد ما إذا كان خادم الأسماء الموثوق به للنطاق المطلوب يدعم بروتوكول DNSSEC، وما إذا كانت الإجابة التي يتلقاها آمنة، وما إذا كان هناك أي خطأ. يختلف إجراء البحث بالنسبة لخوادم الأسماء المتكررة، مثل تلك التي يستخدمها العديد من مزودي خدمة الإنترنت ، وبالنسبة لمُحلِّلات أسماء النطاقات الفرعية ، مثل تلك المُضمَّنة افتراضيًا في أنظمة التشغيل الشائعة. يستخدم نظام التشغيل مايكروسوفت ويندوز مُحلِّل أسماء نطاقات فرعي، ويستخدم كلٌّ من ويندوز سيرفر 2008 R2 وويندوز 7 على وجه الخصوص مُحلِّل أسماء نطاقات فرعي غير مُدقِّق ولكنه مُدرك لبروتوكول DNSSEC. [ 11 ] [ 12 ]

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

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

  1. تبدأ العملية عندما يقوم مُحلِّل أسماء النطاقات المُدرك للأمان بتعيين بتة "DO" ("DNSSEC OK") في استعلام DNS. وبما أن بتة DO موجودة ضمن بتات العلامات الموسعة المُحددة بواسطة آليات التمديد لنظام أسماء النطاقات (EDNS) ، RFC 6891 ، فيجب أن تدعم جميع معاملات DNSSEC بروتوكول EDNS. كما أن دعم EDNS ضروري للسماح بأحجام الحزم الأكبر بكثير التي تتطلبها معاملات DNSSEC. 
  2. عندما يتلقى محلل أسماء النطاقات (DNS) إجابةً عبر عملية البحث العادية، يتحقق من صحتها. في الوضع الأمثل، يبدأ المحلل المُراعي للأمان بالتحقق من سجلات DS وDNSKEY في جذر DNS . ثم يستخدم سجلات DS الخاصة بنطاق المستوى الأعلى "com" الموجود في الجذر للتحقق من سجلات DNSKEY في منطقة "com". بعد ذلك، يتحقق من وجود سجل DS للنطاق الفرعي "example.com" في منطقة "com"، وإذا وُجد، يستخدمه للتحقق من سجل 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 إلى الجذر. [ 13 ] تم توقيع نطاق .com باستخدام مفاتيح أمان صالحة، وأضيفت صلاحية التفويض الآمن إلى منطقة الجذر في 1 أبريل 2011. [ 14 ]

محللات Stub

تُعدّ مُحلِّلات Stub مُحلِّلات DNS بسيطة تستخدم وضع الاستعلام المتكرر لتفريغ معظم مهام تحليل DNS إلى خادم أسماء متكرر. [ 15 ] يقوم مُحلِّل Stub ببساطة بإعادة توجيه الطلب إلى خادم أسماء متكرر، ويستخدم بتّ البيانات المُصادق عليها (AD) في الاستجابة كدليل لمعرفة ما إذا كان خادم الأسماء المتكرر قد تمكّن من التحقق من صحة التوقيعات لجميع البيانات في قسمي الإجابة والسلطة من الاستجابة. [ 16 ] يستخدم نظام التشغيل Microsoft Windows مُحلِّل Stub، ويستخدم Windows Server 2008 R2 وWindows 7 على وجه الخصوص مُحلِّل Stub غير مُدقِّق ولكنه مُدرك لتّ AD. [ 11 ] [ 12 ]

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

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

نقاط ارتكاز الثقة وسلاسل المصادقة

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

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

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

للحد من هجمات إعادة الإرسال، لا تقتصر سجلات نظام أسماء النطاقات (DNS) على قيم TTL العادية لأغراض التخزين المؤقت، بل تتضمن أيضًا طوابع زمنية إضافية في سجلات 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). وقد انتقلت بالفعل عدة نطاقات من نطاقات المستوى الأعلى للبلدان (ccTLDs)، بما في ذلك .at و .br و .cz و .ch و .fr و .ie و .nl [ 19 ] و .ph . كما قامت شركة Verisign بنقل نطاقات .com و .net و .edu إلى الخوارزمية 13 في أواخر عام 2023. [ 20 ] [ 21 ] ويجري التخطيط حاليًا لنقل النطاق الرئيسي من الخوارزمية 8 إلى الخوارزمية 13 في أوائل عام 2024. [ 22 ]

مجموعة عمل DANE

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

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

تم تفعيل دعم شهادات DNSSEC المدمجة في متصفح جوجل كروم 14، [ 24 ] ولكن تمت إزالته لاحقًا. [ 25 ] أما بالنسبة لمتصفح موزيلا فايرفوكس ، فقد تم توفير الدعم من خلال إضافة [ 26 ] حتى الإصدار 56، بينما تم اقتراح دعم أصلي ولكن تم رفضه في النهاية. [ 27 ]

تاريخ

يُعدّ نظام أسماء النطاقات (DNS) خدمةً أساسيةً وحيويةً للإنترنت، ومع ذلك، اكتشف ستيف بيلوفين في عام 1990 ثغراتٍ أمنيةً خطيرةً فيه. بدأ البحث في تأمينه، وتقدّم بشكلٍ ملحوظٍ عندما نُشرت ورقته البحثية في عام 1995. [ 28 ] نشرت فرقة عمل هندسة الإنترنت (IETF) المواصفة RFC 2065 الأولية في عام 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)" لتوفير مستوى إضافي من التوجيه غير المباشر عند نقاط التفويض بين منطقة رئيسية ومنطقة فرعية. في هذا المنهج الجديد، عند تغيير المفتاح العام الرئيسي لمنطقة فرعية، بدلاً من ست رسائل لكل سجل في المنطقة الفرعية، تُرسل رسالة واحدة بسيطة: تُرسل المنطقة الفرعية المفتاح العام الجديد إلى منطقتها الرئيسية (موقعاً بالطبع). تخزن المناطق الرئيسية مفتاحاً عاماً رئيسياً واحداً لكل منطقة فرعية؛ وهذا أكثر عملية. يعني هذا إرسال كمية قليلة من البيانات إلى المنطقة الرئيسية، بدلاً من تبادل كميات هائلة من البيانات بين المنطقة الرئيسية والمناطق الفرعية. هذا يعني أيضاً أن على العملاء بذل جهد إضافي عند التحقق من المفاتيح. وبشكل أكثر تحديداً، يتطلب التحقق من مجموعة سجلات مفاتيح منطقة DNS عمليتي تحقق من التوقيع بدلاً من العملية الواحدة المطلوبة في RFC 2535 (لا يوجد تأثير على عدد التوقيعات التي يتم التحقق منها لأنواع أخرى من مجموعات سجلات المفاتيح). يرى معظم الخبراء أن هذا ثمن زهيد، إذ يجعل نشر بروتوكول DNSSEC أكثر عملية. وقد نُشر الإصدار الجديد في RFC4033-4035.

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

التحقق من صحة استجابات NXDOMAIN وNSEC

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

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

منع التجول في النطاق

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

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

ابتكرت كلاود فلير نهجين بديلين، يحققان النتيجة نفسها بحجم استجابة أقل بمقدار الثلث. [ 32 ] النهج الأول هو شكل معدل من نهج "الأكاذيب البيضاء"، يُسمى "الأكاذيب السوداء"، ويستغل سلوك عميل نظام أسماء النطاقات (DNS) الشائع للتعبير عن عدم وجود السجل بشكل أكثر إيجازًا. [ 33 ] أما النهج الثاني، فيعتمد على إثبات أن "السجل موجود ولكن نوع السجل المطلوب غير موجود"، وهو ما يُطلق عليه "بندقية نظام أسماء النطاقات". [ 34 ] [ 32 ]

الانتشار

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

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

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

عمليات النشر المبكرة

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

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

في 2 يونيو 2009، وقّعت شركة أفيلياس ، مزوّد خدمة تسجيل نطاق .org التابع لسجل المصلحة العامة ، على نطاق المستوى الأعلى .org. [ 45 ] كما أوضحت أفيلياس وسجل المصلحة العامة في 26 سبتمبر 2008 أن المرحلة الأولى، التي تضمّ كبار مسجّلي النطاقات الذين تربطهم بها علاقات عمل وثيقة (الأصدقاء والعائلة)، ستكون أول من يتمكّن من توقيع نطاقاته، بدءًا من "أوائل عام 2009". [ 46 ] وفي 23 يونيو 2010، أُدرج 13 مسجّل نطاقات كجهات تقدّم سجلات DNSSEC لنطاقات .ORG. [ 47 ]

أطلقت شركة VeriSign مشروعًا تجريبيًا لتمكين نطاقات .com و .net من تسجيل نفسها لأغراض تجربة بروتوكول DNSSEC3. في 24 فبراير 2009، أعلنت الشركة أنها ستنشر بروتوكول DNSSEC على جميع نطاقاتها العليا (.com، .net، إلخ) خلال 24 شهرًا، [ 48 ] وفي 16 نوفمبر من العام نفسه، صرّحت بأن نطاقات .com و .net ستكون مُوقّعة بحلول الربع الأول من عام 2011، بعد تأخيرات ناجمة عن جوانب تقنية في التنفيذ. [ 49 ] وقد تحقق هذا الهدف في الموعد المحدد، [ 50 ] وفاز نائب رئيس قسم DNSSEC في VeriSign، مات لارسون، بجائزة InfoWorld للريادة التقنية لعام 2011 لدوره في تطوير بروتوكول DNSSEC. [ 51 ] [ 52 ]

النشر في جذر نظام أسماء النطاقات (DNS)

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

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

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

تخطيط

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

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

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

تم توقيع نطاق المستوى الأعلى .org باستخدام بروتوكول DNSSEC في يونيو 2010، تبعه نطاقات .com و .net و .edu لاحقًا في عامي 2010 و2011. [ 59 ] [ 60 ] وأصبح بإمكان نطاقات المستوى الأعلى التي تحمل رموز الدول إيداع المفاتيح بدءًا من مايو 2010. [ 61 ] اعتبارًا من نوفمبر 2011 أكثر من 25% من نطاقات المستوى الأعلى موقعة باستخدام DNSSEC. [ 62 ]

تطبيق

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

النشر على مستوى نطاق المستوى الأعلى

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

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

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

لاستخدام DLV، كان يلزم وجود مُدقِّق يدعمه، مثل BIND أو Unbound ، مُهيأ برابط ثقة لمنطقة DLV. تحتوي هذه المنطقة على سجلات DLV؛ [ 65 ] ولها نفس تنسيق سجلات DS تمامًا، ولكن بدلًا من الإشارة إلى منطقة فرعية مُفوَّضة، تُشير إلى منطقة أخرى في شجرة DNS. عندما يتعذر على المُدقِّق العثور على سلسلة ثقة من الجذر إلى مجموعة سجلات الموارد (RRset) التي يحاول التحقق منها، فإنه يبحث عن سجل DLV يُمكنه توفير سلسلة ثقة بديلة. [ 66 ]

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

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

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

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

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

أُفيد [ 71 ] أنه في 30 مارس/آذار 2007، اقترحت وزارة الأمن الداخلي الأمريكية "وضع مفتاح توقيع منطقة الجذر لنظام أسماء النطاقات (DNS) في يد الحكومة الأمريكية بشكل كامل". إلا أنه لم يكن أي مسؤول حكومي أمريكي حاضرًا في قاعة الاجتماع، وكان التعليق الذي أثار المقال صادرًا عن جهة أخرى. وعلّقت وزارة الأمن الداخلي لاحقًا [ 72 ] [ 73 ] على سبب اعتقادها بأن البعض استنتج خطأً أن الحكومة الأمريكية قدّمت مثل هذا الاقتراح: "تموّل وزارة الأمن الداخلي الأمريكية تطوير خطة تقنية لتطبيق بروتوكول أمان نظام أسماء النطاقات (DNSSec)، وفي أكتوبر/تشرين الأول الماضي، وزّعت مسودة أولية منها على قائمة طويلة من الخبراء الدوليين لإبداء ملاحظاتهم. وتُحدّد المسودة سلسلة من الخيارات بشأن الجهة التي يمكن أن تكون حاملة، أو "مشغّلة"، مفتاح منطقة الجذر، والتي تُختزل أساسًا إلى وكالة حكومية أو متعاقد. وقال موغان، مدير أبحاث وتطوير الأمن السيبراني في وزارة الأمن الداخلي: "لم نُقدّم في أي مكان في الوثيقة أي اقتراح بشأن هوية مشغّل مفتاح الجذر".

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

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

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

النشر في المُحلِّلات

بدأت العديد من شركات تزويد خدمة الإنترنت في نشر خوادم DNS المتكررة التي تتحقق من صحة DNSSEC. وكانت شركة Comcast أول شركة تزويد خدمة إنترنت رئيسية تفعل ذلك في الولايات المتحدة، حيث أعلنت عن نواياها في 18 أكتوبر 2010 [ 77 ] [ 78 ] وأكملت النشر في 11 يناير 2012. [ 79 ]

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

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

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

دعم DNSSEC

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

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

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

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

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

استقبال

جادل جيف هوستون بضرورة التخلي عن نشر بروتوكول DNSSEC. [ 86 ] في عام 2016، نشرت شركة فاست ميل، مزود خدمة البريد الإلكتروني ، منشورًا على مدونتها ذكرت فيه أنها لا تخطط لتطبيق بروتوكول DNSSEC، مشيرةً إلى العديد من حالات انقطاع الخدمة المرتبطة بهذا البروتوكول والتي حدثت في ذلك الوقت. [ 87 ]

أبدت شركة كلاود فلير ، المتخصصة في البنية التحتية للإنترنت، ردود فعل إيجابية، حيث استعانت بأحد مؤسسي بروتوكول DNSSEC للمساعدة في تطبيقه داخل الشركة. [ 88 ] كما يُفعّل سجل النطاقات سبيس شيب (علامة تجارية تابعة لشركة نيم تشيب [ 89 ] ) بروتوكول DNSSEC تلقائيًا للنطاقات المدعومة التي تستضيف خوادم أسمائها . [ 90 ] وفي عام 2025، عارض سجل النطاقات الهولندي SIDN الادعاء بأن بروتوكول DNSSEC معقد مقارنةً ببروتوكولات الإنترنت الأخرى. [ 91 ]

منشورات IETF

  • ملحقات أمان نظام أسماء النطاقات RFC 2535 
  • RFC 3225 يشير إلى دعم محلل DNSSEC 
  • متطلبات حجم الرسائل لخادم/محلل عناوين IPv6 المتوافقة مع بروتوكول DNSSEC وبروتوكول IPv6 A6 (RFC 3226) 
  • RFC 3833 تحليل التهديدات لنظام أسماء النطاقات 
  • RFC 4033 مقدمة ومتطلبات أمان نظام أسماء النطاقات ( DNSSEC-bis ) 
  • RFC 4034 سجلات الموارد لملحقات أمان نظام أسماء النطاقات ( DNSSEC-bis ) 
  • تعديلات بروتوكول RFC 4035 لملحقات أمان نظام أسماء النطاقات ( DNSSEC-bis ) 
  • RFC 4398 تخزين الشهادات في نظام أسماء النطاقات (DNS) 
  • RFC 4431 سجل موارد نظام أسماء النطاقات (DNS) للتحقق من صحة البحث الجانبي (DLV) في DNSSEC 
  • RFC 4470 تغطية الحد الأدنى لسجلات NSEC والتوقيع الإلكتروني لـ DNSSEC 
  • RFC 4509 استخدام SHA-256 في سجلات موارد التوقيع التفويضي لـ DNSSEC (DS) (RRs) 
  • RFC 4641 الممارسات التشغيلية لـ DNSSEC 
  • تجارب أمن نظام أسماء النطاقات (DNSSEC) RFC 4955 
  • تحديثات أمان نظام أسماء النطاقات التلقائية (DNSSEC) وفقًا لـ RFC 5011 
  • RFC 5155 DNSSEC رفض الوجود الموثق والمشفر 
  • RFC 5702 استخدام خوارزميات SHA-2 مع RSA في سجلات موارد DNSKEY وRRSIG لـ DNSSEC 
  • تخصيص مُعرّف خوارزمية التشفير RFC 6014 لـ DNSSEC 
  • خوارزمية التوقيع الرقمي للمنحنى الإهليلجي (DSA) لبروتوكول DNSSEC (RFC 6605 ) 
  • تحديثات سجل IANA لخوارزمية DNSKEY الخاصة بأمان نظام أسماء النطاقات (DNSSEC) وفقًا لمعيار RFC 6725 
  • RFC 6781 الممارسات التشغيلية لـ DNSSEC، الإصدار 2 
  • RFC 6840 توضيحات وملاحظات تنفيذية لأمن نظام أسماء النطاقات (DNSSEC) 
  • RFC 6975 فهم خوارزمية التشفير للإشارة في ملحقات أمان نظام أسماء النطاقات (DNSSEC) 
  • RFC 7129 رفض الوجود الموثق في نظام أسماء النطاقات 
  • RFC 7344 أتمتة صيانة الثقة لتفويض DNSSEC 
  • اعتبارات توقيت تغيير مفتاح DNSSEC (RFC 7583) 
  • RFC 8078 إدارة سجلات DS من الأصل عبر CDS/CDNSKEY 
  • خوارزمية أمان منحنى إدواردز الرقمية (EdDSA) لبروتوكول DNSSEC (RFC 8080 ) 
  • RFC 8198 الاستخدام المكثف لذاكرة التخزين المؤقت المُتحقق منها بواسطة DNSSEC 
  • متطلبات تنفيذ خوارزمية RFC 8624 وإرشادات استخدامها لبروتوكول DNSSEC 
  • RFC 8749 نقل التحقق من صحة DNSSEC Lookaside (DLV) إلى الوضع التاريخي 
  • RFC 9077 NSEC و NSEC3: TTLs والاستخدام العدواني 
  • RFC 9157: اعتبارات IANA المعدلة لـ DNSSEC 
  • إرشادات RFC 9276 لإعدادات معلمات NSEC3 
  • RFC 9364 ( BCP 237) ملحقات أمان نظام أسماء النطاقات 

أدوات

استخدام DNSSEC في Unbound (التحقق من الصحة باستخدام unbound-host)

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

انظر أيضاً

مراجع

  1. ↑ هيرزبيرغ، أمير؛ شولمان، هايا (2014). "تحديث بروتوكولات الشبكة الأمنية: حالة DNSSEC" . مجلة IEEE للحوسبة عبر الإنترنت . 18 (1). IETF . ص 66-71. doi : 10.1109/MIC.2014.14 . ISSN 1089-7801 . S2CID 12230888 .   
  2. ↑ ربط الخدمة وتحديد المعلمات عبر نظام أسماء النطاقات (DNS SVCB و HTTPS RRS) . IETF .
  3. ↑ رسالة ترحيب العميل المشفرة بتقنية TLS . IETF .
  4. ↑ مقابلة مع دان كامينسكي حول DNSSEC (25 يونيو 2009) مقابلة كامينسكي: DNSSEC يعالج الثقة والأمان بين المنظمات
  5. ↑ "خرائط نشر DNSSEC - CARE" . maps.dnssec.gmu.edu . تم الاطلاع عليه بتاريخ 20 مارس 2026 .
  6. ↑ DNSSEC en IPv6 vanaf 2014 verplicht bij ICANN
  7. ↑ "لوحة نتائج دي إن إس إس إي سي" . فيريساين . تم الاطلاع عليه بتاريخ 25 سبتمبر 2025 .
  8. ↑ غالبية النطاقات الهولندية ومستخدمي الإنترنت لديهم حماية DNSSEC
  9. ↑ جيف هوستون (18 سبتمبر 2023). "قياس استخدام DNSSEC" . APNIC .
  10. ↑ "أرقام خوارزمية أمان نظام أسماء النطاقات (DNSSEC)" . هيئة الأرقام المخصصة للإنترنت (IANA ). 12 يوليو 2010. تاريخ الاسترجاع: 17 يوليو 2010 .
  11. 1 2 "فهم DNSSEC في ويندوز" . مايكروسوفت . 7 أكتوبر 2009. عميل DNS في ويندوز هو محلل أسماء نطاقات فرعي...
  12. 12"DNS Security Extensions (DNSSEC)". Microsoft. October 21, 2009. The DNS client in Windows Server 2008 R2 and Windows® 7 is a non-validating security-aware stub resolver.
  13. ↑"Root DNSSEC".
  14. ↑"Computing - the UK's leading source for the analysis of business technology".
  15. ↑Rose, Scott; Larson, Matt; Massey, Dan; Austein, Rob; Arends, Roy (March 2005). RFC 4033: DNS Security Introduction and Requirements. The Internet Society. p. 11. doi:10.17487/RFC4033. Stub resolvers, by definition, are minimal DNS resolvers that use recursive query mode to offload most of the work of DNS resolution to a recursive name server. An earlier definition was given in an earlier RFC: Robert Braden (October 1989). Braden, R. (ed.). RFC 1123 - Requirements for Internet Hosts -- Application and Support. IETF (Internet Engineering Task Force). p. 74. doi:10.17487/RFC1123. A "stub resolver" relies on the services of a recursive name server [...]
  16. 123Rose, Scott; Larson, Matt; Massey, Dan; Austein, Rob; Arends, Roy (March 2005). RFC 4033: DNS Security Introduction and Requirements. The Internet Society. p. 12. doi:10.17487/RFC4033.
  17. ↑Muñoz Merino, Pedro J.; García-Martínez, Alberto; Organero, Mario Muñoz; Kloos, Carlos Delgado (2006). Meersman, Robert; Tari, Zahir; Herrero, Herrero Martín (eds.). Enabling Practical IPsec Authentication for the Internet(PDF). On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops. Vol. 1. Springer. Archived from the original(PDF) on 2012-04-26.
  18. ↑root-anchors
  19. ↑Ubbink, Stefan. "New DNSSEC algorithm for .nl". www.sidn.nl. Retrieved 29 January 2024.
  20. ↑Wessels, Duane (10 August 2023). "Verisign Will Help Strengthen Security with DNSSEC Algorithm Update". Verisign Blog. Retrieved 29 January 2024.
  21. ↑Wessels, Duane. "Transitioning Verisign's TLDs to Elliptic Curve DNSSEC". DNS-OARC. Retrieved 29 January 2024.
  22. ↑ "تغيير خوارزمية مفتاح التوقيع الأساسي لمنطقة الجذر - ICANN" . www.icann.org . تم الاطلاع عليه بتاريخ 29 يناير 2024 .
  23. ↑ IETF: مصادقة الكيانات المسماة المستندة إلى نظام أسماء النطاقات (دانماركي)
  24. ↑ "ImperialViolet" . تم الاطلاع عليه بتاريخ 26-11-2011 .
  25. ↑ "chromium git" . تم الاطلاع عليه بتاريخ 2013-03-09 .
  26. ↑ "مدقق DNSSEC/TLSA" .
  27. ↑ Bugzilla@Mozilla: خطأ رقم 672600 - استخدام سلسلة DNSSEC/DANE المدمجة في مصافحة TLS في التحقق من صحة سلسلة الشهادات
  28. ↑ "استخدام نظام أسماء النطاقات لاختراق الأنظمة" بقلم ستيف بيلوفين، 1995
  29. ↑ إلياس هيفتريج؛ هايا شولمان؛ نيكلاس فوغل؛ مايكل وايدن. "هجمات حجب الخدمة الخوارزمية لـ KeyTrap على نظام أسماء النطاقات (DNS) الإصدار: يناير 2024" (ملف PDF) . أثينا .( بيان صحفي )
  30. ↑ "NSEC5: منع تعداد مناطق DNSSEC بشكل مثبت" .
  31. ↑ رفض الوجود الموثق في نظام أسماء النطاقات (DNS) . IETF . doi : 10.17487/RFC7129 . RFC 7129 .
  32. 1 2 "الاقتصاد في الحقيقة: جعل إجابات DNSSEC رخيصة" . 2016-06-24.
  33. ↑ "الأكاذيب السوداء" . إنكار وجود DNSSEC المضغوط أو الأكاذيب السوداء . IETF . القسم 2. المعرف draft-valsorda-dnsop-black-lies. 
  34. ↑ "DNSSEC Done Right" . 2015-01-29.
  35. ↑ الاستراتيجية الوطنية الأمريكية لتأمين الفضاء الإلكتروني ، ص 30 فبراير 2003
  36. ↑ ميتزجر، بيري؛ ويليام ألين سيمبسون وبول فيكسي. "تحسين أمان بروتوكول TCP باستخدام ملفات تعريف الارتباط القوية" (ملف PDF) . يوزنيكس . تم الاطلاع عليه بتاريخ 17 ديسمبر 2009 .
  37. ↑ مايلز، باتريك (25 سبتمبر 2014). "تحديث أنشطة المكتب الوطني للملاحة الجغرافية لاجتماع مجلس المكتب الوطني للملاحة الجغرافية" (ملف PDF) . تم الاطلاع عليه بتاريخ 8 أغسطس 2025 .
  38. ↑ مركز معلومات الخصوصية الإلكترونية (EPIC) (27 مايو 2008). DNSSEC
  39. ↑ سياسة RIPE NCC DNSSEC مؤرشفة بتاريخ 22 أكتوبر 2007، على موقع Wayback Machine
  40. ↑ خطة نشر ARIN DNSSEC
  41. ↑ إكلوند-لويندر، آن ماري (12 فبراير 2012). " [ مجموعة عمل نظام أسماء النطاقات ] مزود خدمة الإنترنت السويدي TCD Song يتبنى DNSSEC" . القائمة البريدية لمجموعة عمل نظام أسماء النطاقات . RIPE NCC . تم الاطلاع عليه في 2 ديسمبر 2012 .
  42. ↑ أرشيف مجموعة عمل نظام أسماء النطاقات: قائمة المناطق الموقعة. مؤرشف في 5 مارس 2007 على موقع Wayback Machine.
  43. ↑ أطلقت ISC سجل DLV لبدء نشر DNSSEC عالميًا. مؤرشف في 18 نوفمبر 2008 على Wayback Machine
  44. ↑ مستودع نقاط الثقة المؤقتة
  45. ↑ .ORG هو أول نطاق مفتوح من المستوى الأعلى موقّع بتقنية DNSSEC
  46. ↑ شون مايكل كيرنر. "نطاق .ORG هو الأكثر أمانًا؟" . internetnews.com . تاريخ الاسترجاع: 27-09-2008 .
  47. ↑ "قائمة مسجلي نطاقات .ORG - مع تفعيل DNSSEC في الأعلى" . مؤرشفة من الأصل بتاريخ 12-06-2010 . تم الاطلاع عليها بتاريخ 23-06-2010 . 
  48. ↑ فيريساين: سندعم أمان نظام أسماء النطاقات (DNS) في عام 2011. مؤرشف في 3 مارس 2009 على موقع Wayback Machine.
  49. ↑ "VeriSign: تحديث أمني رئيسي للإنترنت بحلول عام 2011" . مؤرشف من الأصل بتاريخ 19-11-2009 . تم الاطلاع عليه بتاريخ 18-11-2009 .
  50. ↑ نطاق .com آمن أخيرًا [ تمت إزالة الرابط ]
  51. ↑ مات لارسون من شركة فيريساين يفوز بجائزة إنفوورلد للريادة التكنولوجية لعام 2011
  52. ↑ جوائز إنفوورلد للريادة التكنولوجية لعام 2011
  53. 1 2 "أرشيف مشروع DNSSEC" .
  54. ↑ سينجل، رايان (8 أكتوبر 2006). "الحكومة الفيدرالية تبدأ التحرك لمعالجة ثغرة أمنية في الإنترنت" . وايرد نيوز . كوندي نت . تم الاطلاع عليه بتاريخ 9 أكتوبر 2008 .
  55. ↑ «بيان صحفي: الإدارة الوطنية للاتصالات والمعلومات تطلب تعليقات الجمهور بشأن نشر تقنية أمنية ضمن نظام أسماء النطاقات على الإنترنت» (بيان صحفي). الإدارة الوطنية للاتصالات والمعلومات، وزارة التجارة الأمريكية. 9 أكتوبر/تشرين الأول 2008. مؤرشف من الأصل في 13 أكتوبر/تشرين الأول 2008. تم الاطلاع عليه في 9 أكتوبر /تشرين الأول 2008 .
  56. ↑ «وزارة التجارة الأمريكية تتعاون مع مؤسسة الإنترنت للأسماء والأرقام المُخصصة (ICANN) وشركة VeriSign لتعزيز أمن واستقرار نظام أسماء النطاقات وعناوين الإنترنت» (بيان صحفي). المعهد الوطني للمعايير والتكنولوجيا. 3 يونيو 2009. مؤرشف من الأصل في 29 يونيو 2011. تم الاطلاع عليه في 13 يوليو 2017 .
  57. 1 2 "DNSSEC لمنطقة الجذر" (PDF) .
  58. 1 2 هاتشينسون، جيمس (6 مايو 2010). "مؤسسة ICANN وشركة Verisign تضعان القطع الأخيرة من أحجية DNSSEC" . NetworkWorld . مؤرشف من الأصل في 20 ديسمبر 2013. تم الاطلاع عليه في 17 مايو 2010 .
  59. ↑ "سيصبح نظام أمان بيانات الإنترنت (DNSSEC) معيارًا على نطاقات .ORG بحلول نهاية يونيو" . مؤرشف من الأصل بتاريخ 15 مارس 2010. تم الاطلاع عليه بتاريخ 24 مارس 2010 .
  60. ↑ صحيفة ذا إنكوايرر: فيريساين تنشر نظام DNSSEC على نطاق المستوى الأعلى .com
  61. ↑ مزيد من الأمان لخوادم نظام أسماء النطاقات الجذرية، هايز أونلاين، 24 مارس 2010
  62. ↑ CircleID: تحديث DNSSEC من ICANN 42 في داكار
  63. ↑ أطلقت ISC سجل DLV لبدء نشر DNSSEC عالميًا. مؤرشف في 14 يونيو 2011 على Wayback Machine
  64. ↑ RFC 5011، "التحديثات التلقائية لمرساة الثقة في أمان نظام أسماء النطاقات (DNSSEC)"
  65. ↑ RFC 4431، "سجل موارد نظام أسماء النطاقات للتحقق من صحة البحث الجانبي (DLV) في DNSSEC"
  66. ↑ RFC 5074، "التحقق من صحة البحث الجانبي لـDNSSEC (DLV)"
  67. ↑ "استبدال DLV بمنطقة فارغة موقعة - اتحاد أنظمة الإنترنت" . isc.org . 30 سبتمبر 2017. تم الاطلاع عليه بتاريخ 5 يونيو 2020 .
  68. ↑ "BIND 9.16.0، الفرع المستقر لعام 2020 وما بعده - اتحاد أنظمة الإنترنت" . isc.org . 20 فبراير 2020. تاريخ الاسترجاع: 5 يونيو 2020 .
  69. ↑ "تغييرات Unbound 1.5.4" . مختبرات NLnet . تم الاطلاع عليه بتاريخ 2020-06-05 .
  70. ↑ ميكينغ، و .؛ ماهوني، د. (مارس 2020). نقل التحقق من صحة DNSSEC Lookaside (DLV) إلى الوضع التاريخي . IETF . doi : 10.17487/RFC8749 . RFC 879. تم الاطلاع عليه في 3 يونيو 2020 .
  71. ↑ وزارة الأمن الداخلي الأمريكية تطالب بالمفتاح الرئيسي لنظام أسماء النطاقات (DNS) مؤرشف في 6 أبريل 2007 على موقع Wayback Machine أخبار هايس ، 30 مارس 2007
  72. ↑ تحليل: امتلاك مفاتيح الإنترنت ، UPI ، 21 أبريل 2007
  73. تحليل وكالة UPI: امتلاك مفاتيح الإنترنت ، 24 مارس/آذار 2011 - الرابط الأول معطل، ويُعتقد أن هذا هو نفس المحتوى
  74. ↑ نشرة مبادرة نشر DNSSEC - المجلد 1، العدد 2، مؤرشفة في 22 نوفمبر 2007، على موقع Wayback Machine ، يونيو 2006
  75. ↑ مذكرة إلى كبار مسؤولي المعلومات، مؤرشفة بتاريخ 16 سبتمبر 2008 في أرشيف الإنترنت (Wayback Machine) ، المكتب التنفيذي للرئيس - مكتب الإدارة والميزانية، 22 أغسطس 2008
  76. ↑ شددت السلطات الفيدرالية إجراءات الأمن على نطاق .gov. مؤرشف في 25 سبتمبر 2008 في أرشيف الإنترنت (Wayback Machine) . شبكة العالم، 22 سبتمبر 2008
  77. ↑ مدونة كومكاست - بدء تطبيق أمان نظام أسماء النطاقات (DNS) ، 18 أكتوبر 2010
  78. ↑ فيديو إعلان الخدمة العامة لشركة كومكاست حول نظام أمان شبكة الإنترنت (DNSSEC) مؤرشف بتاريخ 21 أكتوبر 2010 في أرشيف الإنترنت (Wayback Machine )، 18 أكتوبر 2010
  79. ↑ شركة كومكاست تُكمل نشر نظام DNSSEC ، 11 يناير 2012
  80. ↑ جيف هوستون: نظام أسماء النطاقات (DNS)، وأمن نظام أسماء النطاقات (DNSSEC)، وخدمة نظام أسماء النطاقات العامة من جوجل (CircleID)
  81. ↑ تقديم نظام أسماء النطاقات العام من فيريساين
  82. ↑ استخدام التحقق من صحة DNSSEC للعالم (XA)
  83. ↑ يدعم نظام أسماء النطاقات العام من جوجل الآن التحقق من صحة DNSSEC، مدونة جوجل للبرمجيات، 1 يونيو 2013
  84. ↑ "الأسئلة الشائعة حول Quad9" . Quad9 . تم الاطلاع عليه في 7 يوليو 2018 .
  85. ↑ "تطبيق بروتوكول SMTP DANE الوارد مع DNSSEC لتدفق البريد في Exchange Online" . TECHCOMMUNITY.MICROSOFT.COM . تاريخ الاسترجاع: 28-05-2024 .
  86. ↑ هيوستن، جيف (28-05-2024). "هل حان وقت إنهاء DNSSEC؟" . مدونة APNIC . تم الاطلاع بتاريخ 28-05-2024 .
  87. ↑ مولر، روب (2016-12-20). "أمن أنظمة الإنترنت الرقمية وشبكة DANE: لا يوجد تقدم حتى الآن" . فاست ميل . تم الاسترجاع في 2026-03-20 .
  88. ↑ "DNSSEC: مقدمة" . مدونة كلاود فلير . 2014-10-07 . تاريخ الاسترجاع 2026-03-20 .
  89. ↑ «منصة تسجيل النطاقات وخدمات الويب الجديدة "سبيسشيب" تسعى للمساهمة في تشكيل مستقبل الإنترنت "غير المرئي"» . نيم تشيب . ١٦ أبريل ٢٠٢٤. مؤرشف من الأصل في ٢٧ يونيو ٢٠٢٥. تم الاطلاع عليه في ٢٠ مارس ٢٠٢٦ .
  90. ↑ برانش، كولين (21 يناير 2026). "ما هو أمان نظام أسماء النطاقات وكيف يساعد في تأمين النطاق؟" . سبيسشيب . تم الاسترجاع في 20 مارس 2026 .{{cite web}}: CS1 maint: url-status ( link )
  91. ↑ "لا يوجد أي من أكبر خدمات الإنترنت مُفعّل بتقنية DNSSEC" . SIDN . 2025-01-28 . تم الاطلاع عليه بتاريخ 2026-03-26 .{{cite web}}: CS1 maint: url-status ( link )
  92. ↑ سيشادري، شيام (11 نوفمبر 2008). "DNSSEC على عميل DNS في نظام التشغيل Windows 7" . المنفذ 53. مايكروسوفت.
  93. ↑ DNSSEC في ويندوز سيرفر

للمزيد من القراءة

  • هـ. يانغ؛ إ. أوسترويل؛ د. ماسي؛ س. لو؛ ل. تشانغ (8 أبريل 2010). "تطبيق التشفير في أنظمة الإنترنت واسعة النطاق: دراسة حالة حول DNSSEC". مجلة IEEE للمعاملات في الحوسبة الموثوقة والآمنة . 8 (5). IETF . ص  656-669. CiteSeerX 10.1.1.158.1984 . doi : 10.1109/TDSC.2010.10 . S2CID 14887477 .  
  • DNSSEC – موقع معلومات DNSSEC: DNSSEC.net
  • مجموعة عمل امتدادات نظام أسماء النطاقات (DNSEXT) التابعة لـ IETF
  • مشروع أدوات DNSSEC