Skip to main content
Resources

التحقق من مراسي الثقة الحالية في وحدات الحل الموثقة لنظام اسم النطاق DNS

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

تمت ترجمة هذه الوثيقة إلى العديد من اللغات بغرض المعلومات فقط. ويمكن العثور على النص الأصلي والموثوق (بالإنجليزية) من: https://www.icann.org/dns-resolvers-checking-current-trust-anchors

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

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

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

من أجل اختبار ما إذا كانت وحدة الحل التي تُشغّلها تقوم بالتحقق من الإمتدادات الأمنية لنظام اسم النطاق، يمكنك استخدام النطاق الخاص "dnssec-failed.org" الذي يتم تشغيله كخدمة عامة من قبل شركة كومكاست "Comcast". هذا النطاق الخاص سيجعل وحدات الحل الموثقة تفشل عمدًا في تقديم إجابة. اعط الأمر التالي في خط أوامر بين قوسين:

‎dig @ADDRESS dnssec-failed.org a +dnssec

في هذا الأمر، استبدل السلسلة ADDRESS بعنوان بروتوكول الإنترنت - الإصدار الرابع IPv4 أو بروتوكول الإنترنت - الإصدار السادس IPv6 لوحدة الحل التي تُشغّلها.

إذا تضمنت الإجابة ما يلي:

‎;; ->>HEADER<<- opcode:‎ ‎QUERY, status:‎ SERVFAIL

فإن وحدة الحل تقوم بالتحقق من الإمتدادات الأمنية لنظام اسم النطاق. (تحديد حالة SERVFAIL تشير إلى أن التحقق قد فشل، مما يعني أن التحقق يتم في الواقع.)

وأما إذا تضمنت الإجابة ما يلي:

‎‎;; ->>HEADER<<- opcode:‎ QUERY, status:‎‎ NOERROR

فإن وحدة الحل لا تقوم بالتحقق من الإمتدادات الأمنية لنظام اسم النطاق.

تدرج بقية هذه الصفحة مختلف تنفيذات وتعليمات وحدة الحل اللازمة للتحقق من مراسي الثقة المدمجة بها.


برامجيات بيركلي لنظام اسم النطاق على الإنترنت BIND

إصدارات BIND رقم 9.9 و9.10 و9.11 تدعم التحقق من الإمتدادات الأمنية لنظام اسم النطاق باستخدام التحديث التلقائي RFC 5011. الإصدارات الفرعية الأخيرة لهذه الإصدارات تأتي مع المفتاح KSK2017 كجزء من مراسي الثقة.

تحقق أولًا من أن التحقق من الإمتدادات الأمنية لنظام اسم النطاق مُفعّل في ملف الإعدادات. يجب أن ترى خطًا في قسم الخيارات والذي يُظهر إما عبارة dnssec-validation auto؛ أو عبارة dnssec-validation yes؛. أما إذا كانت إعداداتك تُظهر dnssec-validation yes؛، إذن يجب تغييره إلى dnssec-validation auto؛ وإعادة إطلاق خادمك قبل اتخاذ الخطوات التالية.

لتوليد ملف يتضمن مراسي الثقة المستخدمة، باستخدام الأمر

rndc secroots

يقوم هذا الأمر بإنشاء ملف يُدعى named.secroots في نفس الدليل حيث تم إنشاء الملفات الأخرى لبرمجية BIND. يتضمن الملف خطين، يُظهر أولهما العبارة ‎/RSASHA256/20326 في حين يُظهر الآخر العبارة ‎/RSASHA256/19036. أما إذا لم يكن يتضمن هذين المفتاحين كليهما، فيجب عليك تحديث مراسي الثقة لديك كما هو موصوف هنا.

شركة ISC، الشركة التي أنتجت برمجية BIND، لديها مزيد من المعلومات بشأن مراسي ثقة الإمتدادات الأمنية لنظام اسم النطاق DNSSEC لبرمجية BIND على الرابط https://kb.isc.org/article/AA-01529/169/KSK-2010-Rollover.html.


الإصدار Unbound

انظر في ملف root.key في دليل إعدادات الإصدار Unbound، والذي هو عادة /etc/unbound. يجب أن يتضمن تسجيلات DNSKEY، أحدها يتضمن النص id = 20326 والآخر هو الذي يتضمن النص id = 19036؛ كما ينبغي أن يظهر التسجيلان كلاهما ما يلي ;;state=2 [ VALID ].

إذا كنت تُشغّل الإصدار Unbound 1.6.2 أو إصدارًا أحدث، يمكنك أيضًا الحصول على مفاتيح الثقة من خلال استفسار وحدة الحل عن اسم trustanchor.unbound في الفئة CH لنوع المصدر TXT، مع الأمر التالي:

dig @address trustanchor.unbound -c CH -t TXT

إذا كانت الملفات لا تتضمن كلا المفتاحين، أو إذا كان أحد المفتاحين لا يتضمن حالة تُظهر ;;state=2 [ VALID ]، أو إذا كان الاستفسار لا يشير إلى المفتاحين، فيجب عليك تحديث مراسي الثقة لديك كما هو موصوف هنا.


إصدار PowerDNS Recursor

إصدار PowerDNS Recursor رقم 4 يدعم التحقق من الإمتدادات الأمنية لنظام اسم النطاق، لكنه لا يدعم بعد التحقق من الإمتدادات الأمنية لنظام اسم النطاق باستخدام التحديث التلقائي RFC 5011. هذا يعني أنه بالنسبة لإصدار PowerDNS Recursor، تحتاج للحصول على مجموعة جديدة من مراسي الثقة في كل وقت تتغير فيه مراسي الثقة. الإصدار 4.0.5 والإصدارات الأحدث من PowerDNS Recursor تأتي مع المفتاح KSK2017 كجزء من مراسي الثقة المثبتة.

في واجهة خط الأوامر، أعط الأمر:

rec_control get-tas

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


وحدة الحل Knot

تدعم وحدة الحل Knot التحقق من الإمتدادات الأمنية لنظام اسم النطاق باستخدام التحديث التلقائي RFC 5011 في جميع الإصدارات.

انظر في ملف root.keys في دليل إعدادات الإصدار وحدة الحل Knot (والذي يختلف حسب التوزيع). يجب أن يتضمن خطين، أحدهما يتضمن النص 0101030803010001A80020A95566BA42E886BB804CDA84E47EF56DB والآخر يتضمن النص 0101030803010001ACFFB409BCC939F831F7A1E5EC88F7A59255EC5. أما إذا لم يكن يتضمن هذين المفتاحين كليهما، فيجب عليك تحديث مراسي الثقة لديك كما هو موصوف هنا.


إصدار خادم ويندوز 2012R2 و2016

إصدارات خادم ويندوز، سواء 2012R2 أو 2016 تدعم التحقق من الإمتدادات الأمنية لنظام اسم النطاق باستخدام RFC 5011 التلقائي. الأوامر التالية لمستخدم ويندوز PowerShell.

للتحقق من محتويات مراسي الثقة، استخدم:

Get-DnsServerTrustAnchor -Name .‎

ويجب أن يظهر ما يلي:

TrustAnchorName	TrustAnchorTyp	TrustAnchorStat	 	TrustAnchorData  					
---------------	--------------	---------------		---------------  					
.	 	DNSKEY	 	Valid	 		[19036][DnsSec][RsaSha256][AwEAAagAIKlVZrpC6Ia7...‎	
.	  	DNSKEY	 	Valid	 		[20326][DnsSec][RsaSha256][AwEAAaz/tAm8yTn4Mfeh...‎	

يتم نشر العلامات الرئيسية تحت TrustAnchorData. بالنسبة لمرساة ثقة الجذر، يجب عليك رؤية هاتين العلامتين الرئيسيتين: 19036 و20326. كلتا مرساتي الثقة يجب أن تتم الإشارة إلى حالتهما بالعبارة "Valid". أما إذا لم يكن يتضمن هذين المفتاحين كليهما، فيجب عليك تحديث مراسي الثقة لديك كما هو موصوف هنا.

لرؤية نقاط الثقة الحالية النشطة على الخادم، استخدم:

Get-DnsServerTrustPoint

وهذا سيُظهر:


TrustPointName	TrustPointState LastActiveRefreshTime 	NextActiveRefreshTime		
--------------	--------------- --------------------- 	---------------------		
. 		Active	 	9/11/2017 8:37:02 PM 	9/12/2017 8:37:02 PM		

الإصدار Akamai DNSi Cacheserve

الإصدار Akamai Cacheserve (الإصدارات المعادلة أو الأحدث مقارنة بالإصدارات 7.1.2.3، و7.2.0.3، و7.2.1.2) تدعم التحقق من الإمتدادات الأمنية لنظام اسم النطاق باستخدام المفاتيح المسيرة بواسطة RFC5011. رغم أن القدرة موجودة أيضًا في الإصدارات القديمة، فلا يجب استخدامها لأن هناك مشكلة مع رمز الإستبدال. للتحقق من أن الإصدار Akamai DNSi Cacheserve يقوم بالفعل بالتحقق، قم بتشغيل الأمر التالي:

nom-tell cacheserve resolver.mget fields='(trusted-keys managed-keys-state)'‎

إذا كانت هناك أية حقول trusted-keys أو managed-keys-state في المخرجات، فإن الإصدار Akamai DNSi Cacheserve يقوم بالتحقق من الإمتدادات الأمنية لنظام اسم النطاق وتحتاج التأكد من أنه يتم استخدام المفاتيح السليمة. في managed-keys-state بالنسبة للجذر ('.') يجب أن يظهر لك keyid مع القيمة 19036 و20326 كليهما مع الحالة في الوضع validومع كون الحقلhas-validated محددًا في True. بالنسبة لمفاتيح الثقة، عليك أن تقارن مواد المفاتيح الحالية. للتحقق من ذلك، أو لإصلاح المفاتيح إذا لم تكن موصوفة، انظر الوصف هنا.


إصدار Infoblox NIOS

إصدار Infoblox NIOS يدعم التحقق من الإمتدادات الأمنية لنظام اسم النطاق، لكنه لا يدعم بعد التحقق من الإمتدادات الأمنية لنظام اسم النطاق باستخدام التحديث التلقائي RFC 5011. هذا يعني أنه بالنسبة لإصدار Infoblox NIOS، تحتاج لإعداد مجموعة جديدة من مراسي الثقة في كل وقت تتغير فيه مراسي الثقة.

الخطوات للتحقق من مراسي الثقة الحالية في إصدار NIOS هي:

  1. تسجيل الدخول إلى NIOS GUI
  2. التصفح إلى Data Management → DNS
  3. الضغط على "Grid DNS Properties" من شريط الأدوات
  4. تفعيل الوضع "Advanced Mode"
  5. اختيار التبويب "DNSSEC"
  6. التمرير لأسفل لاختيار "Trust Anchors"
  7. جميع مراسي الثقة التي تم إعدادها ستظهر في جدول "Trust Anchors". النظر في مدخل مع "." في عمود "Zone" والتحقق من عمود "Secure Entry Point". (إذا لم تكن هناك مرساة ثقة من هذا النوع، فلا يوجد مفتاح توقيع رئيسي لمنطقة الجذر تم إعداده.) تمرير الفأرة على القيمة في عمود "Public Key" لرؤية القيمة الكاملة.

إذا كنت تتحقق من مستوى العضو:

  1. تسجيل الدخول إلى NIOS GUI
  2. التصفح إلى Data Management → DNS → Members/Servers
  3. اختيار خادم نظام اسم النطاق DNS
  4. الضغط على "Edit"
  5. تفعيل الوضع "Advanced Mode"
  6. اختيار "DNSSEC"
  7. التمرير لأسفل لاختيار "Trust Anchors"
  8. جميع مراسي الثقة التي تم إعدادها ستظهر في جدول "Trust Anchors". النظر في مدخل مع "." في عمود "Zone" والتحقق من عمود "Secure Entry Point". (إذا لم تكن هناك مرساة ثقة من هذا النوع، فلا يوجد مفتاح توقيع رئيسي لمنطقة الجذر تم إعداده.) تمرير الفأرة على القيمة في عمود "Public Key" لرؤية القيمة الكاملة.

للتمييز بين مفتاح التوقيع الرئيسي لمنطقة الجذر القديم والجديد، سيظهر مفتاح التوقيع الرئيسي لمنطقة الجذر القديم على الشكل:


AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0Ezr
AcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf
5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMj
JPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmR
LKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=‎

وسيظهر مفتاح التوقيع الرئيسي لمنطقة الجذر الجديد (الحالي) على الشكل:


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