Usługę od Cloudflare spotykamy pod adresami 1.1.1.1 i 1.0.0.1, czyli „dotarła publiczna półka DNS!”

Firma Cloudflare представила publiczny DNS pod adresami:

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

Mówi się, że polityka ta stawia na pierwszym miejscu prywatność, aby użytkownicy mogli mieć pewność co do treści swoich żądań.

Usługa jest o tyle interesująca, że ​​oprócz zwykłego DNS zapewnia możliwość korzystania z technologii DNS-przez TLS и DNS-over-HTTPS, co znacznie uniemożliwi dostawcom podsłuchiwanie Twoich żądań na ścieżce żądań - oraz zbieranie statystyk, monitorowanie, zarządzanie reklamami. Cloudflare twierdzi, że data zapowiedzi (1 kwietnia 2018 r., czyli 04 w notacji amerykańskiej) nie została wybrana przypadkowo: w jaki inny dzień w roku zaprezentowane zostaną „cztery jednostki”?

Ponieważ odbiorcy Habr są doświadczeni technicznie, tradycyjna sekcja „Dlaczego potrzebujesz DNS?” Umieszczę to na końcu wpisu, ale tutaj wymienię rzeczy bardziej praktyczne:

Jak korzystać z nowej usługi?

Najprościej jest podać powyższe adresy serwerów DNS w swoim kliencie DNS (lub jako upstream w ustawieniach lokalnego serwera DNS, którego używasz). Czy ma sens zastąpienie zwykłych wartości DNSy Google’a (8.8.8.8 itd.) lub nieco rzadziej Publiczne serwery DNS Yandex (77.88.8.8 i inne im podobne) na serwery z Cloudflare - oni zadecydują za Ciebie, ale mówi to za początkującego planować szybkość reakcji, według której Cloudflare jest szybszy niż wszyscy konkurenci (wyjaśnię: pomiary zostały wykonane przez usługę strony trzeciej, a prędkość do konkretnego klienta może się oczywiście różnić).

O wiele ciekawiej jest pracować z nowymi trybami, w których żądanie leci do serwera za pośrednictwem szyfrowanego połączenia (w rzeczywistości odpowiedź jest przez nie zwracana), wspomnianymi DNS-over-TLS i DNS-over-HTTPS. Niestety nie są one wspierane „od razu po wyjęciu z pudełka” (autorzy uważają, że to „jeszcze”), ale zorganizowanie ich pracy w swoim oprogramowaniu (a nawet na sprzęcie) nie jest trudne:

DNS przez HTTPs (DoH)

Jak sama nazwa wskazuje, komunikacja odbywa się poprzez kanał HTTPS, co oznacza

1. obecność punktu docelowego (punktu końcowego) - znajduje się on pod adresem https://cloudflare-dns.com/dns-queryi
2. klient, który może wysyłać żądania i odbierać odpowiedzi.

Żądania mogą być w formacie DNS Wireformat zdefiniowanym w RFC1035 (przesyłane metodami POST i GET HTTP) lub w formacie JSON (przy użyciu metody GET HTTP). Dla mnie osobiście pomysł wysyłania żądań DNS za pośrednictwem żądań HTTP wydawał się nieoczekiwany, ale jest w nim racjonalne ziarno: takie żądanie przejdzie przez wiele systemów filtrujących ruch, parsowanie odpowiedzi jest dość proste, a generowanie żądań jest jeszcze łatwiejsze. Za bezpieczeństwo odpowiadają zwykłe biblioteki i protokoły.

Poproś o przykłady prosto z dokumentacji:

Żądanie GET w formacie 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

Żądanie POST w formacie 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

To samo, ale używając 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"
    }
  ]
}

Oczywiście rzadki (jeśli chociaż jeden) router domowy może w ten sposób współpracować z DNS, ale to nie znaczy, że obsługa nie pojawi się jutro - i co ciekawe, tutaj możemy całkiem zaimplementować pracę z DNS w naszej aplikacji (jak już zamierzam stworzyć Mozillę, tylko na serwerach Cloudflare).

DNS przez TLS

Domyślnie zapytania DNS są przesyłane bez szyfrowania. DNS przez TLS to sposób na przesłanie ich przez bezpieczne połączenie. Cloudflare obsługuje DNS przez TLS na standardowym porcie 853 zgodnie z zaleceniami RFC7858. Wykorzystuje certyfikat wydany dla hosta cloudflare-dns.com. Obsługiwane są protokoły TLS 1.2 i TLS 1.3.

Nawiązanie połączenia i praca zgodnie z protokołem przebiega mniej więcej tak:

• Przed nawiązaniem połączenia DNS klient przechowuje zakodowany w formacie Base64 skrót SHA256 certyfikatu TLS cloudflare-dns.com (zwany SPKI)
• Klient DNS ustanawia połączenie TCP z cloudflare-dns.com:853
• Klient DNS inicjuje uzgadnianie TLS
• Podczas procesu uzgadniania TLS host cloudflare-dns.com przedstawia swój certyfikat TLS.
• Po nawiązaniu połączenia TLS klient DNS może wysyłać żądania DNS za pośrednictwem bezpiecznego kanału, co zapobiega podsłuchiwaniu i fałszowaniu żądań i odpowiedzi.
• Wszystkie zapytania DNS wysyłane przez połączenie TLS muszą być zgodne z wysyłanie DNS przez TCP.

Przykład żądania za pośrednictwem DNS przez 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

Ta opcja wydaje się działać najlepiej w przypadku lokalnych serwerów DNS obsługujących potrzeby sieci lokalnej lub pojedynczego użytkownika. Co prawda przy wsparciu standardu nie jest zbyt dobrze, ale – miejmy nadzieję!

Dwa słowa wyjaśnienia o czym jest rozmowa

Skrót DNS oznacza usługę nazw domen (więc określenie „usługa DNS” jest nieco zbędne, skrót zawiera już słowo „usługa”) i służy do rozwiązania prostego zadania - zrozumienia, jaki adres IP ma konkretna nazwa hosta. Za każdym razem, gdy ktoś kliknie łącze lub wprowadzi adres w pasku adresu przeglądarki (powiedzmy, coś w rodzaju „https://habrahabr.ru/post/346430/"), komputer ludzki próbuje dowiedzieć się, do którego serwera wysłać żądanie pobrania zawartości strony. W przypadku habrahabr.ru odpowiedź z DNS będzie zawierać wskazanie adresu IP serwera WWW: 178.248.237.68, a wtedy przeglądarka będzie już próbowała skontaktować się z serwerem o podanym adresie IP.

Z kolei serwer DNS po otrzymaniu zapytania „jaki jest adres IP hosta o nazwie habrahabr.ru?” sprawdza, czy wie cokolwiek o podanym hoście. Jeśli nie, wysyła żądanie do innych serwerów DNS na świecie i krok po kroku próbuje znaleźć odpowiedź na zadane pytanie. Dzięki temu po znalezieniu ostatecznej odpowiedzi znalezione dane wysyłane są do oczekującego na nie klienta oraz zapisywane w pamięci podręcznej samego serwera DNS, co pozwoli następnym razem odpowiedzieć na podobne pytanie znacznie szybciej.

Powszechnym problemem jest to, że po pierwsze dane zapytań DNS są przesyłane w sposób jawny (co daje każdemu, kto ma dostęp do przepływu ruchu, możliwość izolowania zapytań DNS i otrzymanych odpowiedzi, a następnie analizowania ich do własnych celów; daje to możliwość targetowania reklam z dokładnością do klienta DNS, a to całkiem sporo!). Po drugie, niektórzy dostawcy usług internetowych (nie będziemy wskazywać palcami, ale nie ci najmniejsi) mają tendencję do wyświetlania reklam zamiast tej czy innej żądanej strony (co jest realizowane po prostu: zamiast podanego adresu IP dla zapytania habranabr.ru nazwa hosta, losowa osoba W ten sposób zwracany jest adres serwera internetowego dostawcy, na którym wyświetlana jest strona zawierająca reklamę). Po trzecie, istnieją dostawcy dostępu do Internetu, którzy wdrażają mechanizm spełnienia wymagań blokowania poszczególnych witryn poprzez zastąpienie prawidłowych odpowiedzi DNS o adresach IP blokowanych zasobów sieciowych adresem IP swojego serwera zawierającego strony pośredniczące (w efekcie dostęp do takie strony są zauważalnie bardziej skomplikowane) lub na adres Twojego serwera proxy, który wykonuje filtrowanie.

To powinno być prawdopodobnie zdjęcie ze strony. http://1.1.1.1/, używany do opisu połączenia z usługą. Autorzy wydają się być całkiem pewni jakości swojego DNS (jednak od Cloudflare trudno oczekiwać czegoś innego):

Można w pełni zrozumieć Cloudflare, twórcę usługi: zarabia na chleb utrzymując i rozwijając jedną z najpopularniejszych sieci CDN na świecie (której funkcje obejmują nie tylko dystrybucję treści, ale także hosting stref DNS), a dzięki pragnienie tych, który nie jest dobrze zorientowany, naucz ich kogo nie znają, do tego Gdzie iść w sieci globalnej, dość często boryka się z blokowaniem adresów swoich serwerów nie mówmy kto - zatem posiadanie DNS, na który nie mają wpływu „krzyki, gwizdki i bazgroły” dla firmy oznacza mniej szkód dla jej działalności. A zalety techniczne (drobno, ale miłe: w szczególności dla klientów darmowego DNS Cloudflare aktualizacja rekordów DNS zasobów hostowanych na firmowych serwerach DNS będzie błyskawiczna) sprawiają, że korzystanie z usługi opisanej w poście jest jeszcze ciekawsze.

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Czy skorzystasz z nowej usługi?

• Tak, po prostu określając to w systemie operacyjnym i/lub na routerze

• Tak, i będę korzystać z nowych protokołów (DNS przez HTTPs i DNS przez TLS)

• Nie, mam wystarczającą liczbę obecnych serwerów (jest to dostawca publiczny: Google, Yandex itp.)

• Nie, nawet nie wiem, czego teraz używam

• Używam mojego rekurencyjnego DNS z tunelem SSL do nich

Głosowało 693 użytkowników. 191 użytkownik wstrzymał się od głosu.

Źródło: www.habr.com