🥇Powitaj usługę od Cloudflare pod adresami 1.1.1.1 i 1.0.0.1, czyli "półka publicznych DNS powiększa się!"

Firma Cloudflare zaprezentowała publiczne DNS na adresach:

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

Twierdzi się, że stosowana jest polityka „Privacy first”, więc użytkownicy mogą być spokojni o treść swoich zapytań.

Usługa jest interesująca, ponieważ oprócz zwykłego DNS oferuje możliwość skorzystania z technologii DNS-over-TLS и DNS-over-HTTPS, co skutecznie utrudni dostawcom internetu podsłuchiwanie Twoich zapytań po drodze — zbieranie statystyk, monitorowanie, zarządzanie reklamą. Cloudflare twierdzi, że data ogłoszenia (1 kwietnia 2018 roku, czyli 04/01 w amerykańskiej notacji) została wybrana nieprzypadkowo: w którym innym dniu roku można zaprezentować „cztery jedynki”?

Ponieważ publiczność Habra jest technicznie zaznajomiona, tradycyjny dział „po co potrzebny jest DNS?” umieszczę na końcu posta, a tutaj przedstawię bardziej praktyczne rzeczy:

Jak korzystać z nowej usługi?

Najprościej — w swoim kliencie DNS (lub jako upstream w ustawieniach używanego lokalnego serwera DNS) podajemy powyższe adresy DNS-serwerów. Czy ma sens zastąpić tradycyjne wartości google'owskich DNS (8.8.8.8 itd.), lub nieco mniej popularnych publicznych serwerów DNS Yandexa (77.88.8.8 i podobne) na serwery Cloudflare — to rozwiąże wasze problemy, ale nowicjuszy nie dotyczy wykres czasy odpowiedzi, które pokazują, że Cloudflare działa szybciej niż wszyscy konkurenci (przy czym pomiary dokonano przez zewnętrzną usługę, a prędkość do konkretnego klienta może się różnić).

Znacznie ciekawsza jest praca z nowymi trybami, w których zapytanie wysyłane jest сервер przez szyfrowane połączenie (zresztą, odpowiedź wraca tą samą drogą), wymienionymi jako DNS-over-TLS i DNS-over-HTTPS. Niestety, „z pudełka” nie są one obsługiwane (autorzy wierzą, że to „na razie”), ale zorganizowanie ich działania w własnym oprogramowaniu (a nawet na własnym sprzęcie) nie jest trudne:

DNS over HTTPs (DoH)

Jak sugeruje nazwa, komunikacja odbywa się przez kanał HTTPS, co oznacza, że

konieczna jest punkt docelowy (endpoint) — znajduje się pod adresem https://cloudflare-dns.com/dns-query, a
klient, który potrafi wysyłać zapytania i odbierać odpowiedzi.

Zapytania mogą być w formacie DNS Wireformat, określonym w RFC1035 (wysyłane metodami HTTP POST i GET), lub w formacie JSON (używając metody HTTP GET). Osobiście myśl o wykonywaniu zapytań DNS przez zapytania HTTP wydaje mi się zaskakująca, jednak ma w sobie sens: takie zapytanie przejdzie przez wiele systemów filtrujących ruch, parsowanie odpowiedzi jest dość proste, a tworzenie zapytań — jeszcze prostsze. Za bezpieczeństwo odpowiadają znane biblioteki i protokoły.

Przykłady zapytań, bezpośrednio z dokumentacji:

Zapytanie GET w formacie DNS Wireformat

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Używając HTTP2, serwer wspiera wielokrotne użycie
* Stan połączenia zmieniony (HTTP/2 potwierdzono)
* Kopiowanie danych HTTP/2 z bufora strumienia do bufora połączenia po aktualizacji: len=0
* Używając ID strumienia: 1 (łatwe uchwyt 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* Stan połączenia zmieniony (MAX_CONCURRENT_STREAMS zaktualizowane)!
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 bajtów danych]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Połączenie #0 do hosta cloudflare-dns.com pozostało nienaruszone
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 bajtów danych]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Połączenie #0 do hosta cloudflare-dns.com pozostało nienaruszone
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 z użyciem 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"
    }
  ]
}

Jasne, że rzadki (jeśli w ogóle jakiś) router domowy potrafi tak obsługiwać DNS, ale to nie oznacza, że wsparcie nie pojawi się jutro — co ciekawe, tutaj możemy zrealizować obsługę DNS w własnej aplikacji (jak już planuje to zrobić Mozilla, właśnie na serwerach Cloudflare).

DNS over TLS

Domyślnie zapytania DNS są przesyłane bez szyfrowania. DNS over TLS to sposób przesyłania ich przez bezpieczne połączenie. Cloudflare wspiera DNS over TLS na standardowym porcie 853, jak nakazuje RFC7858. Używany jest certyfikat wystawiony dla hosta cloudflare-dns.com, wspierane są TLS 1.2 oraz TLS 1.3.

Nawiązanie połączenia i działanie protokołu przebiega mniej więcej tak:

Przed nawiązaniem połączenia klient DNS przechowuje zakodowany w base64 SHA256-hasz certyfikatu TLS hosta cloudflare-dns.com (nazywany SPKI)
Klient DNS nawiązuje połączenie TCP z cloudflare-dns.com:853
Klient DNS inicjuje procedurę handshake TLS
Podczas wymiany kluczy TLS, host cloudflare-dns.com przedstawia swój certyfikat TLS.
Gdy połączenie TLS jest już nawiązane, klient DNS może wysyłać zapytania DNS przez zabezpieczony kanał, co zapobiega podsłuchiwaniu i fałszowaniu zapytań oraz odpowiedzi.
Wszystkie zapytania DNS wysyłane przez połączenie TLS muszą spełniać specyfikację dotyczącą wysyłania DNS przez TCP.

Przykład zapytania przez DNS over TLS:

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Zapytanie dla owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, zaimportowano 170 certyfikatów systemowych
;; DEBUG: TLS, otrzymano hierarchię certyfikatów:
;; 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, pomijam weryfikację PIN certyfikatu
;; DEBUG: TLS, certyfikat jest zaufany.
;; Sesja TLS (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Flagi: qr rd ra; QUERY: 1; ODPOWIEDŹ: 1; AUTORYTET: 0; DODATKOWE: 1

;; EDNS PSEUDOSECTION:
;; Wersja: 0; flaga: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; SEKCJA ZAPYTAŃ:
;; example.com.             IN  A

;; SEKCJA ODPOWIEDZI:
example.com.            2347    IN  A   93.184.216.34

;; Otrzymano 468 B
;; Czas 2018-03-31 15:20:57 PDT
;; Z 1.1.1.1@853(TCP) w 12.6 ms

Ta opcja wydaje się lepiej dopasowana do lokalnych serwerów DNS służących potrzebom sieci lokalnej lub pojedynczego użytkownika. Choć wsparcie dla standardu nie wygląda najlepiej, miejmy nadzieję!

Dwa słowa wyjaśnień, o co chodzi

Skrót DNS oznacza Domena Name Service (więc określenie „serwis DNS” jest nieco zbędne, ponieważ w skrócie już zawarte jest słowo „serwis”), i jest używane do rozwiązania prostego zadania — zrozumieć, jaki adres IP przypisany jest do konkretnej nazwy hosta. Za każdym razem, gdy osoba klika link lub wpisuje w pasku adresu przeglądarki adres (powiedzmy, coś w stylu „https://habrahabr.ru/post/346430/„), komputer próbuje zrozumieć, do którego serwera powinien skierować zapytanie o zawartość strony. W przypadku habrahabr.ru odpowiedź z DNS będzie zawierać wskazanie na adres IP serwera WWW: 178.248.237.68, a następnie przeglądarka spróbuje połączyć się z serwerem o podanym adresie IP.

Serwer DNS, otrzymując zapytanie "jaki adres IP ma host o nazwie habrahabr.ru?", sprawdza, czy posiada informacje na temat wskazanego hosta. Jeśli nie, wysyła zapytanie do innych serwerów DNS na świecie, krok po kroku starając się ustalić odpowiedź na zadane pytanie. Na końcu, po uzyskaniu ostatecznej odpowiedzi, znaleziona informacja zostaje przekazana oczekującemu klientowi oraz zapisana w pamięci podręcznej serwera DNS, co pozwoli na szybsze odpowiedzenie na podobne pytania w przyszłości.

Typowym problemem jest to, że po pierwsze, dane z zapytań DNS są przesyłane w otwartej formie (co pozwala każdemu, kto ma dostęp do przepływu danych, wyodrębnić zapytania DNS oraz otrzymywane odpowiedzi, a następnie przeanalizować je dla swoich celów; umożliwia to precyzyjne kierowanie reklam do klientów DNS, co jest znaczącą sprawą!). Po drugie, niektórzy dostawcy internetu (nie będziemy wskazywać palcem, ale nie są to najmniejsi) mają tendencję do wyświetlania reklam zamiast żądanej strony (co realizowane jest dość prosto: zamiast określonego adresu IP dla zapytania o nazwę hosta habranabr.ru, użytkownik losowo otrzymuje adres serwera internetowego dostawcy, który zwraca stronę z reklamą). Po trzecie, istnieją dostawcy dostępu do internetu, którzy wdrażają mechanizmy realizacji wymogów dotyczących blokowania konkretnych stron, poprzez podmianę poprawnych odpowiedzi DNS na adresy IP blokowanych zasobów internetowych na adres IP własnego serwera, który zawiera strony zastępcze (w wyniku czego dostęp do takich stron staje się znacznie utrudniony), lub na adres swojego serwera proxy, który wykonuje filtrację.

Tutaj prawdopodobnie powinno znaleźć się zdjęcie z serwisu http://1.1.1.1/, służące do opisu połączenia z usługą. Autorzy wyraźnie są pewni jakości działania swojego DNS (w końcu trudno oczekiwać czegoś innego od Cloudflare):

Można całkowicie zrozumieć firmę Cloudflare, twórcę usługi: zarabiają na życie, wspierając i rozwijając jedną z najpopularniejszych sieci CDN na świecie (gdzie nie tylko dostarczanie treści, ale też hosting stref DNS jest jedną z funkcji), a z powodu potrzeby tych, którzy nie mają dużego doświadczenia, aby uczyć tych, których nie znają, w tym, gdzie chodzić w globalnej sieci, często cierpią na blokady adresów swoich serwerów ze strony niech będzie, nie mówmy o tym — więc posiadanie DNS, które nie podlega wpływom 'krzyków, gwizdów i karteczek', oznacza mniejsze szkody dla ich biznesu. A techniczne korzyści (drobnostka, a cieszy: w szczególności dla klientów darmowego DNS Cloudflare aktualizacja rekordów DNS zasobów, umieszczonych na serwerach DNS firmy, będzie natychmiastowa) sprawiają, że korzystanie z opisanego w poście serwisu jest jeszcze bardziej interesujące.

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.