Cloudflare oferuje nowe DNS-y
#1
Za DP
Cytat:Wybór Pierwszego Kwietnia na publiczne udostępnienie nowego serwera DNS nie był przypadkowy – adres IP to cztery jedynki, a skoro data to czwarty miesiąc, pierwszy dzień, to tym łatwiej będzie to zapamiętać. Zapasowy serwer też jest łatwy do zapamiętania: 1.0.0.1. A wszystko to po to, aby utrudnić dostawcom usług internetowych szpiegowanie aktywności swoich klientów w sieci. Tak, dotyczy to też ogromnie popularnego google’owego serwera 8.8.8.8.

Matthew Prince, współzałożyciel Cloudflare, stwierdził: uważamy to za odrażające, że dane użytkowników są sprzedawane reklamodawcom i używane do namierzania konsumentów bez ich wiedzy i zgody. Szczerze mówiąc, nie chcemy wiedzieć co ludzie robią w Internecie, to nie nasza sprawa. Zaprojektowaliśmy 1.1.1.1 tak, by zapewnić, że ani my, ani dostawcy internetu z całego świata też nie będą mogli tego wiedzieć.

Tak więc nowa usługa DNS nie tylko wspiera wszelkie standardowe mechanizmy bezpieczeństwa dla rozwiązywania domen, ale też takie, które dopiero stają się standardami. Wspierany jest więc DNS-over-TLS, ale też eksperymentalnie wdrożony w Firefoksie protokół DoH, czyli DNS over HTTPS, działa z 1.1.1.1. Dzięki temu można całkowicie ukryć przed dostawcą Internetu, które domeny odwiedzamy, cały ruch jest już dla niego zaszyfrowany.

Cloudflare zapewnia też, że nowa usługa DNS gromadzone z konieczności logi usuwa nieodwracalnie po 24 godzinach. Prawdziwość tych wszystkich deklaracji związanych z prywatnością zagwarantować ma doroczny audyt słynnej szwajcarskiej firmy KPMG.

Wybierając 1.1.1.1 dostajemy też obietnicę najwyższej wydajności, potwierdzoną przez DNSperf, niezależny benchmark serwisów DNS. Pod względem czystej wydajności, usługa Cloudflare jest ponad dwukrotnie szybsza od google’owego DNS-a 8.8.8.8 i uruchomionego przez IBM serwera 9.9.9.9.

Adres można zmienić we właściwościach połączenia sieciowego dla TCP/IPv4:
preferowany serwer  - 1.1.1.1
alternatywny sewer - 1.0.0.1

Źródło

[Aby zobaczyć linki, zarejestruj się tutaj]


Strona projektu

[Aby zobaczyć linki, zarejestruj się tutaj]

"Bezpieczeństwo jest podróżą, a nie celem samym w sobie - to nie jest problem, który można rozwiązać raz na zawsze"
"Zaufanie nie stanowi kontroli, a nadzieja nie jest strategią"
Odpowiedz
#2
Właśnie wczoraj widziałem i ustawiłem, co nie którzy piszą że jeszcze zależy od operatora neta (komentarze z dp)
Odpowiedz
#3
Poniżej dwa artykuły wskazujące na nieco inne aspekty tych DNS

[Aby zobaczyć linki, zarejestruj się tutaj]

@nykolas.z/dns-resolvers-performance-compared-cloudflare-x-google-x-quad9-x-opendns-149e803734e5

[Aby zobaczyć linki, zarejestruj się tutaj]

"Bezpieczeństwo jest podróżą, a nie celem samym w sobie - to nie jest problem, który można rozwiązać raz na zawsze"
"Zaufanie nie stanowi kontroli, a nadzieja nie jest strategią"
Odpowiedz
#4
Ja nie dawno przestawiłem sie na Quad9 i mi sie podoba teraz zmieniłem na Cloudfire i też jest ok Smile
Warstwy ochrony

1)Ograniczenie/blokowanie dostępu do danych/aplikacji
2)Odizolowanie i tworzenie osobnych baz danych/aplikacji
3)Kopia zapasowa systemu/ważnych danych.
4)Wykrywanie i kasowanie wirusów/złośliwych aplikacji.
Odpowiedz
#5
U mnie zestawianie połączenia TLS trwa wyraźnie dłużej niż ping do Cloudflare, ale może oprogramowanie DNS może to jakoś zoptymalizować. Do tego czasu DNSCrypt jest szybszy.
Odpowiedz
#6
a z jakimi serwerami łączysz sie z DNScrypt ?!
Warstwy ochrony

1)Ograniczenie/blokowanie dostępu do danych/aplikacji
2)Odizolowanie i tworzenie osobnych baz danych/aplikacji
3)Kopia zapasowa systemu/ważnych danych.
4)Wykrywanie i kasowanie wirusów/złośliwych aplikacji.
Odpowiedz
#7
(04.04.2018, 14:34)Quassar napisał(a):

[Aby zobaczyć linki, zarejestruj się tutaj]

a z jakimi serwerami łączysz sie z DNScrypt ?!
Nie chodzi tylko o serwery i trasy do nich, ale sam protokół. Zestawienie połączenia TLS trwa więcej niż zapytania DNSCrypta.
Inna sprawa, że użyłem klienta DNS over TLS, który podobno nie umie używać wcześniej otwartych połączeń TLS. Stubby podobno umie. Sprawdzę i porównam.
Odpowiedz
#8
Sprawdzam, ale mam problemy. Duża ilość odpytań Stubb-iego tak szybko zwraca odpowiedzi (ułamki milisekundy), że chyba tylko cache'owanie wewnątrz Stubbiego albo inna optymalizacja może być wyjaśnieniem. Aby sprawiedliwie porównać z DNSCryptem Stubby nie mógłby wewnętrznie cache'ować.
Raczej więc nie będę w stanie ich porównać. Mimo to dalej bardziej prawdopodobne dla mnie jest, że TLS jest wolniejsze niż DNSCrypt.
Odpowiedz
#9
Ja u siebie przetestowałem znanym sobie DNS Jumper...był kiedyś u nas

[Aby zobaczyć linki, zarejestruj się tutaj]

...i wynik jest bardzo przyzwoity zwłaszcza jeśli weźmie się pod uwagę obydwa adresy
   
"Bezpieczeństwo jest podróżą, a nie celem samym w sobie - to nie jest problem, który można rozwiązać raz na zawsze"
"Zaufanie nie stanowi kontroli, a nadzieja nie jest strategią"
Odpowiedz
#10
A użyłem tego DNS Jumpera z 10x śmigłem test i CloudFire nieco szybciej od google lub na równi.

Ichito wiesz ..ustaw sobie CloudFlare jako główny DNS na kompie albo jeszcze lepiej na routerze i potem sprawdź cloudfire.

Bo jak masz inny DNS niż testowany to wynik wychodzi gorszy dlatego takie testy powinno się robić przy aktualnym włączonym DNS który testujesz i pingować połączenia do stron trzecich a nie z DNS do DNS, bo taką metodą można sopro DNS nawzajem wykluczyć.


Załączone pliki Miniatury
   
Warstwy ochrony

1)Ograniczenie/blokowanie dostępu do danych/aplikacji
2)Odizolowanie i tworzenie osobnych baz danych/aplikacji
3)Kopia zapasowa systemu/ważnych danych.
4)Wykrywanie i kasowanie wirusów/złośliwych aplikacji.
Odpowiedz
#11
Moje doświadczenia.
Z jakiegoś względu DNS over TLS jest zwykle wolniejsze od DNS over HTTPS (DoH).
DNSCrypt pod względem wydajności dalej nie jest złym rozwiązaniem, a jest oferowany przez m.in. OpenDNS i Quad9.
DNSCrypt ma przewagę wydajnościową przy pojedynczych żądaniach, a przy kilku DoH zaczyna go doganiać.

Do DoH i DNSCrypta używam dnscrypt-proxy. Program ten na początku jednak potrzebuje pobrać pliki z adresami serwerów, a do tego rozwiązać nazwy domen na IP. Używa do tego nieszyfrowanych połączeń. Chciałem się tego ustrzec, zablokowałem takie pakiety na firewallu i ustawiłem, by dla domeny i poddomen quad9.net były kierowane do Stubby-iego, który jednak oferuje tylko DNS over TLS, ale za to konfigurowany jest statycznie. Wydajność jednak była mało zadowalająca (chociaż i takie jest używany na samym początku, więc to nie ma takiego znaczenia, ale miałem ochotę poeksperymentować), dlatego zacząłem modyfikować config. Z tego co widzę:
Secure renegotiation nie jest obsługiwane przez Cloudflare i Quad9 na porcie 853, gdy połączenie to TLS wersja 1.3 (ale już na porcie 443 tak...). Ustawiłem więc TLS na wersję 1.2, przy którym secure renegotiation jest obsługiwane. 

Kod:
    # Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
    # This option can also be given per upstream.
    tls_min_version: GETDNS_TLS1_2

    # Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
    # This option can also be given per upstream.
    tls_max_version: GETDNS_TLS1_2

Ogólnie przy takim ustawieniu częściej zdarza się, że kilka rozwiązań domen dokonuje się w ramach jednego połączenia TLS.

Wyłączyłem również DNSSEC, ale tylko w Stubby-im, który u mnie rozwiązuje domenę i poddomeny quad9.net:

Kod:
#dnssec: GETDNS_EXTENSION_TRUE

Dla tych kilku żądań od DNSCrypt wystarczy mi zwykłe połączenie TLS 1.2 z uwierzytelnieniem przez sprawdzenie z pinsetem.
Dodatkowo według moich doświadczeń serwer Quad9 9.9.9.10 bez filtrowania, bez DNSSEC i innych dodatkowych featurów jest wyraźnie szybszy niż z filtrowaniem 9.9.9.9.

A takie ogólne przemyślenia po używaniu Cloudflare i innych:
1. w przypadku nieszyfrowanych usług DNS nie widzę gołym okiem podczas surfowania po Internecie różnicy między usługami odpowiadającymi w 20 ms i tymi odpowiadającymi 35 ms.
2. różnice dopiero widać, gdy używa się szyfrowania DNS
3. na wydajność wpływa bardziej niż punkt 1. czy dostaniemy od usługi DNS IP zoptymalizowane pod naszą sieć/ISP
Cloudflare np często zwracało mi IP google.pl do którego miałem ping ponad 40 ms, a czasem skakał do 60 ms, a OpenDNS i Quad9 około 20 ms.
Odpowiedz
#12
Właśnie sobie je ustawiłem.
Wcześniej miałem ustawiony DNS COMODO lecz to ślimak w porównaniu z Cloudflare.
Chyba zagoszczą u mnie na stałe.
Odpowiedz
#13
(20.04.2019, 16:37)Blade napisał(a):

[Aby zobaczyć linki, zarejestruj się tutaj]

Właśnie sobie je ustawiłem.
Wcześniej miałem ustawiony DNS COMODO lecz to ślimak w porównaniu z Cloudflare.
Chyba zagoszczą u mnie na stałe.

Czy używasz szyfrowanego połączenia do CF? Używasz weryfikacji DNSSEC?
Odpowiedz
#14
(20.04.2019, 19:55)bluszcz napisał(a):

[Aby zobaczyć linki, zarejestruj się tutaj]

(20.04.2019, 16:37)Blade napisał(a):

[Aby zobaczyć linki, zarejestruj się tutaj]

Właśnie sobie je ustawiłem.
Wcześniej miałem ustawiony DNS COMODO lecz to ślimak w porównaniu z Cloudflare.
Chyba zagoszczą u mnie na stałe.

Czy używasz szyfrowanego połączenia do CF? Używasz weryfikacji DNSSEC?

Nie wiem chyba nie.
Ustawiłem te adresy w ustawieniach systemu.
Jak uzyskać szyfrowane połączenie?
Odpowiedz
#15
(20.04.2019, 21:53)Blade napisał(a):

[Aby zobaczyć linki, zarejestruj się tutaj]

(20.04.2019, 19:55)bluszcz napisał(a):

[Aby zobaczyć linki, zarejestruj się tutaj]

Czy używasz szyfrowanego połączenia do CF? Używasz weryfikacji DNSSEC?

Nie wiem chyba nie.
Ustawiłem te adresy w ustawieniach systemu.
Jak uzyskać szyfrowane połączenie?

Jeśli chcesz mieć szyfrowane połączenie tylko dla przeglądarki Firefox to popatrz w about:config na wpisy zaczynające się "network.trr".
Jeśli szyfrowane połączenie ma być dla całego systemu trzeba doinstalować program typu dns stub resolver. Potem ustawia się, by nasłuchiwał na np 127.0.0.1 i ustawiasz w ustawieniach systemu DNS na 127.0.0.1. Ja używam DNSCrypta, Stubbiego i Unbounda (spina te pierwsze dwa i to on nasłuchuje na porcie 53) w Gnu/Linuksie.
Odpowiedz


Skocz do:


Użytkownicy przeglądający ten wątek: 2 gości