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
"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ą"
"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ą"
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.
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.
04.04.2018, 17:59 (Ten post był ostatnio modyfikowany: 04.04.2018, 18:00 przez bluszcz.)
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.
...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ą"
05.04.2018, 15:46 (Ten post był ostatnio modyfikowany: 05.04.2018, 15:50 przez Quassar.)
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ć.
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.
19.04.2019, 20:43 (Ten post był ostatnio modyfikowany: 19.04.2019, 21:04 przez bluszcz.)
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.
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.