Skip to main content
Resources

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

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

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

هذه الصفحة مخصصة لمسيري وحدات حل نظام اسم النطاق DNS (والتي تسمى أحيانًا وحدات الحل المكررة"). المعلومات هنا مفيدة إذا ما:

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

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

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

من أجل اختبار ما إذا كانت وحدة الحل التي تُشغّلها تقوم بالتحقق من الإمتدادات الأمنية لنظام اسم النطاق، يمكنك استخدام النطاق الخاص "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 محددة في auto، فأنت لا تحتاج إلى تحديث برنامجك أو إعداداتك. كل ما عليك فعله هو إعادة إطلاق برنامجك، باستخدام أي أمر تستخدمه لإيقاف وبدء برنامج BIND؛ هذا سيجلب أحدث مراسي الثقة إلى dnssec-validation auto.

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

إذا كان بإمكانك تحديث برنامجك:

  1. قم بتحديث آخر إصدار فرعي من BIND 9.9، أو BIND 9.10 أو BIND 9.11 باستخدام أية طريقة استخدمتها لتثبيت البرنامج. إذا كنت تُشغّل برنامج BIND 9.8، فإنه برنامج لم يعد مدعومًا، وتحتاج التحديث إلى الإصدار BIND 9.9 أو إلى إصدار أحدث. أنت بحاجة إلى إصدار فرعي على الأقل:
    • BIND 9.9.10
    • BIND 9.10.5
    • BIND 9.11.1
  2. في ملف إعداداتك، تأكد من أن قسم الخيارات يحتوي على خط يُظهر العبارة dnssec-validation auto؛.
  3. أوقف الإصدار القديم من برمجية BIND وأطلق الإصدار الجديد، باستخدام أي أمر تستخدمه عادة لإيقاف وبدء BIND.

إذا لم يكن بإمكانك تحديث برنامجك:

  1. قم بتحديث الملف bind.keys ليتضمن مرساة الثقة الجديدة. يجب أن يتم حفظ الملف bind.keys في نفس الدليل حيث تم إنشاء الملفات الأخرى لبرمجية BIND. أو، إذا كان ملف named.conf يمضم قسم managed-keys يدرج مراسي الثقة، فيمكنك تحديث ذلك القسم. يجب أن يتضمن الملف المحدث أو الإعدادات المحدثة ما يلي:

    
    managed-keys {
    . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
    FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
    bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
    X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
    W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
    Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
    QxA+Uk1ihz0=";
    
    . initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    R1AkUTV74bU=";
    };
    

إذا كانت الإعدادات تضم dnssec-validation محددًا في وضع auto، فإن محتويات ملف bind.keys سيتم مزجها مع محتويات مجموعة managed-keys في الإعدادات. يمكن إيجاد مزيد من المعلومات بشأن هذا الموضوع على الرابط https://www.isc.org/downloads/bind/bind-keys/.

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


الإصدار Unbound

إلا أن جميع الإصدارات Unbound قبل 1.6.5 محدودة بأمر يمنعها من قبول مرساة الثقة الجديدة إذا كان الإصدار انطلق لأول مرة منذ 30 يومًا أو بعد ذلك قبل الإستبدال.

إذا كنت تُشغّل إصدار Unbound رقم 1.6.5 أو إصدارًا أحدث:

  1. قم بحذف مراسي الثقة الحالية من خلال:

    rm root.key‎
  2. احصل على آخر إصدار من مراسي الثقة من خلال:

    unbound-anchor
  3. قم بإعادة بدء Unbound حتى يعيد تحميل الإعدادات الجديدة، باستخدام أي أمر تستخدمه عادة لبدء إصدار Unbound.

إذا كنت تُشغّل إصدار Unbound رقم 1.6.4 أو إصدارًا أقدم، وكان بإمكانك تحديث برنامجك:

  1. قم بالتحديث إلى إصدار Unbound رقم Unbound أو إلى إصدار أحدث.

  2. قم بحذف مراسي الثقة الحالية من خلال:

    rm root.key
    
  3. احصل على آخر إصدار من مراسي الثقة من خلال:

    unbound-anchor
    
  4. قم بإعادة بدء الإصداؤ الجديد من Unbound حتى يعيد تحميل الإعدادات الجديدة، باستخدام أي أمر تستخدمه عادة لبدء إصدار Unbound.

إذا كنت تُشغّل إصدار Unbound رقم 1.6.4 أو إصدارًا أقدم، وكان أحد المفاتيح في ملف root.key غير مدرج بصفة [ VALID ]، ولم يكن بإمكانك تحديث برنامجك:

  1. راجع الصفحة على الرابط https://www.unbound.net/root-11sep-11oct.html للحصول على معلومات بشأن كيفية الحصول على ملف root.key جديد من NLnet Labs مع كلال المفتاحين بصفة [ VALID ].
  2. قم بإعادة بدء Unbound حتى يعيد تحميل الإعدادات الجديدة، باستخدام أي أمر تستخدمه عادة لبدء إصدار Unbound.

إصدار PowerDNS Recursor

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

إذا كان بإمكانك تحديث برنامجك:

  1. قم بتحديث آخر إصدار فرعي من PowerDNS Recursor باستخدام أية طريقة استخدمتها لتثبيت البرنامج. تأكد من أن الإصدار المسترجع هو 4.0.5 أو إصدار أحدث.
  2. أخرج من الإصدار الحالي للإصدار PowerDNS Recursor وابدأ الإصدار الجديد، باستخدام أية طريقة تستخدمها عادة لإيقاف وبدء الخادم.

إذا لم يكن بإمكانك تحديث برنامجك:

  1. إذا لم يكن لديك بالفعل خط lua-config-file في الإعداد الرئيسي PowerDNS، فعليك أن تضيفه. الخط يشير إلى ملف يحتوي على مزيد من إعدادات PowerDNS. وقد يشبه ذلك الخط:

    lua-config-file=/etc/pdns/luaconf.txt
    
  2. في الملف المشار إليه بواسطة الخط lua-config-file، قم بإضافة الخطين التاليين:

    addDS('.', "19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5")
    addDS('.', "20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D")
    
  3. قم بإعادة بدء الإصدار PowerDNS Recursor، باستخدام أية طريقة تستخدمها عادة لإيقاف وبدء الخادم.


وحدة الحل Knot

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

  1. في ملف الإعدادات، تأكد من أن هناك خطًا يُظهر:

    trust_anchors.file = 'root.keys'
    
  2. إذا كان ذلك الملف لا يتضمن خطًا يحتوي على 19036 و20326، أوقف الخادم باستخدام أية طريقة تستخدمها عادة، واحذف الملف root.keys، وابدأ الخادم مجددًا. هذا سيجعل وحدة الحل Knot تعيد إنشاء الملف مع مراسي الثقة الأخيرة من هيئة الإنترنت للأرقام المخصصة IANA.


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

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

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

Get-DnsServerTrustPoint

وسوف تُظهر ما يلي:

‎
TrustPointName   TrustPointState   LastActiveRefreshTime   NextActiveRefreshTime
--------------   ---------------   ---------------------   ---------------------
.                Active            9/11/2017 7:45:03 PM    9/12/2017 7:45:03 PM

الأوقات المحددة هي وفق التوقيت العالمي المنسق. إذا لم يكن تحديث مرساة الثقة يتم بشكل سليم، يمكنك استبداله من خلال:

Add-DnsServerTrustAnchor -Root

بعد إضافة مرساة الثقة، سترى LastActiveRefreshTime محدثة في مخرجات الأمر Get-DnsServerTrustPoint.

ملاحظة: إذا فشلت Add-DnsServerTrustAnchor -Root، تأكد من أن الإمتدادات الأمنية لنظام اسم النطاق DNSSEC مفعلة على خادمك. استخدم الأوامر الثلاثة:


$a = Get-DnsServerSetting -All 	
$a.EnableDnsSec = 1 		
$a | Set-DnsServerSetting

يمكنك التحقق من أن RootTrustAnchorsURL تشير إلى https://data.iana.org/root-anchors/root-anchors.xml من خلال الأمر:

(Get-DnsServerSetting -All).RootTrustAnchorsURL

إذا كان الأمر Add-DnsServerTrustAnchor -Root لا يعمل أيضًا، فإن ذلك قد يكون بسبب أسوار حماية تقوم بإيقاف النقل. قد يحدث هذا في بعض البيئات ذات التأمين عالي المستوى. من أجل إضافة مرساة الثقة DS يدويًا، فيجب أن تعرف الموجز، والخوارزمية، والعلامة الرئيسية. من أجل إضافة مرساة الثقة DNSKEY، فأنت بحاجة إلى DNSKEY عام (أو Base64Data). أو يمكنك استيراد مرساة الثقة إذا كان لديك وصول إلى ملف مجموعة المفاتيح (بالنسبة لمرساة DNSKEY) أو DSSET (بالنسبة لمرساة DS). الموجز، الخوارزمية (نوع الموجز) والعلامة الرئيسية لمرساة ثقة الجذر يمكن رؤيتها على الرابط https://data.iana.org/root-anchors/root-anchors.xml .

تبين الأوامر التالية كيفية الإضافة اليدوية لمرساة الثقة DS بالنسبة لمنطقة جذر.


Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 -DigestType SHA256 -KeyTag 19036 -ComputerName localhost -PassThru
Add-DnsServerTrustAnchor -Name "." -CryptoAlgorithm RSASHA256 -Digest E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D -DigestType SHA256 -KeyTag 20326 -ComputerName localhost -PassThru

ليس من الضروري إعادة بدء خدمة DNS بعد تحديث مراسي الثقة. إلا أنك قد ترغب في إزالة الذاكرة المؤقتة لخادم DNS من خلال الأمر:

Clear-DnsServerCache -Force

يمكن إيجاد المزيد من المعلومات من شركة مايكروسوفت Microsoft من خلال الرابط https://technet.microsoft.com/en-us/itpro/powershell/windows/dnsserver/add-dnsservertrustanchor.


الإصدار Akamai DNSi Cacheserve

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

إذا كان بإمكانك تحديث برنامجك:

  1. أسهل طريقة للحصول على أحدث مفتاح جذر DNSSEC هي استخدام المفاتيح المسيرة والتحديث إلى إصدار Akamai DNSi Cacheserve:

    • 7.1.2.3
    • 7.2.0.3
    • 7.2.1.2

    أو إلى إصدار أحدث على السلاسل المناسبة، والتي تضم مفتاح الجذر الجديد بالفعل مدمجًا ومشغلًا.

إذا لم يكن بإمكانك تحديث برنامجك:

  1. راجع المعلومات على الرابط https://support.nominum.com/view-article/965 أو تواصل مع الشركة Akamai من خلال https://support.nominum.com/.

إصدار 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. الضغط على زر "Add" وإدخال تفاصيل المفتاح. المنطقة هي "." والخوارزمية هي .‎‎‎"RSA/SHA-256(8)"‎
  8. قم بلصق المفتاح في عمود "المفتاح العام". المفتاح العام هو:
    ‎
    ‎AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    R1AkUTV74bU=
    

إذا كانت الإضافة من مستوى عضو:

  1. تسجيل الدخول في NIOS GUI
  2. التصفح إلى Data Management → DNS → Members/Servers
  3. اختيار خادم نظام اسم النطاق DNS
  4. الضغط على "Edit"
  5. تفعيل الوضع "Advanced Mode"
  6. اختيار "DNSSEC"
  7. التمرير إلى أسفل لاختيار "Trust Anchors"
  8. الضغط على زر "Add" وإدخال تفاصيل المفتاح. المنطقة هي "." والخوارزمية هي .‎‎‎"RSA/SHA-256(8)"‎
  9. قم بلصق المفتاح في عمود "المفتاح العام". المفتاح العام هو:
    AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    R1AkUTV74bU=
    
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."