Dyskusja o bezpieczeństwie i technologiach w nazwa.pl

[MatX]

3 minuty temu, itomek napisał(a):

Widać, że temat jest istotny, zatem dla nazwa.pl jest to też jedno z zadań, które realizujemy w sposób ciągły.

 

 

[Maxx]

3 godziny temu, itomek napisał(a):

Na szybkość strony wpływa wszystko - począwszy od czasu generowania PHP

 

 

Ponad 300 ms SSL + kolejne 650 ms TTFB i 35 ms pobieranie pliku o rozmiarze 43 KB na światłowodzie 1 Gbit, czyli serwer nie dał rady wysłać pliku szybciej niż z prędkością 10 Mbit na sekundę - czyli kolejna mega porażka "lydera cloud hostingu" z Krakowa.

A trzeba mieć coś nie halo z głową aby w takiej sytuacji mówić o przyspieszeniu ładowania strony o 10ms za pomocą CDN-a, kiedy w rzeczywistości to właśnie z tym CDN-em TTFB przekracza ten czas 60 KROTNIE a "nazwaSSL" blisko 30 KROTNIE.
 

Nawet zawsze źle wypadający w materiałach Nazwy - Home.pl,

w przypadku TTFB - masakruje Nazwa.pl blisko 10 KROTNIE,

a jeśli chodzi o szybkość pobierania ponad 20 KROTNIE

 

 

 

@itomek może powinniście zmienić brand na: Porażka.pl Sp. z o.o. ?

 

Edytowane 21 Grudnia 2023 przez Maxx

[itomek]

Blog nazwa.pl dostępny jest pod adresem https://www.nazwa.pl/blog/. Poniżej screen z przeglądarki Chrome, połączenie z okolic Poznania wykonane przed chwilą, sieć Orange:

 

 

Jeżeli faktycznie chcesz realnie przetestować szybkość danego hostingu, nie testuj stron WWW usługodawcy, tylko usługę, którą ten usługodawca oferuje. Na jednym i na drugim serwerze wgraj tę samą stronę WWW, z tą samą liczbą żądań i tym samym rozmiarem. Badanie szybkości stron głównych czy blogów usługodawców nie ma sensu, bo te na ogół wystawiane są na osobnych klastrach, niż usługa, którą finalnie użytkuje klient. Na dwóch serwerach trzeba stworzyć takie samo środowisko (ta sama wersja PHP, konfiguracja SSL) i wgrać tę samą stronę WWW.

 

Takie testy jakiś czas temu przeprowadzone były na przykład przez hostranker.pl https://hostranker.pl/ranking-hostingow-2021/. Porównywane były usługi w danych firmach z wykorzystaniem tego samego obrazu strony. Jeżeli masz czas, zachęcam do wykonania takich testów, będą na pewno ciekawym obrazem szybkości usług w firmach hostingowych.

[Maxx]

Godzinę temu, itomek napisał(a):

Poniżej screen z przeglądarki Chrome, połączenie z okolic Poznania wykonane przed chwilą

 

Od strzała widać że zmanipulowałeś ten test. Po pierwsze nie ma SSL a po drugie strona jest z cache na serwerze. Natomiast ten który zrobiłem w pełni potwierdza Google Page Speed, mierzący realny czas ładowania. Jak widać wszystko się zgadza, nawet TTFB:

 

 

Co można zweryfikować tutaj: https://pagespeed.web.dev/analysis/https-www-nazwa-pl-blog/1kgwr9w4im?form_factor=desktop

 

 

Godzinę temu, itomek napisał(a):

Badanie szybkości stron głównych czy blogów usługodawców nie ma sensu

 

W tym wypadku testujemy CDN-a Nazwa.pl który jak widać na obrazku powyżej jest kompletną porażką, co zresztą potwierdził mój test do którego się odniosłem w poprzedniej wypowiedzi. A to że blog Nazwa.pl używa CDN-a sam przyznałeś, odnośnie PoP-a w Singapurze. 

 

Więc skoro osiągam podobne wyniki jak Google - moja metodologia jest o wiele lepsza, gdyż ma odzwierciedlenie tego, jak szybko się  w rzeczywistości ładuje dana strona i jak Google ją postrzega. Więc Twoje testy na poziomie 70 ms są całkowicie bezużyteczne gdyż nie mają realnego odbicia w rzeczywistości.

 

Więc po co masz się sam okłamywać Tomku i pozostałych czytelników tutaj ?

 

Edytowane 21 Grudnia 2023 przez Maxx

[itomek]

Manipulowanie testu, który każdy może sobie sam powtórzyć w swojej przeglądarce, nie ma sensu. Napisałem, że w trakcie weryfikacji użyta została przeze mnie przeglądarka Chrome, kiedy mniej więcej nawiązałem połączenie oraz skąd zostało ono wykonane. Poniżej kolejny screen sprzed chwili, gdzie widać adres strony:

 

 

Przeprowadzając jakiekolwiek testy hostingów należy po pierwsze korzystać z usługi danej firmy, a nie badać jej strony firmowe, po drugie mieć uruchomione na tej usłudze możliwe te same wersje oprogramowania (głównie chodzi o wersje PHP, ale w przypadku baz danych, gdy strona z niej korzysta, wersja serwera też może mieć znaczenie), po trzecie testowana strona musi mieć tę samą budowę/rozmiar. Inne testy nie są miarodajne. Nie ma znaczenia, co się testuje, należy robić to w sposób nie budzący wątpliwości. CDN nazwa.pl przyspiesza działanie stron dlatego, że przechowuje w węzłach statyczne elementy stron, takie jak grafiki, kody JS czy pliki CSS i korzysta z wymiany ruchu z operatorami w wielu miejscach, co skraca trasę, jaką muszą pokonać dane. 

[Maxx]

Godzinę temu, itomek napisał(a):

Przeprowadzając jakiekolwiek testy hostingów

Ale tu nie testujemy żadnych hostingów tylko CDN-a Nazwa.pl. Więc żeby wzrok Ci się wyostrzył Tomku, zrobiłem specjalnie dla Ciebie powiększenie wycinka obrazka który wstawiłeś, więc przyjrzyj mu się dokładnie:

 

 

 

 

Gdyż tak tragiczne wyniki można osiągnąć wyłącznie z CDN-em Nazwa.pl i przeglądając blog "lydera technologicznego" który tak fatalny wynik osiąga nawet po poprzednim rozwiązaniu zapytania DNS oraz nawiązaniu połączenia HTTPS. 

 

 

 

9 godzin temu, itomek napisał(a):

Manipulowanie testu ... ,Napisałem, że ... nawiązałem połączenie 

Nie "nawiązałeś połączenie" tylko wykorzystałeś już wcześniej nawiązane połączenie i dlatego nie ma na Twoich obrazkach ani DNS Lookup ani Initial connection / SSL. Serio myślałeś że nikt z forumowiczów nie zauważy tej różnicy ? 

 

 

 

A test powyżej został wykonany 30 ms od serwera w W-wie na symetrycznym łączu światłowodowym o przepustowości 1 Gbps. Dla porównania test TTFB po stronie klienta z Hostido.pl

 

 

 

Gdybym dla tej strony włączył CDN Nazwa.pl - czas ładowania ZWIĘKSZYŁBY się co najmniej 3 KROTNIE już po odliczeniu iż "eksperci" z Nazwa.pl nie zdołali jeszcze przez 25 lat uruchomić wtyczki CACHE na swoim blogu. Gdyż jak widać na obrazku odnośnie bloga Nazwa.pl - sam czas nawiązania połączenia do CDN Nazwa.pl + SSL to ponad 300 ms.

 

Dlatego na obrazkach zamieszczonych przez Tomka - na próżno szukać czasu nawiązania połączenia. Na tym właśnie polega prymitywna manipulacja Tomka, który zrobił test na otwartym już połączeniu.

 

 

[itomek]

Po pierwsze zwrócę uwagę na to, że porównywanie czasów rozwiązania domeny hostido.pl bez DNSSEC z domeną nazwa.pl, która jest zabezpieczona za pomocą DNSSEC, to ewidentny błąd. DNSSEC ma bowiem swój narzut na czasie połączenia, gdyż zapytania o domeny zabezpieczone przez DNSSEC wymagają więcej RTT, a ponadto muszą być przełączane z UDP na TCP.

 

Po drugie, po raz kolejny porównywane są TTFB dla różnych stron z dynamicznym contentem. Przecież dynamiczny content nie podlega cache'owaniu na węzłach CDN. W przypadku dynamicznego contentu, czas TTFB zależy od czasu generowania strony na serwerze i od jej budowy / złożoności / ilości dodatków itd.

 

Po raz kolejny zachęcam do tego, aby próbując coś wykazać lub udowodnić, wykonać testy w sposób rzetelny, przedstawiając porównanie szybkości działania takiej samej strony, która jest obsługiwana z takimi samymi zabezpieczeniami, zaczynając już od poziomu DNSSEC. Środowisko, na którym uruchamiana jest strona powinno korzystać z tej samej wersji PHP i możliwie tej samej wersji serwera baz danych, zabezpieczenia typu SSL / brak SSL i ewentualne przekierowania powinny być ustawione tak samo. Porównywanie różnych stron na różnych konfiguracjach środowisk nie jest miarodajne i tylko wprowadza w błąd.

 

 

Edytowane 22 Grudnia 2023 przez itomek

[Maxx]

20 godzin temu, itomek napisał(a):

DNSSEC ma bowiem swój narzut na czasie

300 ms ?  To chyba tylko z DNS Anycast i "nazwaSSL". Mimo iż w tak fatalnym wyniku DNSSEC ma tylko ułamkowy udział, to trudno już dzisiaj znaleźć na rynku usługodawcę, który by wciąż jeszcze używał tego straszliwego i bezużytecznego dziadostwa jakim niewątpliwie jest DNSSEC. A przypomnę iż Nazwa.pl BEZ PYTANIA I ZGODY klientów samowolnie włączyła im DNSSEC na każdej domenie, czym spowolniła strony klientów. A ponieważ DNSSEC jest kompletnie bezużyteczny - nie stosują go ani największe banki, ani strony e-commerce ani portale informacyjne, ani setki milionów innych stron na świecie - o czym może się przekonać każda osoba przeglądając whois takich domen jak choćby ebay.com allegro.pl olx.pl onet.pl mbank.pl inteligo.pl wp.pl itd.... a nawet NASK.pl

 

Więc z DNSSEC korzystają/mówią jeszcze raczej tylko  "lyderzy technologiczni" nie mogący wyjść z epoki kamienia i odnaleźć się na rynku w roku 2023/2024 jak i również osoby nie mające bladego pojęcia o wektorach ataków hakerskich w sieci.

 

A swoją drogą, jak prymitywna musi być firma, która włącza coś klientowi bez jego wiedzy i zgody, nie tylko spowalniając mu stronę ale i również narażając na utratę pozycji w Google. Dlatego usługodawcy z górnej półki oferują klientowi możliwość włączenia DNSSEC, ale nie robią tego samowolnie. W tej klasie jakości usług oczywiście nie gra Nazwa.pl a tylko przyjaźni dla klienta  usługodawcy jak choćby Hostido.pl

 

 

 

 

20 godzin temu, itomek napisał(a):

Po raz kolejny zachęcam do tego, aby próbując coś wykazać lub udowodnić

Ja też zachęcam Cię Tomku po raz drugi, abyś nie próbował więcej oszukiwać społeczności RootNode czy to poprzez ukrycie w swoich "rzetelnych badaniach" czasu nawiązania połączenia do CDN Nazwa.pl które w niektórych przypadkach sięga aż 300 ms, podobnie też abyś nie oszukiwał ich że to przez DNSSEC. Gdyż za tak fatalny wynik w 100% są odpowiedzialni wyłącznie "eksperci" z Nazwa.pl którzy spowolnili czas nawiązania połączenia do firmowego bloga za pomocą CDN Nazwa.pl

 

 

 

 

20 godzin temu, itomek napisał(a):

Środowisko, na którym uruchamiana jest strona powinno korzystać z tej samej wersji PHP i możliwie tej samej wersji serwera baz danych, zabezpieczenia typu SSL / brak SSL i ewentualne przekierowania powinny być ustawione tak samo. Porównywanie różnych stron na różnych konfiguracjach środowisk nie jest miarodajne i tylko wprowadza w błąd.

 

W przypadku gdy mówimy wyłącznie o czasie nawiązania połączenia do CDN Nazwa.pl, nie ma to absolutnie żadnego znaczenia. Znaczenie ma natomiast fakt, iż niemożliwe jest znalezienie rónie straszliwego dziadostwa na rynku reklamowanego jako CDN, do którego sam czas nawiązania połączenia sięga 300 ms podczas gdy przed włączeniem CDN Nazwa.pl - czas nawiązania połączenie był o wiele niższy. I właśnie ten fakt świadczy o tym, z jak straszliwym dziadostwem mamy do czynienia, w przypadku CDN Nazwa.pl

 

 

Edytowane 23 Grudnia 2023 przez Maxx

[itomek]

Informacje na temat DNSSEC można znaleźć na oficjalnej stronie NASK oraz ICANN:

 

https://www.dns.pl/DNSSEC

https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en

 

Jeżeli po przeczytaniu tych informacji nadal ktoś uważa, że DNSSEC nie jest istotny, to chyba tylko dlatego, że ma kłopot z wdrożeniem tego zabezpieczenia w firmie, którą reprezentuje. Nie ma jednego zabezpieczenia dla usług hostingowych / serwerów. Należy stosować wiele typów zabezpieczeń, które pomagają odpierać różne typy zagrożeń w sieci. DNSSEC jest jednym z takich elementów.

 

CDN nazwa.pl to sieć dystrybucji treści w całości stworzona i zarządzana przez nazwa.pl. Wykorzystuje ona poszczególne węzły, które zostały umieszczone w kluczowych dla ruchu internetowego miejscach na świecie do tego, aby przechowywać elementy statyczne stron. Dodatkowo korzystanie z CDN nazwa.pl pozwala na wymianę ruchu lokalnie z różnymi dostawcami Internetu. O tym, jaki duży ruch przechodzi przez poszczególne węzły, można przekonać się korzystając z dostępnego systemu statystyk w CloudHosting Panel lub w Panelu Klienta (w przypadku samodzielnej usługi). 

 

Każdy użytkownik forum posiada przeglądarkę Internetową, a w niej "Narzędzia dla developerów". Może więc sam przeprowadzić test z analizą Waterfalla i zobaczyć, jaki czas zajmują poszczególne składowe przy nawiązywaniu połączenia. I do tego każdego zachęcam. Taką weryfikację można później zestawić z informacjami, jakie są zwracane przez test2speed.pl (testy tylko z Polski) oraz test2speed.com (testy z całego świata).

 

Polecam także ranking szybkości stron opartych na WordPress na różnych hostingach, który dostępny jest na stronie https://webspeed.pl/rankingi/wordpress. Poniżej tylko kilka linków, więcej pod w/w adresem:

 

https://webspeed.pl/avg.wordpress.nazwa.pl

https://webspeed.pl/avg.wordpress.o12.pl

https://webspeed.pl/avg.wordpress.jdm.pl

https://webspeed.pl/avg.wordpress.lh.pl

https://webspeed.pl/avg.wordpress.dhosting.pl

https://webspeed.pl/avg.wordpress.hostido.net.pl

 

Po zapoznaniu się z tymi informacjami, można w bardzo prosty sposób wyciągnąć wnioski, który hosting jak szybko pracuje z tym najpopularniejszym systemem CMS, z którego korzysta przeszło 40% wszystkich stron internetowych.

  

Edytowane 23 Grudnia 2023 przez itomek

[Maxx]

6 godzin temu, itomek napisał(a):

Informacje na temat DNSSEC można znaleźć na ... Jeżeli po przeczytaniu tych informacji ...

 

Za dużo się naczytałeś teorii spiskowych o DNSSEC które nie mają absolutnie żadnego odbicia ani w liczbach ani przykładach. Natomiast bez problemu można znaleźć przykład jak wygląda bezpieczna domena z DNSSEC w Nazwa.pl :

 

A tylko straszliwy głupiec podobnie jak Nazwa.pl może twierdzić iż DNSSEC uniemożliwia przekierowania na inną domenę, podczas gdy nawet dla amatorów hackingu zrobienie przekierowania jest proste jak splunięcie. Z powodu całkowitej bezużyteczności DNSSEC tylko firmy wciąż pozostające w epoce kamienia i nie mające bladego pojęcia o bezpieczeństwie i wektorach ataków w sieci mogą się jeszcze w 2023 roku podniecać tak straszliwym dziadostwem, jakim bezdyskusyjnie jest DNSSEC.

 

Dlatego na liście top 100 Alexy niemożliwe było znaleźć ani jednej domeny którą by zarządzał ktoś tak straszliwie głupi, aby włączyć na niej DNSSEC. A przypomnę iż na tej liście znajdowali się czołowi giganci technologiczni jak Google, Amazon, Apple oraz dziesiątki innych stron zbierających grubo ponad 90% światowego ruchu w internecie.

 

Więc wybacz Tomku że biorę przykład wyłącznie z czołówki liderów na światowym rynku a nie pozostających w jaskini domenowo-hostingowych dziadów. Nie widzę natomiast przeszkłód abyś Ty mógł pozostać w tej jaskini wraz z Nazwa.pl

 

Edytowane 23 Grudnia 2023 przez Maxx

[itomek]

DNSSEC nie jest zabezpieczeniem, które likwiduje zagrożenia code injection czy XSS, pojawiające się w momencie umieszczenia na serwerze skryptów lub plików, które bez dodatkowego filtrowania pozwalają na zdalne wykonanie pewnych funkcji. DNSSEC chroni przez atakami typu domain hijacking, cache poisoning i innymi działaniami, które mogą zagrozić integralności i poufności zapytań i odpowiedzi DNS. 

 

DNSSEC to system hierarchiczny, za pomocą którego podpisane są zarówno strefa domen .pl, jak i większość głównych stref domen globalnych. Istotę jego wykorzystania widać właśnie na tym przykładzie, kiedy przy rozwiązywaniu nazw chociażby we wspomnianej strefie .pl wykorzystuje się DNSSEC. Poziom bezpieczeństwa DNSSEC jest powiązany z poziomem zabezpieczeń kryptografii asymetrycznej, zatem negowanie wykorzystania DNSSEC jest podobnie do podnoszenia argumentów negujących zasadność stosowania połączeń TLS i certyfikatów na przykład przy transmisji stron WWW i poczty. Internetowy łańcuch zaufania opiera się na gotowości usług i tras DNS, urzędów certyfikacji SSL, rejestratorów domen i dostawców usług internetowych. 

 

Każda domena chroniona przez DNSSEC wymaga cyfrowego klucza podpisującego, który musi być co pewien czas zmieniany. Odpowiednio częsta aktualizacja kluczy i wykonywanie innych krytycznych czynności zarządzania tym zabezpieczeniem to wysiłek dla organizacji. Prawidłowe wdrożenie DNSSEC to duże koszty na poziomie i czasu, i zasobów ludzkich. Niestety, często cierpi na tym bezpieczeństwo. Dodatkowo cierpi tez jak widać świadomość użytkowników, którzy próbują z bliżej nieznanych powodów negować coś, co zostało uznane za właściwy krok w kierunku bezpieczeństwa usług IT. Podkreślam jeszcze raz - nie ma jednego zabezpieczenia, które swoim zakresem likwidowałoby wszystkie rodzaje potencjalnych zagrożeń. Wdrożenie warstwowego podejścia do bezpieczeństwa, w tym zabezpieczeń sieciowych, bezpiecznych konfiguracji resolverów DNS oraz ciągłego monitorowania i audytu, jest niezbędne do utrzymania odpornej infrastruktury DNS.

[Maxx]

12 godzin temu, itomek napisał(a):

Prawidłowe wdrożenie DNSSEC to duże koszty na poziomie i czasu, i zasobów ludzkich.

 

Dla firmy zatrudniającej nieudaczników zamiast administratorów wdrożenie DNSSEC poprzez zainstalowanie DARMOWEGO programu PowerDNS w wersji 4.8.3 (używanego przez Nazwa.pl) oraz jego poprawna konfiguracja zaiste może być największym osiągnięciem w całej historii takiej firmy. Z tego co napisałeś wynika jasno, że to właśnie w tej klasie gra Nazwa.pl.

 

Stało się też oczywiste, iż to właśnie przez tego typu nieudaczników nazywanie żartobliwie "ekspertami" nie dość że Nazwa.pl straciła dane klientów to jeszcze nadpisała backupy uszkodzonymi plikami i to w momencie gorącego okresu przedświątecznego kiedy ów klienci mogli najwięcej zarobić. 

 

Nie chcę też Tomku abyś pozostał w ciemnościach i zdradzę Ci w sekrecie iż dla ogarniętego administratora zainstalowanie PowerDNS i poprawna konfiguracja DNSSEC to maksymalnie godzina czasu wliczając dłuższą przerwą na kawę. Trochę więcej czasu zajmie zintegrowanie tego z systemem oraz rejestrem, jednak pisanie że "to duże koszty na poziomie i czasu, i zasobów ludzkich" to robienie z siebie pośmiewiska i ogłoszanie wszystkim, jak słabymi ludźmi dysponuje dana firma.

 

Dlatego firmy z górnej półki wyznaczające najwyższe standardy usług na rynku jak choćby Hostido.pl -  nie tylko oferują klientowi możliwość włączenia DNSSEC w panelu klienta ale co dużo ważniejsze - w tym samym panelu klient ma możliwość uzyskania kodu Auth-info, czego nie może zrobić u rejestratorów nie mogących od długiego już czasu wyjść z epoki kamienia, a którzy wciąż stosują tak niezwykle prymitywne metody jak wysyłka Auth-info pocztą - nie tylko marnując cenny czas ale i środki finansowe klientów.

 

Trudno też oczekiwać, aby klient pokrywał koszty zatrudniania przez największych dziadów na rynku wyłącznie samych nieudaczników zamiast administratorów a którym zainstalowanie PowerDNS i skonfigurowanie DNSSEC zajmuje lata zamiast jednej godziny. Między innymi to z tego powodu odnowienie domeny w Hostido.pl może kosztować 51 PLN a w Nazwa.pl kosztuje absurdalne 200 PLN.

Dlatego też od dziadów należy się trzymać z dala. Gdyż nie dość że mogą klientowi pokasować cenne dane to jeszcze marnują czas i pieniądze klientów. Dlatego wyjątkowo trafne jest tu powiedzenie: z dziadami przystajesz - dziadem się stajesz.

 

Edytowane 25 Grudnia 2023 przez Maxx

[l3szcz]

Wtrącę 3 grosze co do zabezpieczeń. Jest tylko jeden sposób by w pełni zabezpieczyć serwer przed atakami - odłączyć go od prądu.

Inne metody to tylko szukanie potencjalnych wektorów ataku.

 

[V0sl3]

12 godzin temu, Maxx napisał(a):

 

Dla firmy zatrudniającej nieudaczników zamiast administratorów wdrożenie DNSSEC poprzez zainstalowanie DARMOWEGO programu PowerDNS w wersji 4.8.3 (używanego przez Nazwa.pl) oraz jego poprawna konfiguracja zaiste może być największym osiągnięciem w całej historii takiej firmy. Z tego co napisałeś wynika jasno, że to właśnie w tej klasie gra Nazwa.pl.

 

Stało się też oczywiste, iż to właśnie przez tego typu nieudaczników nazywanie żartobliwie "ekspertami" nie dość że Nazwa.pl straciła dane klientów to jeszcze nadpisała backupy uszkodzonymi plikami i to w momencie gorącego okresu przedświątecznego kiedy ów klienci mogli najwięcej zarobić. 

 

Nie chcę też Tomku abyś pozostał w ciemnościach i zdradzę Ci w sekrecie iż dla ogarniętego administratora zainstalowanie PowerDNS i poprawna konfiguracja DNSSEC to maksymalnie godzina czasu wliczając dłuższą przerwą na kawę. Trochę więcej czasu zajmie zintegrowanie tego z systemem oraz rejestrem, jednak pisanie że "to duże koszty na poziomie i czasu, i zasobów ludzkich" to robienie z siebie pośmiewiska i ogłoszanie wszystkim, jak słabymi ludźmi dysponuje dana firma.

 

Dlatego firmy z górnej półki wyznaczające najwyższe standardy usług na rynku jak choćby Hostido.pl -  nie tylko oferują klientowi możliwość włączenia DNSSEC w panelu klienta ale co dużo ważniejsze - w tym samym panelu klient ma możliwość uzyskania kodu Auth-info, czego nie może zrobić u rejestratorów nie mogących od długiego już czasu wyjść z epoki kamienia, a którzy wciąż stosują tak niezwykle prymitywne metody jak wysyłka Auth-info pocztą - nie tylko marnując cenny czas ale i środki finansowe klientów.

 

Trudno też oczekiwać, aby klient pokrywał koszty zatrudniania przez największych dziadów na rynku wyłącznie samych nieudaczników zamiast administratorów a którym zainstalowanie PowerDNS i skonfigurowanie DNSSEC zajmuje lata zamiast jednej godziny. Między innymi to z tego powodu odnowienie domeny w Hostido.pl może kosztować 51 PLN a w Nazwa.pl kosztuje absurdalne 200 PLN.

Dlatego też od dziadów należy się trzymać z dala. Gdyż nie dość że mogą klientowi pokasować cenne dane to jeszcze marnują czas i pieniądze klientów. Dlatego wyjątkowo trafne jest tu powiedzenie: z dziadami przystajesz - dziadem się stajesz.

 

Trochę zaczynam wątpić, czy ty na serio tak piszesz, czy już powoli zaczynasz żartować. Jeśli słyszę, że ktoś mówi, że wdrożenie czegoś to maksymalnie godzina zabawy, porównując Nazwę do jakiegoś prywatnego projektu opartego o trzy serwery, to mnie bierze na śmiech. To nie jest jakieś środowisko testowe, gdzie mogą się bawić i nie zważać na możliwe komplikacje, brane tutaj jest pod uwagę wiele scenariuszy tak, aby nie wywołać zbędnej niedostępności usług.

Zapomniałeś także chyba o szacunku, nie wiesz dokładnie jak to wszystko od podszewki wygląda i warto mieć na uwadzę, że nie każda firma stawia na gotowe rozwiązania w przypadku chociażby paneli, przez co, wdrażanie niektórych rzeczy może potrwać nieco dłuzej, ale pozwala na więcej możliwości

 

Cytat

Dlatego firmy z górnej półki wyznaczające najwyższe standardy usług na rynku jak choćby Hostido.pl -  nie tylko oferują klientowi możliwość włączenia DNSSEC w panelu klienta ale co dużo ważniejsze - w tym samym panelu klient ma możliwość uzyskania kodu Auth-info, czego nie może zrobić u rejestratorów nie mogących od długiego już czasu wyjść z epoki kamienia, a którzy wciąż stosują tak niezwykle prymitywne metody jak wysyłka Auth-info pocztą - nie tylko marnując cenny czas ale i środki finansowe klientów.

Twoim zdaniem to prymitywna metoda, dla mnie to ogromy benefit bezpieczeństwa. W moim przypadku nie zamierzam zmieniać dostawcy co rok, aby przyoszczędzić kilka groszy, a takto mam pewność, że domena nie zostanie w jakiś sposób przechwycona. Warto także mieć na uwadzę, że nie każdemu zależy na kupnie hurtowej ilości domen, a potem ich transfer

 

Jest także wiele sposobów na jego dostarczenie, także nie wydaje mi się, aby to był ogromny problem chociażby z pomocą trzeciego punktu.

Edytowane 25 Grudnia 2023 przez V0sl3

[Maxx]

2 godziny temu, V0sl3 napisał(a):

... porównując Nazwę do jakiegoś prywatnego projektu,... opartego o trzy serwery

 

 

Musisz zrozumieć bro, że Nazwa.pl to nie Hetzner.com czy OVH.  Gdyż Nazwa.pl to straszliwie malutki robaczek, tak mały, że Nazwa.pl była w stanie spakować całe swoje "data center" do busa razem z kabliskami i przewieźć je z podkrakowskiego Polkomu do Atmana. Jeśli wiesz ile średnio waży serwer i jaką dopuszczalną ładowność ma busik, bardzo szybko obliczysz o jak śmiesznie małej ilości serwerów mówimy w przypadku "data center" Nazwa.pl

 

Podobnie też musisz zrozumieć bro, iż dla ogarniętego administratora nie ma większego znaczenia, czy dane rozwiązanie instaluje/wdraża na 3-ch czy też 3,000 serwerów. Podam Ci przykład ja to wygląda w praktyce na przykładzie kompletnej instalacji tego samego rozwiązania w przypadku Vultr.com  oferującego VPS-y w 32 lokalizacjach na świecie, w tym również Warszawie.

 

Vultr jako poważny gracz z górnej półki na rynku VPS-ów ma na pokładzie nie tylko API ale i również daje możliwość uruchomienie skryptu startowego przy instalacji serwera. Dzięki czemu w zaledwie kilka minut do pracy są gotowe 32 serwery i na każdym z nich jest już zainstalowane wszystko co potrzeba (w tym również np. docelowa strona łącznie z bazą danych) a administrator w tym czasie może pozwolić sobie na łyczek kawy okropnie zmęczony wysłaniem aż 1 komendy poprzez API co zajęło mu aż kilka sekund łącznie z uruchomieniem konsoli.

 

Dlatego dla ogarniętego administratora współpraca z poważnymi graczami na rynku to czysta przyjemność, czego nie można powiedzieć o współpracy z największymi dziadersami nie mającymi nawet tak podstawowej funkcjonalności jaką jest API a mieniącymi się "lyderami" podczas gdy w rzeczywistości na rynku hostingu w chmurze - nie wyszli jeszcze nawet z jaskini. 

 

 

2 godziny temu, V0sl3 napisał(a):

Zapomniałeś także chyba o szacunku

 

Wybacz bro, ale jeśli ktoś pisze, iż inni nie wprowadził DNSSEC ze względu na brak wiedzy w temacie - nie mam litości dla takiego pyszałka i dlatego rychło sprowadzam go na ziemię wraz z  jego wysadzonym w kosmos ego opartym najczęściej o czysto teoretyczną wiedzę, czego temat odnośnie DNSSEC i wypowiedzi naszego kolegi z Nazwa.pl są doskonałym przykładem. A jaka jest brutalna prawda w przypadku DNSSEC napisałem już wcześniej:

 

"Na liście top 100 Alexy niemożliwe było znaleźć ani jednej domeny którą by zarządzał ktoś tak straszliwie głupi, aby włączyć na niej DNSSEC. A przypomnę iż na tej liście znajdowali się czołowi giganci technologiczni jak Google, Amazon, Apple oraz dziesiątki innych stron zbierających grubo ponad 90% światowego ruchu w internecie."

Dlatego też każda osoba może podjąć decyzję, czy bierze przykład z rzeczywistych liderów z Top 100 Alexy czy też największych dziadersów którzy wciskają klientowi kompletnie bezużyteczne rozwiązania do jakich bezdyskusyjnie zalicza się DNSSEC,  A które nie dość że przed niczym klienta nie chronią to jeszcze spowalniają strony klientów i narażają ich na utratę pozycji w Google.

Dlatego nie jest możliwe aby jakikolwiek dziaders zachwycający się DNSSEC podał przykład jakiejkolwiek strony która została zhakowana przez brak DNSSEC pomimo setek milionów domen bez DNSSEC. Zgadza się @itomek ?

 

Edytowane 25 Grudnia 2023 przez Maxx

[itomek]

DNSSEC nie zabezpieczy strony przez zhackowaniem. To dodatkowe zabezpieczenie w warstwie DNS, które przeciwdziała atakom typu  domain hijacking czy cache poisoning, które dotyczą serwerów DNS. To zupełnie inna forma ochrony. 

 

Ważne jest aby pamiętać, że skuteczność ochrony stron WWW zależy w dużej mierze także od samych użytkowników. Można mieć dostępne na serwerze różne warianty zabezpieczeń, podobnie jak można mieć wiele różnych typów zabezpieczeń zamków w domowych drzwiach, ale nawet jeżeli te zabezpieczenia są, to niewłaściwa budowa samej strony WWW może powodować, że będzie ona nadal podatna na ataki. To tak, jakby we wspomnianych drzwiach zaryglować wszystkie zamki z najwyższymi standardami zabezpieczeń, ale nie zamknąć okien i drzwi od ogrodu. 

 

Każde dodatkowe zabezpieczenie, które oferuje firma hostingowa, to krok do ochrony strony WWW. Nie ma jednego cudownego zabezpieczenia, trzeba korzystać z wielu form ochrony, które współdziałając razem mają szansę na zatrzymanie tych użytkowników, którzy chcą zniszczyć daną stronę WWW.

[zajcev]

W dniu 25.12.2023 o 00:57, Maxx napisał(a):

Stało się też oczywiste, iż to właśnie przez tego typu nieudaczników nazywanie żartobliwie "ekspertami" nie dość że Nazwa.pl straciła dane klientów to jeszcze nadpisała backupy uszkodzonymi plikami i to w momencie gorącego okresu przedświątecznego kiedy ów klienci mogli najwięcej zarobić. 

 

 

a to nie Kylos?   tak gdzieś czytałem, że wrzucili przed świetami backup z lipca

 

 

 

[Maxx]

Godzinę temu, zajcev napisał(a):

a to nie Kylos?

 

To właśnie ta awaria w Kylosie przypomniała mi tą w Nazwie. Tyle, że Kylos nie robi z siebie pośmiewiska tak jak Nazwa.pl która ma przypał za przypałem a rżnie lydera będąc jedynie naśladowcą i to wyjątkowo nieudolnym w niektórych kwestiach 

 

 

9 godzin temu, itomek napisał(a):

DNSSEC ... to dodatkowe zabezpieczenie w warstwie DNS, które przeciwdziała atakom typu  domain hijacking czy cache poisoning, które dotyczą serwerów DNS.

 

Znów straszliwe głupoty opowiadasz. DNSSEC nikogo nie zabezpieczy przed przejęciem domeny czyli domain hijacking, gdyż żeby doszło do przejęcia domeny potrzebny jest kod Auth-info. A jak ktoś ma Auth-info to dziadostwem DNSSEC można sobie tyłek utrzeć.

 

Jeśli zaś chodzi o Twoją ostatnią deskę ratunku - czyli cache poisoning - nikt tego nie używa, gdyż nikt nie burzy muru głową jeśli ma na oścież drzwi otwarte.

 

 

 

9 godzin temu, itomek napisał(a):

To tak, jakby we wspomnianych drzwiach zaryglować wszystkie zamki z najwyższymi standardami zabezpieczeń, ale nie zamknąć okien i drzwi od ogrodu. 

 

Dokładnie tak robi Nazwa.pl a co gorsza wprowadza użytkowników mających wszystkie drzwi i okna pootwierane w fałszywe przekonanie że ich strony są bezpieczne gdyż klucze do klatki z kanarkiem są wymieniane. Więc defacto działalność Nazwa.pl jest szkodliwa społecznie. No ale jak ktoś nie ma pomysłów na "byznes", to musi się promować przestarzałym i kompletnie bezużytecznym dziadostwem którego nie używa już nikt, kto ma choć minimalne pojęcie o wektorach ataków w sieci.
 

 

[psz]

W dniu 25.12.2023 o 14:36, Maxx napisał(a):

Dlatego nie jest możliwe aby jakikolwiek dziaders zachwycający się DNSSEC podał przykład jakiejkolwiek strony która została zhakowana przez brak DNSSEC pomimo setek milionów domen bez DNSSEC. Zgadza się @itomek ?

 

I tu się grubo mylisz: https://www.theregister.com/2018/04/24/myetherwallet_dns_hijack/

 

DNSSEC jest istotnym elementem zabezpieczeń (lecz nie jedynym). W pełni popieram i pochwalam działania nazwy.pl w celu promowania tego standardu w polskim Internecie. Chciałbym, apeluję, żeby inni polscy usługodawcy podążyli tą drogą i wprowadzili łatwe w obsłudze wsparcie dla DNSSEC w swoich panelach (np. na jeden klik na wzór OVH lub Cloudflare), albo wręcz automatyczne (np. nazwa.pl, Cloudflare Registrar).

 

Również Cloudflare (mój pracodawca) jest zaangażowany w promowanie i rozwój tego standardu (nasi pracownicy są współautorami dokumentów RFC z tej i innych dziedzin). To, że Google, Apple czy Amazon nie stosują tego zabezpieczenia ("fałsz", bo stosują, ale nie w sposób, o którym myślisz) nie jest żadną wymówką, żeby tego nie stosować.

 

PS: Moja sugestia dla adminów/moderatorów forum o wydzielenie z tego tematu postów niezwiązanych z tematem wątku (ocena produktów), a które wprowadzają chaos informacyjny, do osobnego wątku ("Dyskusja na temat technologii nazwa.pl" czy coś podobnego).

 

PS2: No i miałem się już nie udzielać. Pękłem

[kafi]

8 minut temu, psz napisał(a):

Również Cloudflare (mój pracodawca) jest zaangażowany w promowanie i rozwój tego standardu (nasi pracownicy są współautorami dokumentów RFC z tej i innych dziedzin). To, że Google, Apple czy Amazon nie stosują tego zabezpieczenia ("fałsz", bo stosują, ale nie w sposób, o którym myślisz) nie jest żadną wymówką, żeby tego nie stosować.

 

 

Z jednej strony fajne szumne protekcje. Z drugiej CF oferuje coś takiego, jak 1.0.0.2, które jawnie deklaruje się... podmienianiem niewygodnych wpisów DNS na inne. Trochę to tak niczym Panu Bogu świeczkę a diabłu ogarek

Patrząc po tym, że ludzie gotowi są korzystać z takich szemranych resolverów dns-ów czy aplikacji które wycinają reklamy na zasadzie m.in. hijackowania ruchu dns to ten mechanizm, mimo że w założeniach bardzo szlachetny, to eee... wydaje się tak naprawdę psu na budę w rzeczywistości potrzebny.

 

[Maxx]

Godzinę temu, psz napisał(a):

Również Cloudflare (mój pracodawca) jest zaangażowany w promowanie i rozwój tego standardu

CloudFlare stara się też nachalnie i bezskutecznie promować IPV6. Więc przekaż swoim pracodawcom, że tak drobny szczegół jak wymuszanie wyłączenia IPV6 wyłącznie przez API doprowadzi w końcu do tego, iż część płatnych użytkowników Was oleje jeśli dojdą kolejne podobne wybryki (np. wymuszanie DNSSEC) a ja będę jednym z pierwszych bo nie potrzebuje tatusiów i mamusiek z CloudFlare tylko konkretne usługi. A jak wiesz, dziś na rynku jest masę alternatyw i ani opinia ani zaangażowanie CloudFlare zupełnie mnie nie interesują ani w kwestii DNSSEC ani w kwestii IPV6.

 

A jak ktoś na siłę stara wpychać komuś swoje pomysły - zawsze kończy się to fatalnie. Więc to że wciąż jeszcze jestem Waszym klientem zawdzięczacie wyłącznie temu, że IPV6 wciąż da się jeszcze wyłączyć przez API. A jak się go wyłączyć nie będzie dało to po prostu oleje CloudFlare i tak się zakończy Wasza promocja IPV6, które przy okazji zostanie jeszcze bardziej znienawidzone. Tak więc sugeruje jednak skupienie się na core biznesu zamiast największym dziadostwie jakie przez ostatnią dekadę nie udało się przeforsować. Bo za chwile stracicie zarówno dochód jak i darmową promocję ze swoimi idiotycznymi pomysłami w zakresie IPV6 i DNSSEC.

 

Więc moja sugestia jest następująca: jak już przekonacie te skromne 60 firm z Alexa Top 100 to wrócimy do tematu. A do tego czasu sugeruję nie drażnić klientów dziadostwem DNSSEC czy też zamulonym IPV6.

 

PS. Wybacz więc @psz że tym razem nie było ochów i achów odnośnie CloudFlare, ale staram się być obiektywny niezależnie od tego, czy danego usługodawcę lubię czy też nie. Po prostu mojej opinii nie da się kupić ponieważ sprzedają się wyłącznie prostytutki. A na dobrą opinię długo trzeba pracować ale za to można  ją stracić w kilka sekund.

Edytowane 27 Grudnia 2023 przez Maxx

[Sevos]

2 godziny temu, Maxx napisał(a):

CloudFlare stara się też nachalnie i bezskutecznie promować IPV6

 

Nie musi promować IPv6, bo ten protokół jest włączony by default  Dzięki temu sporo stron, które korzystają z Cloudflare, jest dostępnych dla każdego, również dla tych bez dostępu do IPv4. 

 

2 godziny temu, Maxx napisał(a):

A jak ktoś na siłę stara wpychać komuś swoje pomysły - zawsze kończy się to fatalnie.

 

Gdzie tu widzisz wpychanie? Lider usług security i cdn implementuje nowe standardy oraz technologie, a potem wskazuje kurs, w jakim wszyscy mogą podążyć, tym samym popychając cały internet do przodu. Bycie częścią innowacyjności to istotny wkład w rozwój. Pewne rzeczy trzeba narzucać, tak samo jak Apple narzuciło wiele rzeczy, a klienci i tak podążają wtedy za nimi.

 

W celu przyspieszenia popularyzacji nowych rzeczy trzeba czasami dostarczyć odpowiednie narzędzia oraz wsparcie, żeby ludzie mogli szybko to zaadaptować i się zaadaptować. 

[Maxx]

8 godzin temu, Sevos napisał(a):

bo ten protokół jest włączony by default

 

Właśnie o tym pisałem wyżej, że w CF da się go wyłączyć jedynie poprzez API co zazwyczaj robię w pierwszej kolejności ze względu na niesłychaną mułowatość IPV6.  Bo nie po to rozkładam serwery w różnych miejscach na świecie aby następnie zepsuć cały efekt przez IPV6.  I dlatego jak również wyżej napisałem - jeśli tego IPV6 nie będę mógł wyłączyć to pożegnam się z CF.  Nie widzę natomiast przeszkody, aby inni mogli korzystać z muła IPV6.

 

 

9 godzin temu, Sevos napisał(a):

Pewne rzeczy trzeba narzucać

 

Jeśli chodzi o IPV6 - proponuję zacząć od najbardziej zacofanej technologicznie firmy w tej kwestii - Nazwa.pl

 

[theqkash]

Posty niezwiązane z tematem zostały wydzielone do: 

 

[psz]

14 godzin temu, kafi napisał(a):

Z jednej strony fajne szumne protekcje. Z drugiej CF oferuje coś takiego, jak 1.0.0.2, które jawnie deklaruje się... podmienianiem niewygodnych wpisów DNS na inne.

 

Mylisz dwie różne usługi: DNS autorytatywny (o nim tutaj mowa) z DNS resolverem (który użytkownik sobie wybiera wedle uznania, ten konkretny filtruje malware, ale podstawowa wersja 1.1.1.1 nie ma żadnego filtra; zobacz również: Public recursive name server na Wikipedii).

 

13 godzin temu, Maxx napisał(a):

CloudFlare stara się też nachalnie i bezskutecznie promować IPV6. Więc przekaż swoim pracodawcom, że tak drobny szczegół jak wymuszanie wyłączenia IPV6 wyłącznie przez API doprowadzi w końcu do tego, iż część płatnych użytkowników Was oleje jeśli dojdą kolejne podobne wybryki (np. wymuszanie DNSSEC) a ja będę jednym z pierwszych bo nie potrzebuje tatusiów i mamusiek z CloudFlare tylko konkretne usługi. A jak wiesz, dziś na rynku jest masę alternatyw i ani opinia ani zaangażowanie CloudFlare zupełnie mnie nie interesują ani w kwestii DNSSEC ani w kwestii IPV6.

 

"Nikt tu nikogo pod pistoletem nie zatrzymuje, wprost przeciwnie". Jeśli nie odpowiadają Ci nasze usługi, a jak napisałeś, jest masa alternatyw, to jak najbardziej powinieneś z nich skorzystać.

 

13 godzin temu, Maxx napisał(a):

Wybacz więc @psz że tym razem nie było ochów i achów odnośnie CloudFlare, ale staram się być obiektywny niezależnie od tego, czy danego usługodawcę lubię czy też nie.

 

Słuchamy opinii klientów, bo dzięki temu wiemy, co należy rozwijać/poprawiać. Tak więc doceniamy konstruktywną krytykę. Powyższe do nich nie należy.

 

Mam nieodparte wrażenie, że przyszedłeś na to forum, aby wylać swoją frustrację na innych. Zero merytoryki, wiadro pomyj. Dalsza dyskusja traci sens.