بر اساس گزارش XDA Developers، بسیاری از کاربران Pi-hole آن را به‌عنوان ابزاری «تنظیم کن و فراموش کن» برای فیلتر DNS در شبکه خانگی می‌شناسند؛ اما یک نکته مهم می‌تواند بخشی از دستگاه‌ها را از این فیلتر عبور دهد. داشبورد Pi-hole تنها پرس‌وجوهایی را می‌شمارد که به آن می‌رسند؛ بنابراین اگر دستگاهی درخواست DNS خود را به سرور دیگری بفرستد، Pi-hole هرگز آن را نمی‌بیند.
IPv6 چگونه DNS دیگری به دستگاه‌ها می‌دهد؟
در یک راه‌اندازی معمول، همه‌چیز روی IPv4 انجام می‌شود: سرور DHCP روتر به هر دستگاه نشانی، دروازه و مهم‌تر از همه نشانی DNS را می‌دهد که به Pi-hole اشاره می‌کند. این روش تا زمانی کار می‌کند که DHCP تنها راه دریافت تنظیمات DNS توسط دستگاه‌ها باشد. اما فعال بودن IPv6 می‌تواند این معادله را به هم بزند.
وقتی IPv6 روشن است، دستگاه‌ها با استفاده از پیام‌های اعلان روتر (Router Advertisements) خود را پیکربندی می‌کنند؛ پیام‌هایی که روتر برای اعلام پیشوند شبکه می‌فرستد. روتر می‌تواند با گزینه‌ای به نام RDNSS یک سرور DNS را در همین پیام‌ها قرار دهد، آن را از طریق DHCPv6 تحویل دهد یا هر دو کار را انجام دهد. بسیاری از روترهای مصرفی به‌صورت پیش‌فرض خودشان را تبلیغ می‌کنند، اغلب با یک نشانی link-local که با fe80 شروع می‌شود.
در این حالت هر دستگاه می‌تواند دو resolver داشته باشد: یکی Pi-hole روی IPv4 و دیگری روتر روی IPv6. مشکل اینجاست که هیچ چیزی به دستگاه نمی‌گوید کدام مرجع است و انتخاب بین آن‌ها تا حد زیادی به سیستم‌عامل بستگی دارد. پرس‌وجوهایی که به روتر می‌روند از هدایت‌کننده داخلی (forwarder) آن و سپس مسیر بالادست (upstream) مورد استفاده عبور می‌کنند، بدون هیچ فیلتری در مسیر. Pi-hole خودش IPv6 را بدون مشکل مدیریت می‌کند؛ مسئله مسیری است که پرس‌وجو طی می‌کند.
چرا فقط برخی دستگاه‌ها از فیلتر عبور می‌کنند؟
تشخیص این نشت DNS دشوار است، زیرا دستگاه‌ها تنظیمات DNS مربوط به IPv6 را به شکل‌های متفاوتی دریافت می‌کنند. اندروید مدت‌هاست برای سرورهای DNS خود در IPv6 به RDNSS تکیه می‌کند و نه DHCPv6. ویندوز سال‌ها به DHCPv6 تکیه داشت، با یک به‌روزرسانی ویندوز ۱۰ پشتیبانی از RDNSS را دریافت کرد، اما هنوز وقتی هر دو را دریافت کند سرور تأمین‌شده از DHCPv6 را ترجیح می‌دهد. پلتفرم‌های اپل و توزیع‌های لینوکس هرکدام رفتار خودشان را دارند؛ بنابراین بسته به دستگاه‌های موجود، این موضوع می‌تواند کاملاً پنهان بماند.
تنظیمات IPv6 روتر هم تعیین می‌کند کدام دستگاه‌ها نشت کنند. برای نمونه، TP-Link Archer چهار حالت دارد: ND Proxy، DHCPv6، SLAAC+Stateless DHCP و SLAAC+RDNSS. در حالتی که DNS فقط از طریق stateless DHCPv6 ارائه می‌شود، گوشی‌های اندروید ممکن است هرگز resolver IPv6 را دریافت نکنند و روی Pi-hole بمانند، در حالی که ماشین‌های ویندوز resolver روتر را برمی‌دارند. در حالتی که از RDNSS استفاده می‌شود، resolver روتر به گوشی‌ها هم داده می‌شود.
اگر همه دستگاه‌ها Pi-hole را دور بزنند، داشبورد خلوت می‌شود و کاربر سریع متوجه می‌شود. اما وقتی فقط برخی دستگاه‌ها چنین رفتاری دارند، همان‌طور که در بیشتر نشت‌های جزئی دیده می‌شود، نمودار ظاهر سالم خود را حفظ می‌کند و همین موضوع می‌تواند کاربر را غافل کند.
چگونه نشت را شناسایی و رفع کنیم؟
برای بررسی، از نمای Clients در Pi-hole شروع کنید و آن را با دستگاه‌هایی که می‌دانید در شبکه حضور دارند مقایسه کنید. اگر چیزی را مفقود دیدید، خود دستگاه را بررسی کنید. اجرای ipconfig /all در ویندوز، scutil --dns در macOS یا resolvectl status در لینوکس فهرست سرورهای DNS در حال استفاده را نشان می‌دهد. اگر در کنار نشانی Pi-hole یک نشانی fe80 یا resolver IPv6 مربوط به ISP دیدید، عامل نشت را پیدا کرده‌اید.
- به Pi-hole یک نشانی پایدار IPv6 بدهید و کاری کنید روتر همان را تبلیغ کند.
- اگر از هیچ سرویس IPv6 استفاده نمی‌کنید، IPv6 را در سطح روتر خاموش کنید.
- پس از تغییر تنظیمات، دوباره نمای Clients و تنظیمات DNS دستگاه‌ها را بررسی کنید.
راه‌های دیگر دور زدن Pi-hole
IPv6 تنها راه نفوذ به فیلتر یک Pi-hole مبتنی بر IPv4 نیست. قابلیت‌هایی مانند DNS-over-HTTPS هم می‌توانند از فیلتر عبور کنند، هرچند برخی پیاده‌سازی‌ها وجود مسدودسازی را بررسی می‌کنند و فایرفاکس در این زمینه نسبتاً خوب عمل می‌کند. Pi-hole همچنین دامنه‌هایی را که اپل برای تشخیص امکان اجرای iCloud Private Relay استفاده می‌کند مسدود می‌کند، بنابراین این مسیر هم ممکن نیست. برخی دستگاه‌ها نیز resolverهای عمومی را به‌صورت سخت‌کدشده (hardcoded) در خود دارند که کار را دشوارتر می‌کند.