Lakhasly

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

يوجد تسلسل هرمي لأسماء DNS للأسماء بهذا النموذج، مع المناطق والخوادم المعتمدة. إذا تم تكوين كل هذا - وهو ما لا يحدث غالبًا، خاصة بالنسبة لمحطات عمل المستخدم - فإن طلب سجل PTR المطابق لما ورد أعلاه يجب أن يُرجع اسم مضيف DNS. في الحالة أعلاه، الاسمluc.edu تم إرجاعه (على الأقل اعتبارًا من 2018).
سجلات PTR هي سجلات DNS الوحيدة التي لها تسلسل هرمي منفصل تمامًا؛ تتلاءم أنواع DNS الأخرى مع التسلسل الهرمي "القياسي". على سبيل المثال، يدعم DNS أيضًا سجلات MX أو Mail eXchange، التي تهدف إلى تعيين اسم المجال (والذي قد لا يتوافق مع أي اسم مضيف، وإذا كان كذلك، فمن المرجح أن يتوافق مع اسم خادم الويب) إلى اسم المضيف للخادم الذي يقبل البريد الإلكتروني نيابة عن المجال. في الواقع، يسمح هذا لاسم نطاق المؤسسة، على سبيل المثال، luc.edu، بتمثيل خادم الويب، وخادم البريد الإلكتروني على عنوان IP مختلف. يمكن أن تمثل سجلات MX أيضًا مجموعة من عناوين IP التي تقبل البريد الإلكتروني.

لقد دعم DNS منذ البداية سجلات TXT للسلاسل النصية العشوائية. إطار سياسة مرسل البريد الإلكتروني (آر إف سي 7208) تم تطويره ليجعل من الصعب على مرسلي البريد الإلكتروني التظاهر بأنهم نطاق ليسوا كذلك؛ يتضمن ذلك إدراج ما يسمى بسجلات SPF كسجلات DNS TXT.
على سبيل المثال، قد يؤدي استعلام DNS لسجلات TXT لـ google.com (وليس gmail.com!) إلى (2018)

يهتم نظام SPF بالسجل الثاني فقط؛ يحدد "v=spf1" إصدار SPF. يخبرنا هذا السجل الثاني بالبحث عن _spf.google.com. يعود هذا البحث

البحث عن _netblocks.google.com ثم يعود

إذا كان المضيف يتصل بخادم بريد إلكتروني، ويعلن أنه يقوم بتسليم البريد من شخص ما على google.com، فيجب أن تظهر قائمة البريد الإلكتروني للمضيف في القائمة أعلاه، أو في إحدى القوائم الأخرى المضمنة. إذا لم يكن الأمر كذلك، فهناك احتمال كبير أن يمثل البريد الإلكتروني بريدًا عشوائيًا.
كل سجل DNS (أو "سجل المورد") له اسم (على سبيل المثال cs.luc.edu) ونوع (على سبيل المثال A أو AAAA أو NS أو MX). بالنظر إلى الاسم والنوع، تُعرف مجموعة سجلات الموارد المطابقة باسم RRset لهذا الاسم والنوع (من الناحية الفنية هناك أيضًا "فئة"، ولكن فئة جميع سجلات DNS التي نهتم بها هي IN، للإنترنت) . عندما يستجيب خادم الأسماء لاستعلام DNS، فإن ما يتم إرجاعه (في قسم الإجابة) هو دائمًا مجموعة RRset بأكملها: مجموعة RRset لجميع سجلات الموارد التي تطابق الاسم والنوع الموجود في الاستعلام الأصلي.
في كثير من الحالات، تحتوي مجموعات RRsets على عضو واحد، لأن العديد من المضيفين لديهم عنوان IPv4 واحد. ومع ذلك، هذا ليس عالميًا. لقد رأينا أعلاه مثالًا لاسم DNS واحد يحتوي على سجلات A متعددة عند استخدام نظام DNS الدائري. قد يحتوي اسم DNS الفردي أيضًا على سجلات A منفصلة لعناوين IPv4 العامة والخاصة للمضيف. غالبًا ما تحتوي سجلات TXT أيضًا على إدخالات متعددة في مجموعة RRset واحدة. في مثال TXT أعلاه، رأينا أنه تم تخزين بيانات SPF في سجلات DNS TXT، ولكن هناك بروتوكولات أخرى إلى جانب SPF تستخدم سجلات TXT أيضًا؛ الامثله تشملDMARC والتحقق من موقع جوجل
_. أخيرًا، ربما تحتوي معظم مجموعات RR الخاصة بسجل MX (تبادل البريد) على إدخالات متعددة، حيث تفضل المؤسسات غالبًا، من أجل التكرار، أن يكون لديها أكثر من خادم واحد يمكنه تلقي البريد الإلكتروني.