Skip to main content
Resources

امتدادات أمن نظام أسماء النطاقات DNSSEC – ما هي وما أهميتها؟

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

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

BENEFITS OF DEPLOYING DNSSEC

المحتوى:

وصف موجز لكيفية عمل نظام أسماء النطاقات DNS

لفهم الامتدادات الأمنية لنظام اسم النطاق (DNSSEC)، من المفيد أن يكون لديك فهم أساسي لنظام اسم النطاق (DNS).

يعتمد التشغيل السليم للإنترنت بشكل أساسي على نظام أسماء النطاقات DNS. فكل صفحة ويب تتم زيارتها، وكل بريد إلكتروني يتم إرساله، وكل صورة يتم استرجاعها من وسائل التواصل الاجتماعي تعتمد على نظام أسماء النطاقات. وفي حقيقة الأمر، يترجم نظام أسماء النطاقات أسماء النطاقات سهلة الاستخدام، مثل icann.org، إلى عناوين IP مثل 192.0.43.7 وأيضًا 2001:500:88:200::7. وعناوين IP هذه ضرورية بالنسبة للخوادم ولأجهزة التوجيه ولغيرها من أجهزة الشبكة من أجل توجيه مرور البيانات عبر الإنترنت وصولاً إلى الوجهة الصحيحة.

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

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

إن نظام أسماء النطاقات DNS في حد ذاته غير آمن

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

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

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

الامتدادات الأمنية لنظام أسماء النطاقات

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

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

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

تضيف DNSSEC ميزتين مهمتين إلى بروتوكول DNS:

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

الثقة بمفاتيح امتدادات أمن نظام أسماء النطاقات DNSSEC

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

لذلك يعد المفتاح العمومي لمنطقة الجذر نقطة انطلاق هامة للتحقق من صحة بيانات DNS. إذا كانت هناك وحدة حل تصديق تثق بالمفتاح العمومي لمنطقة الجذر، فيمكنها الوثوق بالمفاتيح العامة لمناطق المستوى الأعلى الموقعة بالمفتاح الخاص للجذر، مثل المفتاح العمومي لمنطقة org. ولأن وحدة الحل يمكنها الوثوق بالمفتاح العمومي لمنطقة org، فإنه يمكنها الوثوق بالمفاتيح العامة التي تم توقيعها بواسطة المفتاح الخاص لكل منها، مثل المفتاح العمومي لموقع icann.org. (في الممارسة الفعلية، لا تقوم المنطقة الأم بتوقيع مفتاح المنطقة الفرعية مباشرةً --تكون الآلية الفعلية أكثر تعقيدًا - ولكن التأثير يكون التأثير هو نفس التأثير الناجم عن ما إن كانت المنطقة الأصل قد وقَّعت مفتاح المنطقة الفرعية).

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

التوثيق والتوقيع باستخدام امتدادات أمن نظام أسماء النطاقات DNSSEC

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

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

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

لكي يتمكن مالك منطقة من نشر واستخدام الامتدادات الأمنية لنظام أسماء النطاقات DNSSEC عن طريق توقيع بيانات منطقته، يجب أيضًا توقيع أصل تلك المنطقة والمنطقة التابعة لها، وصولاً إلى منطقة الجذر، حتى تكون الامتدادات الأمنية لنظام أسماء النطاقات DNSSEC فعالة قدر الإمكان. وتسمح سلسلة مستمرة من المناطق الموقعة تبدأ من منطقة الجذر لوحدة الحل بإنشاء سلسلة ثقة من منطقة الجذر للتحقق من صحة البيانات. على سبيل المثال، لنشر DNSSEC بفاعلية في منطقة icann.org، يجب أن يتم توقيع منطقة المؤسسة وكذلك منطقة الجذر. ولحسن الحظ، تم توقيع منطقة جذر نظام أسماء النطاقات DNS منذ عام 2010، كما تم توقيع جميع نطاقات المستوى الأعلى العامة (gTLD) والعديد من نطاقات المستوى الأعلى لرموز البلدان (ccTLD).

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

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

الخطوات التالية لامتدادات DNSSEC

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

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

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

اعرف المزيد

ما الذي تقوم به ICANN في محيط امتدادات أمن نظام أسماء النطاقات DNSSEC
  • معلومات امتدادات أمن نظام أسماء النطاقات DNSSEC من هيئة الإنترنت للأرقام المخصصة IANA
    تحتوي هذه الصفحة على معلومات ذات صلة بدور هيئة الإنترنت للأرقام المخصصة IANA باعتبارها مشغل مفتاح توقيع شفرة الدخول الأساسية لمنطقة جذر نظام أسماء النطاقات DNS: أي مرتكزات الثقة ووحدات حل المصادقة ومواد تبديل مفتاح توقيع شفرة الدخول الأساسية وسياسات وإجراءات إدارة مفاتيح خوادم الجذر.
  • المشاركة الفنية
    تحتوي هذه الصفحة على معلومات حول فريق ICANN المسئول عن إجراء وتسيير مبادرات بناء القدرات الفنية والمشاركة في التوعية والتواصل مع مختلف أصحاب المصلحة داخل مجتمع الإنترنت من أجل المساعدة في الحفاظ على منظومة أسماء نطاقات DNS آمنة.
منشورات ذات صلة

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

مستندات ICANN
  • OCTO-035: مراقبة دورات حياة مفتاح DNSSEC، يوليو/تموز 2022
  • OCTO-033: استخدام خوارزمية DNSSEC في عام 2022، أبريل/نيسان 2022
  • OCTO-029: دليل نشر واستخدام امتدادات DNSSEC لنطاقات ccTLD، نوفمبر/تشرين الثاني 2021
  • OCTO-012: مراجعة استبدال مفتاح توقيع شفرة الدخول الأساسية KSK لامتدادات أمن نظام أسماء النطاقات DNSSEC في عام 2018، يوليو/تموز 2020
  • OCTO-006: امتدادات أمن نظام أسماء النطاقات DNSSEC: تأمين نظام DNS، تحديث في يوليو/تموز 2020
  • محفوظات مشروع امتدادات أمن نظام أسماء النطاقات DNSSEC: المستندات المحفوظة في الأرشيف من مشروعات المجتمع الخاصة ذات الصلة بنشر واستخدام وتطور امتدادات أمن نظام أسماء النطاقات DNSSEC في منطقة الجذر. ولا يجب الاعتماد عليها في الحصول على معلومات حديثة حول العمليات، فهي مقدمة للأغراض التاريخية فقط.
روابط خارجية
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."