الخلاصة

  • قلب IQUERY ترتيب رسالة DNS المعتاد: قدّم resource record في Answer وطلب من الخادم إعادة owner names المطابقة في Question.
  • اتبعت سلطة DNS الأسماء وحدود zones، لا قيم RDATA الاعتباطية؛ لذلك أمكن أن تكون القائمة صحيحة محلياً من دون أن تثبت اكتمالها في namespace الموزع.
  • جعل المسح الشامل والفهارس الموازية ومشكلات cache والردود الضخمة وكشف البيانات وعداً ضعيفاً ومكلفاً، بينما حوّل PTR تحت IN-ADDR.ARPA عكس العنوان إلى استعلام اسم عادي يقبل التفويض.

سبقت الإجابة السؤال داخل الرسالة

يضع DNS query العادي QNAME وQTYPE وQCLASS في قسم Question، ثم يضيف الخادم records المناسبة إلى Answer. بدأ IQUERY بصورة معكوسة: ظل Question فارغاً، فيما حمل Answer شيئاً مثل A IN 10.1.0.52. كان العميل يسأل عن كل اسم تصبح هذه المعلومة جواباً له.

خصّص RFC 1035 للعملية opcode 1. لم تكن قيمة owner name ولا TTL في RR المقدّم ذات دلالة، وكان ممكناً استعمال root label القصير مكان الاسم المجهول. يضع الخادم في response صفراً أو اسماً واحداً أو عدة مجموعات من QNAME وQTYPE وQCLASS داخل Question، ويعدّل record الأصلي ليتوافق مع أول نتيجة.

على مستوى wire format بدا التناظر أنيقاً. انتقل الاستعلام القياسي من اسم إلى مورد، فيما انتقل inverse query من مورد إلى أسماء. احتوت البنية نفسها الاتجاهين.

غير أن البنية الموزعة خلف الرسالة لم تكن متناظرة. يستطيع resolver يعرف اسماً أن يتبع referrals من root حتى zone المسؤولة عنه. أما address أو MX target أو string داخل RR آخر فلا يحمل مساراً مماثلاً إلى كل zone قد تنشر القيمة نفسها. كان على العميل اختيار خادم قبل أن يعرف إن كان يملك المجموعة الملائمة.

ظهر الحد في مواصفات عام 1983

ذكر RFC 882 أن domain system لا يستطيع ضمان اكتمال inverse queries أو فرادتها، لأنه منظم وفق domain name لا host address أو resource type آخر. إذا أراد resolver ضماناً فعليه استعمال خادم معروف بامتلاك البيانات المناسبة، أو سؤال كل الخوادم ضمن domain موضع الاهتمام.

لم يكن هذا اعتذاراً عن بطء الحواسيب القديمة. كان غياباً لمسار يعثر على authority بواسطة مفتاح البحث. في استعلام الاسم يكون delegation جزءاً من DNS نفسه؛ يدل parent على الجهة التالية. لا تملك القيمة الاعتباطية parent أو referral أو حداً طبيعياً يضيّق فضاء البحث تدريجياً.

لذلك عالج RFC 883 inverse query وفق البيئة. أمكن لمؤسسة أن توجه resolvers إلى خوادم تحمل نسخة واسعة من zones الخاصة بها. أفاد ذلك في الإدارة والتشخيص، لكنه لم يمنح قاعدة محلية سلطة على namespace كله.

قد تكون ثلاث علاقات أعادها الخادم صحيحة تماماً، مع بقاء علاقة رابعة في zone لم يحملها قط. صحة المرئي لا تعني اكتماله، ولا تمنح حق نفي الغائب.

اقتصر العقد الحقيقي على ما عرفه الخادم المختار

قيّد RFC 1035 الرد بالأسماء التي تملك RR والتي يعرفها name server. لا تعرف آلة واحدة domain space بأكمله، ومن ثم لا يجوز افتراض اكتمال النتيجة. حصر النص IQUERY أساساً في database management وdebugging، ورفض اعتباره طريقة عامة لتحويل host address إلى host name.

عنت قائمة فارغة أن الخادم المختار لم يجد تطابقاً في corpus المرئي لديه. لم تعنِ أن التطابق غير موجود عالمياً. أثبتت نتيجة واحدة علاقة مرئية لا فرادة. وقد تعكس آلاف النتائج فقط authoritative zones محلية أو cache عارضاً أو RR types بُني لها index.

للجواب السلبي العادي في DNS نطاق أوضح. يقود الاسم المطلوب إلى authoritative zone، وفيها يستطيع الخادم الحديث عن وجود الاسم. لم يحدد IQUERY مجموعة «كل records التي تحمل هذه القيمة». ولإثبات الغياب كان يلزم استبعاد كل zone يمكن أن تظهر فيها القيمة.

لذلك لا تستمد قائمة البحث قوتها من صحة rows وحدها. يلزم تعريف universe الذي فُحص، ومن يتحكم فيه، ووقت المشاهدة، وطريقة اكتشاف الأجزاء التي لم تُفحص. عندما تضيع هذه provenance تبدو القائمة المرتبة أوسع دلالة مما تسمح به الأدلة.

أنشأ الوصول العكسي قاعدة ثانية إلى جانب الأولى

تنظم name servers بيانات RR عادة تحت owner names لأن queries القياسية تبدأ بـQNAME. يحتاج البحث السريع داخل RDATA إلى طريق وصول ثانوي.

وصف RFC 883 inversion tables منفصلة بحسب zone والمفتاح، وقد يفرض تحديث zone إعادة بنائها. قدم RFC 1035 خيارين: exhaustive search للقاعدة، أو separate database مفهرسة بقيم القاعدة الرئيسية. يدفع المسح كلفة CPU مع كل request، فيما يدفع index كلفة memory والتزامن والتعقيد باستمرار.

اختلفت المقارنة أيضاً بحسب RR type. قد تحتوي RDATA على address أو domain name أو character string أو بنية مركبة. أوصى RFC 1035 بمقارنة لا تميّز case عندما يكون ذلك ممكناً، لكنه أقر بأن الخادم قد يخزن octets من غير أن يعرف أنها نص. لم يكن «اعثر على هذه القيمة» عملية bytes موحدة.

توزعت الحوافز بصورة غير متوازنة. أرسل requester قيمة قصيرة، ودفع operator ثمن index والمسح وتجميع reply ونقله. لم يثبت query منفعة لـzone، ولم يتضمن حد تفويض طبيعي لعدد النتائج.

نشر DNS records منفردة لأغراض resolution لا يساوي التعهد بخدمة تحليل اعتباطية لكل محتواها. أضاف IQUERY السطح الثاني إلى البنية التي كانت مسؤولة أصلاً عن البيانات التشغيلية.

كرر cache المشهد ولم يوسّع سلطته

يتوسع DNS بإعادة استعمال RRsets حتى انتهاء TTL. لم تلائم نتائج IQUERY هذا الأسلوب. حذر RFC 1035 من حفظها بالطريقة نفسها التي تحفظ بها answers العادية.

قد يملك multihomed host عدة address RR من النوع نفسه. العثور على اسمه بواسطة عنوان واحد لا يكشف بالضرورة RRset كاملاً. إذا حفظ cache العلاقة المستخرجة كأنها جواب عادي تحت QNAME المعاد بناؤه، تحولت عينة اختيرت بالقيمة إلى مجموعة تبدو كاملة وفق الاسم.

يضيع corpus الأصلي أيضاً. ربما عكست response عدداً من zones وبعض cache على آلة بعينها. بعد نسخها، يرى المستهلك data ولا يرى الأجزاء التي لم تُسأل قط. يجعل الانتشار الوصول أرخص، لكنه لا يزيد نطاق البرهان.

في query عادي تتوافق lookup key وdelegation وauthority وcache key وTTL حول الاسم. أعاد IQUERY استخدام envelope وفك هذا التوافق. كان على كل تحسين أن يحمل قيداً يسهل نسيانه: هذه فقط معرفة هذا الخادم في تلك اللحظة.

منح PTR المفتاح العكسي اسماً قابلاً للتفويض

لم ينجح reverse mapping للعناوين لأن العالم أنشأ محرك بحث أفضل للقيم. يصف RFC 1034 نطاق IN-ADDR.ARPA، حيث توضع octets عنوان IPv4 بترتيب معكوس كـlabels تحت domain خاص، ويشير PTR عند owner name الناتج إلى domain name آخر.

يبني resolver لعنوان 10.1.0.52 اسماً متوقعاً في reverse tree ويرسل query قياسياً. يمكن تفويض فروع الشجرة، والعثور على authoritative servers، وحفظ RRset وفق TTL عادي، وفهم الجواب السلبي داخل zone معلومة.

كانت indirection هي الإصلاح المعماري. لا يعد PTR بأن لكل عنوان record، أو بأن الاسم وحيد، أو بأن الاسم يعادل توثيق آلة. إنه يفعل شيئاً أضيق: يضع الادعاء العكسي تحت owner name يعرف DNS كيف يجد المسؤول عنه.

طلب IQUERY من النظام اكتشاف index مجهول انطلاقاً من القيمة. يطلب PTR من المسؤول عن reverse space نشر علاقة صريحة في اسم معروف. يتحول البحث المفتوح إلى قراءة مفوضة.

احتاج العميل الصادق إلى الاكتمال، أما الإساءة فلم تحتجه

في 2002 أعلن RFC 3425 IQUERY obsolete بالكامل. لم يُنفذ على نطاق عام، وكثيراً ما أغلق operators دعماً قديماً له. ذكر المستند bugs في code نادر الاستعمال، وحمل database، وكشف كتل كبيرة من names.

كان لبعض القيم عدد هائل من التطابقات. يمكن لاستعلام عن كل domains المفوضة إلى nameserver لدى مزود كبير أن يعيد عشرات الآلاف من tuples وmegabytes من data. أطلق request صغير حساباً ونقلاً غير متناسبين، صالحين لـdenial of service.

جمعت inverse MX queries أسماء كثيرة تستخدم mail infrastructure واحدة. كون كل RR متاحاً بصورة منفردة لا يعني أن operator عرض catalogue جماعياً بأي محور. خفّض IQUERY كلفة aggregation على الطالب ونقل جزءاً منها إلى server.

احتاج المستخدم المشروع إلى قائمة كاملة ولم يستطع الحصول عليها. لم يحتج المسيء إلى ذلك؛ كان استهلاك CPU أو memory أو bandwidth، أو انتزاع مجموعة محلية، كافياً. لم تقلل هشاشة الدليل الخطر التشغيلي.

حفظ التقاعد الدائم معنى opcode

لم يعِد RFC 3425 تخصيص opcode 1 لمعنى جديد. حل محل القسم المعني من RFC 1035، ووسم IQUERY بأنه obsolete، وأوصى برد Not Implemented، وطلب إبقاء الرقم retired نهائياً.

كان من شأن إعادة الاستعمال أن تجعل software قديماً يفسر traffic جديداً وفق الدلالة المهجورة. لا يكون الرقم المتقاعد هدراً بالضرورة؛ فهو يحفظ تاريخ protocol بلا التباس وينهي توقع الخدمة من دون صنع collision جديدة.

أشار المستند أيضاً إلى عدم وجود clients معروفين يعتمدون IQUERY لخدمة ذات معنى، وإلى أن PTR تحت IN-ADDR.ARPA أدى reverse mapping الشائع سنوات طويلة. احترم الإلغاء الاعتماد الفعلي بدلاً من قطع خدمة عامة حية.

أظهر DNSSEC صعوبة البرهان بصورة أوضح. رأى RFC 3425 أن تأمين IQUERY responses شديد الصعوبة من دون digital signing لحظة إنشاء الجواب. تصادق signed zone على named RRsets وعلى negative proofs داخل بنية أسماء. أما البحث الاعتباطي فعليه أيضاً إثبات أنه لم يسقط تطابقاً من universe لم يحدده IQUERY عالمياً.

بقي الخادم شاهداً ولم يصبح namespace كله

قد يكون DNS server مشاركاً حقيقياً وauthoritative لعدد من zones ويحمل records دقيقة. يجعله ذلك شاهداً جيداً ضمن نطاق محدد. امتلاك نسخة قابلة للبحث لا يحوله إلى principal لكل الأسماء الخارجية التي تشترك في القيمة.

تفصل ملاحظات Lu Heng بين المشاركة وauthorization، وبين إدارة registry والسلطة على الشيء الموصوف. يعرض IQUERY الحد نفسه داخل protocol. تتيح visibility وصف المرئي، ولا تمنح سلطة نفي zones الغائبة.

لم يكن الإصلاح catalogue مركزياً أكبر. احتفظ DNS بطبقة مشتركة صغيرة: names وdelegations وRR types وTTL وعلاقات عكسية منشورة صراحة. يعلن كل مشارك داخل zone محدودة، ويتبع resolver قواعد مشتركة من غير منح وسيط واحد صفة العارف بكل شيء.

حدود الأدلة

تثبت RFCs الخمسة صيغة الرسالة والحدود المعروفة وطريق PTR والقرار المعياري بالتقاعد. لا تقيس traffic opcode 1 الحالي، ولا تحصي كل implementations التاريخية، ولا تستبعد أدوات تشخيص خاصة.

NOTIMP هو الرد المتوقع، لا دليل على أن server لم يحلل request مطلقاً. قد ينتج timeout عن filtering أو loss. تثبت response إيجابية معالجة محلية، لا اكتمالاً عالمياً.

ولا يشكل PTR شهادة هوية. قد تغيب forward وreverse data أو تختلف أو تتعدد. ميزته هنا هي إمكان تحديد المسؤول عن الادعاء، لا جعل كل ادعاء منشور صحيحاً تلقائياً.

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

المصادر