مطوّر يكتشف أن مزوّد الإنترنت يعترض استعلامات DNS ويرد عليها بعنوان IP من عنده

نشر المطوّر Karthikey Hegde في 3 نوفمبر 2026 تدوينة يروي فيها كيف بحث عن سبب تعذّر فتح موقع من داخل container على جهازه، ليجد أن السبب عند مزوّد الإنترنت نفسه.

استعلم عن النطاق من أكثر من مزوّد DNS، منها Google وCloudflare، فأعادت كلها عنوان IP واحدًا. ثم أرسل الاستعلام نفسه إلى عنوان DoH الخاص بـ Cloudflare، وهو بروتوكول يرسل استعلامات الـ DNS مشفرة داخل HTTPS، فعاد إليه عنوان مختلف تمامًا. وحين بحث عن مالك العنوان الأول، وجد أنه مزوّد الإنترنت الذي يستخدمه.

ومعنى ذلك أن الاستعلامات غير المشفرة كانت تُعترض في الطريق ويُرد عليها، فلا يصل إليه رد النطاق الحقيقي، أيًّا كان مزوّد الـ DNS الذي يختاره.

وكثيرًا ما يُذكر DNSSEC بوصفه الحماية من هذا النوع من التلاعب، لكنه يعمل بطريقة مختلفة. فهو يتحقق من توقيع الرد ولا يشفّره، فيبقى الاستعلام والرد مقروءين لأي طرف في الطريق. وإذا فشل الرد المزوّر في التحقق، يعود للمستخدم خطأ SERVFAIL بدل العنوان الخاطئ.

كما أن أغلب النطاقات لا تستخدمه أصلًا. فبحسب إحصاء نوفمبر 2026 على موقع Defaults.Exposed، من 334,831,177 نطاقًا جرى فحصها، تملك 7.1% فقط سلسلة توقيع كاملة يمكن التحقق منها، و92.8% غير موقّعة من الأساس.

ولذلك فالذي يحمي الاستعلام نفسه هو تشفيره، عبر DoH أو DoT. غير أن التشفير لا يلغي الحاجة إلى الثقة، بل ينقلها من مزوّد الإنترنت إلى مزوّد الـ DNS الذي يستقبل الاستعلامات المشفرة.

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