محلل DNS خاص بك.
السجل الوحيد الذي لا يفكر أحد في نقله.

هناك جهازان مختلفان تماماً يختبئان خلف عبارة "خادم DNS الخاص بي"، وتبني كل الدروس التعليمية تقريباً الجهاز الخطأ. احسم هذا الأمر قبل أن تثبّت أي شيء، لأنه الفارق بين أداة خصوصية ووكيل لسياسة خصوصية طرف آخر.

المُمرِّر يأخذ استعلامك ويمرّره إلى محلل آخر — عادة Cloudflare أو Google أو Quad9 أو مزوّد خدمة الإنترنت لديك — ثم يخزّن مؤقتاً كل ما يعود. إنه بسيط وسريع، ويسلّم دفق استعلاماتك بأكمله لطرف ثالث واحد. كل دليل ينتهي بعبارة "والآن اضبط منبعك على 1.1.1.1" قد بنى واحداً من هذه.

المحلل العودي يقوم بالعمل بنفسه. للعثور على mail.example.com يسأل خادم جذر عمّن يدير .com، ثم يسأل خوادم .com عمّن يدير example.com، ثم يسأل خوادم أسماء example.com نفسها عن السجل. ثلاث أو أربع محادثات قصيرة مع ثلاث أو أربع جهات تشغيل مختلفة، لا يُخبَر أي منها بأي شيء عن الأخرى. ومع تفعيل تصغير QNAME، يذهب الأمر أبعد من ذلك: يُسأل الجذر فقط عن .com، وتُسأل خوادم .com فقط عن example.com. يُكشف الاسم الكامل لطرف واحد بالضبط — الطرف المُستضيف للاسم، وهو من كان سيستقبل اتصالك بعد ثلاثين جزءاً من الألف من الثانية على أي حال.

العمودان الأيمنان ليسا متنافسين — بل هما نصفا نفس البنية. يمتلك AdGuard Home المنفذ 53، ويطبّق قوائم الحظر، وينهي عمليات النقل المشفّرة؛ ويجلس Unbound خلفه على loopback ويقوم بالتحليل. لا يؤدي أي من النصفين عمل الآخر جيداً، والسلسلة كاملة تستهلك نحو مئة ميغابايت من RAM إجمالاً.

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

Unbound هو محلل عودي مُصادِق وذو ذاكرة مؤقتة من NLnet Labs. إنه مُحزَّم في كل مكان، وهو ما يشغّله جزء كبير من الإنترنت أصلاً، وهو يعمل عودياً من الصندوق مباشرة — عليك أن تبذل جهداً إضافياً كي تحوّله إلى مُمرِّر. ثبّته إلى جانب حزمة تلميحات الجذر كي يعرف مكان خوادم الجذر دون جلب قائمة من أي مكان:

apt update && apt install -y unbound dns-root-data
unbound -V | head -2

تُثبّت حزمة dns-root-data تلميحات الجذر في /usr/share/dns/root.hints ومرساة ثقة جذر DNSSEC في /usr/share/dns/root.key، وتُبقي كليهما محدَّثين عبر قناة الحزم العادية. هذه هي الطريقة المملة والصحيحة للحصول عليهما؛ أما تنزيل root.hints من رابط URL في مهمة cron فهي الطريقة التي تفشل صامتة في نهاية المطاف.

/etc/unbound/unbound.conf.d/nb-resolver.conf

server:
    # ---- Who may ask. Deny first, allow narrowly.
    interface: 127.0.0.1@5335
    interface: 10.8.0.1
    access-control: 0.0.0.0/0 refuse
    access-control: ::0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: 10.8.0.0/24 allow

    # ---- Privacy of the recursion itself.
    qname-minimisation: yes
    qname-minimisation-strict: no
    hide-identity: yes
    hide-version: yes
    rrset-roundrobin: yes

    # ---- DNSSEC. The anchor is maintained by the dns-root-data package.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    root-hints: "/usr/share/dns/root.hints"
    harden-dnssec-stripped: yes
    harden-glue: yes
    harden-below-nxdomain: yes
    harden-large-queries: yes
    harden-short-bufsize: yes
    aggressive-nsec: yes
    val-clean-additional: yes

    # ---- Do not be a reflector, even by accident.
    refuse-any: yes
    ratelimit: 1000
    ip-ratelimit: 200
    edns-buffer-size: 1232

    # ---- Cache. This is where the 4 GB actually earns its keep.
    msg-cache-size: 128m
    rrset-cache-size: 256m
    cache-min-ttl: 60
    cache-max-ttl: 86400
    prefetch: yes
    prefetch-key: yes
    serve-expired: yes
    serve-expired-ttl: 3600

    # ---- Never chase a name that has no business being on the internet.
    private-address: 10.0.0.0/8
    private-address: 172.16.0.0/12
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: fd00::/8
    private-address: fe80::/10

    num-threads: 2
    so-reuseport: yes
    verbosity: 0
    logfile: ""

remote-control:
    control-enable: yes
    control-interface: /run/unbound.ctl

أربعة من تلك الأسطر تقوم بالعمل الحقيقي وتستحق كل منها جملة.

• 01access-control: 0.0.0.0/0 refuse — الإجابة الافتراضية للإنترنت هي "لا". كل ما يأتي بعدها استثناء كتبته أنت عن قصد. هذا السطر الوحيد هو ما يوقف قصة التضخيم من الخطوة 02 حتى قبل أن يضطر جدار الحماية للتدخل.
• 02qname-minimisation: yes — يُسأل خوادم الجذر عن .com، لا عن اسم المضيف الكامل. RFC 9156، مفعّل افتراضياً في إصدارات Unbound الحالية، وهو سبب تسرّب المحلل العودي أقل مما يوحي به المخطط. أبقِ الوضع الصارم مُعطَّلاً: عدد صغير من النطاقات سيئة الإعداد لا يزال يتعطل تحته.
• 03refuse-any: yes — تُعيد استعلامات ANY أكبر إجابة ممكنة مقابل أصغر سؤال ممكن، وهو بالضبط ما يريده هجوم التضخيم. لا شيء مشروع يحتاج إليها.
• 04serve-expired: yes — حين يتعذّر الوصول إلى خادم مرجعي، سلّم الإجابة القديمة وحدّثها في الخلفية بدل الفشل. هذا هو الإعداد الذي يمنع انقطاعاً بعيداً من أن يبدو، لدى كل من في المنزل، وكأن الإنترنت معطّل.

لاحظ المستمعَين. loopback على المنفذ 5335 هو ما سيستخدمه AdGuard Home في الخطوة التالية؛ و10.8.0.1 هو عنوان النفق، كي تتمكن الأجهزة على VPN من استعلام Unbound مباشرة إن قررت تخطي طبقة التصفية. إذا لم تكن تشغّل WireGuard بعد، احذف سطر الواجهة الثاني هذا مؤقتاً — لن يبدأ Unbound بعنوان غير موجود على الخادم.

شغّله وأثبت أنه يعمل:

unbound-checkconf
systemctl restart unbound && systemctl enable unbound

apt install -y dnsutils
dig @127.0.0.1 -p 5335 nordbastion.com +short

# DNSSEC: the first must come back with the "ad" flag set,
# the second must FAIL — its signatures are deliberately broken.
dig @127.0.0.1 -p 5335 dnssec-tools.org +dnssec | grep -E 'flags:|status:'
dig @127.0.0.1 -p 5335 dnssec-failed.org  | grep 'status:'

علامة ad في الإجابة الأولى تعني أن Unbound تحقق من سلسلة التوقيعات من الجذر وحتى السجل وأنها صمدت. أما SERVFAIL في الإجابة الثانية فيعني أن التحقق رفض إجابة مُتلاعَباً بها بدل تمريرها إليك. إذا أعادت الثانية عنواناً بدلاً من ذلك، فالتحقق غير مفعّل ومرساة الثقة هي أول ما يجب فحصه.

محلل لا يستطيع أحد الوصول إليه غير مفيد، ومحلل يستطيع الجميع الوصول إليه هو نمط الفشل من الخطوة 02. هناك إجابتان جيدتان بالضبط، وينتهي الأمر بمعظم الناس إلى تشغيل كلتيهما — النفق في المنزل وعلى الحاسوب المحمول، وDNS المشفّر على الهاتف وعلى الشبكات التي يُصفّى فيها UDP.

الخيار أ — عبر WireGuard. الأفضل من الاثنين، وسبب استمرار هذا الدليل في الإشارة إلى دليل WireGuard. يبقى المنفذ 53 غير مرئي للإنترنت، والاستعلام نفسه لا يعبر أبداً شبكة غير موثوقة بأي شكل، ولا توجد شهادة يجب تجديدها. إذا كان VPS مخرج VPN الخاص بك أصلاً، فهذا سطر واحد في إعداد كل طرف:

# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1

دقيقة واحدة تعضّ الناس: على Linux، يضبط wg-quick ذلك العنوان عبر resolvconf أو systemd-resolved، وإذا لم يكن أي منهما مثبّتاً فإنه لا يفعل شيئاً بصمت بينما يعمل النفق بشكل مثالي. تحقق باستخدام resolvectl status أو بقراءة /etc/resolv.conf بعد رفع النفق — نفق يعمل مع محلل قديم لا يزال مُعدّاً هو بالضبط التسرب الذي يدور حوله هذا التمرين بأكمله.

الخيار ب — DNS-over-TLS وDNS-over-HTTPS. ضروري حين لا يمكن للجهاز أن يبقى على النفق دائماً. كلاهما يُصادَق عليه بشهادة، وهو ما يعني اسم مضيف: وجّه سجل A نحو VPS، ثم دع AdGuard Home يحمل الشهادة مباشرة أو ضعه خلف وكيل عكسي يُنهي TLS نيابة عنك أصلاً. المستمعان هما 853/tcp لـDoT و443/tcp لـDoH.

ufw allow 853/tcp                     # DNS-over-TLS
ufw allow 443/tcp                     # DNS-over-HTTPS
# 53/udp is still NOT open on the public interface. It never will be.
ufw status

امنح نقطة نهاية DoH مساراً لا يمكن تخمينه — يتيح لك AdGuard Home تقديمه تحت /dns-query/<random>، ومسار مختلف لكل شخص يعني أن الوصول يمكن إلغاؤه لشخص واحد في كل مرة دون تدوير أي شيء للجميع. إنه ليس توثيقاً بأي معنى قوي، لكنه يمنع مستمعاً عاماً من أن يكون محللاً مفتوحاً بخطوات إضافية.

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

إعداد أخير يستحق معرفته: المتصفح الذي يُفعَّل فيه DNS-over-HTTPS سيستخدم محلله الخاص ويتجاهل بصمت إعداد النظام، سواء أكان هناك نفق أم لا. يُشحَن كل من Firefox وChrome بهذا مفعّلاً افتراضياً في بعض المناطق. إما وجّه المتصفح أيضاً إلى نقطة نهايتك، أو أطفئ DoH فيه كي يتبع نظام التشغيل.

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

الاتصال لا يزال يحدث. بعد جزء من الألف من الثانية من عملية البحث، يفتح جهازك اتصال TCP على العنوان الذي تعلمه للتو. أي طرف يراقب خطك يرى ذلك العنوان. بالنسبة لموقع على عنوان IP خاص به، العنوان هو الموقع. DNS المشفّر يزيل السؤال؛ لكنه لا يزيل الإجابة.

مصافحة TLS تكشف اسم الموقع عادةً. يُرسَل Server Name Indication بشكل صريح غير مشفّر في بداية كل اتصال HTTPS تقريباً، لذا يقرأ المراقب السلبي اسم المضيف على أي حال. يُصلح Encrypted Client Hello هذا الأمر، لكنه منشور بشكل متفاوت — حيث يدعمه كل من المتصفح والموقع يُخفى الاسم، وحيث لا يدعمانه فلا يُخفى. لا تفترض أنه مفعّل.

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

يستطيع المزوّد رؤية الحزم، كالعادة. يعمل VPS على عتاد يملكه طرف آخر في مركز بيانات يملكه طرف آخر. لا يفحص NordBastion حركة مرور العملاء، ويصف تقرير الشفافية وإشعار أمر المراقبة السري (warrant canary) ما سيحدث إن طُلب منه ذلك — لكن التصريح المعماري الصادق هو أن الجهاز الذي تستأجره هو جهاز يستطيع طرف آخر الوصول إليه فيزيائياً. ما تغيّره الاستضافة الذاتية هو أنه لا يوجد سجل استعلامات على مستوى المنتج، ولا خط تحليلات، ولا سياسة خصوصية يمكن تعديلها؛ بل توجد فقط عملية تحمل ذاكرة مؤقتة في RAM، أعددتها أنت، في ولاية قضائية اخترتها عن قصد.

ما اشتريته فعلياً، وبدقة: أغنى مصدر وأرخصه للبيانات السلوكية عنك لم يعد يُجمَع من قِبل طرف يقوم نموذج عمله على جمعه. هذا ادعاء ضيق، لكنه ادعاء حقيقي. لا شيء في هذه الصفحة بديل عن Tor حين يستدعي نموذج التهديد استخدام Tor — ولذلك، فدليل خدمة onion أدناه هو القراءة الصادقة التالية.