🥇Witamy serwis od Cloudflare na adresach 1.1.1.1 i 1.0.0.1, czyli „półka publicznych DNS wzrosła!”

Firma Cloudflare przedstawił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”, dzięki czemu użytkownicy mogą być spokojni o treść swoich zapytań.

Usługa jest interesująca tym, że oprócz standardowego DNS oferuje możliwość korzystania z technologii DNS-over-TLS i DNS-over-HTTPS, co znacznie utrudni dostawcom usług podsłuchiwanie Twoich zapytań w trakcie ich przesyłania — oraz gromadzenie statystyk, monitorowanie, zarządzanie reklamami. Cloudflare twierdzi, że data ogłoszenia (1 kwietnia 2018, czyli 04/01 w amerykańskiej notacji) została wybrana nieprzypadkowo: w którym innym dniu roku można przedstawić „cztery jeden”?

Ponieważ społeczność Habr jest technicznie zaawansowana, tradycyjny dział „po co potrzebny jest DNS?” umieszczę na końcu wpisu, a tutaj przedstawiam bardziej praktyczne informacje:

Jak korzystać z nowej usługi?

Najprościej — w swoim kliencie DNS (lub jako upstream w ustawieniach używanego przez Ciebie lokalnego serwera DNS) podajemy wyżej wymienione adresy DNS-serwerów. Czy ma sens zastepować znane wartości google'owskimi DNS (8.8.8.8 itd.), albo nieco mniej popularnymi yandeksowskimi publicznymi serwerami DNS (77.88.8.8 i im podobnymi) serwerami Cloudflare — zdecydujecie sami, ale nowicjusz wskazuje wykres czasów odpowiedzi, z którego wynika, że Cloudflare działa szybciej niż wszyscy konkurenci (dodam: pomiary wykonane przez niezależną usługę, a prędkość do konkretnego klienta może oczywiście się różnić).

O wiele ciekawsza jest praca z nowymi trybami, w których zapytanie przesyłane jest serwer za pośrednictwem szyfrowanego połączenia (rzecz jasna, odpowiedź wraca tą samą drogą), czyli wspomnianymi DNS-over-TLS i DNS-over-HTTPS. Niestety, „out of the box” są one obecnie nieobsługiwane (autorzy wierzą, że to „na chwilę obecną”), ale zorganizowanie ich działania w Twoim programie (lub nawet na własnym sprzęcie) nie jest trudne:

DNS over HTTPs (DoH)

Jak wskazuje nazwa, komunikacja odbywa się na kanale HTTPS, co oznacza

konieczność posiadania punktu docelowego (endpoint) — znajduje się pod adresem https://cloudflare-dns.com/dns-query, oraz
klienta, który potrafi wysyłać zapytania i odbierać odpowiedzi.

Zapytania mogą być formatu DNS Wireformat, określonego w RFC1035 (wysyłanie za pomocą metod HTTP POST i GET), lub w formacie JSON (używa metody HTTP GET). Osobiście pomysł wykonywania zapytań DNS przez zapytania HTTP wydał mi się zaskakujący, jednak jest w nim sens: takie zapytanie przejdzie przez wiele systemów filtracji ruchu, odpowiedzi są łatwe do parsowania, a formułowanie zapytań — jeszcze prostsze. O 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 obsługuje wielokrotne użycie
* Zespół stanu połączenia zmieniony (HTTP/2 potwierdzone)
* Kopiowanie danych HTTP/2 w buforze strumieniowym do bufora połączenia po aktualizacji: len=0
* Używanie ID strumienia: 1 (łatwy uchwyt 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* Zespół stanu 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 z hostem cloudflare-dns.com pozostaje 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

Zapytanie 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 z hostem cloudflare-dns.com pozostaje 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"
    }
  ]
}

Oczywiste jest, że rzadki (jeśli w ogóle jakiś) domowy router potrafi tak pracować z DNS, ale to nie oznacza, że wsparcie nie pojawi się jutro — co ciekawe, tutaj w pełni możemy zrealizować pracę z DNS w naszej aplikacji (jak już planuje zrobić Mozilla, właśnie na serwerach Cloudflare).

DNS przez TLS

Domyślnie zapytania DNS są przesyłane bez szyfrowania. DNS over TLS to sposób przesyłania ich przez zabezpieczone połączenie. Cloudflare obsługuje DNS over TLS na standardowym porcie 853, zgodnie z zaleceniami RFC7858. W tym przypadku używany jest certyfikat wystawiony dla hosta cloudflare-dns.com, obsługiwane są TLS 1.2 i TLS 1.3.

Nawiązanie połączenia i działanie protokołu przebiega mniej więcej w ten sposób:

Przed nawiązaniem połączenia klient DNS przechowuje zakodowany w base64 hash SHA256 certyfikatu TLS cloudflare-dns.com (nazywany SPKI)
Klient DNS nawiązuje połączenie TCP z cloudflare-dns.com:853
Klient DNS inicjuje procedurę handshake TLS
W trakcie handshake TLS host cloudflare-dns.com przedstawia swój certyfikat TLS.
Gdy połączenie TLS zostanie 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ą być zgodne ze specyfikacją 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 o właściciela(example.com.), klasa(1), typ(1), serwer(1.1.1.1), port(853), protokół(TCP)
;; DEBUG: TLS, zaimportowano 170 certyfikatów systemowych
;; DEBUG: TLS, otrzymana hierarchia 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, pomijanie sprawdzania 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: ; rozmiar UDP: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; SEKCJA ZAPYTANIA:
;; 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ę bardziej odpowiednia dla lokalnych serwerów DNS obsługujących potrzeby lokalnej sieci lub jednego użytkownika. Prawda, z obsługą standardu nie jest to zbyt dobrze, ale miejmy nadzieję!

Dwa słowa wyjaśnienia, o czym jest mowa

Skrót DNS oznacza Domena Name Service (więc mówienie "usługa DNS" jest nieco zbędne, w skrócie już jest słowo "usługa"), i jest używane do rozwiązania prostej kwestii — zrozumieć, jaki adres IP ma konkretna nazwa hosta. Za każdym razem, gdy ktoś kliknie w link lub wpisuje w pasku adresu przeglądarki adres (powiedzmy coś takiego jakhttps://habrahabr.ru/post/346430/Kiedy komputer próbuje zrozumieć, do którego serwera należy skierować żądanie, aby otrzymać treść strony. W przypadku habrahabr.ru odpowiedź z DNS zawiera wskazanie na adres IP serwera WWW: 178.248.237.68, a następnie przeglądarka spróbuje nawiązać kontakt z serwerem o podanym adresie IP.

Z kolei serwer DNS, otrzymując zapytanie "jaki adres IP ma host o nazwie habrahabr.ru?", ustala, czy coś wie o wskazanym hoście. Jeśli nie, zadaje pytanie innym serwerom DNS na świecie i krok po kroku stara się znaleźć odpowiedź na postawione pytanie. W końcu, po znalezieniu ostatecznej odpowiedzi, otrzymane dane są wysyłane do oczekującego klienta, a także są zapisywane w pamięci podręcznej samego serwera DNS, co pozwoli w przyszłości odpowiedzieć na podobne pytanie znacznie szybciej.

Powszechnym problemem jest to, że, po pierwsze, dane zapytań DNS są przesyłane w otwartej formie (co pozwala wszystkim, którzy mają dostęp do strumienia danych, wyodrębnić zapytania DNS oraz otrzymane odpowiedzi, a następnie je analizować w swoich celach; umożliwia to celowanie w reklamy z dużą precyzją na klienta DNS, co nie jest małym problemem!). Po drugie, niektórzy dostawcy internetu (nie będziemy wskazywać palcem, ale to nie są najmniejsi) mają tendencję do wyświetlania reklam zamiast żądanej strony (co jest realizowane dość prosto: zamiast wskazanego adresu IP dla zapytania o nazwę hosta habranabr.ru, użytkownik losowo otrzymuje adres serwera WWW dostawcy, na którym wyświetlana jest strona z reklamą). Po trzecie, są dostawcy dostępu do internetu, którzy wdrażają mechanizm realizacji wymagań dotyczących blokowania poszczególnych stron, poprzez podmianę poprawnych odpowiedzi DNS o adresy IP blokowanych zasobów internetowych na adres IP swojego serwera, który zawiera strony zatrzymujące (w wyniku czego dostęp do takich stron jest znacznie utrudniony), lub na adres swojego serwera proxy, który przeprowadza filtrację.

Tutaj prawdopodobnie należy umieścić obrazek ze strony http://1.1.1.1/, służący do opisu połączenia z usługą. Autorzy wydają się całkowicie pewni jakości działania swojego DNS (choć od Cloudflare trudno oczekiwać czegoś innego):

Można zrozumieć firmę Cloudflare, twórcę usługi: zarabiają na życie, wspierając i rozwijając jedną z najpopularniejszych sieci CDN na świecie (której funkcje obejmują nie tylko dostarczanie treści, ale także hosting stref DNS), a przez pragnienie tych, którzy niezbyt się orientują, aby uczyć tych, których nie znają, o tym, gdzie chodzić w globalnej sieci, dość często cierpią z powodu blokad adresów swoich serwerów ze strony nie będziemy mówić, kto — więc posiadanie DNS, niepodlegającego wpływowi "okrików, gwizdów i karteczek", oznacza dla firmy mniejsze szkody w ich działalności. A techniczne plusy (niby drobiazg, ale miły: w szczególności dla klientów bezpłatnego DNS Cloudflare, aktualizacja rekordów DNS dla zasobów umieszczonych na serwerach DNS firmy będzie natychmiastowa) sprawiają, że korzystanie z opisanego w poście serwisu jest jeszcze ciekawsze.

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