ჩვენ ვხვდებით სერვისს Cloudflare-დან 1.1.1.1 და 1.0.0.1 მისამართებზე, ან "საჯარო DNS თარო მოვიდა!"

კომპანია Cloudflare წარმოდგენილი საჯარო DNS მისამართებზე:

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

ნათქვამია, რომ პოლიტიკა არის „პირველ რიგში კონფიდენციალურობა“, რათა მომხმარებლებმა მშვიდად იგრძნონ თავიანთი მოთხოვნების შინაარსი.

სერვისი საინტერესოა იმით, რომ ჩვეულებრივი DNS-ის გარდა, ის უზრუნველყოფს ტექნოლოგიების გამოყენების შესაძლებლობას DNS-ზე-TLS и DNS- ზე მეტი HTTPS, რაც მნიშვნელოვნად შეუშლის პროვაიდერებს თქვენი მოთხოვნების მოსმენაში მოთხოვნის გზაზე - და შეაგროვოს სტატისტიკა, მონიტორინგს, რეკლამის მართვას. Cloudflare ამტკიცებს, რომ განცხადების თარიღი (1 აპრილი, 2018, ან 04/01 ამერიკული ნოტაციით) შემთხვევით არ აირჩიეს: წლის რომელ დღეს იქნება წარმოდგენილი „ოთხი ერთეული“?

ვინაიდან Habr-ის აუდიტორია ტექნიკურად საზრიანია, ტრადიციული განყოფილება "რატომ გჭირდებათ DNS?" პოსტის ბოლოს დავდებ, მაგრამ აქ უფრო პრაქტიკულად სასარგებლო რამეებს დავასახელებ:

როგორ გამოვიყენოთ ახალი სერვისი?

უმარტივესი რამ არის ზემოაღნიშნული DNS სერვერის მისამართების მითითება თქვენს DNS კლიენტში (ან თქვენ მიერ გამოყენებული ადგილობრივი DNS სერვერის პარამეტრებში). აქვს თუ არა აზრი ჩვეულებრივი მნიშვნელობების შეცვლას Google DNS (8.8.8.8 და ა.შ.), ან ოდნავ ნაკლებად გავრცელებული Yandex საჯარო DNS სერვერები (77.88.8.8 და სხვა მსგავსი) სერვერებზე Cloudflare - ისინი გადაწყვეტენ თქვენთვის, მაგრამ საუბრობენ დამწყებთათვის გრაფიკით რეაგირების სიჩქარე, რომლის მიხედვითაც Cloudflare უფრო სწრაფია ვიდრე ყველა კონკურენტი (მე განვმარტავ: გაზომვები იქნა მიღებული მესამე მხარის სერვისის მიერ და კონკრეტული კლიენტის სიჩქარე, რა თქმა უნდა, შეიძლება განსხვავდებოდეს).

ბევრად უფრო საინტერესოა მუშაობა ახალ რეჟიმებთან, რომლებშიც მოთხოვნა სერვერზე მიფრინავს დაშიფრული კავშირის საშუალებით (ფაქტობრივად, პასუხი ბრუნდება მისი მეშვეობით), აღნიშნული DNS-over-TLS და DNS-over-HTTPS. სამწუხაროდ, ისინი არ არიან მხარდაჭერილი „გარეშე“ (ავტორებს მიაჩნიათ, რომ ეს „ჯერჯერობით“), მაგრამ ძნელი არ არის მათი მუშაობის ორგანიზება თქვენს პროგრამულ უზრუნველყოფაში (ან თუნდაც თქვენს აპარატურაზე):

DNS HTTP-ზე (DoH)

როგორც სახელი გვთავაზობს, კომუნიკაცია ხდება HTTPS არხზე, რაც ნიშნავს

1. სადესანტო წერტილის არსებობა (ბოლო წერტილი) - ის მდებარეობს მისამართზე https://cloudflare-dns.com/dns-queryდა
2. კლიენტი, რომელსაც შეუძლია მოთხოვნის გაგზავნა და პასუხების მიღება.

მოთხოვნები შეიძლება იყოს DNS Wireformat ფორმატში, რომელიც განსაზღვრულია RFC1035 (იგზავნება POST და GET HTTP მეთოდების გამოყენებით), ან JSON ფორმატში (GET HTTP მეთოდის გამოყენებით). პირადად ჩემთვის, HTTP მოთხოვნის საშუალებით DNS მოთხოვნების გაკეთების იდეა მოულოდნელი ჩანდა, მაგრამ მასში არის რაციონალური მარცვალი: ასეთი მოთხოვნა გაივლის მრავალი ტრაფიკის ფილტრაციის სისტემას, პასუხების ანალიზი საკმაოდ მარტივია, ხოლო მოთხოვნების გენერირება კიდევ უფრო ადვილია. უსაფრთხოებაზე პასუხისმგებელია ჩვეულებრივი ბიბლიოთეკები და პროტოკოლები.

მოითხოვეთ მაგალითები პირდაპირ დოკუმენტაციიდან:

მიიღეთ მოთხოვნა DNS Wireformat ფორმატში

$ 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

POST მოთხოვნა DNS Wireformat ფორმატში

$ 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"
    }
  ]
}

ცხადია, იშვიათი (თუ ერთი) სახლის როუტერს შეუძლია ამ გზით იმუშაოს DNS-ით, მაგრამ ეს არ ნიშნავს, რომ მხარდაჭერა ხვალ არ გამოჩნდება - და, საინტერესოა, რომ აქ ჩვენ შეგვიძლია საკმაოდ განვახორციელოთ DNS-თან მუშაობა ჩვენს აპლიკაციაში (როგორც უკვე აპირებს Mozilla-ს შექმნას, მხოლოდ Cloudflare სერვერებზე).

DNS მეტი TLS

ნაგულისხმევად, DNS მოთხოვნები გადაიცემა დაშიფვრის გარეშე. DNS TLS-ზე არის მათი გაგზავნის საშუალება უსაფრთხო კავშირით. Cloudflare მხარს უჭერს DNS-ს TLS-ზე სტანდარტულ პორტ 853-ზე, როგორც დადგენილია RFC7858. ეს იყენებს cloudflare-dns.com ჰოსტისთვის გაცემულ სერთიფიკატს, მხარდაჭერილია TLS 1.2 და TLS 1.3.

კავშირის დამყარება და პროტოკოლის მიხედვით მუშაობა ასე ხდება:

• DNS კავშირის დამყარებამდე, კლიენტი ინახავს cloudflare-dns.com-ის TLS სერტიფიკატის base64 კოდირებულ SHA256 ჰეშს (ე.წ. SPKI)
• DNS კლიენტი ამყარებს TCP კავშირს cloudflare-dns.com:853-თან
• DNS კლიენტი იწყებს TLS ხელის ჩამორთმევას
• TLS ხელის ჩამორთმევის პროცესის დროს, cloudflare-dns.com ჰოსტი წარმოადგენს თავის TLS სერთიფიკატს.
• TLS კავშირის დამყარების შემდეგ, DNS კლიენტს შეუძლია გააგზავნოს DNS მოთხოვნები უსაფრთხო არხზე, რაც ხელს უშლის მოთხოვნებისა და პასუხების მოსმენას და გაყალბებას.
• ყველა DNS მოთხოვნა, რომელიც გაგზავნილია TLS კავშირით, უნდა შეესაბამებოდეს DNS-ის გაგზავნა TCP-ით.

მოთხოვნის მაგალითი DNS-ით TLS-ზე:

$ 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 ნიშნავს Domain Name Service-ს (ასე რომ, „DNS სერვისის“ თქმა გარკვეულწილად ზედმეტია, აბრევიატურა უკვე შეიცავს სიტყვას „სერვისი“) და გამოიყენება მარტივი ამოცანის გადასაჭრელად - იმის გასაგებად, თუ რა IP მისამართი აქვს კონკრეტულ ჰოსტის სახელს. ყოველ ჯერზე, როცა ადამიანი დააწკაპუნებს ბმულზე, ან შეიყვანს მისამართს ბრაუზერის მისამართების ზოლში (მაგალითად, რაღაც "https://habrahabr.ru/post/346430/"), ადამიანის კომპიუტერი ცდილობს გაარკვიოს, რომელ სერვერზე გაგზავნოს მოთხოვნა გვერდის შინაარსის მისაღებად. habrahabr.ru-ს შემთხვევაში, DNS პასუხი შეიცავს მითითებას ვებ სერვერის IP მისამართის შესახებ: 178.248.237.68 და შემდეგ ბრაუზერი უკვე შეეცდება დაუკავშირდეს სერვერს მითითებული IP მისამართით.

თავის მხრივ, DNS სერვერმა მიიღო მოთხოვნა "რა არის ჰოსტის IP მისამართი, სახელად habrahabr.ru?", განსაზღვრავს, იცის თუ არა რაიმე მითითებულ ჰოსტის შესახებ. თუ არა, ის უგზავნის მოთხოვნას მსოფლიოს სხვა DNS სერვერებს და, ეტაპობრივად, ცდილობს გაერკვია დასმულ კითხვაზე პასუხი. შედეგად, საბოლოო პასუხის პოვნისთანავე, ნაპოვნი მონაცემები ეგზავნება კლიენტს, რომელსაც ჯერ კიდევ ელოდება, გარდა ამისა, ის ინახება თავად DNS სერვერის ქეშში, რაც საშუალებას მოგცემთ უპასუხოთ მსგავს კითხვას შემდეგ ჯერზე ბევრად უფრო სწრაფად.

საერთო პრობლემა ის არის, რომ, პირველ რიგში, DNS მოთხოვნის მონაცემები გადაცემულია მკაფიოდ (რაც ნებისმიერს, ვისაც აქვს წვდომა ტრაფიკის ნაკადზე, აძლევს შესაძლებლობას იზოლირება მოახდინოს DNS მოთხოვნებისა და მათ მიერ მიღებული პასუხების შესახებ და შემდეგ გააანალიზოს ისინი საკუთარი მიზნებისთვის; ეს იძლევა DNS კლიენტისთვის რეკლამების სიზუსტით დამიზნების შესაძლებლობა, რაც საკმაოდ ბევრია!). მეორეც, ზოგიერთი პროვაიდერი (ჩვენ არ ვაჩვენებთ თითს, მაგრამ არა ყველაზე პატარებს) ტენდენცია აქვთ აჩვენონ რეკლამები ამა თუ იმ მოთხოვნილი გვერდის ნაცვლად (რომელიც საკმაოდ მარტივად ხორციელდება: habranabr.ru-ს მიერ შეკითხვისთვის მითითებული IP მისამართის ნაცვლად). ჰოსტის სახელი, შემთხვევითი პირი. ამრიგად, ბრუნდება პროვაიდერის ვებ სერვერის მისამართი, სადაც განთავსებულია რეკლამის შემცველი გვერდი). მესამე, არსებობენ ინტერნეტთან წვდომის პროვაიდერები, რომლებიც ახორციელებენ მექანიზმს ინდივიდუალური საიტების დაბლოკვის მოთხოვნების შესასრულებლად დაბლოკილი ვებ რესურსების IP მისამართების შესახებ სწორი DNS პასუხების ჩანაცვლებით მათი სერვერის IP მისამართით, რომელიც შეიცავს გვერდებს (შედეგად, წვდომა ასეთი საიტები შესამჩნევად უფრო რთული), ან თქვენი პროქსი სერვერის მისამართზე, რომელიც ახორციელებს ფილტრაციას.

ეს ალბათ საიტის სურათი უნდა იყოს. http://1.1.1.1/, გამოიყენება სერვისთან კავშირის აღსაწერად. როგორც ჩანს, ავტორები საკმაოდ დარწმუნებულნი არიან თავიანთი DNS-ის ხარისხში (თუმცა, Cloudflare-ისგან სხვა რამის მოლოდინი ძნელია):

Cloudflare-ის, სერვისის შემქმნელის სრული გაგება შეიძლება: ისინი თავიანთ პურს შოულობენ მსოფლიოში ერთ-ერთი ყველაზე პოპულარული CDN ქსელის შენარჩუნებით და განვითარებით (რომელიც ფუნქციებში შედის არა მხოლოდ შინაარსის გავრცელება, არამედ DNS ზონების ჰოსტინგი) და მათი სურვილი, რომელიც კარგად არ ერკვევა, ასწავლე მათ ვისაც არ იცნობენ, იმისთვის სად წავიდეთ გლობალურ ქსელში, საკმაოდ ხშირად განიცდის მათი სერვერების მისამართების დაბლოკვას ნუ ვიტყვით ვინ - ასე რომ, DNS-ის ქონა, რომელსაც კომპანიისთვის „ყვირილი, სასტვენი და ჩანაწერი“ არ შეეხება, ნიშნავს ნაკლებ ზიანს მათ ბიზნესს. და ტექნიკური უპირატესობები (წვრილმანი, მაგრამ სასიამოვნო: კერძოდ, უფასო DNS Cloudflare-ის მომხმარებლებისთვის, კომპანიის DNS სერვერებზე განთავსებული რესურსების DNS ჩანაწერების განახლება მყისიერი იქნება) პოსტში აღწერილი სერვისის გამოყენებას კიდევ უფრო საინტერესოს გახდის.

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

ისარგებლებთ თუ არა ახალი სერვისით?

• დიახ, უბრალოდ OS-ში და/ან როუტერზე მითითებით

• დიახ, და მე გამოვიყენებ ახალ პროტოკოლებს (DNS HTTP-ზე და DNS TLS-ზე)

• არა, მე მაქვს საკმარისი მიმდინარე სერვერები (ეს არის საჯარო პროვაიდერი: Google, Yandex და ა.შ.)

• არა, არც კი ვიცი, რას ვიყენებ ახლა

• მე ვიყენებ ჩემს რეკურსიულ DNS-ს მათთან SSL გვირაბით

ხმა მისცა 693 მომხმარებელმა. 191 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com