Сустракаем сэрвіс ад 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 працуе хутчэй за ўсіх канкурэнтаў (удакладню: замеры зроблены стронным сэрвісам, і хуткасць да канкрэтнага кліента, вядома, можа адрознівацца).

Значна цікавей праца з новымі рэжымамі, у якіх запыт ляціць на сервер па шыфраваным злучэнні (уласна, адказ вяртаецца па ім жа), згаданымі 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 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'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, стваральніка сэрвісу: яны зарабляюць свой хлеб, падтрымліваючы і развіваючы адну з самых папулярных CDN-сетак у свеце (сярод функцый якой - не толькі раздача кантэнту, але і хостынг DNS-зон), і, у сілу жадання тых , хто не вельмі разбіраецца, вучыць тых, каго яны не ведаюць, таму, куды хадзіць у глабальнай сетцы, досыць часта пакутуе ад блакіровак адрасоў сваіх сервераў са боку не будзем казаць каго — так што наяўнасць DNS, не схільнага ўплыву "окрыкаў, свісткоў і пісулек", для кампаніі азначае меншую шкоду іх бізнэсу. А тэхнічныя плюсы (дробязь, а прыемна: у прыватнасці, для кліентаў бясплатнага DNS Cloudflare абнаўленне DNS-запісаў рэсурсаў, размешчаных на DNS-серверах кампаніі, будзе імгненным) робяць карыстанне апісванага ў пасце сэрвісу яшчэ цікавейшым.

Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. Увайдзіце, Калі ласка.

Ці будзеце вы выкарыстоўваць новы сэрвіс?

• Так, проста паказаўшы яго ў АС і/ці на роўтары

• Так, і буду карыстацца новымі пратаколамі (DNS over HTTPs і DNS over TLS)

• Не, мне хапае бягучых сервераў (гэта публічны правайдэр: Google, Яндэкс і інш.)

• Не, я нават не ведаю, чым я зараз карыстаюся

• Выкарыстоўваю свае рэкурсіўныя DNS з SSL тунэлем да іх

Прагаласавалі 693 карыстальніка. Устрымаўся 191 карыстач.

Крыніца: habr.com