Срещаме услугата от Cloudflare на адреси 1.1.1.1 и 1.0.0.1 или „публичният DNS рафт пристигна!“

Срещаме услугата от 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-over-TLS и DNS-над-HTTPS, което значително ще попречи на доставчиците да подслушват вашите заявки по пътя на заявките - и да събират статистики, да наблюдават, да управляват реклами. Cloudflare твърди, че датата на анонса (1 април 2018 г. или 04/01 в американската нотация) не е избрана случайно: кой друг ден от годината ще бъдат представени „четирите единици“?

Тъй като аудиторията на Habr е технически разбирана, традиционният раздел "защо имате нужда от DNS?" Ще го сложа в края на поста, но тук ще изложа още практически полезни неща:

Как да използвате новата услуга?

Най-простото нещо е да посочите горните адреси на DNS сървъри във вашия DNS клиент (или нагоре в настройките на локалния DNS сървър, който използвате). Има ли смисъл да се заменят обичайните стойности Google DNS (8.8.8.8 и т.н.) или малко по-рядко Обществени DNS сървъри на Yandex (77.88.8.8 и други подобни) към сървърите от Cloudflare - те ще решат вместо вас, но говори за начинаещ разписание скорост на реакция, според която Cloudflare е по-бърз от всички конкуренти (ще изясня: измерванията са направени от услуга на трета страна и скоростта за конкретен клиент, разбира се, може да се различава).

Срещаме услугата от Cloudflare на адреси 1.1.1.1 и 1.0.0.1 или „публичният DNS рафт пристигна!“

Много по-интересно е да се работи с нови режими, в които заявката лети до сървъра през криптирана връзка (всъщност отговорът се връща през него), споменатите DNS-over-TLS и DNS-over-HTTPS. За съжаление, те не се поддържат „извън кутията“ (авторите смятат, че това е „все още“), но не е трудно да организирате работата им във вашия софтуер (или дори на вашия хардуер):

DNS през HTTPs (DoH)

Както подсказва името, комуникацията се осъществява по HTTPS канал, което означава

  1. наличието на точка за кацане (крайна точка) - намира се на адрес https://cloudflare-dns.com/dns-queryИ
  2. клиент, който може да изпраща заявки и да получава отговори.

Заявките могат да бъдат във формата на DNS Wireformat, дефиниран в RFC1035 (изпратено чрез методите POST и GET HTTP) или във формат JSON (чрез метода GET HTTP). За мен лично идеята да правя DNS заявки чрез HTTP заявки изглеждаше неочаквана, но в нея има рационално зърно: такава заявка ще премине много системи за филтриране на трафика, анализирането на отговорите е доста просто и генерирането на заявки е още по-лесно. Обичайните библиотеки и протоколи са отговорни за сигурността.

Поискайте примери, направо от документацията:

GET заявка във формат 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 връзка, клиентът съхранява base64 кодиран SHA256 хеш на TLS сертификата на cloudflare-dns.com (наречен 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 означава услуга за имена на домейни (така че казването „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 клиент, което е доста!). Второ, някои интернет доставчици (няма да сочим с пръст, но не и най-малките) са склонни да показват реклами вместо една или друга заявена страница (което се реализира доста просто: вместо посочения IP адрес за заявка от habranabr.ru име на хост, случаен човек По този начин се връща адресът на уеб сървъра на доставчика, където се обслужва страницата, съдържаща рекламата). Трето, има доставчици на достъп до интернет, които прилагат механизъм за изпълнение на изискванията за блокиране на отделни сайтове, като заменят правилните DNS отговори за IP адресите на блокираните уеб ресурси с IP адреса на техния сървър, съдържащ страници-мънички (в резултат на това достъпът до такива сайтове значително по-сложни), или до адреса на вашия прокси сървър, който извършва филтриране.

Това вероятно трябва да е снимка от сайта. http://1.1.1.1/, използван за описание на връзката към услугата. Авторите изглеждат доста уверени в качеството на своя DNS (обаче е трудно да се очаква нещо друго от Cloudflare):

Срещаме услугата от Cloudflare на адреси 1.1.1.1 и 1.0.0.1 или „публичният DNS рафт пристигна!“

Човек може напълно да разбере Cloudflare, създателя на услугата: те печелят хляба си, като поддържат и развиват една от най-популярните CDN мрежи в света (които функции включват не само разпространение на съдържание, но и хостване на DNS зони), и поради желанието на тези, който не е добре запознат, научи тези които не познават, към това Къде да отидем в глобалната мрежа доста често страда от блокиране на адресите на своите сървъри от да не казваме кой - така че наличието на DNS, който не е засегнат от "викове, подсвирквания и драсканици" за компанията означава по-малко вреда за техния бизнес. И техническите предимства (дреболия, но хубаво: по-специално за клиентите на безплатния DNS Cloudflare, актуализирането на DNS записите на ресурсите, хоствани на DNS сървърите на компанията, ще бъде незабавно) правят използването на услугата, описана в публикацията, още по-интересно.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Ще ползвате ли новата услуга?

  • Да, като просто го посочите в операционната система и / или на рутера

  • Да, и ще използвам нови протоколи (DNS през HTTPs и DNS през TLS)

  • Не, имам достатъчно текущи сървъри (това е обществен доставчик: Google, Yandex и др.)

  • Не, дори не знам какво използвам в момента

  • Използвам моя рекурсивен DNS с SSL тунел към тях

693 потребители гласуваха. 191 потребител се въздържа.

Източник: www.habr.com

Добавяне на нов коментар