आपके devices जो भी domain देखते हैं, वह किसी और की file में एक timestamped लाइन बन जाता है — आपके ISP की, या एक मुफ़्त public resolver की। उस file को अपनी खुद की मशीन पर लाने के छह चरण: root से resolve करता Unbound, आगे filtering करता AdGuard Home, एक असली certificate पर encrypted DNS, और एक port 53 जो कभी internet के सामने नहीं आता। यह box $3.90 प्रति माह का है। Debian 12 पर tested.
स्वरूप
Recursive, forwarding नहीं
बंद करें
Port 53, इसके खुलने से पहले
Resolve करें
Unbound, validate करते हुए
Filter करें
AdGuard Home, DoH, DoT
Reach करें
पहले tunnel, फिर clients
सत्यापित करें
लीक, DNSSEC, uptime
disk को encrypt करें, traffic को tunnel करें, Monero में भुगतान करें, बिना किसी email के sign up करें — और फिर laptop को छोड़ दें कि वह एक ऐसे resolver से, जिसके बारे में आपने कभी सोचा ही नहीं, हर hostname को, जिसे वह छूता है, एक-एक करके, खुलेआम, पूरे दिन translate करवाए। name lookup वह हिस्सा है जिसे लोग सबसे आख़िर में सख़्त करते हैं, और यही वह हिस्सा है जो इस बात का सबसे साफ़ रिकॉर्ड बनाता है कि कोई असल में क्या करता है।
यह ठीक-ठीक समझना ज़रूरी है कि उस रिकॉर्ड में क्या होता है, क्योंकि "DNS आपकी browsing लीक करता है" बात सच भी है और सतही भी। एक query log timestamps के साथ domain names की एक सूची है, जो पूछने वाले IP address से जुड़ी होती है। यह वे पन्ने नहीं हैं जो आप पढ़ते हैं, और आमतौर पर यह ठीक-ठीक URL भी नहीं है। यह इससे कुछ ज़्यादा शांत और, profiling के लिए, बेहतर चीज़ है: एक ज़िंदगी की बनावट। बैंक। नियोक्ता। हर चार मिनट में check-in करने वाला dating app। रात 02:00 बजे एक बार देखी गई medical site। वे तीन domains जो हमेशा साथ ही दिखते हैं क्योंकि वे एक ही messaging client के हैं। जब index इतनी अच्छी हो तो किसी को content की ज़रूरत ही नहीं पड़ती।
चार पक्ष उस index को रख सकते हैं, और self-hosting इसे पहले दो से चौथे पक्ष तक ले जाती है:
| सेटअप | आपकी हर query कौन देखता है | wire पर क्या दिखता है | गुमनामी सेट |
|---|---|---|---|
| ISP resolver, plaintext (डिफ़ॉल्ट) | आपका ISP, नाम और account से | रास्ते में मौजूद किसी को भी, सब कुछ | उनके subscribers |
| सार्वजनिक resolver, encrypted (DoH/DoT) | वह एक कंपनी, आपके IP से बंधी हुई | destination के अलावा कुछ नहीं | लाखों |
| आपका अपना resolver, upstream पर forward करता हुआ | आपने जो upstream चुना — जस का तस | destination के अलावा कुछ नहीं | एक |
| आपका अपना resolver, root से recurse करता हुआ | कोई नहीं — हर zone सिर्फ़ अपने ही नाम देखता है | destination के अलावा कुछ नहीं | एक, ऐसे IP पर जो आप नहीं हैं |
तीसरी row वह row है जो लोगों को फंसाती है। अपने ही server पर एक resolver install करना और फिर उसे सब कुछ 1.1.1.1 पर forward करने को कहना ठीक एक चीज़ बदलता है: अब आपकी queries एक अलग IP address से Cloudflare तक पहुंचती हैं। log अब भी मौजूद है, यह अब भी किसी और का है, और आपने बदले में कुछ भी पाए बिना बनाए रखने के लिए एक मशीन जोड़ ली है।
आख़िरी column ईमानदार कीमत है, और यह गाइड इस पर दो बार लौटती है। एक घर द्वारा इस्तेमाल किया गया resolver एक ऐसा resolver है जिसकी queries साफ़ तौर पर उसी घर की होती हैं। यह सौदा लेने लायक क्या बनाता है, यह है कि पूछने वाला IP एक किराए का Nordic server है जिसके पीछे कोई पहचान दस्तावेज़ नहीं है — न किसी subscriber नाम वाली home line, न किसी card रखने वाला hyperscaler account। गुमनामी सेट सिकुड़ता है; जो असल में टूटता है वह है किसी व्यक्ति से जुड़ने वाला link।
"मेरा अपना DNS server" वाक्यांश के पीछे दो बिल्कुल अलग मशीनें छिपी होती हैं, और लगभग हर tutorial ग़लत वाली बना देता है। कुछ भी install करने से पहले यह तय कर लें, क्योंकि यही फ़र्क है एक privacy tool और किसी और की privacy policy के लिए एक proxy के बीच।
एक forwarder आपकी query लेता है और उसे किसी और resolver को भेज देता है — आमतौर पर Cloudflare, Google, Quad9 या आपका ISP — फिर जो कुछ वापस आता है उसे cache कर लेता है। यह सरल है, तेज़ है, और आपकी पूरी query stream एक अकेले तीसरे पक्ष को सौंप देता है। हर वह guide जो "अब अपना upstream 1.1.1.1 पर सेट करें" पर ख़त्म होती है, उसने इनमें से एक ही बनाया है।
एक recursive resolver यह काम खुद करता है। mail.example.com को ढूंढने के लिए यह एक root server से पूछता है कि .com कौन चलाता है, फिर .com servers से पूछता है कि example.com कौन चलाता है, फिर record के लिए example.com के अपने nameservers से पूछता है। तीन या चार अलग-अलग operators के साथ तीन या चार छोटी बातचीत, जिनमें से किसी को भी बाक़ी के बारे में कुछ नहीं बताया जाता। QNAME minimisation चालू होने पर यह और आगे जाता है: root से सिर्फ़ .com के बारे में पूछा जाता है, और .com servers से सिर्फ़ example.com के बारे में। पूरा नाम ठीक एक पक्ष को पता चलता है — वह जो उस नाम को host करता है, जिसे वैसे भी तीस मिलीसेकंड बाद आपका connection मिलने वाला था।
| विशेषता | Unbound, recursive वाला | कोई भी forwarder | अकेला AdGuard Home |
|---|---|---|---|
| एक ही पक्ष हर query देखता है | नहीं | हां | हां — इसका upstream |
| DNSSEC locally validate होता है | हां | upstream से trust किया गया | upstream से trust किया गया |
| Blocklists और per-device rules | सिर्फ़ local zones के ज़रिए | daemon पर निर्भर | हां, एक web interface के साथ |
| clients के लिए DoH / DoT listeners | DoT natively, DoH एक proxy के ज़रिए | daemon पर निर्भर | दोनों, built in |
| Cold-start देरी | 3–4 राउंड ट्रिप | 1 राउंड ट्रिप | 1 राउंड ट्रिप |
| सही जवाब | stack का privacy वाला आधा हिस्सा | सिर्फ़ एक जानबूझकर लिए गए fallback के तौर पर | आगे वाला, filtering वाला आधा हिस्सा |
दाईं तरफ़ के दोनों columns एक-दूसरे के प्रतिस्पर्धी नहीं हैं — वे एक ही build के दो हिस्से हैं। AdGuard Home port 53 का मालिक है, blocklists लागू करता है और encrypted transports को terminate करता है; Unbound इसके पीछे loopback पर बैठकर resolving करता है। कोई भी आधा हिस्सा दूसरे का काम अच्छी तरह नहीं करता, और यह पूरी chain मिलाकर लगभग सौ megabytes RAM लेती है।
अगर आप इस पन्ने से सिर्फ़ एक बात लेकर जाएं, तो यह लें: एक ऐसा resolver जो एक public DNS provider को forward करता है, उसने आपके DNS को private नहीं बनाया। इसने बस log को एक hop आगे खिसका दिया है और आपकी maintenance list में एक server जोड़ दिया है। पूरी बात recursion की है।
पहले box order करें। panel में: Order → VPS → Sentinel, image Debian 12, उस bastion में जो इसे इस्तेमाल करने वाले devices के सबसे नज़दीक हो — Helsinki, Stockholm, Oslo या Reykjavík। account खोलने के लिए किसी email address की ज़रूरत नहीं, और invoice Monero, Bitcoin, Lightning या किसी और supported asset में चुकता हो जाता है, जो यहां सामान्य से कहीं ज़्यादा मायने रखता है: एक निजी resolver की पूरी कीमत इसी पर टिकी है कि पूछने वाला IP address किसी नाम से traceable न हो।
फिर पहले घंटे की hardening checklist से गुज़रें — सिर्फ़ SSH keys, कोई password login नहीं, unattended upgrades — क्योंकि आगे जो कुछ भी है वह मानकर चलता है कि box पहले से compromised नहीं है।
एक recursive resolver जो पूरे internet को जवाब देता है, उसे open resolver कहा जाता है, और port खुलने के कुछ घंटों के भीतर ही internet-wide scanners इसे ढूंढ लेंगे। DNS, UDP पर चलता है, UDP source addresses को forge करना आसान है, और एक 60-byte की query दर्जनों गुना बड़ा एक response पैदा कर सकती है — इसलिए एक open resolver किसी तीसरे पक्ष के ख़िलाफ़ denial-of-service हमले के लिए एक मुफ़्त amplifier है। इसके बाद जो क्रम आता है वह हमेशा एक जैसा होता है: traffic शुरू होता है, abuse reports आते हैं, और IP null-routed हो जाता है। एक पहले DNS server के ख़त्म होने का यह सबसे आम तरीका है। दो नियम इसे पूरी तरह रोक देते हैं: resolver config में by default मना करें, और firewall में 0.0.0.0/0 से 53/udp को कभी अनुमति न दें।
इसलिए firewall पहले आता है, जबकि अभी कुछ भी सुन नहीं रहा। नीचे दिए नियम एक WireGuard tunnel को 10.8.0.0/24 पर मानकर चलते हैं — अगर आपने अभी तक एक नहीं बनाया है, तो इस पन्ने के आख़िर में दिया गया WireGuard guide पंद्रह मिनट का एक छोटा रास्ता है, और यही वह transport है जिस पर यह पूरा design सबसे ज़्यादा सहज रहता है।
ufw default deny incoming
ufw allow 22/tcp # or your moved SSH port
ufw allow 51820/udp # WireGuard
ufw allow in on wg0 to any port 53 proto udp
ufw allow in on wg0 to any port 53 proto tcp
ufw enable
# DNS is NOT opened to the world. Confirm it:
ufw status numbered | grep 53
ग़ौर करें कि जानबूझकर क्या नहीं है: कोई ऐसा नियम नहीं है जो public interface पर 53 खोले। Port 53 सिर्फ़ wg0 पर और loopback पर मौजूद है। अगर आप बाद में DNS-over-TLS या DNS-over-HTTPS जोड़ते हैं, तो वे TCP 853 और TCP 443 हैं, वे एक certificate से authenticate होते हैं, और उन्हें चरण 05 में अपने ख़ुद के नियम मिलते हैं — plaintext UDP port हर हाल में बंद ही रहता है।
अब port को साफ़ करें। Ubuntu पर — और किसी भी ऐसे Debian पर जहां किसी ने इसे enable किया हो — systemd-resolved पहले से ही 127.0.0.53:53 पर सुन रहा होता है, और Unbound एक bind error के साथ शुरू होने से मना कर देगा जिसे लोग बीस मिनट तक ग़लत समझते रहते हैं। पहले जांच लें, फिर सिर्फ़ stub listener को disable करें, systemd-resolved को local client-side interface के तौर पर बनाए रखते हुए:
ss -lunp 'sport = :53' # who owns UDP/53 right now?
mkdir -p /etc/systemd/resolved.conf.d
cat > /etc/systemd/resolved.conf.d/no-stub.conf <<'EOF'
[Resolve]
DNSStubListener=no
EOF
systemctl restart systemd-resolved
ss -lunp 'sport = :53' # should now be empty
एक साफ़ Debian 12 पर पहला command कुछ भी print नहीं करता और करने को कुछ नहीं होता। फिर भी इसे चलाएं — इसमें बस एक सेकंड लगता है, और दूसरा विकल्प है एक ऐसी service के ख़िलाफ़ "address already in use" का पता लगाना जिसके चलने के बारे में आपको पता ही नहीं था।
Unbound, NLnet Labs का एक validating, recursive, caching resolver है। यह हर जगह packaged मिलता है, यह वही है जो internet का एक बड़ा हिस्सा पहले से चला रहा है, और out of the box यह recurse करता है — इसे forwarder बनाने के लिए आपको ख़ास तौर पर मेहनत करनी पड़ती है। इसे root hints package के साथ install करें ताकि इसे बिना कहीं से कोई list लाए यह पता हो कि root servers कहां हैं:
apt update && apt install -y unbound dns-root-data
unbound -V | head -2
dns-root-data package, root hints को /usr/share/dns/root.hints पर और DNSSEC root trust anchor को /usr/share/dns/root.key पर install करता है, और दोनों को सामान्य package channel के ज़रिए updated रखता है। यही इन्हें पाने का उबाऊ, सही तरीका है; root.hints को किसी URL से एक cron job में download करना वह तरीका है जो आख़िरकार चुपचाप fail हो जाता है।
/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
उनमें से चार लाइनें असली काम कर रही हैं और हर एक अपने बारे में एक वाक्य की हक़दार है।
दोनों listeners पर ग़ौर करें। port 5335 पर Loopback वह है जिसे अगले चरण में AdGuard Home इस्तेमाल करेगा; 10.8.0.1 tunnel address है, ताकि अगर आप filtering layer को छोड़ने का फ़ैसला करें तो VPN पर मौजूद clients सीधे Unbound से query कर सकें। अगर आप अभी तक WireGuard नहीं चला रहे हैं, तो फ़िलहाल उस दूसरी interface लाइन को हटा दें — Unbound एक ऐसे address के साथ शुरू नहीं होगा जो box पर मौजूद ही नहीं है।
इसे शुरू करें और साबित करें कि यह काम करता है:
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 flag का मतलब है कि Unbound ने root से लेकर record तक signatures की chain जांची और वह सही निकली। दूसरे पर SERVFAIL का मतलब है कि validation ने एक छेड़छाड़ किए गए जवाब को आप तक पहुंचाने के बजाय ठुकरा दिया। अगर दूसरा जवाब इसके बजाय एक address लौटाता है, तो validation चालू नहीं है और सबसे पहले trust anchor को देखना चाहिए।
सख़्त मायने में यह चरण वैकल्पिक है — अकेला Unbound पहले से ही एक private resolver है — और फिर भी लगभग हर कोई इसे चाहता है। AdGuard Home आपको blocklists, per-client policies, debugging के दौरान पढ़ने लायक एक query log देता है, और, सबसे काम की बात, native DNS-over-TLS और DNS-over-HTTPS listeners देता है ताकि फ़ोन और browsers उन networks से भी आपके resolver से बात कर सकें जहां VPN व्यावहारिक नहीं है।
यह व्यवस्था एक chain है, और ports को सही रखना ही पूरी तरक़ीब है: AdGuard Home 53 का मालिक है और clients की तरफ़ मुंह किए है, Unbound 127.0.0.1:5335 पर बैठा है और internet की तरफ़ मुंह किए है। box पर और कुछ भी 53 पर नहीं सुनता।
curl -fsSL https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v
# Web interface: http://<vps>:3000 — reach it over the SSH tunnel below,
# never by opening 3000 to the internet.
ssh -N -L 3000:127.0.0.1:3000 root@<vps>
उस tunnel के ज़रिए first-run wizard पूरा करें। admin listener को 127.0.0.1 पर या tunnel address पर सेट करें, कभी 0.0.0.0 पर नहीं, और इसे एक लंबा password दें — यह interface आपके network द्वारा resolve किए जाने वाले हर नाम को फिर से लिख सकता है, जो इसे resolver जितना ही संवेदनशील बना देता है।
फिर ठीक एक upstream सेट करें: Settings → DNS settings में, default list साफ़ करें और अपना Unbound instance डालें। एक लाइन, और कुछ नहीं। अगर उस box में कोई public resolver बचा रह गया, तो चरण 01 में किया गया सब कुछ बेकार हो गया।
127.0.0.1:5335
"Parallel requests" को बंद ही रहने दें — एक अकेले upstream के साथ यह traffic को दोहराने के अलावा कुछ नहीं करता — और "Use private reverse DNS resolvers" को बंद रखें जब तक आप सच में एक internal zone न चला रहे हों। bootstrap servers को किसी ऐसी चीज़ पर सेट करें जिस पर आप भरोसा करते हैं; इनका इस्तेमाल सिर्फ़ upstream servers के hostnames को resolve करने के लिए होता है, और एक सीधे IP वाले upstream के साथ इनसे कभी पूछा ही नहीं जाएगा।
Blocklists: संकरे दायरे से शुरू करें। स्वाभाविक झुकाव यह होता है कि list page पर सब कुछ enable कर दें और counter का मज़ा लें। इस झुकाव का विरोध करें। हर list किसी और के द्वारा लिए गए judgement calls का एक समूह है कि आपके devices को कहां पहुंचने की अनुमति है, और इसकी विफलताएं चुपचाप और उलझाने वाली होती हैं — एक आधा-load हुआ page, एक button जो कुछ नहीं करता, एक बैंक ऐप जो खुलने से मना कर देता है। default AdGuard DNS filter से शुरू करें, या OISD जैसे किसी एक अच्छी तरह maintained aggregate से, दो हफ़्ते इसके साथ रहें, और तभी और जोड़ें। एक allowlist रखें और बिना किसी अपराधबोध के इसका इस्तेमाल करें।
आपने अभी एक ऐसी मशीन बनाई है जिसका मक़सद किसी और को आपके devices द्वारा resolve किए गए हर नाम की एक list रखने से रोकना है — और AdGuard Home सबसे पहले जो करता है वह है ठीक वही list रखना, by default चालू, नब्बे दिनों के लिए। blocklists को tune करते समय यह वाकई काम की चीज़ है, और यह server की सबसे संवेदनशील file है। जानबूझकर फ़ैसला लें: "उस device ने अभी क्या मांगा?" का जवाब देने के लिए 24 घंटे काफ़ी हैं, tuning पूरी होने के बाद शून्य ही ईमानदार setting है, और नब्बे दिन एक ऐसा फ़ैसला है जो किसी को भी एक default को यूं ही छोड़कर नहीं लेना चाहिए। Settings → General → Query log, और वहीं रहते हुए statistics retention भी सेट कर लें।
firewall को इस नई व्यवस्था के हिसाब से मोड़ें — अब AdGuard Home tunnel interface पर port 53 का मालिक है, और Unbound सिर्फ़ loopback पर पहुंचा जा सकता है। public interface के बारे में कुछ भी नहीं बदलता: उस पर अब भी बिल्कुल कोई DNS नहीं है।
एक ऐसा resolver जिस तक कोई नहीं पहुंच सकता, वह किसी काम का नहीं, और एक ऐसा resolver जिस तक हर कोई पहुंच सकता है, वह चरण 02 वाला विफलता का तरीका है। ठीक दो अच्छे जवाब हैं, और ज़्यादातर लोग आख़िरकार दोनों ही चलाते हैं — घर पर और laptop पर tunnel, फ़ोन पर और उन networks पर encrypted DNS जहां UDP filter किया जाता है।
विकल्प A — WireGuard के ज़रिए। दोनों में से बेहतर, और यही वजह है कि यह गाइड बार-बार WireGuard guide की तरफ़ इशारा करती है। Port 53 internet के लिए अदृश्य रहता है, query किसी भी रूप में कभी किसी अविश्वसनीय network से नहीं गुज़रती, और renew करने के लिए कोई certificate नहीं है। अगर VPS पहले से आपका VPN exit है, तो यह हर peer की configuration में बस एक लाइन है:
# On the client, in the [Interface] section of the peer config:
DNS = 10.8.0.1
एक बारीक बात जो लोगों को काट लेती है: Linux पर, wg-quick उस address को resolvconf या systemd-resolved के ज़रिए सेट करता है, और अगर इनमें से कोई भी installed नहीं है तो यह चुपचाप कुछ नहीं करता जबकि tunnel बिल्कुल ठीक तरह से खड़ा हो जाता है। tunnel के खड़े होने के बाद resolvectl status से या /etc/resolv.conf पढ़कर जांच लें — पुराने resolver को अब भी configured रखने वाला एक काम करता हुआ tunnel ठीक वही leak है जिसके बारे में यह पूरी कवायद है।
विकल्प B — DNS-over-TLS और DNS-over-HTTPS। ज़रूरी तब होता है जब device हमेशा tunnel पर नहीं रह सकता। दोनों एक certificate से authenticate होते हैं, जिसका मतलब है एक hostname: एक A record को VPS पर point करें, फिर या तो AdGuard Home को सीधे certificate रखने दें या इसे एक reverse proxy के पीछे रखें जो आपके लिए पहले से TLS terminate करता हो। listeners हैं DoT के लिए 853/tcp और DoH के लिए 443/tcp।
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 endpoint को एक ऐसा path दें जिसका अंदाज़ा न लगाया जा सके — AdGuard Home आपको इसे /dns-query/<random> के तहत serve करने देता है, और हर व्यक्ति के लिए एक अलग path का मतलब है कि access को बाक़ी सबके लिए कुछ भी बदले बिना, एक-एक व्यक्ति करके रद्द किया जा सकता है। यह किसी मज़बूत मायने में authentication नहीं है, लेकिन यह एक public listener को अतिरिक्त क़दमों वाला एक open resolver बनने से रोकता है।
| क्लाइंट | setting कहां मिलती है | यह कौन-सा transport बोलता है |
|---|---|---|
| Android 9 और उसके बाद के | सेटिंग → नेटवर्क → निजी DNS → hostname | सिर्फ़ DNS-over-TLS |
| iOS और macOS | एक signed .mobileconfig DNS profile | DoH या DoT, पूरे system में |
| Windows 11 | सेटिंग → नेटवर्क → DNS सर्वर असाइनमेंट | DoH, हर adapter पर |
| Firefox | सेटिंग → गोपनीयता → DNS over HTTPS → कस्टम | DoH, सिर्फ़ browser में |
| Router (पूरा network) | WAN DNS, या DHCP option 6 | Plain DNS — इसलिए इसे tunnel करें |
router वाली row वह है जिसके बारे में सोचना चाहिए। अपने resolver को DHCP के ज़रिए बांटने से घर का हर device एक साथ cover हो जाता है, यहां तक कि वे भी जिनमें कोई settings screen नहीं है — लेकिन फिर router से VPS तक का hop खुले internet पर plain DNS बन जाता है, जो वही चीज़ है जिसे आप रोकना चाहते थे। या तो tunnel को router पर ही चलाएं, या यह मान लें कि आख़िरी मील unencrypted है और recursion को ही अपनी जीत मान लें।
जानने लायक एक आख़िरी configuration: एक browser जिसमें DNS-over-HTTPS चालू है, वह अपना ख़ुद का resolver इस्तेमाल करेगा और tunnel हो या न हो, चुपचाप system setting को नज़रअंदाज़ कर देगा। Firefox और Chrome दोनों कुछ regions में इसे by default चालू भेजते हैं। या तो browser को भी अपने endpoint पर point करें, या इसका DoH बंद कर दें ताकि यह operating system का अनुसरण करे।
1. क्या यह internet के लिए खुला है? इसे एक ऐसी मशीन से चलाएं जो tunnel पर नहीं है — mobile data वाला एक फ़ोन, कोई और VPS, कुछ भी। एक timeout ही सही और वांछित जवाब है। एक असली response का मतलब है कि internet का हर scanner भी इसे ढूंढ लेगा, और आपको तुरंत चरण 02 पर वापस जाना चाहिए।
dig @<public-ip-of-vps> +timeout=3 example.com
# Expected: ";; connection timed out; no servers could be reached"
2. क्या device वाकई इसका इस्तेमाल कर रहा है? यह वह जांच है जो सबसे ज़्यादा बार विफल होती है, और यह विफलता अदृश्य होती है: tunnel खड़ा है, setting सही दिखती है, और operating system अब भी उसी resolver से पूछ रहा है जो café ने DHCP से थमाया था। ख़ुद resolver से पूछें कि वह आपको कौन समझता है, फिर दूसरी तरफ़ से पुष्टि करें।
# On the client — which resolver is the system actually using?
resolvectl status | grep -A2 'Current DNS' # Linux
scutil --dns | grep nameserver # macOS
# On the server — does the query actually arrive?
tail -f /var/log/syslog | grep -i unbound &
unbound-control stats_noreset | grep total.num.queries
फिर device से किसी एक public DNS-leak test page को load करें और नतीजा पढ़ें। अगर यह आपके VPS provider का नाम लेता है, तो रास्ता सही है। अगर यह आपके ISP या किसी बड़े public resolver का नाम लेता है, तो tunnel से ऊपर कहीं कुछ अब भी जवाब दे रहा है।
3. क्या validation वाकई चालू है? चरण 03 वाले दोनों dig commands को इस बार सीधे Unbound के बजाय पूरी chain से गुज़ार कर दोहराएं — client, AdGuard Home, Unbound। एक टूटे हुए-signature वाला नाम यहां भी विफल होना चाहिए। अगर AdGuard Home की settings में कहीं एक दूसरा upstream रह गया है, तो यहीं वह दिखता है।
4. क्या cache अपना काम कर रहा है? एक दिन के सामान्य इस्तेमाल के बाद hit rate सत्तर और नब्बे प्रतिशत के बीच कहीं होनी चाहिए। इससे काफ़ी कम होने का आमतौर पर मतलब है कि cache बहुत छोटा है या cache-min-ttl को नज़रअंदाज़ किया जा रहा है क्योंकि upstream में सब कुछ बहुत छोटे TTL वाला है; एक व्यस्त network पर इससे काफ़ी ज़्यादा होना एक ख़ुशी की निशानी है कि prefetch काम कर रहा है।
unbound-control stats_noreset | grep -E 'total.num.(queries|cachehits)'
# hit rate = cachehits / queries
और फिर दो operational फ़ैसले। पहला: जब यह box reboot होता है तो क्या होता है। इसकी तरफ़ point किया हुआ हर device नाम resolution खो देता है, जिसे घर का हर कोई internet के टूटे होने के तौर पर बताएगा। service को failure पर restart होने और boot पर शुरू होने के लिए सेट करें, फिर जानबूझकर एक बार VPS को reboot करके देखें कि यह वापस आता है। दूसरा: एक fallback। या तो अपने clients पर एक public resolver को secondary के तौर पर सूचीबद्ध करें और मान लें कि outage के दौरान वे queries आपके नियंत्रण से बाहर चली जाएंगी, या किसी दूसरे bastion में एक दूसरे VPS पर एक दूसरा instance चलाएं। दोनों ही उचित ठहराए जा सकते हैं। रविवार को रात 23:00 बजे इस सवाल का पता चलना उचित नहीं है।
systemctl enable unbound AdGuardHome
systemctl show unbound -p Restart -p RestartUSec
reboot # then, from a client: dig nordbastion.com +short
एक private resolver एक असली सुधार है और यह कोई नक़ाब नहीं है। जो कोई इसे नक़ाब के तौर पर बेच रहा है, वह कुछ और बेच रहा है। यहां उस सूची है जो ऊपर की सारी कवायद के बाद भी दिखाई देती रहती है, क्योंकि बचे हुए exposure की बनावट जानना ही एक बचाव और एक झूठी तसल्ली के बीच का फ़र्क है।
connection अब भी होता है। lookup के एक मिलीसेकंड बाद, आपका device अभी-अभी जाने गए address पर एक TCP connection खोलता है। आपकी line को देख रहा कोई भी वह address देख लेता है। अपने ही IP पर मौजूद किसी site के लिए, address ही site है। Encrypted DNS सवाल हटाता है; यह जवाब नहीं हटाता।
TLS handshake आमतौर पर site का नाम बता देता है। Server Name Indication लगभग हर HTTPS connection की शुरुआत में साफ़-साफ़ भेजा जाता है, इसलिए एक passive observer वैसे भी hostname पढ़ लेता है। Encrypted Client Hello इसे ठीक करता है और इसे असमान रूप से deploy किया गया है — जहां browser और site दोनों इसे support करते हैं वहां नाम छुपा रहता है, और जहां नहीं करते वहां नहीं। यह मान न लें कि यह चालू है।
resolver operator अब आप हैं, और आप एक अकेले व्यक्ति हैं। आपका resolver जिस भी authoritative server से बात करता है, वह अपने zone के बारे में पूछता हुआ एक अकेला IP address देखता है। कई zones में, उस IP का एक विशिष्ट pattern बन जाता है, और वह pattern एक घर है। यही पहले अध्याय वाली गुमनामी सेट की कीमत है, और इसे कम करने वाली इकलौती चीज़ है IP का किसी नाम से traceable न होना — crypto में भुगतान किया गया एक KYC-मुक्त VPS — और, आदर्श रूप से, वही IP होना जहां से आपका traffic पहले से exit करता है।
provider हमेशा की तरह packets देख सकता है। VPS किसी और के hardware पर, किसी और के datacentre में चलता है। NordBastion customer traffic का निरीक्षण नहीं करता और transparency report तथा warrant canary बताते हैं कि पूछे जाने पर क्या होगा — लेकिन ईमानदार architectural बात यह है कि आप जो मशीन किराए पर लेते हैं, वह एक ऐसी मशीन है जिस तक कोई और शारीरिक रूप से पहुंच सकता है। self-hosting जो बदलता है वह यह है कि अब कोई product-level query log नहीं है, कोई analytics pipeline नहीं है और कोई privacy policy नहीं है जिसे बदला जा सके; अब सिर्फ़ एक process है जो RAM में एक cache रखे हुए है, आपके द्वारा configure किया गया, एक ऐसे jurisdiction में जिसे आपने जानबूझकर चुना।
आपने ठीक-ठीक क्या ख़रीदा है: आपके बारे में behavioural data का सबसे समृद्ध और सबसे सस्ता स्रोत अब उस पक्ष द्वारा इकट्ठा नहीं किया जा रहा जिसके व्यापार मॉडल में इसे इकट्ठा करना शामिल है। यह एक सीमित दावा है, और यह एक असली दावा है। इस पन्ने पर कुछ भी Tor का विकल्प नहीं है जब threat model को Tor की ज़रूरत हो — और उसके लिए, नीचे दिया गया onion-service guide अगला ईमानदार पठन है।
| स्तर | मासिक | संसाधन | यह आराम से क्या चला सकता है |
|---|---|---|---|
| Sentinel | $3.90 | 2 vCPU · 4 GB · 120 GB | एक घर के लिए Resolver + WireGuard। सही जवाब। |
| Garrison | $7.90 | 4 vCPU · 8 GB · 240 GB | वही, साथ में एक Vaultwarden, एक SearXNG और एक backup target |
| Ravelin | $16.90 | 8 vCPU · 16 GB · 480 GB | एक छोटी टीम, पच्चीस tunnel peers, साथ में और services |
| एक दूसरा Sentinel | $3.90 | किसी और bastion में | fallback resolver, ताकि एक outage internet की outage न बन जाए |
इस table में कुछ भी DNS के लिए नहीं चुना गया है। तीस devices के लिए एक resolver, cache के कुछ सौ megabytes और एक core के एक अंश का इस्तेमाल करता है, और महीने में कुछ सौ megabytes traffic चलाता है। tier को WireGuard peers, बाक़ी services और disk के हिसाब से चुनें — फिर resolver को मुफ़्त में साथ चलने दें।
एक firewall rule ज़्यादा, या एक access-control लाइन जो allow पर छूट गई। Scanners घंटों में port ढूंढ लेते हैं, amplification traffic शुरू हो जाता है, abuse report आ जाती है, IP बुझ जाता है। by default मना करें, सिर्फ़ tunnel को अनुमति दें, और off-network से test करें।
AdGuard Home installed है, upstream default list पर ही छूटा हुआ है, सब कुछ ख़ूबसूरती से चल रहा है — और query log अब भी उस कंपनी के पास जमा हो रहा है जिसका नाम settings box में है। एक upstream सेट करें, और उसे अपना Unbound बनाएं।
wg-quick DNS setting push नहीं कर सका क्योंकि resolvconf installed नहीं है, या कोई browser अपना ख़ुद का DNS-over-HTTPS कर रहा है। सब कुछ सही दिखता है और हर lookup अब भी उसी network पर जाता है जिस पर आप बैठे हैं। client की settings screen से नहीं, resolver की तरफ़ से verify करें।
कुछ भी अपने आप को DNS विफलता के तौर पर नहीं दिखाता — एक page आधा load होता है, एक button कुछ नहीं करता। पहले ही दिन enable की गई छह आक्रामक lists इसे untraceable बना देती हैं। एक से शुरू करें, धीरे-धीरे जोड़ें, एक allowlist रखें, और सवाल का जवाब देने लायक query log रखें।
पूरा build इसलिए है कि किसी और को यह list रखने से रोका जाए, और filtering layer इसे box से बाहर, disk पर, तीन महीने तक रखती है। retention को जानबूझकर सेट करें — tuning के दौरान 24 घंटे, बाद में शून्य — और याद रखें कि यह सिर्फ़ आप पर नहीं, network के हर किसी पर लागू होती है।
एक resolver, infrastructure तभी बन जाता है जब दूसरे लोग इस पर निर्भर करने लगते हैं। दोनों services को boot पर enable करें, Restart=on-failure सेट करें, इसे साबित करने के लिए जानबूझकर एक बार reboot करें, और fallback को ज़रूरत पड़ने के दौरान नहीं बल्कि उससे पहले तय कर लें।
इसे बनाते समय उठने वाले ग्यारह सवाल — उन दो सहित जो तय करते हैं कि इसे बनाना बिल्कुल लायक भी है या नहीं।
यह अलग है, और उस मायने में बेहतर है जो सबसे ज़्यादा मायने रखता है — लेकिन ईमानदार जवाब के दो हिस्से हैं। आपको क्या मिलता है: एक recursive resolver के साथ, कोई एक पक्ष कभी भी आपकी पूरी query stream नहीं देखता। root servers को पता चलता है कि किसी ने .com के बारे में पूछा, .com servers को पता चलता है कि किसी ने example.com के बारे में पूछा, और सिर्फ़ example.com के operator को पूरा नाम पता चलता है — और इनमें से कोई भी अगले हज़ार नाम नहीं देखता जो आप देखते हैं। इसके उलट, एक public resolver हर एक query देखता है, क्रम में, timestamps के साथ, हमेशा के लिए, और उस list तथा किसी और के बीच सिर्फ़ उसकी privacy policy ही खड़ी होती है। आप क्या खोते हैं: एक निजी resolver का anonymity set एक का होता है। एक बड़े public resolver से निकलने वाली queries लाखों दूसरे लोगों की queries के साथ मिली होती हैं; आपके resolver से निकलने वाली queries साफ़ तौर पर आपकी होती हैं। यह सौदा तब लेने लायक है जब resolver का IP आपकी पहचान से न जुड़ा हो — जो ठीक वही चीज़ है जो crypto में भुगतान किया गया एक KYC-मुक्त VPS आपको देता है, और ठीक वह चीज़ है जो आपका कार्ड रखने वाला एक hyperscaler नहीं देता। resolver को उसी VPS के पीछे रखें जहां से आपका VPN पहले से exit करता है, और anonymity set बिल्कुल भी नहीं सिकुड़ता, क्योंकि वह IP पहले से ही आपकी browsing कर रहा था।
किसी नाम के पहले lookup पर थोड़ा धीमा, हर दोहराव पर काफ़ी तेज़, और कुल मिलाकर लगभग बराबर। ठंडी शुरुआत करने वाले एक recursive resolver को delegation chain पर चलना पड़ता है — root, TLD, authoritative — जो एक public resolver के एक round trip के बजाय तीन या चार round trips होते हैं, जिसके पास जवाब पहले से ही किसी और की query से cache किया हुआ था। एक बार आपका cache गर्म हो जाए, जिसमें एक घर के लिए लगभग एक दिन लगता है, तो आम नाम RAM से एक मिलीसेकंड से भी कम में serve हो जाते हैं और आप आगे होते हैं। prefetch चालू करें ताकि लोकप्रिय records के expire होने से पहले ही उन्हें refresh कर दिया जाए और cold-start वाला मामला लगभग ख़त्म हो जाए। जिस एक जगह आप वाकई performance खो सकते हैं वह है CDN geolocation: बड़े public resolvers authoritative server को आपके network location का एक truncated version भेजते हैं (EDNS Client Subnet) ताकि CDN एक नज़दीकी edge चुन सके। Unbound इसे जानबूझकर नहीं भेजता। अगर आपका resolver आपके जैसे ही region में बैठा है, तो इससे मापने लायक कुछ नहीं बदलता। अगर resolver Reykjavík में है और आप Singapore में हैं, तो कुछ CDNs आपको एक European edge देंगे और आपको यह महसूस होगा।
सिर्फ़ encrypted transport के लिए। एक WireGuard tunnel पर plain DNS को न कोई domain चाहिए, न कोई certificate, और न ही किसी तरह का public exposure — resolver 10.8.0.1 जैसे एक private address पर सुनता है और सिर्फ़ tunnel पर मौजूद peers को जवाब देता है। यह configuration इस गाइड में सबसे सरल और सबसे private, दोनों है। जैसे ही आपको DNS-over-TLS या DNS-over-HTTPS चाहिए, आपको एक domain की ज़रूरत पड़ती है, क्योंकि दोनों एक certificate से authenticate होते हैं और एक certificate एक नाम के लिए जारी होता है। यही वह configuration है जिसे चुनें जब devices हमेशा VPN पर नहीं रह सकते — एक office वाला laptop, ऐसे network पर एक फ़ोन जो UDP block करता है, परिवार का कोई सदस्य जो एक tunnel बनाए नहीं रखेगा। अगर आप एक register करते ही हैं, तो उसे कहीं ऐसी जगह register करें जिसे वही पहचान न चाहिए हो जिसके बारे में आप कहीं और सावधान रहे हैं, और WHOIS privacy चालू रखें।
ये दोनों अलग-अलग समस्याएं हल करते हैं और यह जोड़ी बेवजह की नहीं है। Unbound resolver है: यह root से DNS पर चलता है, DNSSEC signatures validate करता है और नतीजों को cache करता है। AdGuard Home बिल्कुल भी resolver नहीं है — यह एक web interface और encrypted listeners वाला एक filtering front end है, और जो कुछ यह block नहीं करता उसे एक upstream पर forward कर देता है। अकेले AdGuard Home चलाएं तो उसका upstream एक public resolver होता है, जो आपकी पूरी query stream को वापस किसी और के log में डाल देता है। अकेले Unbound चलाएं तो आपको बिना blocklists, बिना per-device rules और बिना किसी interface के, एक वाकई private resolver मिलता है। जब दोनों को chain किया जाए — 53 पर AdGuard, और उसके इकलौते upstream के रूप में 127.0.0.1:5335 पर Unbound — तो आपको root से जवाब देने वाले एक resolver के आगे filtering और encrypted transport, दोनों मिल जाते हैं। अगर आपको सबसे छोटा मुमकिन attack surface चाहिए और ad blocking की परवाह नहीं है, तो अकेला Unbound भी पूरी तरह सम्मानजनक जवाब है, और यही वह आधा हिस्सा है जो असल में privacy देता है।
एक open resolver एक ऐसा recursive resolver है जो internet पर किसी भी source address से आई queries का जवाब देता है। यह एक बड़ी बात इसलिए है क्योंकि DNS, UDP पर चलता है, UDP source addresses को आसानी से forge किया जा सकता है, और एक छोटी सी query एक बड़ा जवाब पैदा कर सकती है। एक हमलावर आपके server को एक 60-byte की query भेजता है जिसमें source के तौर पर किसी शिकार का address forge किया गया होता है; आपका server ईमानदारी से उस शिकार को दर्जनों गुना बड़ा एक response भेज देता है। इसे हज़ारों open resolvers से गुणा करें तो यह एक reflection-and-amplification DDoS बन जाता है, और आपका server उन बंदूकों में से एक होता है। असल में यह क्रम तेज़ और अनुमान लगाने लायक होता है: internet-wide scanners घंटों के भीतर नए खुले port 53 को ढूंढ लेते हैं, traffic शुरू हो जाता है, abuse की शिकायतें आती हैं, और provider अपने network को बचाने के लिए उस IP को null-route कर देता है। यह कोई काल्पनिक बात नहीं है और न ही दुर्लभ है — एक पहले DNS server के बुरी तरह ख़त्म होने का यह सबसे आम तरीका है। इसका समाधान बस एक firewall rule और config की एक लाइन में आ जाता है: by default मना करें, सिर्फ़ अपने tunnel को अनुमति दें।
यह lookup छुपाता है, visit नहीं। DNS-over-TLS और DNS-over-HTTPS का मतलब है कि आपका ISP अब example.com कहने वाला एक plaintext सवाल नहीं देखता। जो यह अब भी देखता है वह है वह connection जो आप एक मिलीसेकंड बाद बनाते हैं: destination IP address, और — जब तक दोनों सिरे Encrypted Client Hello support न करें — TLS handshake में साफ़-साफ़ server का नाम। एक dedicated IP पर मौजूद site के लिए, अकेला address ही उसे पहचान देता है; एक बड़े CDN के पीछे मौजूद site के लिए address साझा होता है और SNI ही भेद खोल देता है। तो encrypted DNS, passive logging की कीमत बढ़ा देता है और मौजूद सबसे आसान, सबसे सस्ती surveillance सतह हटा देता है, लेकिन यह आपकी browsing को अदृश्य नहीं बनाता। अगर threat model आपका ISP या सब कुछ देखने वाला कोई विरोधी network है, तो उसके लिए सही tool tunnel है — encrypted DNS उस leak को बंद करता है जो अकेले एक VPN के पास अब भी हो सकता है, जब operating system tunnel के बाहर ISP resolver का इस्तेमाल करता रहता है।
लोगों की उम्मीद से कहीं छोटा। DNS के जवाब सैकड़ों bytes के होते हैं और हर query पर होने वाला काम एक hash lookup है, इसलिए एक घर या एक छोटी टीम के लिए resolver लगभग हर वक़्त idle रहता है। एक Sentinel — 2 vCPU, 4 GB, $3.90 प्रति माह — load average को शून्य से ऊपर उठाए बिना दर्जनों devices को serve कर देगा, और उस 4 GB का ज़्यादातर हिस्सा cache पर खर्च करने के लिए उपलब्ध रहता है, जो असल में अनुभव सुधारने वाला इकलौता resource है। Unbound को message और RRset cache के लिए कुछ सौ megabytes दें और आपकी hit rate अस्सी-से-नब्बे प्रतिशत के दायरे में रहेगी। बड़ा size लेने की वजह कभी DNS नहीं होती: वजह यह होती है कि वही box आपके WireGuard tunnel को भी terminate कर रहा है, या एक Vaultwarden चला रहा है, या एक backup repository रखे हुए है। Bandwidth कोई मुद्दा नहीं है — एक व्यस्त घरेलू resolver महीने में कुछ सौ megabytes ही चलाता है।
इसे इस्तेमाल करने के लिए configure किया गया हर device नाम resolve करना बंद कर देता है, जिसे इस्तेमाल करने वाले लोग "internet बंद है" कहकर बताएंगे। यही DNS को self-host करने की असली operational कीमत है और इसे एक खोज नहीं बल्कि एक फ़ैसले के रूप में लिया जाना चाहिए। मेहनत के बढ़ते क्रम में तीन बचाव। अपने clients पर एक secondary resolver configure करें — Quad9 या dns0.eu जैसा कोई public resolver — और यह मान लें कि outage के दौरान वे queries आपके नियंत्रण से बाहर चली जाएंगी; ज़्यादातर लोगों को यही करना चाहिए। या फिर किसी दूसरे bastion में एक दूसरे VPS पर एक दूसरा instance चलाएं और दोनों को list करें, जो दूसरे $3.90 वाले box की कीमत पर सब कुछ घर के भीतर ही रखता है। या, tunnel पर, हर client पर एक छोटा-सा local cache चलाएं ताकि एक छोटा outage दिखाई ही न दे। आप जो भी चुनें, unit पर Restart=on-failure सेट करें, इसे boot पर enable करें, और जानबूझकर एक बार reboot करके देख लें — एक resolver जो अपने आप वापस नहीं आता, इसे साबित करने के लिए हमेशा सबसे बुरा पल ही चुनेगा।
हां, कभी-कभार, और आप इसे कैसे संभालते हैं, यही फ़र्क तय करता है कि एक setup टिकता है या दो हफ़्तों में उखाड़ फेंका जाता है। Blocklists लोगों द्वारा judgement calls लेकर बनाई और बनाए रखी जाती हैं, और कभी-कभार कोई call उस चीज़ को पकड़ लेती है जिसकी आपको ज़रूरत है: किसी बैंक का fraud-detection endpoint, एक delivery-tracking widget, एक login flow जो किसी analytics domain से होकर redirect करता है। यह विफलता उलझाने वाली होती है क्योंकि यह DNS जैसी दिखती ही नहीं — page आधा load होता है, या कोई button कुछ नहीं करता। तीन आदतें इसे ठीक करती हैं। छह आक्रामक lists के बजाय एक संयमित list से शुरुआत करें। एक allowlist रखें और बिना किसी अपराधबोध के उसमें जोड़ते रहें। और query log को इतनी देर तक चालू रखें कि यह सवाल पूछा जा सके "इस device ने अभी क्या मांगा, और हमने क्या मना किया?" — यही वह पल है जब आपको पता चलता है कि एक filtering resolver खुद भी एक ऐसा device है जो सब कुछ log करता है, और उसकी retention setting एक privacy फ़ैसला है जो आप network के हर किसी के लिए ले रहे हैं।
हां, और इसे बनाने की यह सबसे अच्छी वजहों में से एक है — एक $3.90 वाला box पूरे एक घर या मुट्ठी भर दोस्तों के लिए DNS ठीक कर सकता है। दो नियम इसे सुरक्षित बनाते हैं। पहला, इसे tunnel पर या एक authenticated encrypted endpoint पर साझा करें, दुनिया के लिए port 53 खोलकर कभी नहीं; DNS-over-HTTPS के साथ आप हर व्यक्ति को एक अलग path दे सकते हैं ताकि access को अलग-अलग रद्द किया जा सके, और फिर AdGuard Home हर client पर अलग filtering लागू कर सकता है। दूसरा, अपने आप से साफ़ रहें कि आप क्या ज़िम्मेदारी ले रहे हैं: अब आपके पास इसे इस्तेमाल करने वाले हर व्यक्ति का query log है। retention को शून्य या एक दिन पर सेट करें, उन्हें बताएं कि यह setting क्या है, और याद रखें कि अगर यह कभी आपकी अपनी privacy भी हो जिसे आप बचा रहे हों, तो पांच लोगों द्वारा इस्तेमाल किया गया resolver भी एक ऐसा resolver है जहां किसी एक query को उनमें से किसी एक व्यक्ति से जोड़ पाना मुश्किल होता है।
बिल्कुल नहीं — एक private, access-controlled resolver एक सामान्य workload है और acceptable-use policy को इसके बारे में कुछ नहीं कहना। जिस चीज़ की policy को परवाह है, और जिसकी हर गंभीर network को परवाह है, वह है किसी तीसरे पक्ष के ख़िलाफ़ amplification reflector के तौर पर इस्तेमाल हो रहा एक open resolver, क्योंकि हमला करने वाला traffic हमारे network से निकलकर किसी और के network पर जा गिरता है। step 02 का पालन करें और यह कभी नहीं होता: by default मना करें, tunnel को अनुमति दें, बाक़ी सब को rate-limit करें। अगर आप दूसरों की सेवा के लिए जानबूझकर एक public resolver चलाना चाहते हैं, तो यह एक ऐसी बातचीत है जो पहले abuse report आने के बाद के बजाय पहले से कर लेने लायक है — technical ज़रूरतें (response-rate limiting, कोई ANY नहीं, monitoring) अच्छी तरह समझी हुई हैं, और समस्या ग़लती से एक चलाना है, जानबूझकर एक चलाना नहीं।
Sentinel — 2 vCPU और 4 GB, $3.90 प्रति माह में, Helsinki, Stockholm, Oslo या Reykjavík में। resolver के लिए काफ़ी, उस WireGuard tunnel के लिए जिसके पीछे इसे रहना चाहिए, और जो कुछ भी आप किराए पर लेना बंद करने का फ़ैसला करें उसके लिए भी। signup पर कोई email नहीं, कोई पहचान दस्तावेज़ नहीं, और आप जो कुछ भी देखते हैं उसका कोई product-level log नहीं।
अंतिम review · 2026-10-12 · स्रोत · Unbound और AdGuard Home documentation, RFC 9156 (QNAME minimisation), RFC 7858 (DNS-over-TLS), RFC 8484 (DNS-over-HTTPS), systemd-resolved(8) · आवृत्ति · वार्षिक
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own WireGuard tunnel — server config, peer keys, kill-switch.
A v3 .onion address that survives reboots and IP changes.
Your own Tailscale control server — ACLs, MagicDNS, exit node, own DERP.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
निजी होस्टिंग, उत्तर में निर्मित।