सार्वजनिक DNS resolver चुनने की गाइड

 (evilbit.de)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सार्वजनिक DNS resolver चुनते समय सिर्फ़ गति नहीं, बल्कि गोपनीयता, फ़िल्टरिंग, jurisdiction, ऑपरेटर, encrypted transport भी साथ में देखना चाहिए; यह गाइड 30 वैश्विक सेवाओं की अलग-अलग ज़रूरतों के आधार पर तुलना करती है
  • चयन टूल DoH·DoT·DoQ·DNSCrypt, DNSSEC validation, IPv6, jurisdiction, operator type, EDNS Client Subnet को hard filter के रूप में इस्तेमाल करता है और उपयोग के उद्देश्य के अनुसार प्राथमिकताओं को score देता है
  • ब्राउज़र-आधारित DoH latency test आपकी मौजूदा लोकेशन से relative speed दिखाता है, लेकिन इसमें TLS/HTTP overhead शामिल होता है और plain DNS-only resolver को माप नहीं सकता
  • encrypted DNS बीच के हमलावरों द्वारा snooping और tampering को कम करता है, लेकिन चुना गया resolver provider क्वेरी किए गए domain देख सकता है; इसलिए no-log policy और oblivious design पर भी विचार करना चाहिए
  • व्यवहारिक चयन में DNSSEC, ECS का speed-privacy tradeoff, DoQ performance, DNSCrypt की विशेषताएँ, traffic analysis की सीमाएँ, standards compliance के अंतर, jurisdiction और centralization risk को साथ में परखना चाहिए

चयन टूल किन मानदंडों की तुलना करता है

  • सार्वजनिक DNS resolver की तुलना इस तरह की जाती है कि उपयोगकर्ता जिन शर्तों को महत्वपूर्ण मानते हैं, उन्हें चुनकर resolver ढूँढा जाए
  • hard filter के रूप में इस्तेमाल होने वाली शर्तें
    • encrypted transport: DNS-over-HTTPS(DoH), DNS-over-TLS(DoT), DNS-over-QUIC(DoQ), DNSCrypt
    • DNSSEC validation support
    • IPv6 resolver address उपलब्ध होना
    • operator jurisdiction
    • operator type: non-profit·community·public-interest, commercial, all
    • EDNS Client Subnet(ECS): उपयोग नहीं करता, उपयोग करता है, कोई फ़र्क नहीं
  • priority scoring में शामिल आइटम
    • अधिकतम गोपनीयता और no-log या minimal-log
    • malware·phishing block
    • ads·tracker block
    • child protection और adult content block
    • प्रकाशित DNS response को ज्यों का त्यों लौटाने वाला unfiltered mode
    • account के ज़रिए custom block list·rules
    • global Anycast-आधारित low-latency speed
    • non-commercial operator

मौजूदा लोकेशन के आधार पर DoH speed test

  • built-in test ब्राउज़र में हर DoH-सपोर्टेड resolver तक round-trip time मापता है
  • जो resolver सिर्फ़ plain DNS सपोर्ट करते हैं, उन्हें इस तरीके से test नहीं किया जा सकता
  • नतीजे relative reference value हैं, और इनमें TLS तथा HTTP overhead शामिल है, इसलिए इन्हें कई बार चलाना बेहतर है
  • क्योंकि ब्राउज़र हर resolver को सीधे query भेजता है, उपयोगकर्ता का IP address उस resolver को दिखाई देता है
  • test implementation ने Silviu Stroe के open source DNS Speed Test से प्रेरणा ली है, लेकिन यह स्वतंत्र implementation है और केवल तब चलता है जब पेज HTTPS पर दिया गया हो

performance और encrypted transport का अंतर

  • DoH और DoT जैसे encrypted transport हर query पर latency बढ़ाते हैं, लेकिन कुल page load time कई मामलों में plain DNS के क़रीब रहता है और वास्तविक वातावरण में DoH overhead भी कम दिखता है
  • packet loss या ज़्यादा latency वाले link पर plain Do53 अब भी फ़ायदेमंद रह सकता है
  • performance provider और region के अनुसार बदलती है, इसलिए सबसे तेज़ resolver उपयोगकर्ता की लोकेशन पर निर्भर करता है
  • encrypted DNS के बड़े पैमाने के end-to-end माप में पाया गया कि plain DNS की तुलना में queries के transit के दौरान intercept या modify होने की संभावना बहुत कम थी और overhead छोटा था
  • हालांकि उसी शोध में लगभग 25% DoT providers ने invalid TLS certificates दिए, इसलिए अच्छी operational quality वाले provider को चुनना ज़रूरी है

गोपनीयता की वास्तविक सीमाएँ

  • encrypted DNS नेटवर्क पर queries को छिपाता है, लेकिन चुना गया resolver provider देख सकता है कि कौन से domain lookup किए गए
  • अगर यह समस्या है, तो no-log operator चुनें या ODoH जैसी oblivious design पर विचार करें, जहाँ proxy पहचान और query को अलग करता है
  • Cloudflare और Apple, ODoH deploy करने के उदाहरण हैं
  • सिर्फ़ encrypted DNS से visited site पूरी तरह नहीं छिपती
    • DoH इस्तेमाल करने पर भी traffic analysis से visited domain को काफ़ी उच्च सटीकता से पहचाना जा सकता है
    • standard EDNS padding भी इसे पूरी तरह नहीं रोक पाती
    • अगर आपका threat model ऐसा है, तो सिर्फ़ padding पर निर्भर न रहें; Tor या oblivious design साथ में इस्तेमाल करें

DNSSEC, ECS, jurisdiction

  • DNSSEC validation करने वाले resolver ही forged record से सुरक्षा देते हैं
  • Google, Cloudflare, Quad9 DNSSEC validate करते हैं और पहले root key KSK rollover को बिना user disruption के संभाल चुके हैं
  • अगर integrity महत्वपूर्ण है, तो DNSSEC validation को अनिवार्य शर्त मानना चाहिए
  • EDNS Client Subnet(ECS) बेहतर geographic routing के लिए IP का कुछ हिस्सा CDN को भेजता है
    • Google और OpenDNS ज़्यादा सटीक CDN mapping के लिए ECS भेजते हैं
    • Cloudflare और standard Quad9 गोपनीयता के लिए ECS बंद रखते हैं
  • operator का कानूनी आधार compelled measures और logs को प्रभावित करता है
  • कुछ ही providers दुनिया भर के recursive DNS traffic का बड़ा हिस्सा संभाल रहे हैं
  • अमेरिकी NSA ने चेतावनी दी है कि external resolver आंतरिक DNS filtering और inspection को bypass कर सकते हैं; इसलिए सुविधा और नियंत्रण के बीच संतुलन देखना चाहिए

DoQ और DNSCrypt

  • 2022 के DoQ measurement में DNS-over-QUIC response time में DoT और DoH दोनों से आगे था
  • लेकिन QUIC के address validation limitation की वजह से लगभग 40% handshakes धीमे हुए
  • अगर client और resolver दोनों support करते हों, तो DoQ पसंदीदा encrypted option हो सकता है
    • support उदाहरण: Quad9, AdGuard, NextDNS, Control D, Mullvad, UncensoredDNS, और चीन की प्रमुख सेवाएँ
  • DNSCrypt DoH, DoT, DoQ से पुराना encrypted option है और version 2, 2013 में आया था
  • DNSCrypt resolver की pre-shared public key से पहले packet से ही encryption करता है, इसलिए plain hostname lookup या certificate authority पर निर्भरता नहीं रहती
  • 2019 का Anonymized DNS mode client IP भी छिपाता है
  • तुलना में शामिल DNSCrypt providers हैं: Quad9, OpenDNS, AdGuard, NextDNS, Control D, Yandex
  • भरोसेमंद usage आँकड़ों की कमी है, और APNIC Labs जैसे बड़े measurement DoH और DoT को track करते हैं, लेकिन DNSCrypt को नहीं

resolver implementation quality और operational data

  • 2023 के Extended DNS Errors शोध में प्रमुख resolvers की diagnostic error reporting, test cases के 94% में असंगत पाई गई
  • उस शोध में Cloudflare ने सबसे सटीक error reporting दिखाई
  • resolver-वार implementation quality और standards compliance का अंतर troubleshooting और reliability को प्रभावित करता है
  • संदर्भ के लिए उपयोगी operational·community data
    • ICANN Identifier Technology Health Indicators: DNSSEC validation resolver ratio और resolver concentration को track करता है
    • DNS-OARC workshop talks और past-event archive: encrypted DNS, resolver performance, measurement पर operators और researchers की प्रस्तुतियाँ
    • APNIC Labs measurements: देशवार DNSSEC validation rate, public resolver usage, DoH·DoT adoption data

छोटे, community और regional resolver

  • तुलना तालिका के बाहर भी hobby, community और country-specific resolver मौजूद हैं; उपयोग से पहले उनकी मौजूदा स्थिति और policy की जाँच करनी चाहिए
  • यूरोप से जुड़े विकल्प European Alternatives में संकलित हैं
  • जिन क्षेत्रों में कड़ी censorship या sanctions हैं, वहाँ के resolver स्थानीय content rules लागू कर सकते हैं या geo-blocking bypass के लिए चलाए जा सकते हैं; इसलिए अतिरिक्त सावधानी ज़रूरी है
  • उदाहरण सेवाएँ
    • DNS4all: neutrality और performance पर ज़ोर देने वाला यूरोपीय unfiltered resolver
    • BlahDNS: छोटे regional server पर चलने वाला open source hobby ad-blocking project, DoH·DoT·DoQ support
    • LibreDNS: LibreOps का community resolver, ad blocking और no-log policy, DoH·DoT support
    • Dismail.de: privacy-केंद्रित जर्मन community resolver, no-log, DoH·DoT support
    • IIJ Public DNS: Internet Initiative Japan का public DoH·DoT resolver, child sexual abuse material domain block
    • DNS for Family: adult content, gambling, malware, ads·tracker, safe search सहित family-filtering DoH
  • जिन legacy या बंद सेवाओं से बचना चाहिए, उनमें Oracle Dyn, Level3(4.2.2.x), Freenom World, dns0.eu, Norton ConnectSafe का उल्लेख है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • ऐसी सूचियां या नई service announcements देखते समय मुझे खास उत्साह नहीं होता, और Hacker News पर भी हैरानी की बात है कि काफी लोगों की प्रतिक्रिया ऐसी ही दिखती है
    मैं लगभग 25 साल से खुद proxy DNS service चला रहा हूं, और छह operating systems पर तीन software bundles इस्तेमाल कर चुका हूं; filter tab में मौजूद सारी चीजें खुद की जा सकती हैं और मैं असल में कर भी रहा हूं
    इस सूची में choices से ज्यादा दिलचस्प वह बातें हैं जो इससे उजागर होती हैं। मसलन, ‘China’ के तौर पर दिखाए गए सभी entries में लिखा है कि वे ‘चीनी regulation के तहत संचालित’ हैं, लेकिन 2026 में यह सिर्फ China entries के लिए नहीं, बल्कि मेरे महाद्वीप के users के लिए भी चिंता का विषय है
    ‘Denmark में 1 individual द्वारा संचालित’ वाली लाइन bus factor दिखाने वाली दिलचस्प जानकारी है, लेकिन यह मान नहीं सकते कि बाकी entries इस बात का जिक्र नहीं करतीं इसलिए वे बेहतर हैं। DNS.Watch के पीछे कौन है, इसकी जानकारी Thomas Steen Rasmussen की तुलना में बहुत कम है, और हाल के कुछ वर्षों में यह कम-से-कम एक बार down हुआ लगता है, इसलिए यह जायज चिंता है
    Quad101 में availability region की सीमाएं दिखती हैं, और Gcore का AI company होना जैसे कई ऐसे factors भी हैं जो इस सूची में नहीं हैं लेकिन users के लिए महत्वपूर्ण हो सकते हैं

    • ‘Denmark में 1 individual द्वारा संचालित’ वाली बात bus factor से ज्यादा organizational oversight के लिहाज से दिलचस्प है
      अगर संचालन में कई लोग शामिल हों, तो वे एक-दूसरे पर नजर रख सकते हैं, और अगर DNS resolver selective logging करे या results में दखल दे जैसी अजीब चीजें दिखें, तो मुद्दा उठा सकते हैं। अगर एक ही व्यक्ति सब कुछ चला रहा है, तो उसे रोकने वाला कोई नहीं होता
      आप सोच सकते हैं, “वह व्यक्ति सिद्धांतों वाला है, ऐसा कभी नहीं करेगा,” लेकिन law enforcement agencies का दबाव बहुत मजबूत हो सकता है
    • करीब 2 साल पहले मैंने खुद resolver configure किया था और वह बस ठीक चलता है। एक बार भी समस्या नहीं आई

  • ISP का official DNS इस्तेमाल करने पर ISP handoff point से CDN या overseas trunk तक संभव सबसे छोटा route मिल सकता है। मतलब ऐसा generic DNS न इस्तेमाल करें जिसे ISP structure की जानकारी न हो
    ISP: Cloudflare तक 1ms
    Cloudflare: Cloudflare तक 10ms
    हालांकि, यह सलाह उन देशों पर लागू होती है जहां privacy laws अच्छे हैं और state surveillance नहीं है। यानी अमेरिका नहीं

    • अगर censorship-free DNS चाहिए, तो वह तरीका अच्छा नहीं है
    • असल में ad servers block करने वाला DNS इस्तेमाल करना overall performance के लिए बेहतर होने की संभावना ज्यादा है
    • पता नहीं ऐसे देश अभी भी सच में मौजूद हैं या नहीं। और यह सिर्फ privacy का मामला नहीं है; लगभग हर देश ऐसी जगहों तक users की पहुंच रोकना चाहता है जहां वह नहीं चाहता कि users जाएं, और आमतौर पर तरीका ढीला-ढाला होता है: ISP का default DNS जिस site को खोलना था उसकी जगह warning page पर भेज देता है
      इसलिए 8.8.8.8 जैसे DNS पर switch करना privacy को जरूरी नहीं कि बढ़ाए, फिर भी browsing experience सुधारने का पहला बड़ा कदम बन जाता है
    • Cloudflare, जैसा कि मशहूर है, anycast इस्तेमाल करता है, इसलिए आप कहीं से भी आएं, DNS response समान होता है। दिए गए numbers को DNS की वजह मानना मुश्किल है
      उल्टा, Cloudflare अपनी services के लिए recursive lookup को छोटा कर सकता है, इसलिए name resolution stage में तेज हो सकता है, और जरूरत पड़े तो eDNS client subnet से location-based routing भी संभव है
    • DNS बदलने से privacy पर बहुत कम असर पड़ता है। क्योंकि अब भी DNS queries और SNI पढ़े जा सकते हैं

  • Public Wi-Fi पर DNS resolver के साथ इस्तेमाल करने के तरीके पर सलाह चाहिए
    कई public Wi-Fi को terms acceptance screen पर redirect करने के लिए अपने DNS का इस्तेमाल करवाना पड़ता है, और वे हर 30–60 मिनट में re-approval भी मांगते हैं
    जब दिक्कत आती है, तो आप नोटिस करते हैं कि internet रुक गया है, google.com पर ping करते हैं और timeout का इंतजार करते हैं, अंदाजा लगाते हैं कि ISP issue है या नहीं, फिर समझते हैं कि शायद Wi-Fi session expire हो गया है, DNS बदलते हैं और cache clear करते हैं, फिर किसी non-TLS domain पर जाते हैं, gate approve करते हैं, और फिर DNS वापस बदलना पड़ता है
    जरूर ऐसा कुछ होना चाहिए जो इसे manage कर दे

    • macOS पर शायद /etc/resolver से यह हल हो सकता है
      sudo sh -c 'echo "nameserver 192.168.1.1" > /etc/resolver/captive.apple.com'
      जब university internal site सिर्फ network nameserver से resolve होती थी, तब मैंने यह तरीका इस्तेमाल किया था। मुझे लगा कि macOS captive portal detection के लिए जिस URL का इस्तेमाल करता है उस पर भी यह लागू हो सकता है, और अगली बार cafe जाऊंगा तो check करना होगा
    • macOS और iOS में आप हमेशा इस्तेमाल होने वाला DNS server specify करने के लिए profile बना सकते हैं। यह दूसरे Wi-Fi और mobile data पर भी लागू होता है
      https://doh.lvv.me/
      मैं कई सालों से इसे इस्तेमाल कर रहा हूं और public hotspots पर कभी समस्या नहीं हुई
    • address bar में बस IP address डाल दें। आमतौर पर वे port 80 traffic को पूरी तरह intercept कर रहे होते हैं
    • ऐसी चीजों को operating system को captive portal support के हिस्से के रूप में handle करना चाहिए। operating system vendor से संपर्क करके bug register करना बेहतर होगा

  • लोकल में Unbound को DoH सर्वर के तौर पर इस्तेमाल कर रहा हूँ। Alpine Linux का Unbound पैकेज इन-बिल्ट DoH listener के लिए ज़रूरी libnghttp2 के साथ compile किया गया है, और ECH चालू करने के लिए इतना काफी है
    हर घंटे cron से अक्सर इस्तेमाल होने वाले सभी domains को पहले से cache कर देता हूँ। ISP मेरे DNS requests से छेड़छाड़ नहीं करेगा, और उसके कर्मचारी मुझसे भी ज़्यादा अजीब लोग हैं। अगर मैं फोन पर web browsing शुरू करूँगा, तो अपना public DoH server बना लूँगा। इसमें कुछ ही मिनट लगते हैं, और अजीब समस्याएँ debug करते समय अपने query logs भी मिल जाते हैं
    [1] - https://tls-ech.dev/

    • करीब 3 साल से अपने public powerdns, dnsdist, recursive/authoritative server instances पर DoH, DoT, DoQ, TCP, UDP चला रहा हूँ
      पहले bind, unbound, dnsmasq इस्तेमाल करता था, इसलिए configuration में थोड़ा समय लगा। यह बहुत stable है, mobile या पुराने devices पर भी इस्तेमाल किया जा सकता है, और unbound, adguard/dnsproxy, local resolve.conf के resolver के तौर पर भी इस्तेमाल हो सकता है
    • जानना चाहता हूँ कि पहले से cache क्यों करते हैं। अगर speed के लिए है, तो ज़्यादा से ज़्यादा 30–50ms ही नहीं होगा? अगर authoritative server का TTL 60 मिनट से कम हो तो क्या आप उसे 3600 पर force करते हैं, यह भी जानना चाहता हूँ
      क्या आप देखे जाने वाले हर website के connections audit करके assets host करने वाले domains तक इकट्ठा कर सबको पहले से cache करते हैं, या फिर महसूस होने वाली latency पर सबसे बड़ा असर डालने वाले main site domains ही महत्वपूर्ण हैं, यह भी जानना चाहता हूँ
    • Unbound में prefetch है, जो expire होने के करीब cache records को refresh करता है, और cache व TTL से जुड़ी कई tuning options भी हैं। serve-expired भी ठीक काम करता दिखा था
    • “हर घंटे cron से अक्सर इस्तेमाल होने वाले सभी domains को पहले से cache करता हूँ” किस रूप में है, यह जानना चाहता हूँ। क्या यह hostnames की list query करने वाली shell script है, और “इस्तेमाल होने वाले domains” का मानदंड क्या है?
    • यहाँ भी Unbound चला रहा हूँ। domains block करने में wildcard इस्तेमाल कर सकने वाली बात पसंद है। बड़ी block list इस्तेमाल करता हूँ, और उसके ऊपर exceptions allow list रखता हूँ
      ayt7.ads.acme.com, afi6.ads.acme.com, foi5.ads.acme.com जैसे inputs को ads.acme.com में simplify करने वाला एक छोटा tool भी है
      साथ ही इस्तेमाल किए जाने वाले domains के variants generate करने वाली script भी रखी है। उदाहरण के लिए अगर legitimate domain mybank.com है, तो myb4nk.com, mibank.com, mybank.{बाकी सभी TLD} वगैरह block करता हूँ
      ऐसे variants के सैकड़ों हज़ार entries generate करके सबको Unbound में block करता हूँ। बैंक ने बहुत विश्वसनीय लगने वाली phishing site का उदाहरण भेजा था, उसके बाद यह बनाया
      कई सालों से यही setup इस्तेमाल कर रहा हूँ, और दस लाख blocked domains भी पुराने Pi 3 पर ठीक चलते हैं। ज़्यादा powerful computer हो तो Unbound शायद कई मिलियन, शायद दसियों मिलियन domains की block list भी संभाल सकता है। अभी allow-list-only तरीके पर shift नहीं किया है
      Unicode domains भी पूरी तरह block करता हूँ। जिन domains के नाम में Unicode characters हैं, उन्हें access नहीं कर सकता, और मुझे इसकी परवाह नहीं

  • NextDNS से संतुष्ट होकर इस्तेमाल कर रहा हूँ। कौन-सी filter lists चालू करनी हैं, logging कैसे करनी है आदि में काफी configurability है
    लगभग हर जगह stable और fast है। cloud में अपना resolver चलाकर यह हासिल करना ज्यादा मुश्किल है, और वैसे भी मैं maintain नहीं करना चाहता

    • मैं भी NextDNS अच्छे से इस्तेमाल कर रहा हूँ। खासकर Pi-hole को कई साल छेड़ने के बाद maintenance से थक गया था, उसके बाद और ज़्यादा संतुष्टि है। जरूरत पड़ने पर Mullvad VPN के साथ भी आसानी से इस्तेमाल हो जाता है
    • मेरे लिए भी काफी ठीक रहा

  • समझ नहीं आता सिर्फ 29 ही क्यों हैं
    क्या लेखक कह रहा है कि आज के internet पर open resolvers की वास्तविक संख्या इतनी ही है
    DNS की “privacy” या “security” पर विचार करते हुए SNI को साथ में कैसे नज़रअंदाज़ किया जा सकता है, यह सवाल है
    SNI किसी third party को यह देखने देता है कि user किस domain name के public address से connect करना चाहता है, और ऐसी connection में बाधा भी डालने देता है
    DNS सिर्फ इतना देखने देता है कि user किस domain name के public address को lookup कर रहा है। non-DNS traffic को इस query से जोड़ने के लिए इस बात पर assumptions चाहिए कि वह software कैसे काम करता है
    इसलिए यह हैरानी की बात नहीं कि popular web browsers पर नियंत्रण रखने वाली ad companies चाहती हैं कि user browser के अंदर, या enterprise operating systems में DoH चुने। इसे भ्रामक रूप से “private DNS” कहने पर third parties browser या enterprise operating system में चल रहे software के non-DNS traffic और queries को ज़्यादा प्रभावी ढंग से correlate कर सकती हैं
    ऐसे भ्रामक दावों की वजह से मुकदमा भी हो सकता है। उदाहरण के लिए “private browsing” पर भ्रामक दावों के मामले में users मुकदमे में जीत चुके हैं

    • उन 29 का मतलब है कि वे ऐसी services हैं जिन पर काफी लोग अपनी DNS queries सौंपने लायक कुछ हद तक भरोसा करते हैं। साथ ही वे 29 अपनी service attributes की जानकारी public करती हैं
      पूरा page पढ़ेंगे तो उल्लेखनीय दूसरे public DNS resolvers भी अलग से list किए गए हैं
      unknown long tail वाले open DNS resolvers के लिए Shodan इस्तेमाल कर सकते हैं। हालांकि Shodan में जो मिले, उस पर अपना internet use भरोसे से सौंपने की सलाह मैं नहीं दूँगा
      SNI सामान्य internet privacy issue है, यह सही है, लेकिन यह DNS की property नहीं है। सकारात्मक रूप से देखें तो ECH IETF से pass हो चुका है, और धीरे-धीरे सामान्य users तक भी पहुँचेगा
      — लेखक
    • कुछ “test” sites को छोड़कर ECH आम web users के लिए व्यापक रूप से उपलब्ध नहीं है
      लेखक के जवाब में “you” किसे refer कर रहा है, यह भी स्पष्ट नहीं है
      मेरे मामले में remote DNS सिर्फ bulk DNS data समय-समय पर लाते वक्त इस्तेमाल करता हूँ। HTTP servers access करते समय remote DNS request नहीं करता। जरूरी IP address information मेरे पास पहले से होती है, और यह तरीका तेज़ व अधिक reliable है
      कई sources से मिले bulk DNS data को local TLS forward proxy की memory में load करके रखता हूँ
      users सभी अलग हैं, और हर किसी को खुद सोच लेना चाहिए

  • अगर आप Canada में user हैं, तो CIRA IPv4, IPv6, DoH, DoT के जरिए public resolver चलाता है
    https://www.cira.ca/en/canadian-shield/configure/summary-cir...

    • समझ नहीं आता कि Canadian लोगों को दूसरे विकल्पों की तुलना में CIRA पर ज़्यादा भरोसा क्यों करना चाहिए। फिर भी default ISP DNS इस्तेमाल करने से बेहतर होने की काफी संभावना है

  • DNScryptProxy सार्वजनिक DNS सर्वरों की एक विशाल सूची बनाए रखता है। यह यह भी दिखाता है कि DNSSEC, filtering और logging समर्थित हैं या नहीं
    https://download.dnscrypt.info/dnscrypt-resolvers/v3/public-...

  • अच्छा होगा अगर ऐसी site local network के आधार पर basic speed comparison test दे
    random queries के लिए P90 response time और median response time की तुलना कर पाना उपयोगी होगा

    • मैं लेखक हूँ, और अब इसे जोड़ दिया है: https://evilbit.de/dns-resolver-guide2.html#speedtest
      हालांकि यह सिर्फ DoH पर काम करता है
    • इस repository को clone करने के बाद domain names और resolvers को अपनी जरूरत के हिसाब से बदल दें, तो आप जिस तरह का result खोज रहे हैं उसके करीब पहुंच सकते हैं
      [1] - https://github.com/cleanbrowsing/dnsperftest
    • इस काम के लिए मैं local तौर पर एक smokeping instance चला रहा हूँ। यह कई DNS servers, ISP DNS और कुछ प्रमुख websites को ping भेजता है, और उन results के आधार पर local DNS server के upstream को नियमित रूप से update करता है
      मेरे environment में बड़े DNS servers सभी 5–6ms range में हैं, लेकिन हमेशा ऐसा नहीं था। ISP DNS का average भी मिलता-जुलता है, पर variation ज्यादा है और spikes 50ms तक चले जाते हैं। जबकि यह सबसे तेज होना चाहिए, फिर भी ऐसा है

  • DNS privacy और security के लिए बहुत अहम विषय है। public DNS चुनने के बजाय अपना infrastructure host करना बेहतर लगता है
    public instance की जरूरत नहीं है। router या machine पर ADGUARD, unbound, dnsmasq, dnsdist को recursive mode में चला सकते हैं
    जरूरत के अनुसार restrictions और blocklists भी configure कर सकते हैं

    • फिर भी ISP सभी queries को log कर सकता है