हमें Cloudflare की सेवा 1.1.1.1 और 1.0.0.1 पते पर मिलती है, या "सार्वजनिक DNS शेल्फ़ आ गया है!"

क्लाउडफ्लेयर कंपनी प्रस्तुत पतों पर सार्वजनिक DNS:

• 1.1.1.1
• 1.0.0.1
• 2606: 4700: 4700 :: 1111
• 2606: 4700: 4700 :: 1001

नीति को "गोपनीयता पहले" कहा जाता है ताकि उपयोगकर्ताओं को अपने अनुरोधों की सामग्री के बारे में मानसिक शांति मिल सके।

यह सेवा इस मायने में दिलचस्प है कि सामान्य DNS के अलावा, यह प्रौद्योगिकियों का उपयोग करने की क्षमता प्रदान करती है डीएनएस-ओवर-टीएलएस и DNS-ओवर-HTTPS, जो प्रदाताओं को अनुरोधों के रास्ते में आपके अनुरोधों पर नज़र रखने से रोकेगा - और आंकड़े एकत्र करेगा, निगरानी करेगा, विज्ञापन प्रबंधित करेगा। क्लाउडफ्लेयर का दावा है कि घोषणा की तारीख (1 अप्रैल, 2018, या अमेरिकी संकेतन में 04/01) संयोग से नहीं चुनी गई थी: वर्ष के किस अन्य दिन "चार इकाइयाँ" प्रस्तुत की जाएंगी?

चूँकि हैबर के दर्शक तकनीकी रूप से समझदार हैं, पारंपरिक खंड "आपको DNS की आवश्यकता क्यों है?" मैं इसे पोस्ट के अंत में रखूंगा, लेकिन यहां मैं अधिक व्यावहारिक रूप से उपयोगी बातें बताऊंगा:

नई सेवा का उपयोग कैसे करें?

सबसे सरल बात यह है कि उपरोक्त DNS सर्वर पते को अपने DNS क्लाइंट में निर्दिष्ट करें (या आपके द्वारा उपयोग किए जाने वाले स्थानीय DNS सर्वर की सेटिंग्स में अपस्ट्रीम के रूप में)। क्या सामान्य मूल्यों को बदलने का कोई मतलब है? गूगल डीएनएस (8.8.8.8, आदि), या थोड़ा कम आम यांडेक्स सार्वजनिक डीएनएस सर्वर (77.88.8.8 और उनके जैसे अन्य) क्लाउडफ़ेयर के सर्वरों के लिए - वे आपके लिए निर्णय लेंगे, लेकिन एक शुरुआत के लिए बोलते हैं अनुसूची प्रतिक्रिया की गति, जिसके अनुसार क्लाउडफ्लेयर सभी प्रतिस्पर्धियों की तुलना में तेज़ है (मैं स्पष्ट कर दूंगा: माप तीसरे पक्ष की सेवा द्वारा लिया गया था, और किसी विशिष्ट ग्राहक की गति, निश्चित रूप से भिन्न हो सकती है)।

नए मोड के साथ काम करना अधिक दिलचस्प है जिसमें अनुरोध एक एन्क्रिप्टेड कनेक्शन (वास्तव में, प्रतिक्रिया इसके माध्यम से वापस आती है) पर सर्वर पर उड़ती है, उल्लिखित डीएनएस-ओवर-टीएलएस और डीएनएस-ओवर-एचटीटीपीएस। दुर्भाग्य से, वे "आउट ऑफ़ द बॉक्स" समर्थित नहीं हैं (लेखकों का मानना ​​है कि यह "अभी तक" है), लेकिन आपके सॉफ़्टवेयर (या यहां तक ​​कि आपके हार्डवेयर पर) में उनके काम को व्यवस्थित करना मुश्किल नहीं है:

HTTPs पर DNS (DoH)

जैसा कि नाम से पता चलता है, संचार HTTPS चैनल पर होता है, जिसका अर्थ है

1. एक लैंडिंग बिंदु (अंत बिंदु) की उपस्थिति - यह पते पर स्थित है https://cloudflare-dns.com/dns-queryऔर
2. एक ग्राहक जो अनुरोध भेज सकता है और प्रतिक्रिया प्राप्त कर सकता है।

अनुरोध या तो परिभाषित DNS वायरफॉर्मेट प्रारूप में हो सकते हैं RFC1035 (POST और GET HTTP विधियों का उपयोग करके भेजा गया), या JSON प्रारूप में (GET HTTP विधि का उपयोग करके)। मेरे लिए व्यक्तिगत रूप से, HTTP अनुरोधों के माध्यम से DNS अनुरोध करने का विचार अप्रत्याशित लग रहा था, लेकिन इसमें एक तर्कसंगत पहलू है: ऐसा अनुरोध कई ट्रैफ़िक फ़िल्टरिंग सिस्टम को पार कर जाएगा, प्रतिक्रियाओं को पार्स करना काफी सरल है, और अनुरोध उत्पन्न करना और भी आसान है। सुरक्षा के लिए सामान्य पुस्तकालय और प्रोटोकॉल जिम्मेदार हैं।

दस्तावेज़ से सीधे उदाहरणों का अनुरोध करें:

DNS वायरफॉर्मेट प्रारूप में अनुरोध प्राप्त करें

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
HTTP/2 200
date: Fri, 23 Mar 2018 05:14:02 GMT
content-type: application/dns-udpwireformat
content-length: 49
cache-control: max-age=0
set-cookie: __cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=Sat, 23-Mar-19 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly
server: cloudflare-nginx
cf-ray: 3ffe69838a418c4c-SFO-DOG

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

डीएनएस वायरफॉर्मेट प्रारूप में पोस्ट अनुरोध

$ echo -n 'q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | base64 -D | curl -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://cloudflare-dns.com/dns-query -o - | hexdump

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

वही लेकिन JSON का उपयोग कर रहा हूँ

$ curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=example.com&type=AAAA'

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "example.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "example.com.",
      "type": 1,
      "TTL": 1069,
      "data": "93.184.216.34"
    }
  ]
}

जाहिर है, एक दुर्लभ (यदि कम से कम एक) होम राउटर इस तरह से डीएनएस के साथ काम कर सकता है, लेकिन इसका मतलब यह नहीं है कि समर्थन कल दिखाई नहीं देगा - और, दिलचस्प बात यह है कि यहां हम अपने एप्लिकेशन में डीएनएस के साथ काम करने को काफी हद तक लागू कर सकते हैं (जैसा कि पहले से ही है) मोज़िला बनाने जा रहा हूँ, केवल Cloudflare सर्वर पर)।

टीएलएस पर डीएनएस

डिफ़ॉल्ट रूप से, DNS क्वेरीज़ एन्क्रिप्शन के बिना प्रसारित की जाती हैं। टीएलएस पर डीएनएस उन्हें सुरक्षित कनेक्शन पर भेजने का एक तरीका है। क्लाउडफ्लेयर निर्धारित मानक पोर्ट 853 पर टीएलएस पर डीएनएस का समर्थन करता है RFC7858. यह Cloudflare-dns.com होस्ट के लिए जारी प्रमाणपत्र का उपयोग करता है, TLS 1.2 और TLS 1.3 समर्थित हैं।

कनेक्शन स्थापित करना और प्रोटोकॉल के अनुसार काम करना कुछ इस प्रकार है:

• DNS कनेक्शन स्थापित करने से पहले, क्लाइंट क्लाउडफ्लेयर-डीएनएस.कॉम के टीएलएस प्रमाणपत्र (जिसे एसपीकेआई कहा जाता है) का बेस 64 एन्कोडेड SHA256 हैश संग्रहीत करता है।
• DNS क्लाइंट Cloudflare-dns.com:853 से एक TCP कनेक्शन स्थापित करता है
• DNS क्लाइंट TLS हैंडशेक आरंभ करता है
• टीएलएस हैंडशेक प्रक्रिया के दौरान, Cloudflare-dns.com होस्ट अपना टीएलएस प्रमाणपत्र प्रस्तुत करता है।
• एक बार टीएलएस कनेक्शन स्थापित हो जाने पर, डीएनएस क्लाइंट एक सुरक्षित चैनल पर डीएनएस क्वेरी भेज सकता है, जो अनुरोधों और प्रतिक्रियाओं को गुप्त और नकली होने से रोकता है।
• टीएलएस कनेक्शन पर भेजे गए सभी डीएनएस प्रश्नों को इसका अनुपालन करना होगा टीसीपी पर डीएनएस भेजना.

टीएलएस पर डीएनएस के माध्यम से अनुरोध का एक उदाहरण:

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 170 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare, Inc.,CN=*.cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; QUESTION SECTION:
;; example.com.             IN  A

;; ANSWER SECTION:
example.com.            2347    IN  A   93.184.216.34

;; Received 468 B
;; Time 2018-03-31 15:20:57 PDT
;; From 1.1.1.1@853(TCP) in 12.6 ms

यह विकल्प स्थानीय नेटवर्क या एकल उपयोगकर्ता की ज़रूरतों को पूरा करने वाले स्थानीय DNS सर्वरों के लिए सबसे अच्छा काम करता प्रतीत होता है। सच है, मानक का समर्थन बहुत अच्छा नहीं है, लेकिन - आशा करते हैं!

बातचीत किस बारे में है, इसकी व्याख्या के लिए दो शब्द

संक्षिप्त नाम DNS का अर्थ डोमेन नाम सेवा है (इसलिए "DNS सेवा" कहना कुछ हद तक अनावश्यक है, संक्षिप्त नाम में पहले से ही "सेवा" शब्द शामिल है), और इसका उपयोग एक सरल कार्य को हल करने के लिए किया जाता है - यह समझने के लिए कि किसी विशेष होस्ट नाम का आईपी पता क्या है। हर बार जब कोई व्यक्ति किसी लिंक पर क्लिक करता है, या ब्राउज़र के एड्रेस बार में कोई पता दर्ज करता है (मान लीजिए, कुछ इस तरह)https://habrahabr.ru/post/346430/"), मानव कंप्यूटर यह पता लगाने की कोशिश कर रहा है कि पृष्ठ की सामग्री प्राप्त करने के लिए किस सर्वर को अनुरोध भेजना है। Habrahabr.ru के मामले में, DNS की प्रतिक्रिया में वेब सर्वर आईपी पते का एक संकेत होगा: 178.248.237.68, और फिर ब्राउज़र पहले से ही निर्दिष्ट आईपी पते के साथ सर्वर से संपर्क करने का प्रयास करेगा।

बदले में, DNS सर्वर, अनुरोध प्राप्त करके "habrahabr.ru नामक होस्ट का आईपी पता क्या है?", यह निर्धारित करता है कि क्या वह निर्दिष्ट होस्ट के बारे में कुछ जानता है। यदि नहीं, तो यह दुनिया के अन्य DNS सर्वरों से अनुरोध करता है, और, चरण दर चरण, पूछे गए प्रश्न का उत्तर जानने का प्रयास करता है। परिणामस्वरूप, अंतिम उत्तर मिलने पर, पाया गया डेटा उस क्लाइंट को भेज दिया जाता है जो अभी भी उनका इंतजार कर रहा है, साथ ही यह DNS सर्वर के कैश में ही संग्रहीत होता है, जो आपको अगली बार इसी तरह के प्रश्न का उत्तर बहुत तेजी से देने की अनुमति देगा।

एक आम समस्या यह है कि, सबसे पहले, DNS क्वेरी डेटा को स्पष्ट रूप से प्रसारित किया जाता है (जो ट्रैफ़िक प्रवाह तक पहुंच रखने वाले किसी भी व्यक्ति को DNS क्वेरीज़ और उन्हें प्राप्त होने वाली प्रतिक्रियाओं को अलग करने और फिर उन्हें अपने उद्देश्यों के लिए पार्स करने की क्षमता देता है; यह देता है) DNS क्लाइंट के लिए सटीकता के साथ विज्ञापनों को लक्षित करने की क्षमता, जो काफी है!)। दूसरे, कुछ आईएसपी (हम उंगलियां नहीं उठाएंगे, लेकिन सबसे छोटे वाले भी नहीं) एक या दूसरे अनुरोधित पेज के बजाय विज्ञापन दिखाते हैं (जिसे काफी सरलता से लागू किया जाता है: habranabr.ru द्वारा एक क्वेरी के लिए निर्दिष्ट आईपी पते के बजाय) होस्ट नाम, एक यादृच्छिक व्यक्ति इस प्रकार, प्रदाता के वेब सर्वर का पता वापस कर दिया जाता है, जहां विज्ञापन वाला पृष्ठ परोसा जाता है)। तीसरा, ऐसे इंटरनेट एक्सेस प्रदाता हैं जो अवरुद्ध वेब संसाधनों के आईपी पते के बारे में सही डीएनएस प्रतिक्रियाओं को स्टब पृष्ठों वाले अपने सर्वर के आईपी पते के साथ बदलकर व्यक्तिगत साइटों को अवरुद्ध करने की आवश्यकताओं को पूरा करने के लिए तंत्र को लागू करते हैं (परिणामस्वरूप, पहुंच) ऐसी साइटें काफ़ी अधिक जटिल होती हैं), या आपके प्रॉक्सी सर्वर के पते पर जो फ़िल्टरिंग करता है।

यह संभवतः साइट से लिया गया चित्र होना चाहिए. http://1.1.1.1/, सेवा से कनेक्शन का वर्णन करने के लिए उपयोग किया जाता है। लेखक अपने DNS की गुणवत्ता को लेकर काफी आश्वस्त प्रतीत होते हैं (हालाँकि, Cloudflare से किसी और चीज़ की उम्मीद करना कठिन है):

सेवा के निर्माता क्लाउडफ्लेयर को कोई भी पूरी तरह से समझ सकता है: वे दुनिया में सबसे लोकप्रिय सीडीएन नेटवर्क में से एक को बनाए रखने और विकसित करने से अपनी रोटी कमाते हैं (जिसमें कार्यों में न केवल सामग्री वितरित करना, बल्कि डीएनएस जोन की मेजबानी भी शामिल है), और, के कारण उन लोगों की चाहत, जो पारंगत नहीं है, उनको सिखाओ जिन्हें वे नहीं जानते, उस के लिए कहाँ जाए वैश्विक नेटवर्क में, अक्सर अपने सर्वर के पते को अवरुद्ध करने से पीड़ित होते हैं आइए यह न कहें कि कौन - इसलिए ऐसा DNS होना जो कंपनी के लिए "चिल्लाने, सीटी बजाने और हाथापाई" से प्रभावित न हो, इसका मतलब है कि उनके व्यवसाय को कम नुकसान होगा। और तकनीकी फायदे (एक छोटी सी, लेकिन अच्छी बात: विशेष रूप से, मुफ्त डीएनएस क्लाउडफ्लेयर के ग्राहकों के लिए, कंपनी के डीएनएस सर्वर पर होस्ट किए गए संसाधनों के डीएनएस रिकॉर्ड को अपडेट करना तुरंत होगा) पोस्ट में वर्णित सेवा का उपयोग करना और भी दिलचस्प बनाते हैं।

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या आप नई सेवा का उपयोग करेंगे?

• हां, इसे केवल ओएस और/या राउटर पर निर्दिष्ट करके

• हां, और मैं नए प्रोटोकॉल का उपयोग करूंगा (HTTP पर DNS और TLS पर DNS)

• नहीं, मेरे पास पर्याप्त वर्तमान सर्वर हैं (यह एक सार्वजनिक प्रदाता है: Google, Yandex, आदि)

• नहीं, मुझे यह भी नहीं पता कि मैं अभी क्या उपयोग कर रहा हूं

• मैं उनके लिए एसएसएल सुरंग के साथ अपने पुनरावर्ती डीएनएस का उपयोग करता हूं

693 उपयोगकर्ताओं ने मतदान किया। 191 उपयोगकर्ता ने भाग लिया।

स्रोत: www.habr.com