في المقال السابق فكّكتُ «معرّف الموارد URL»، ورأيتَ أن اسم النطاق داخله (مثل google.com) هو ما يحدّد الخادم. لكنّ الأجهزة لا تتخاطب بالأسماء، بل بأرقام تُسمّى عناوين IP، مثل 142.250.184.196. فمن يترجم الاسم الذي تكتبه إلى الرقم الذي تفهمه الآلة؟ هذا عمل نظام أسماء النطاقات (DNS)، وهو موضوع هذا المقال.
تخيّله دليل هاتف للإنترنت: أنت تعرف اسم الشخص، وتحتاج رقمه. الفرق أن هذا الدليل موزّع على ملايين الخوادم حول العالم، ويجيب على مليارات الاستعلامات في الثانية، دون أن تشعر بوجوده. سأتتبّع هنا كيف يجد جوابك، خطوة خطوة، ثم ما الذي يخزّنه فعلًا غير عناوين المواقع.
وفائدة DNS أبعد من سهولة الحفظ. لأن الاسم منفصل عن العنوان، تستطيع نقل موقعك إلى خادم جديد بعنوان مختلف دون أن يتغيّر اسمك، فيتبعك زوّارك دون أن يشعروا بشيء. الاسم ثابت يطمئنّ إليه الناس، والعنوان خلفه حرّ يتبدّل وقت ما شئت. هذا الفصل بين «ما تتذكّره» و«أين يقع فعلًا» هو نصف قيمة النظام.
كيف يتحوّل الاسم إلى عنوان: خطوات الاستعلام
حين تكتب اسم نطاق وتضغط Enter، لا يبدأ متصفّحك بحثا عالميا فورًا، بل يبحث أقرب فأبعد، ويتوقّف عند أول جواب يجده. هذا الترتيب هو سرّ سرعة الإنترنت.
أولا: الذاكرة المحلية
قبل أن يسأل أحدا، يفتّش المتصفّح ذاكرته القريبة. فلكلّ متصفّح تخزين مؤقّت (Cache) صغير يحتفظ فيه بعناوين المواقع التي زرتها حديثًا. فإن لم يجد، سأل نظام التشغيل (ويندوز أو ماك أو لينكس)، ولنظام التشغيل تخزينه المؤقّت الأكبر المشترك بين كل تطبيقاتك. إن وُجد العنوان في أيّ منهما، انتهى الاستعلام في أجزاء من الألف من الثانية، وبدأ الاتصال فورًا. هذا ما يجعل المواقع التي تزورها كل يوم تفتح وكأنها بلا تأخير.
وثمّة طبقة أقدم من هذا كلّه: ملفّ «المضيفين» (hosts) على جهازك، وهو جدول يدويّ صغير يربط أسماء بعناوين، يسبق DNS تاريخيا وما زال يُفحَص قبله. يستعمله المطوّرون لتوجيه اسم إلى خادم محليّ أثناء التطوير، وقد يُستعمَل لحجب مواقع بربط اسمها بعنوان فارغ.
وإنما يبدأ «التحقيق العالميّ» إذا فشل البحث المحلّيّ كلّه.
ثانيًا: المحلِّل التكراريّ، الوكيل الذي تفوّضه
لا يجوب جهازك الإنترنت بنفسه، بل يفوّض المهمّة لخادم متخصّص اسمه «المحلِّل التكراريّ» (Recursive Resolver)، غالبًا تابع لمزوّد خدمتك، وقد يكون محلِّلا عامّا مثل 1.1.1.1 من Cloudflare أو 8.8.8.8 من Google.[1] تعطيه سؤالا بسيطا («ما عنوان google.com؟») فيتكفّل هو بكل الخطوات التالية ولا يعود إلا بالجواب النهائيّ، بينما ينتظر جهازك بهدوء.
وللمحلِّل ذاكرة مؤقّتة قويّة مشتركة، وهنا قوّته: إن سأل جارُك الذي يشترك معك في المزوّد عن موقع قبل دقيقة، خزّن المحلِّل عنوانه، فيجيبك أنت فورًا من ذاكرته دون أن يكرّر الاستعلام. فهو لا يسرّع استعلاماتك وحدك، بل استعلامات منطقتك كلّها. ومثل خوادم الجذر، تنشر المحلِّلات العامّة الكبرى نفسها بتقنية Anycast في مدن كثيرة، فيصل سؤالك إلى أقرب نسخة منها، وهو من أسباب سرعة محلِّل مثل 1.1.1.1.
ولفظ «التكراريّ» يحتاج توضيحا. سؤالك للمحلِّل سؤال تكراريّ بمعنى: «لا تَعُد إلا بالجواب النهائيّ مهما كلّفك». أما أسئلة المحلِّل للخوادم الأخرى (الجذر، فالنطاق الأعلى، فالمعتمد) فمن نوع آخر يُسمّى «التدرّجيّ» (Iterative): كلّ منها لا يعطيه الجواب، بل يحيله إلى الخطوة التالية الأقرب. فالمحلِّل يحمل عنك عبء التنقّل بين هذه المستويات، ويردّ عليك بجواب واحد جاهز.
مسار الاستعلام: المحلِّل التكراريّ يسأل خادم الجذر، ثم خادم النطاق الأعلى، ثم الخادم المعتمد، حتى يعود بعنوان IP إلى العميل.
ثالثًا: خادم الجذر، من يدلّك على الاتجاه
حين لا يجد المحلِّل الجواب في ذاكرته، يبدأ من القمّة: خوادم الجذر (Root Servers). هي لا تعرف عنوان كل موقع، لكنها تعرف من المسؤول عن كل نطاق أعلى (.com، .org، .sa…). فحين يسألها المحلِّل عن google.com، لا تنظر إلا إلى النهاية .com، وتردّ: «لا أملك العنوان، لكن هذا خادم المسؤول عن .com، اسأله».
وثمّة تفصيل يُساء فهمه: يُقال إن خوادم الجذر «13»، لكنّ هذا عدد العناوين لا عدد الأجهزة. فكل عنوان منها شبكة من مئات النسخ المتطابقة موزّعة حول العالم بتقنية «البثّ الأقرب» (Anycast)، فيصل سؤالك إلى أقرب نسخة جغرافيا، ويبقى النظام صامدا أمام الأعطال.[4]
رابعًا: خادم النطاق الأعلى (TLD)
يذهب المحلِّل الآن إلى الخادم المسؤول عن كل ما ينتهي بـ.com. هذا الخادم يدير سجلّات كل النطاقات التي تشترك في الامتداد نفسه، ولكلّ امتداد خوادمه (واحدة لـ.com، وأخرى لـ.org…). لا يملك العنوان النهائيّ، لكنه يعرف من يملكه: يبحث عن google.com في سجلّه، فيجد أسماء الخوادم التي سجّلتها جوجل لإدارة نطاقها (مثل ns1.google.com)، ويردّ: «اذهب واسأل هذا الخادم، فهو المصدر الرسميّ». وتدير خوادمَ النطاقات العليا جهات مُسجِّلة معتمدة: تشغّل شركة Verisign سجلّ .com مثلًا، وتتولّى هيئات وطنية نطاقات الدول مثل .sa، وكلّها تعمل تحت تنسيق ICANN.
خامسًا: الخادم المعتمد، المصدر الرسميّ للجواب
هنا ينتهي الاستعلام: الخادم المعتمد (Authoritative Name Server) هو من يملك الملفّ الأصليّ لسجلّات النطاق (يُسمّى Zone File)، ويعطي جوابا نهائيا لا توجيها. يسأله المحلِّل: «ما عنوان IP للمضيف www في google.com؟» فينظر في ملفّه ويردّ بالعنوان القاطع: 142.250.184.196. وعادةً يكون لكل نطاق خادمان معتمدان على الأقلّ، احتياطا للموثوقية.[1]
وهذه الخطوة تلمسها عمليا. حين تشتري استضافة، تعطيك الشركة عنوانَي خادمَي أسماء (مثل ns1.host.com وns2.host.com). وحين تذهب إلى مُسجِّل نطاقك وتضبط «خوادم الأسماء» على هذين العنوانين، فأنت تعلن للعالم عبر DNS: «من سأل عن نطاقي، فليُرسَل إلى هذين الخادمين، فهما يملكان الإجابة الصحيحة».
سادسًا: التوصيل والتذكّر (TTL)
يعود المحلِّل بالعنوان إلى جهازك، فيمرّره نظام التشغيل إلى المتصفّح، الذي صار يعرف وجهته ويبدأ محادثته مع الخادم. لكنّ المحلِّل، قبل أن يسلّمك الجواب، يحتفظ بنسخة منه في ذاكرته. وكلّ سجلّ يأتي ومعه «مدّة صلاحية» تُسمّى TTL، أشبه بتاريخ انتهاء الصلاحية: تقول للمحلِّل «هذا العنوان صحيح لكذا ساعة، فلا تسأل عنه ثانية خلالها».
هذا التخزين المؤقّت المتدرّج (في متصفّحك، ونظامك، والمحلِّل) هو ما يجعل هذا المسار العالميّ المعقّد لا يتكرّر إلا عند الضرورة. فأول من يطلب موقعا في منطقتك قد يستغرق طلبه 200 جزء من الألف من الثانية، أما من يطلبه بعده فيُجاب في جزء واحد، من ذاكرة المحلِّل مباشرةً.
انتشار DNS: لماذا يتأخّر التغيير؟
القدرة نفسها التي تمنح DNS سرعته، التخزين المؤقّت، تسبّب أكثر ما يُربك المبتدئين: «انتشار DNS». تنقل موقعك إلى استضافة جديدة، أو توجّه نطاقك إلى خادم آخر، ثم تكتب عنوانك فترى النسخة القديمة. لماذا؟
لأنك حدّثت العنوان في خادمك المعتمد (دليلك الرسميّ)، لكنّ المحلِّلات حول العالم ما زالت تحمل الجواب القديم في ذاكرتها حتى تنتهي صلاحيته. فمدّة الانتشار القصوى هي قيمة TTL التي ضبطتَها على سجلّاتك القديمة: إن كانت أربعا وعشرين ساعة، فقد يرى بعض الناس موقعك القديم طوال هذه المدّة. لذا حين تغيّر إعدادات DNS، اخفِض TTL قبل التغيير بيوم أو يومين (إلى بضع دقائق مثلًا)، فينتشر تحديثك الجديد بسرعة، ثم أعِده إلى قيمة أعلى بعد استقرار النقل.
ويمكنك أن ترى هذا العدّاد بعينك في أقلّ من دقيقة: اسأل عن نطاق مرّتين بينهما بضع ثوان، وانظر إلى قيمة TTL في الجواب. سألتُ عن نطاق هذا الموقع فجاء الجواب بـ135 ثانية، ثمّ سألتُ بعد اثنتي عشرة ثانية فجاء بـ123. فالقيمة ليست رقما ثابتا يُعاد عليك. هي عدّاد ينزل، فإذا انتهى سُئل الخادم المعتمد من جديد.
وللنفي ذاكرة كذلك، وهذا يفسّر أشيع شكوى في هذا الباب: تسجّل نطاقا جديدا أو تضيف سجلّا، ثمّ يظلّ المتصفّح يقول «تعذّر الوصول» وأنت ترى السجلّ أمامك في لوحة التحكّم. فالمحلِّل الذي سُئل عن الاسم قبل وجوده خزّن الجواب السالب (Negative Caching) كما يخزّن الموجب، ومدّة حفظه يحدّدها سجلّ SOA في النطاق نفسه لا المحلِّل الذي سألته.[6] والفرق العمليّ هنا يستحقّ الانتباه: خفض TTL قبل التغيير ينفع حين تعدّل سجلّا قائما، ولا ينفع في هذه الحالة بحال، إذ لم يكن ثمّة سجلّ لتخفض مدّته قبل أن يوجد. لا يبقى إلّا الانتظار، أو أن تجرّب الاسم من محلِّل آخر لم يُسأل عن هذا الاسم بعد.
وقد يخطر لك أن تُفرِغ ذاكرة جهازك، فتكتب ipconfig /flushdns على ويندوز أو ما يقابله على غيره. وهذا يمسح ما خزّنه جهازك أنت، ولا يمسّ ما خزّنه المحلِّل عند مزوّدك، وهو صاحب الجواب الذي يعنيك. ومن هنا تأتي تلك الحالة المحيّرة: يرى جارك الموقع وأنت لا تراه، لأنّ لكلّ منكما محلِّلا بذاكرة مختلفة. والذي في يدك فعلًا أن تسأل محلِّلا آخر مباشرةً، وهو ما تتيحه أدوات مثل dig وnslookup حين تحدّد لها الخادم.
ولأن DNS هو الخطوة الأولى في طريق أيّ طلب، فإن فشله يعني تعذّر الوصول كليا. حين يردّ النظام بأن الاسم غير موجود (NXDOMAIN) تظهر رسالة «تعذّر الوصول إلى الموقع»، حتى لو كان الخادم سليما. ولأنه نقطة مركزية يمرّ بها كل طلب، يُستعمل أحيانا للحجب: يكفي أن يردّ محلِّل بعنوان خاطئ أو فارغ ليُمنَع موقع عن منطقة كاملة. وهذا أحد أسباب لجوء الناس إلى المحلِّلات العامّة أو إلى تشفير الاستعلام، وهو ما يتناوله القسم التالي. وإن أردتَ أن ترى تغييرا فورًا على جهازك دون انتظار الانتشار، تستطيع مسح ذاكرة DNS المحلية (بأمر مثل ipconfig /flushdns في ويندوز)، لكنّ هذا يطهّر ذاكرتك أنت وحدك، لا ذاكرات بقية العالم.
وانضمّ إلى هذين ثالث أحدث: DNS عبر QUIC، ويُختصر DoQ. وقد مرّ بك QUIC في مقال «كيف يعمل الإنترنت» بروتوكولا يدمج فتح الاتصال والتشفير في مصافحة واحدة، والفائدة هنا هي نفسها: استعلام مشفّر بزمن بدء أقصر ممّا يكلّفه DoT.[7] وهو أقلّ الثلاثة انتشارا اليوم، وأنسبها للهواتف، فكلّ مصافحة فيها محسوبة.
أكثر من عناوين مواقع: سجلّات DNS
دليل النطاق ليس قائمة أسماء وأرقام فحسب. فملفّ كل نطاق (الـZone File) يحوي أنواعا من «السجلّات»، لكلّ وظيفة محدّدة، أشبه بملفّ كامل لمؤسّسة: عنوان للمقرّ، وآخر للبريد، وثالث للتحقّق من الهوية.[2] ويُكتب كل سجلّ سطرا بسيطا: اسم، فنوعُ السجل، فقيمته، ومعه مدّة صلاحيته (TTL). فالسطر example.com IN A 142.250.184.196 يقول ببساطة: «قيمة سجل A لهذا الاسم هي هذا العنوان». وأهمّ الأنواع:
- سجل A: الأساسيّ والأشيع، يربط اسم النطاق بعنوان IPv4 للخادم، مثل
example.com → 142.250.184.196. بدونه لا يجد المتصفّح موقعك. - سجل AAAA: يفعل ما يفعله سجل A لكن لعنوان IPv6 الأطول، وقد مرّ بك في مقال URL لماذا صار ضروريا مع نفاد عناوين IPv4.
- سجل CNAME: يربط اسما باسم آخر لا بعنوان IP، أشبه باسم مستعار. تجعل به
shop.yourdomain.comيشير إلى عنوان منصّة خارجية مثلyour-store.myshopify.com. - سجل MX: لا علاقة له بموقعك، بل يوجّه البريد. حين يُرسِل أحد رسالة إلى
[email protected]، يبحث خادمه عن سجل MX للنطاق ليعرف أيّ خادم بريد يستقبلها. به تستضيف موقعك في مكان وبريدك في آخر (كـGoogle Workspace). - سجل NS: يحدّد خوادم الأسماء المعتمدة للنطاق، أي «من يملك الإجابات». وهو نفسه ما تضبطه عند مُسجِّل نطاقك، وهو ما يدلّ خادمَ TLD على وجهتك في الخطوة الرابعة.
- سجل TXT: نصّ حرّ تعلّقه على نطاقك، أشهر استعمالاته إثبات الملكية (يطلب منك Google Search Console مثلًا وضع رمز في سجل TXT)، وحماية البريد عبر SPF وDKIM.
- سجل SOA: «بداية السلطة»، سجل واحد في كل نطاق يحمل بياناته الإدارية: خادمه الأساسيّ، وبريد المسؤول عنه، وأرقام إصدار الملفّ ومُهَل تحديثه. هو بطاقة هوية الـZone File.
- سجل PTR: العكس تمامًا، يترجم عنوان IP إلى اسم (يُسمّى DNS العكسيّ). تعتمد عليه خوادم البريد خاصة للتحقّق أن المُرسِل ليس مصدر رسائل مزعجة.
وللـCNAME قيد يصطدم به كلّ من ربط نطاقه بخدمة خارجية: لا يجوز أن يوضع على قمّة النطاق (Apex)، أي على example.com عاريا بلا نطاق فرعيّ. والسبب بنيويّ لا اعتباطيّ: القمّة تحمل أصلًا سجلّي SOA وNS، والمواصفة تمنع أن يجتمع CNAME مع أيّ سجلّ آخر على الاسم الواحد.[8] لذلك يصلح http://www.example.com أن يكون CNAME، ولا يصلح example.com، وتقدّم بعض خدمات DNS مخرجا خاصّا بها تسمّيه ALIAS أو ANAME، وهو يتصرّف كأنّه CNAME في القمّة، لكنّه يردّ على السائل بعنوان IP لا باسم آخر.
وثمّة سلوك قريب يفسّر لغزا يصادفه بعضهم: تكتب اسما فرعيّا لم يُسجَّل قطّ فيعمل. والسبب سجلّ بديل (Wildcard) يُكتب بنجمة، مثل *.example.com، ومعناه للمحلِّل: كلّ اسم فرعيّ لم أذكره صراحة فأجب عنه بهذا. سألتُ عن اسم فرعيّ عشوائيّ من نطاق هذا الموقع فلم يأتِ خطأ بأنّ الاسم غير موجود، وإنّما سجلُّ CNAME يشير إلى النطاق نفسه بمدّة أربع ساعات. فمن اعتمد على غياب الاسم دليلا على غياب الخدمة قد يُخطئ.
DNS أداة للتوزيع والتوسّع
إلى هنا بدا DNS كأنه يربط اسما بعنوان واحد، لكنّه يفعل أكثر من ذلك. يمكن لاسم واحد أن يحمل عناوين IP عدّة، فتوزَّع الطلبات عليها بالتناوب، وهو أبسط أشكال «موازنة الحِمل» التي تمنع خادما واحدا من الاختناق تحت ضغط الزوّار. وأبعد من ذلك، يستطيع الخادم المعتمد أن يردّ بعنوان مختلف بحسب موقع السائل الجغرافيّ (GeoDNS)، فيوجّه زائرا من الخليج إلى خادم قريب منه، وزائرا من أوروبا إلى آخر.
هذه الفكرة بعينها هي ما تقوم عليه شبكات توصيل المحتوى (CDN) التي لها مقال مستقلّ في السلسلة: يبقى الاسم الذي تكتبه واحدا، بينما يتغيّر العنوان الذي يردّه DNS ليكون أقرب خادم إليك جغرافيا، فتصل الصفحة أسرع. هكذا يتحوّل «دليل الهاتف» من جدول جامد إلى أداة توجيه ذكية تُوزّع حِمل الإنترنت وتقرّبه من الناس.
خصوصية الاستعلام: DoH وDoT
في تصميمه الأصليّ، يسافر استعلام DNS نصّا مكشوفا. هذا يعني أن مزوّد خدمتك، بل أيّ متنصّت على الطريق، يمكنه أن يرى كل اسم نطاق تزوره، حتى لو كان الموقع نفسه مشفّرا بـHTTPS. ولسدّ هذه الثغرة ظهر معيارَان يشفّران الاستعلام: «DNS عبر TLS» (DoT) الذي يجري على منفذ خاصّ (853)، و«DNS عبر HTTPS» (DoH) الذي يخفي الاستعلام داخل حركة HTTPS العادية على المنفذ 443 فلا يكاد يُميَّز عنها.[3]
تدعم المحلِّلات العامّة مثل 1.1.1.1 و8.8.8.8 هذين المعيارين، وصارت المتصفّحات الحديثة تفعّل DoH افتراضا في كثير من البلدان. المكسب خصوصيّة أكبر لك، والثمن أن إدارة الشبكة تفقد رؤية كانت تستعملها للحجب أو الرقابة، وهو جدل قائم بين الخصوصية والتحكّم.
وهنا سؤال يطرحه كثيرون: من يرى استعلاماتي إذن؟ حين تستعمل DoH أو DoT، تنتقل الرؤية من مزوّد خدمتك إلى المحلِّل الذي اخترته. فالخصوصية المطلقة وهم: ثمّة دائمًا طرف يحلّ أسماءك، والفرق أنك تختاره. أتثق بمزوّدك المحليّ، أم بشركة كبرى تَعِد بعدم الاحتفاظ بسجلّات استعلاماتك، أم بمحلِّل يصفّي المواقع الضارّة أو يحجب المحتوى غير اللائق للعائلات؟ اختيار المحلِّل قرار يوازن بين الخصوصية والسرعة والتصفية.
هل تثق بالجواب؟ DNSSEC
ثمّة مشكلة أخرى غير التنصّت: كيف تتأكّد أن الجواب الذي وصلك جاءك من المصدر الرسميّ ولم يُزوَّر في الطريق؟ في DNS الأصليّ لا ضمان، وهذا يفتح باب «تسميم الذاكرة المؤقّتة» (Cache Poisoning)، حيث يدسّ مهاجم عنوانا كاذبا فيوجّهك إلى خادم خبيث. الحلّ هو DNSSEC: امتدادات تُوقّع سجلّات DNS توقيعا تعمّيا يثبت أنها صادرة عن الخادم المعتمد ولم تُبدَّل.[5]
ويعمل بسلسلة ثقة تمتدّ من القمّة: الجذر يوقّع على مفاتيح النطاقات العليا، وهذه توقّع على مفاتيح النطاقات تحتها، حتى نطاقك. فإن صحّت السلسلة كلّها وثِق المحلِّل بالجواب، وإن انكسرت حلقة منها رفضه. لهذا يلزم أن يدعم نطاقُك وخادمُه المعتمد DNSSEC حتى تستفيد منه، وما زال انتشاره غير مكتمل.
انتبه إلى الفرق: DNSSEC يتحقّق من صحّة الجواب لكنه لا يخفيه (لا يشفّر)، بينما DoH وDoT يخفيان الاستعلام لكنهما لا يثبتان صحّة مصدره. هما يعالجان مشكلتين مختلفتين، ويكمّل أحدهما الآخر.
جرّبه بنفسك
كلّ ما وصفتُه تراه بعينك بأمر واحد. افتح الطرفية واكتب nslookup (يعمل على الأنظمة كلّها) متبوعا باسم نطاق، أو dig الأغنى تفصيلا على ماك ولينكس:
nslookup kutaibashikhani.com
dig kutaibashikhani.comفيظهر لك العنوان الذي تحوّل إليه الاسم، وأحيانا الخادم الذي أجاب وزمن الاستجابة. جرّب نطاقا تعرفه، ثمّ نطاقا ضخما كنطاق جوجل، ولاحظ كيف قد يعيد عناوين متعدّدة للاسم الواحد (توزيع الحِمل الذي سبق شرحه). هذا الأمر الصغير نافذة مباشرة على كلّ المسار الذي شرحتُه.
من الاسم إلى المحادثة
نظام DNS تحفة في اللامركزية: لا خادم واحد يعرف كل شيء، بل هرم يدلّ كلُّ مستواه على المستوى الأدقّ، والتخزين المؤقّت يجعل الاستعلام شبه فوريّ في معظم الأوقات. وكلّ هذا يجري في أجزاء من الثانية قبل أن تظهر الصفحة، فلا تكاد تلحظه إلا حين تبطئ أو حين تغيّر إعداداتك. وهذه اللامركزية بالذات هي ما سمح للنظام أن يكبر من بضعة آلاف من الأسماء سنة ثمانينيات القرن الماضي إلى مليارات الأسماء اليوم دون أن يُعاد بناؤه.
الآن صار متصفّحك يملك عنوان IP للخادم، فبقي أن يفتح معه قناة ويطلب الصفحة فعلًا. وهذا عمل بروتوكول الويب، موضوع المقال التالي: «HTTP وHTTPS: لغة الويب».
المصادر
- AWS: What is DNS? مسار الاستعلام: المحلِّل التكراريّ، وخادم الجذر، وخادم النطاق الأعلى، والخادم المعتمد، والتخزين المؤقّت.
- IETF: RFC 1035: Domain Names. الوثيقة المؤسِّسة لنظام DNS وأنواع سجلّاته (A، NS، CNAME، MX، TXT).
- IETF: RFC 8484: DNS Queries over HTTPS (DoH). تشفير استعلام DNS؛ ومعه DoT (RFC 7858) على المنفذ 853.
- Root Server Technical Operations: root-servers.org. خوادم الجذر الثلاثة عشر وتوزيعها بتقنية Anycast.
- ICANN: DNSSEC: What Is It and Why Is It Important? توقيع سجلّات DNS لمنع التزوير وتسميم الذاكرة المؤقّتة.
- IETF: RFC 2308: التخزين المؤقّت للأجوبة السالبة. أنّ الجواب السالب يُخزَّن مؤقّتًا كالموجب، وأنّ مدّته تُشتقّ من سجلّ SOA للنطاق.
- IETF: RFC 9250: DNS عبر QUIC. DoQ ثالث صور الاستعلام المشفّر بعد DoH وDoT.
- IETF: RFC 2181: توضيحات لمواصفة DNS، القسم 10.1. أنّ سجلّ CNAME لا يجتمع مع غيره على الاسم نفسه، وهو سبب امتناعه على قمّة النطاق.