ProHoster > Блог > адміністрування > Зустрічаємо сервіс від Cloudflare на адресах 1.1.1.1 та 1.0.0.1, або «полку публічних DNS прибуло!»

Зустрічаємо сервіс від Cloudflare на адресах 1.1.1.1 та 1.0.0.1, або «полку публічних DNS прибуло!»

Зустрічаємо сервіс від Cloudflare на адресах 1.1.1.1 та 1.0.0.1, або «полку публічних DNS прибуло!»

Компанія Cloudflare представила публічні ДНС на адресах:

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

Стверджується, що використовується політика Privacy first, так що користувачі можуть бути спокійні за зміст своїх запитів.

Сервіс цікавий тим, що окрім звичайного DNS надає можливість використовувати технології DNS через TLS и DNS через HTTPS, Що здорово завадить провайдерам шляхом запитів підслуховувати ваші запити - і збирати статистику, стежити, керувати рекламою. Cloudflare стверджує, що дату анонсу (1 квітня 2018, або 04/01 в американській нотації) було обрано не випадково: в який ще день року уявити «чотири одиниці»?

Оскільки аудиторія Хабра технічно підкована, традиційний розділ «навіщо потрібний DNS?» я поміщу під кінець посту, а тут викладу практично корисні речі:

Як використати новий сервіс?

Найпростіше - у своєму DNS-клієнті (або як upstream в налаштуваннях використовуваного вами локального DNS-сервера) вказуємо наведені вище адреси DNS-серверів. Чи має сенс замінити звичні значення гуглівських DNS (8.8.8.8 і т.д.), або трохи менш поширених яндексівських публічних серверів DNS (77.88.8.8 і іже з ними) на сервері від Cloudflare - вирішать вам, але за новачка каже графік швидкості відповідей, згідно з яким Cloudflare працює швидше за всіх конкурентів (уточню: виміри зроблені стронним сервісом, і швидкість до конкретного клієнта, звичайно, може відрізнятися).

Зустрічаємо сервіс від Cloudflare на адресах 1.1.1.1 та 1.0.0.1, або «полку публічних DNS прибуло!»

Набагато цікавішою є робота з новими режимами, в яких запит відлітає на сервер по шифрованому з'єднанню (власне, відповідь повертається по ньому ж), згаданими DNS-over-TLS і DNS-over-HTTPS. На жаль, «з коробки» вони не підтримуються (автори вірять, що це «поки що»), але організувати у своєму ПО (або навіть на своїй залізниці) їхню роботу нескладно:

DNS over HTTPs (DoH)

Як і слідує з назви, спілкування йде поверх HTTPS-каналу, що передбачає

  1. наявність точки приземлення (endpoint) – він знаходиться за адресою https://cloudflare-dns.com/dns-query, І
  2. клієнта, який вміє надсилати запити, та отримувати відповіді.

Запити можуть бути або у форматі 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
* 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 over TLS — це спосіб надсилати їх захищеним з'єднанням. Cloudflare підтримує DNS over TLS на стандартному порту 853, як передбачається RFC7858. При цьому використовується сертифікат, виписаний для хоста cloudflare-dns.com, підтримуються TLS 1.2 та TLS 1.3.

Встановлення зв'язку та робота з протоколу відбувається приблизно так:

  • До встановлення з'єднання з DNS клієнт зберігає закодований base64 SHA256-хеш TLS-сертифіката cloudflare-dns.com's (званий 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: 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, а це дуже багато!). По-друге, деякі інтернет-провайдери (не показуватимемо пальцем, але не найменші) мають тенденцію показу реклами замість тієї чи іншої запитаної сторінки (що реалізується дуже просто: замість зазначеної 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 over HTTPs та DNS over TLS)

  • Ні, мені вистачає поточних серверів (це публічний провайдер: Google, Яндекс та ін.)

  • Ні, я навіть не знаю, чим я зараз користуюся

  • Використовую свої рекурсивні DNS із SSL тунелем до них

Проголосували 693 користувача. Утримався 191 користувач.

Джерело: habr.com

Додати коментар або відгук