💛 👍🏽 🤖 Google सार्वजनिक डीएनएस चुपचाप टीएलएस समर्थन पर डीएनएस को चालू कर दिया है 🛍️ 🧑🏾‍🤝‍🧑🏻 ⤴️

अचानक, प्रारंभिक घोषणा के बिना, टीएलएस पर डीएनएस ने 8.8.8.8 पर काम करना शुरू कर दिया । पहले, Google ने HTTPS से अधिक DNS के लिए केवल समर्थन की घोषणा की ।

CloudFlare के सार्वजनिक पते पर IP पते के साथ 1.1.1.1 परियोजना शुरू होने के बाद से टीएलएस पर DNS का समर्थन किया है।

क्यों जरूरी है?

क्लासिक डीएनएस स्कीम का उपयोग करके, प्रदाता अपने गंदे पंजे को आपके डीएनएस पैकेट में डाल सकते हैं, ब्राउज़ कर सकते हैं कि आप कौन से डोमेन का अनुरोध कर रहे हैं, और आप की तरह जवाब को खराब कर सकते हैं। स्कैमर एक ही करते हैं, हैक किए गए राउटर पर रिज़ॉल्वर को बदलकर उपयोगकर्ता को एक नकली सर्वर पर निर्देशित करने के लिए।

टीएलएस / एचटीटीपीएस पर डीएनएस के साथ, अनुरोध एक एन्क्रिप्टेड सुरंग के अंदर भेजे जाते हैं ताकि प्रदाता अनुरोध को बदल या देख न सके।

और एक्स 509 प्रमाणपत्र ( ईएसएनआई ) में डोमेन नाम एन्क्रिप्शन के आगमन के साथ, एसएनआई (सर्वर नाम इंडिकेशन, एक विशेष क्षेत्र जिसमें डोमेन नाम पहले टीएलएस पैकेट में प्रेषित होता है) के माध्यम से डीपीआई के माध्यम से ब्लॉक करना असंभव हो जाएगा, जो अब कुछ बड़े प्रदाताओं द्वारा उपयोग किया जाता है।

यह कैसे काम करता है

एक टीएलएस कनेक्शन टीसीपी: 853 पोर्ट के लिए बनाया गया है, और रिसोल्वर प्रमाणपत्र सिस्टम रूट प्रमाणपत्रों का उपयोग करके सत्यापित किया जाता है, जैसे कि ब्राउज़र में HTTPS। यह मैन्युअल रूप से किसी भी कुंजी को जोड़ने की आवश्यकता को समाप्त करता है। सुरंग के अंदर, एक नियमित DNS क्वेरी की जाती है। यह HTTPS पर DNS की तुलना में कम ओवरहेड बनाता है, जो अनुरोध और प्रतिक्रिया में HTTP हेडर जोड़ता है।

दुर्भाग्य से, वर्तमान में केवल टीएलएस से अधिक DNS के लिए एंड्रॉइड 9 (पाई) समर्थन सिस्टम रिज़ॉल्वर में बनाया गया है। Android 9 के लिए सेटअप निर्देश ।

अन्य प्रणालियों के लिए, तीसरे पक्ष के डेमॉन का उपयोग करने का प्रस्ताव है, और सिस्टम रिज़ॉल्वर को स्थानीयहोस्ट (127.0.0.1) पर भेजना प्रस्तावित है।

MacOS पर सेटअप करें

उदाहरण के रूप में गाँठ रिज़ॉल्वर का उपयोग करते हुए, macOS के नवीनतम संस्करण में टीएलएस पर डीएनएस का विश्लेषण करते हैं

स्थापना

brew install knot-resolver

डिफ़ॉल्ट रूप से, गाँठ एक नियमित पुनरावर्ती रिज़ॉल्वर की तरह काम करेगा, जैसे कि dnsmasq।

विन्यास का संपादन

 nano /usr/local/etc/kresd/config

और फ़ाइल के अंत में जोड़ें:

 policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))

परिणामस्वरूप, मेरा विन्यास इस तरह दिखता है:

स्पॉइलर का विस्तार करें

 -- Config file example useable for personal resolver. -- The goal is to have a validating resolver with tiny memory footprint, -- while actively tracking and refreshing frequent records to lower user latency. -- Refer to manual: https://knot-resolver.readthedocs.io/en/latest/daemon.html#configuration -- Listen on localhost (default) -- net = { '127.0.0.1', '::1' } -- Drop root privileges -- user('knot-resolver', 'knot-resolver') -- Auto-maintain root TA trust_anchors.file = 'root.keys' -- Load Useful modules modules = { 'policy', -- Block queries to local zones/bad sites 'hints', -- Load /etc/hosts and allow custom root hints 'stats', -- Track internal statistics 'predict', -- Prefetch expiring/frequent records } -- Smaller cache size cache.size = 10 * MB policy.add( policy.all( policy.TLS_FORWARD({ {'8.8.8.8', hostname='8.8.8.8'}, {'8.8.4.4', hostname='8.8.4.4'} })))

होस्टनाम और टीएलएस प्रमाणपत्र प्रमाणीकरण के बारे में अधिक जानें।

इस मामले में hostname पैरामीटर प्रमाण पत्र का सामान्य नाम (CN) या विषय Alt नाम (SAN) है। वह है, डोमेन नाम जिसके लिए प्रमाण पत्र जारी किया जाता है। यह सर्वर प्रमाणपत्र की प्रामाणिकता की पुष्टि करता है।

प्रमाणपत्र के लिए SAN मान यहां दिए गए हैं जो 8.8.8.8:853 से कनेक्ट करते समय उपयोग किए जाते हैं

 dns.google 8888.google 8.8.4.4 8.8.8.8 2001:4860:4860:0:0:0:0:64 2001:4860:4860:0:0:0:0:6464 2001:4860:4860:0:0:0:0:8844 2001:4860:4860:0:0:0:0:8888

इनमें से कोई भी मान होस्टनाम पैरामीटर के रूप में उपयोग किया जा सकता है। यदि आप अपनी स्वयं की सार्वजनिक पुनरावर्ती रिज़ॉल्वर को तैनात करेंगे, तो आप एक IP पते के लिए X.509 प्रमाणपत्र जारी करने का प्रबंधन करने की संभावना नहीं रखते हैं, इसलिए आपको hostname पैरामीटर में एक डोमेन नाम निर्दिष्ट करना होगा।

डेमॉन लॉन्च

 sudo brew services start knot-resolver

यदि कमांड का उपयोग करके डेमॉन सफलतापूर्वक शुरू हो गया है, तो आप देख सकते हैं:

 sudo lsof -i -P -n | grep kresd

Kresd प्रक्रिया को लोकलहोस्ट पर पोर्ट 53 पर सुनना चाहिए।

अगर कुछ गलत हुआ, तो त्रुटि लॉग देखें:

 cat /usr/local/var/log/kresd.log

रिज़ॉल्वर ऑपरेशन की जाँच करना

 dig @127.0.0.1 habr.com

जांचें कि स्थानीय रिज़ॉल्वर सही ढंग से प्रतिक्रिया करता है।

एक सिस्टम रिज़ॉल्वर के रूप में स्थापना

यदि सब कुछ सही ढंग से काम करता है, तो आप नेटवर्क एडेप्टर के गुणों में एक सिस्टम रिज़ॉल्वर असाइन कर सकते हैं:

युपीडी

TLS / HTTPS पर DNSCrypt, DNSSEC, DNS के बीच अंतर क्या है।

DNSCrypt UDP और TCP पर काम कर सकता है। पोर्ट 443 से कनेक्शन। एन्क्रिप्शन के लिए, अपने स्वयं के प्रोटोकॉल का उपयोग किया जाता है, जो HTTPS से भिन्न होता है। डीपीआई का उपयोग करके इसे आसानी से उजागर किया जा सकता है। यह एक मसौदा है, जिसे टीएलएस / एचटीटीपीएस पर डीएनएस की शुरुआत से पहले परीक्षण किया गया था, क्योंकि इसमें आरएफसी नहीं है, अर्थात यह आधिकारिक इंटरनेट मानक नहीं है। सबसे अधिक संभावना है, जल्द ही, इसे पूरी तरह से बाद के द्वारा बदल दिया जाएगा।

डीएल ओवर टीएलएस (डीओटी) - टीसीपी कनेक्शन पोर्ट 853 पर होता है, सुरंग के अंदर एक नियमित डीएनएस अनुरोध प्रेषित होता है। प्रदाता देखता है कि यह एक DNS क्वेरी है, लेकिन इसके साथ हस्तक्षेप नहीं कर सकता। टीएलएस से अधिक डीएनएस में अन्य चीजें बराबर होती हैं, एचटीटीपीएस की तुलना में प्रत्येक अनुरोध के लिए थोड़ा कम ओवरहेड होना चाहिए।

DNS पर HTTP (DoH) - नियमित HTTPS के समान 443 पोर्ट के लिए TCP कनेक्शन। HTTP हेडर के साथ अंदर एक अलग अनुरोध प्रारूप है। हालांकि, प्रदाता के लिए, इस तरह के अनुरोध को सामान्य HTTPS कनेक्शन के रूप में देखा जाएगा। मुझे लगता है कि इस प्रोटोकॉल का आविष्कार उस स्थिति में हुआ था जब सामान्य वेब ट्रैफ़िक के तहत मास्क करने के लिए विदेशी सर्वरों के लिए DNS प्रश्नों को अवरुद्ध किया जाता है। और यह भी, ताकि ब्राउज़र स्वयं डोमेन को हल कर सकें और असामान्य ट्रैफ़िक न बना सकें।

वास्तव में, HTTPS और TLS पर DNS एक ही चीज़ हैं, थोड़े अलग अनुरोध प्रारूप के साथ। इन दोनों प्रोटोकॉल को मानकों के रूप में स्वीकार किया जाता है और एक RFC होता है। सबसे अधिक संभावना है, निकट भविष्य में हम दोनों के सामूहिक वितरण को देखेंगे।

DNSSEC डीएनएस रिकॉर्ड पर हस्ताक्षर करने के लिए एक प्रोटोकॉल है। यह एन्क्रिप्शन से संबंधित नहीं है, क्योंकि सभी अनुरोध स्पष्ट पाठ में प्रेषित किए जाते हैं। यह पुराने क्लासिक DNS प्रोटोकॉल, यानी UDP / TCP दोनों को पोर्ट 53 पर और DNS को TLS / HTTPS के अंदर काम कर सकता है। DNSSEC का उद्देश्य एक DNS रिकॉर्ड को प्रमाणित करना है। एक डोमेन स्वामी अपने डोमेन ज़ोन के रूट सर्वर में एक सार्वजनिक कुंजी जोड़ सकता है और एनएस सर्वर विज़ार्ड पर सभी प्रविष्टियों पर हस्ताक्षर कर सकता है। वास्तव में, प्रत्येक DNS रिकॉर्ड, उदाहरण के लिए, ए-रिकॉर्ड या एमएक्स-रिकॉर्ड, आरआरएसआईजी प्रकार का एक और रिकॉर्ड जोड़ा जाता है जिसमें हस्ताक्षर होते हैं। एक पुनरावर्ती रिज़ॉल्वर पर DNSSEC सत्यापन प्रक्रिया आपको यह स्थापित करने की अनुमति देती है कि क्या यह रिकॉर्ड वास्तव में डोमेन स्वामी द्वारा बनाया गया था।

सभी प्रोटोकॉलों की अधिक विस्तृत तुलना dnscrypt.info/faq (पैरा अन्य प्रोटोकॉल)

Google सार्वजनिक डीएनएस चुपचाप टीएलएस समर्थन पर डीएनएस को चालू कर दिया है