Компания Cloudflare представи публични DNS на адреси:
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
Твърди се, че се използва политика „Privacy first“, така че потребителите могат да са спокойни за съдържанието на своите заявки.
Услугата е интересна с това, че освен обикновен DNS предлага възможност за използване на технологии DNS-over-TLS и DNS-over-HTTPS, което значително пречи на доставчиците да подслушват вашите заявки по пътя им — и събиране на статистика, следене, управление на реклама. Cloudflare твърди, че датата на анонса (1 април 2018 г., или 04/01 в американската нотация) е избрана неслучайно: в кой друг ден от годината да се представят „четирите единици“?
Тъй като аудиторията на Хабра е технически подготвена, традиционният раздел „защо е нужен DNS?“ ще поставя в края на поста, а тук ще изложа по-практически полезни неща:
Как да използвате новата услуга?
Най-простото е в своя DNS клиент (или като upstream в настройките на локалния DNS сървър, който използвате) да посочите горепосочените адреси на DNS-сървърите. Има ли смисъл да заменим познатите стойности на Google DNS (8.8.8.8 и т.н.), или малко по-малко разпространените на публичните DNS сървъри на Yandex (77.88.8.8 и подобни) с серверите на Cloudflare — ще решите вие, но за новаците говори график на скоростите на отговорите, според който Cloudflare работи по-бързо от всички конкуренти (нека уточня: измерванията са направени от трети сервис и скоростта до конкретния клиент, разбира се, може да се различава).
Много по-интересна е работата с новите режими, при които заявките се изпращат сървър по шифровани връзки (всъщност, отговорите се връщат по същия начин), споменати DNS-over-TLS и DNS-over-HTTPS. За съжаление, те не се поддържат „из коробки“ (авторите вярват, че това е „засега“), но е лесно да организирате работата им на собственото си ПО (или дори на собственото си оборудване):
DNS over HTTPs (DoH)
Както подсказва името, комуникацията протича през HTTPS канал, което предполага
- наличието на точка за свързване (endpoint) — тя се намира на адрес https://cloudflare-dns.com/dns-query, и
- клиент, който може да изпраща запитвания и да получава отговори.
Запитванията могат да бъдат в формат DNS Wireformat, определен в RFC1035 (използвайки HTTP методи POST и GET), или в JSON формат (използва HTTP метод GET). Лично за мен идеята да се правят DNS запитвания чрез HTTP запитвания изглеждаше неочаквано, но има рационално зърно в нея: такова запитване ще премине през много системи за филтриране на трафика, парсването на отговорите е достатъчно лесно, а формирането на запитванията - още по-лесно. За безопасността отговарят познати библиотеки и протоколи.
Примери на запитвания, направо от документацията:
GET запитване в DNS Wireformat
$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Използване на HTTP2, сървърът поддържа многократна употреба
* Променено състояние на връзката (HTTP/2 потвърдено)
* Копиране на HTTP/2 данни в буфера на връзката след ъпгрейда: len=0
* Използване на Stream ID: 1 (лесно хендъл 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*
* Променено състояние на връзката (MAX_CONCURRENT_STREAMS актуализирано)!
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
* Връзка #0 към хоста cloudflare-dns.com остана непокътната
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
* Връзка #0 към хоста cloudflare-dns.com остана непокътната
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 over TLS
По подразбиране DNS заявките се предават без криптиране. DNS over TLS е метод за изпращане на тези заявки по защитена връзка. Cloudflare поддържа DNS over 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 handshake.
- По време на TLS handshake, хостът cloudflare-dns.com представя своя TLS сертификат.
- След като TLS връзката е установена, DNS клиентът може да изпраща DNS заявки през защитен канал, предотвратявайки подслушване и фалшифициране на заявките и отговорите.
- Всички DNS заявки, изпращани през TLS връзка, трябва да отговарят на спецификацията за изпращане на DNS през TCP..
Пример за заявка чрез DNS over TLS:
$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Запитване за owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, импортирани 170 системни сертификата
;; DEBUG: TLS, получен сертификатен хиерархичен ред:
;; 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, пропускане на проверка на сертификатния PIN
;; DEBUG: TLS, Сертификатът е надежден.
;; TLS сесия (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; статус: NOERROR; id: 58548
;; Флагове: qr rd ra; QUERY: 1; ОТГОВОР: 1; АВТОРИТЕТ: 0; ДОПЪЛНИТЕЛЕН: 1
;; EDNS ПСЕУДОСЕКЦИЯ:
;; Версия: 0; флагове: ; UDP размер: 1536 B; ext-rcode: NOERROR
;; ПАДДИНГ: 408 B
;; ВЪПРОСНА СЕКЦИЯ:
;; example.com. IN A
;; ОТГОВОРНА СЕКЦИЯ:
example.com. 2347 IN A 93.184.216.34
;; Получено 468 B
;; Време 2018-03-31 15:20:57 PDT
;; От 1.1.1.1@853(TCP) за 12.6 ms
Тази опция изглежда по-подходяща за локални DNS сървъри, обслужващи нуждите на локалната мрежа или на един потребител. Въпреки че с поддръжката на стандарта нещата не изглеждат много добре, но — ще се надяваме!
Два думи за пояснение, за какво става дума
Съкращението DNS означава Домейн 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, което е значително!). От друга страна, някои интернет провайдери (да не сочим с пръст, но не са най-малките) имат тенденция да показват реклами вместо определени искани страници (което се реализира доста просто: вместо посочения IP адрес за заявка по име на хост habranabr.ru, на човека произволно се връща адрес на уеб сървъра на провайдера, където се предоставя страница с реклами). В-трети, съществуват интернет доставчици, които реализират механизъм за изпълнение на изискванията за блокиране на отделни сайтове, чрез подмяна на правилните DNS отговори за IP адресите на блокираните уеб ресурси с IP адреса на своя сървър, съдържащ страници-заместители (в резултат достъпът до такива сайтове става значително по-труден), или към адреса на своя прокси сървър, осъществяващ филтрация.
Тук вероятно трябва да поставите снимка от сайта http://1.1.1.1/, която служи за описание на свързването към услугата. Авторите, както изглежда, са напълно уверени в качеството на работата на своя DNS (впрочем, трудно е да се очаква нещо друго от Cloudflare):
Може да разберем компанията Cloudflare, създател на услугата: те изкарват прехраната си, като поддържат и развиват една от най-популярните CDN мрежи в света (включваща функции не само за разпространение на съдържание, но и хостване на DNS зони) и, поради желанието на тези, които не разбират много, да обучат тези, които не познават, какво, къде да търсят в глобалната мрежа, често страдат от блокировки на адресите на своите сървъри от нека не споменаваме кой — така че наличието на DNS, неподвластен на "изкривания, свирки и писма", означава по-малко вреда за техния бизнес. А техническите предимства (малка подробност, но приятна: по-специално, за клиентите на безплатния DNS на Cloudflare, обновяването на DNS записите на ресурсите, хоствани на DNS сървърите на компанията, ще бъде мигновено) правят използването на обсъжданата услуга още по-интересно.
Само регистрирани потребители могат да участват в анкетата. Влезте, моля.
Ще използвате ли новата услуга?
- Да, просто като я посочите в ОС и/или на рутера
- Да, и ще ползвам новите протоколи (DNS over HTTPs и DNS over TLS)
- Не, достатъчни са ми текущите сървъри (това е публичен доставчик: Гугъл, Яндекс и др.)
- Не, дори не знам какво ползвам в момента
- Използвам собствените си рекурсивни DNS с SSL тунел до тях
Гласували са 693 потребители. 191 потребител се е въздържал.
Източник: habr.com
