Syarikat Cloudflare DNS awam di alamat:
- 1.1.1.1
- 1.0.0.1
- 2606: 4700: 4700 :: 1111
- 2606: 4700: 4700 :: 1001
Dasar ini dikatakan sebagai "Privasi didahulukan" supaya pengguna boleh berasa tenang tentang kandungan permintaan mereka.
Perkhidmatan ini menarik kerana, sebagai tambahan kepada DNS biasa, ia menyediakan keupayaan untuk menggunakan teknologi DNS-over-TLS ΠΈ DNS-over-HTTPS, yang akan sangat menghalang pembekal daripada mencuri dengar permintaan anda di sepanjang laluan permintaan - dan mengumpul statistik, memantau, mengurus pengiklanan. Cloudflare mendakwa bahawa tarikh pengumuman (1 April 2018, atau 04/01 dalam tatatanda Amerika) tidak dipilih secara kebetulan: apakah hari lain dalam tahun yang akan "empat unit" itu dibentangkan?
Memandangkan penonton Habr mahir secara teknikal, bahagian tradisional "mengapa anda memerlukan DNS?" Saya akan meletakkannya di penghujung jawatan, tetapi di sini saya akan menyatakan perkara yang lebih praktikal:
Bagaimana untuk menggunakan perkhidmatan baharu?
Perkara yang paling mudah ialah untuk menentukan alamat pelayan DNS di atas dalam klien DNS anda (atau sebagai huluan dalam tetapan pelayan DNS tempatan yang anda gunakan). Adakah masuk akal untuk menggantikan nilai biasa (8.8.8.8, dsb.), atau kurang biasa (77.88.8.8 dan lain-lain seperti mereka) kepada pelayan daripada Cloudflare - mereka akan membuat keputusan untuk anda, tetapi bercakap untuk pemula kelajuan tindak balas, mengikut mana Cloudflare lebih pantas daripada semua pesaing (saya akan menjelaskan: pengukuran telah diambil oleh perkhidmatan pihak ketiga, dan kelajuan kepada pelanggan tertentu, sudah tentu, mungkin berbeza).
Adalah lebih menarik untuk bekerja dengan mod baharu di mana permintaan itu dihantar ke pelayan melalui sambungan yang disulitkan (sebenarnya, respons dikembalikan melaluinya), DNS-over-TLS dan DNS-over-HTTPS yang disebutkan. Malangnya, mereka tidak disokong "di luar kotak" (pengarang percaya bahawa ini "belum"), tetapi tidak sukar untuk mengatur kerja mereka dalam perisian anda (atau bahkan pada perkakasan anda):
DNS melalui HTTP (DoH)
Seperti namanya, komunikasi berlaku melalui saluran HTTPS, yang bermaksud
- kehadiran titik pendaratan (titik akhir) - ia terletak di alamat dan
- pelanggan yang boleh menghantar permintaan dan menerima respons.
Permintaan boleh sama ada dalam format DNS Wireformat yang ditakrifkan dalam (dihantar menggunakan kaedah POST dan GET HTTP), atau dalam format JSON (menggunakan kaedah HTTP GET). Bagi saya secara peribadi, idea untuk membuat permintaan DNS melalui permintaan HTTP nampaknya tidak dijangka, tetapi terdapat butiran yang rasional di dalamnya: permintaan sedemikian akan melepasi banyak sistem penapisan lalu lintas, menghuraikan respons agak mudah, dan menjana permintaan lebih mudah. Perpustakaan dan protokol biasa bertanggungjawab untuk keselamatan.
Minta contoh, terus dari dokumentasi:
DAPATKAN permintaan dalam format 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
0000031Permintaan POST dalam format 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
Sama tetapi menggunakan 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"
}
]
}Jelas sekali, penghala rumah yang jarang berlaku (jika sekurang-kurangnya satu) boleh berfungsi dengan DNS dengan cara ini, tetapi ini tidak bermakna sokongan tidak akan muncul esok - dan, menariknya, di sini kami boleh melaksanakan kerja dengan DNS dalam aplikasi kami (seperti yang sudah , hanya pada pelayan Cloudflare).
DNS melalui TLS
Secara lalai, pertanyaan DNS dihantar tanpa penyulitan. DNS melalui TLS ialah cara untuk menghantarnya melalui sambungan selamat. Cloudflare menyokong DNS melalui TLS pada port standard 853 seperti yang ditetapkan . Ini menggunakan sijil yang dikeluarkan untuk hos cloudflare-dns.com, TLS 1.2 dan TLS 1.3 disokong.
Mewujudkan sambungan dan bekerja mengikut protokol berjalan seperti ini:
- Sebelum mewujudkan sambungan DNS, pelanggan menyimpan cincangan SHA64 yang dikodkan base256 bagi sijil TLS cloudflare-dns.com (dipanggil SPKI)
- Pelanggan DNS mewujudkan sambungan TCP ke cloudflare-dns.com:853
- Pelanggan DNS memulakan jabat tangan TLS
- Semasa proses jabat tangan TLS, hos cloudflare-dns.com membentangkan sijil TLSnya.
- Setelah sambungan TLS diwujudkan, klien DNS boleh menghantar pertanyaan DNS melalui saluran selamat, yang menghalang permintaan dan respons daripada didengari dan ditipu.
- Semua pertanyaan DNS yang dihantar melalui sambungan TLS mesti mematuhi .
Contoh permintaan melalui DNS melalui 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 msPilihan ini nampaknya berfungsi paling baik untuk pelayan DNS tempatan yang memenuhi keperluan rangkaian tempatan atau pengguna tunggal. Benar, dengan sokongan standard tidak begitu baik, tetapi - mari kita berharap!
Dua perkataan penjelasan tentang maksud perbualan
Singkatan DNS adalah singkatan dari Perkhidmatan Nama Domain (jadi mengatakan "perkhidmatan DNS" agak berlebihan, singkatan sudah mengandungi perkataan "perkhidmatan"), dan digunakan untuk menyelesaikan tugas mudah - untuk memahami alamat IP yang dimiliki oleh nama hos tertentu. Setiap kali seseorang mengklik pada pautan atau memasukkan alamat dalam bar alamat penyemak imbas (katakan, sesuatu seperti ""), komputer manusia sedang cuba memikirkan pelayan mana untuk menghantar permintaan untuk mendapatkan kandungan halaman. Dalam kes habrahabr.ru, respons daripada DNS akan mengandungi petunjuk alamat IP pelayan web: 178.248.237.68, dan kemudian penyemak imbas akan cuba menghubungi pelayan dengan alamat IP yang ditentukan.
Sebaliknya, pelayan DNS, setelah menerima permintaan "apakah alamat IP hos bernama habrahabr.ru?", menentukan sama ada ia mengetahui apa-apa tentang hos yang ditentukan. Jika tidak, ia membuat permintaan kepada pelayan DNS lain di dunia, dan, langkah demi langkah, cuba memikirkan jawapan kepada soalan yang ditanya. Akibatnya, apabila mencari jawapan muktamad, data yang ditemui dihantar kepada pelanggan yang masih menunggu mereka, ditambah ia disimpan dalam cache pelayan DNS itu sendiri, yang akan membolehkan anda menjawab soalan yang sama dengan lebih cepat pada masa akan datang.
Masalah biasa ialah, pertama, data pertanyaan DNS dihantar secara jelas (yang memberikan sesiapa yang mempunyai akses kepada aliran trafik keupayaan untuk mengasingkan pertanyaan DNS dan respons yang mereka terima dan kemudian menghuraikannya untuk tujuan mereka sendiri; ini memberikan keupayaan untuk menyasarkan iklan dengan ketepatan untuk pelanggan DNS, yang agak banyak!). Kedua, sesetengah ISP (kami tidak akan menuding jari, tetapi bukan yang terkecil) cenderung untuk memaparkan iklan dan bukannya satu atau satu lagi halaman yang diminta (yang dilaksanakan secara ringkas: bukannya alamat IP yang ditentukan untuk pertanyaan oleh habranabr.ru nama hos, orang rawak Oleh itu, alamat pelayan web pembekal dikembalikan, di mana halaman yang mengandungi iklan dihidangkan). Ketiga, terdapat penyedia akses Internet yang melaksanakan mekanisme untuk memenuhi keperluan untuk menyekat tapak individu dengan menggantikan respons DNS yang betul tentang alamat IP sumber web yang disekat dengan alamat IP pelayan mereka yang mengandungi halaman rintisan (akibatnya, akses kepada tapak sedemikian nyata lebih rumit), atau ke alamat pelayan proksi anda yang menjalankan penapisan.
Ini mungkin gambar dari tapak. , digunakan untuk menerangkan sambungan kepada perkhidmatan. Penulis nampaknya agak yakin dengan kualiti DNS mereka (namun, sukar untuk mengharapkan apa-apa lagi daripada Cloudflare):
Seseorang boleh memahami sepenuhnya Cloudflare, pencipta perkhidmatan: mereka memperoleh pendapatan mereka dengan mengekalkan dan membangunkan salah satu rangkaian CDN yang paling popular di dunia (yang berfungsi termasuk bukan sahaja mengedarkan kandungan, tetapi juga menganjurkan zon DNS), dan, disebabkan oleh keinginan mereka, yang kurang arif, ajar mereka yang mereka tidak kenali, untuk itu mana nak pergi dalam rangkaian global, selalunya mengalami penyekatan alamat pelayan mereka daripada jangan cakap siapa - jadi mempunyai DNS yang tidak terjejas oleh "jerit, wisel dan coretan" untuk syarikat bermakna kurang bahaya kepada perniagaan mereka. Dan kelebihan teknikal (sedikit, tetapi bagus: khususnya, untuk pelanggan DNS Cloudflare percuma, mengemas kini rekod DNS sumber yang dihoskan pada pelayan DNS syarikat akan menjadi serta-merta) menjadikan penggunaan perkhidmatan yang diterangkan dalam siaran itu lebih menarik.
Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. , Sama-sama.
Adakah anda akan menggunakan perkhidmatan baharu?
-
Ya, dengan hanya menyatakannya dalam OS dan / atau pada penghala
-
Ya, dan saya akan menggunakan protokol baharu (DNS melalui HTTP dan DNS melalui TLS)
-
Tidak, saya mempunyai pelayan semasa yang mencukupi (ini adalah pembekal awam: Google, Yandex, dsb.)
-
Tidak, saya tidak tahu apa yang saya gunakan sekarang
-
Saya menggunakan DNS rekursif saya dengan terowong SSL kepada mereka
693 pengguna mengundi. 191 pengguna berpantang.
Sumber: www.habr.com