Opinie o nazwa.pl

mariaczi · 10 Lipca 2018

1 godzinę temu, nazwa.pl napisał:

Z uwagi na fakt, że nazwa.pl jest firmą nr. 1 w Polsce w zakresie rejestracji domen i usług hostingowych

To się już wszystkim, a na tym forum na pewno, odbija czkawką. Przy kolejnych wypowiedziach darujcie sobie takie stwierdzenia. Poza Waszymi materiałami nigdzie nie znalazłem informacji to potwierdzających.

Poziomecki · 10 Lipca 2018

Może weźcie kogoś z doświadczeniem w IT do spraw marketingowych?

theqkash · 10 Lipca 2018

50 minut temu, mariaczi napisał:

Poza Waszymi materiałami nigdzie nie znalazłem informacji to potwierdzających.

Co do rejestracji domen nie zgodzę się z Tobą. Raport NASK potwierdza ten fakt, nazwa.pl faktycznie jest nr 1 w tym zakresie. Nie jest natomiast określona ilość utrzymywanych domen, który rejestrator w danym momencie posiada ich najwięcej, a to mogłoby być podstawą do dyskusji. Na ten moment pewne dane można wyciągnąć z Top100.

mariaczi · 10 Lipca 2018

1 minutę temu, theqkash napisał:

Co do rejestracji domen nie zgodzę się z Tobą. Raport NASK potwierdza ten fakt,

Yhm, to prawda. Rejestracji nie neguję -> wciskania domen za zero złotych na lewo i prawo bez jasnego /przedstawiania/ poinformowania o cenach w kolejnych latach, i że nie można po pierwszym roku przenieść takiej domeny do innego registrata bez opłacenia jej u nich.

theqkash · 10 Lipca 2018

Teraz, mariaczi napisał:

Rejestracji nie neguję -> wciskania domen za zero złotych na lewo i prawo bez jasnego /przedstawiania/ poinformowania o cenach w kolejnych latach, i że nie można po pierwszym roku przenieść takiej domeny do innego registrata bez opłacenia jej u nich.

Tak sie składa, że czytałem dziś opinię na temat netart oraz nazwa.pl i niektórzy podają tam informację o tym, że pracownicy na słuchawce nawet mają powiedziane, że mają nie informować o kosztach. Nie dziwi zatem pozycja rejestratora nr 1

otlet · 10 Lipca 2018

A czy przypadkiem nie informowanie o kosztach jest sprzeczne jakoś z prawem? Nie znam prawa, więc chyba czas poszukać

mariaczi · 10 Lipca 2018

1 minutę temu, theqkash napisał:

pozycja rejestratora nr 1

I naciągacza tym samym... A gdzie uczciwość?

theqkash · 10 Lipca 2018

1 minutę temu, otlet napisał:

A czy przypadkiem nie informowanie o kosztach jest sprzeczne jakoś z prawem?

W zasadzie to niekoniecznie, bo możesz usługi nie utrzymywać po roku czasu. Dziś dostajesz przecież usługę za darmo, o tym akurat jesteś informowany.

1 minutę temu, mariaczi napisał:

A gdzie uczciwość?

otlet · 10 Lipca 2018

3 minuty temu, mariaczi napisał:

I naciągacza tym samym... A gdzie uczciwość?

Uczciwość kiedykolwiek w historii nigdy nie istniała szczególnie, gdy chodzi o pieniądze.

11 Lipca 2018

@theqkash
Dziękujemy za postawione merytoryczne pytania. Poniżej przedstawiamy precyzyjne odpowiedzi, o jakie Pan prosił. Ponieważ jest to forum branżowe, nie rozpisujemy się w sprawach oczywistych, ale jeżeli pojawią się kolejne merytoryczne pytania, nie naruszające know-how firmy, postaramy się udzielić również i na nie odpowiedzi.

1) Na czym polega wspomniana georedundancja? Czy strony klientów są na wielu serwerach naraz i w przypadku gdy coś się stanie z jednym serwerem w Polsce będzie przepięty na inny serwer w pozostałych serwerowniach?

Georedundancja, o której mowa na stronie https://www.nazwa.pl/o-firmie/technologie/ oznacza rozproszenie geograficzne Data Center nazwa.pl, służące zapewnieniu ciągłości działania usług spółki oraz podniesieniu jakości świadczonych przez nią usług. Nie sposób ustrzec się przed wypadkami losowymi związanymi na przykład z naruszeniem działających traktów światłowodowych, przerwami w dostawach zasilania, klęskami żywiołowymi, awariami pojedynczych punktów wymiany operatorskiej, ale można te ryzyka obniżać poprzez zastosowanie redundancji infrastruktury. Ta redundancja może oznaczać działania prewencyjne na poziomie lokalnego Data Center (wykorzystanie traktów światłowodowych od wielu operatorów, dostaw zasilania z wielu Gwarantowanych Punktów Zasilania (GPZ), systemu agregatów i UPS), jak również rozproszenie infrastruktury pomiędzy geograficznie oddalone Data Center.

W przypadku nazwa.pl georedundancja Data Center pozwoliła już na całkowite przeniesienie świadczenia usług VPS z Krakowa do Warszawy (przeniesienie to, jak warto wspomnieć, odbyło się w sposób niezauważalny dla Klientów i nie wymagało nawet restartów maszyn wirtualnych i systemów operacyjnych w nich uruchomionych). Usługi hostingu świadczone są więc nadal w Krakowie, natomiast usługi VPS z Warszawy. Innym przykładem korzyści wynikających z georedundancji jest zastosowanie przez nazwa.pl rozproszonego systemu DNS Anycast, który z powodzeniem od czerwca 2018 r. działa w Krakowie i w Warszawie, a w dniu dzisiejszym został rozszerzony o kolejne Data Center: we Frankfurcie i Amsterdamie. Działanie tego systemu polega na rozgłaszaniu tych samych klas adresów IP w różnych lokalizacjach, dzięki czemu nie tylko został skrócony czas odpowiedzi serwerów DNS, ale przede wszystkim cały system DNS Anycast nazwa.pl stał się dużo bardziej odporny na ataki. Przykładowo, próba przeciążenia serwerów DNS Anycast nazwa.pl z Europy Zachodniej z sieci, z którymi nazwa.pl wymienia ruch w DE-CIX i AMS-IX zostanie skierowana tylko i wyłącznie na serwery zlokalizowane we Frankfurcie i Amsterdamie, nie czyniąc żadnej szkody użytkownikom łączącym się z Polski i korzystającym z serwerów DNS Anycast nazwa.pl podłączonych w Data Center w Krakowie i Warszawie.

Georedundancja to również przyspieszenie działania wielu usług poprzez możliwość zastosowania innych usług opartych o technologię Anycast. Warto zwrócić uwagę, że typowe opóźnienia w transmisji pomiędzy serwerem w Polsce a klientem korzystającym z urządzenia mobilnego (3G) w Europie Zachodniej wynoszą około 100 ms, ale trzeba mieć na uwadze, że w przypadku transmisji TCP realne rozpoczęcie przesyłania danych z uwagi na działanie protokołu TCP i three-way handshake (https://pl.wikipedia.org/wiki/Protok%C3%B3%C5%82_sterowania_transmisj%C4%85) następuje dopiero po pełnym nawiązaniu łączności, co oznacza około 3 x 100 ms = 300 ms. Pierwsza porcja danych dociera więc do użytkownika dopiero po prawie 0,5 s, gdyż czas przesłania pierwszej porcji informacji również trwa 100 ms. Skrócenie czasu o połowę do zapytania o DNS oznacza więc wczytanie każdej strony hostowanej w nazwa.pl o blisko 0,5 s szybciej niż w przypadku, gdyby przekierowanie odbywało się do serwerów w Polsce.

2) Jaki wpływ ma postawienie serwerów poza Polską (tu: w Niemczech i Holandii) na czasy dostępu, podczas gdy większość odbiorców korzystających ze stron Państwa klientów znajduje się w Polsce? W praktyce, ongiś posiadanie serwerów w Polsce było zaletą dla firm świadczących usługi dla Polskiego odbiorcy, ponieważ czasy były właśnie niższe.

Większość Klientów nazwa.pl pochodzi z Polski, jednak nie oznacza to, że użytkownicy, którzy korzystają ze stron Klientów nazwa.pl łączą się wyłącznie z Polski. Z uwagi na obecność Polski w strukturach Unii Europejskiej, 2,5 mln obywateli polskich przebywających na emigracji zarobkowej, wymianę handlową z firmami i konsumentami zagranicznymi, dla wielu Klientów nazwa.pl bardzo ważne jest jak szybko ich usługi działają nie tylko w Polsce, ale i po za jej granicami. Szybkie działanie usług poza obszarem Polski jest szczególnie ważne w sezonie wakacyjnym, gdyż jak szacują eksperci - ponad 5 mln osób rok rocznie wybiera wczasy zagraniczne. Rozpoczęcie świadczenia usług w Data Center we Frankfurcie i Amsterdamie jest kluczowe z uwagi na topologię współczesnego Internetu. To w tych miastach znajdują się główne „skrzyżowania” (DE-CIX, AMS-IX), w których przecinają się drogi przesyłania informacji operatorów telekomunikacyjnych z całego świata. Posiadanie własnych bezpośrednich połączeń z tym centrum gwarantuje, że Klienci otrzymali od nazwa.pl dostęp do „autostrady” łączącej bezpośrednio ich usługi z klientami w wielu państwach na świecie.

Na uwagę zasługuje również fakt, że postawienie na Data Center w tak kluczowych punktach, jak punkty wymiany ruchu DE-CIX i AMS-IX, pozwoli w najbliższej przyszłości na uruchomienie przez nazwa.pl usług jeszcze bardziej przyspieszających transmisję danych, poprzez zastosowanie technologii Content Delivery Network (CDN) nie tylko w zakresie usług DNS, ale również przykładowo dla usług WWW.

3) Jak istotny wpływ maja czasy do np. wspomnianej Australii w przypadku gdy serwer znajduje się w Polsce, a w Niemczech?

Transmisja danych pomiędzy klientem z Australii, a serwerem w Polsce odbywa się poprzez trakty światłowodowe, które tak czy tak krzyżują się w węzłach wymiany ruchu we Frankfurcie (DE-CIX) lub w Amsterdamie (AMS-IX). Każdy dostawca z Australii i z Polski może zdecydować jednak, czy wykorzystać do transmisji do tych węzłów współdzielone transmisje międzynarodowe oferowane przez operatorów Tier1 (autobusy bez gwarancji miejsc siedzących na całym odcinku drogi), czy też zakontraktować dla siebie transmisję punkt-punkt o gwarantowanych przepustowościach (autostrady). Wykorzystanie transmisji zagranicznej oferowanej przez operatorów Tier1 jest więc dużo gorszym rozwiązaniem niż zastosowanie dedykowanych połączeń Polska-Frankfurt, Polska-Amsterdam, z których korzysta nazwa.pl lub Frankfurt-Australia, Amsterdam-Australia, z których korzysta część operatorów z tamtego regionu świata. Nazwa.pl gwarantuje więc największą możliwą szybkość transmisji do węzłów wymiany ruchu z operatorami zagranicznymi (DE-CIX, AMS-IX), czym niezależnie od miejsca kolokacji zapewnia minimalne czasy opóźnień zbliżone do granicy medium światłowodowego (ok. 1 ms na 100 km).

4) Dlaczego lg.nazwa.pl którym się Państwo chwalicie nie działa poprawnie?
Przykład: https://lg.nazwa.pl./?query=trace&protocol=IPv4&addr=nazwa.pl&router=Kraków

Pytanie jest nieprecyzyjne, gdyż nie wiadomo, co miało by nie działać poprawnie. Wskazany link generuje stronę, która prawidłowo pokazuje trasę przesyłania pakietu pomiędzy routerem w Data Center zlokalizowanym w Krakowie a stroną nazwa.pl działającą w tym samym Data Center:

traceroute to nazwa.pl (85.128.128.36), 30 hops max, 60 byte packets
1 nazwa.pl (85.128.128.36) 0.186 ms 0.248 ms 0.241 ms

Przypomnimy jedynie, że narzędzia typu traceroute pokazują adres kolejnego urządzenia za urządzeniem, z którego wykonywane jest zapytanie.

5) Dlaczego używany jest zwrot, że Wasze LG jest pierwsze w Polsce, podczas gdy np. ATMAN ma swoje LG od około 2005 roku? Czy firma ATMAN nie jest firmą hostingową w Państwa nomenklaturze?

W informacji prasowej na stronie https://biuroprasowe.nazwa.pl/33833-nazwa-pl-otwiera-data-center-w-sercu-globalnego-internetu można przeczytać: „Nazwa.pl, jako pierwsza duża firma hostingowa w Polsce, udostępniła swoim klientom usługę Looking Glass – https://lg.nazwa.pl”. Porównanie nazwa.pl do firmy ATM S.A. jest oczywiście tyle samo zaszczytne, co nie trafione, gdyż można by tutaj jeszcze wskazać do porównania narodowego operatora Orange (dawniej Telekomunikacja Polska S.A.) czy T-Mobile. Dla wszystkich wskazanych powyżej spółek usługi hostingowe stanowią niewielki procent przychodów i skupiają się raczej na usługach telekomunikacyjnych i Data Center. Potwierdza to również fakt, że żadna z tych spółek nie osiągnęła wysokiej pozycji w rankingu top100.wht.pl, ani top100.rootnode.pl. Według Raportu kwartalnego spółki ATM S.A. za pierwszy kwartał 2018 można przeczytać, że głównymi przedmiotami działalności tej spółki są:

- Segment Usług Centrów Danych, obejmujący usługi kolokacyjne oraz inne usługi związane z infrastrukturą centrów danych (takie jak np. dzierżawa serwerów dedykowanych, usługi cloud-computingu, usługi biur zapasowych oraz usługi związane z bezpieczeństwem danych i tzw. Business Continuity Management, np. AntyDDoS),

- Segment Usług Telekomunikacyjnych, obejmujący usługi szerokopasmowej transmisji danych, usługi dzierżawy łączy telekomunikacyjnych, usługi dostępu do Internetu oraz usługi głosowe (ISDN i VoIP).
W przypadku spółek hostingowych to hosting i zazwyczaj rejestracja domen jest głównym przedmiotem działalności i tak ma to miejsce w przypadku firm notowanych na czołowych miejscach w rankingach top100.wht.pl i top100.rootnode.pl.

6) Dlaczego w odniesieniu do wynajmowanej szafy/serwerów w szafie w serwerowniach europejskich używają Państwo zwrotu "nasze Data Center"? Czy jeśli moja firma dzierżawi serwery we wszystkich serwerowniach takiego OVH to znaczy, że moja firma ma 10 Data Center?

Data Center to oznaczenie, które może być rozumiane zarówno w kontekście samego budynku i szaf kolokacyjnych, jak i centrum przetwarzania danych rozumiane jako zespół składników niezbędnych do świadczenia usług hostingowych. Na takie centrum składa się wiele elementów, w szczególności budynek wraz z zabezpieczeniami fizycznymi, zasilanie, klimatyzacja, jak również szeroki zakres usług powiązanych, jak kable światłowodowe różnych operatorów telekomunikacyjnych, krosownice, ale również i całe know-how w zakresie wykorzystania tych elementów składowych do stworzenia funkcjonującego centrum przetwarzania danych w ramach Autonomous System. Uruchomienie działającego Data Center oprócz szaf wymaga więc posiadania własnego numeru AS, własnej numeracji IP dla danego Data Center, sesji BGP z co najmniej 2 niezależnymi sieciami AS posiadającymi pełny dostęp do Internetu, zainstalowania routerów, zaimplementowania polityk routingu, systemu DDoS oraz reguł firewallingu. To trochę więcej niż kolokacja serwera w firmie, którą Pan wskazał.

7) Jaki wpływ ma ilość MegaWatów (MW) używanych w materiałach prasowych na działanie infrastruktury i serwisów klientów?

Wszystkie urządzenia konieczne do świadczenia usług hostingowych wymagają bardzo dużej ilości prądu, dlatego ilość energii elektrycznej dostarczonej do budynku Data Center ma kluczowe znaczenie z punktu widzenia przydziału mocy na szafę kolokacyjną. Współcześnie, w dobie miniaturyzacji, to nie wielkość powierzchni kolokacyjnej stanowi bowiem ograniczenie, ale ilość urządzeń, które można zasilić energetycznie i odprowadzić ciepło wytwarzane przez te urządzenia (klimatyzacja). Typowe wartości przydziału mocy na pojedynczą szafę 48 U wynoszą w krajach Europy Zachodniej, Azji i Ameryki Północnej około 2-3 kW. Oznacza to możliwość podłączenia zasilania jedynie do jednego serwera typu blade (https://pl.wikipedia.org/wiki/Serwer_kasetowy), który zajmuje zaledwie 25% miejsca w szafie (około 10 U). Reszta miejsca w szafie kolokacyjnej jest więc w takim wypadku marnowana. Nazwa.pl korzysta jedynie z budynków Data Center o wysokiej dostępności mocy energetycznej na szafę, rzędu 6-12 kW, stosując serwery blade, co umożliwia spółce dostarczenie Klientom dużego zapasu mocy obliczeniowej i możliwość szybkiej rozbudowy klastrów serwerów, bez konieczności czasochłonnej rozbudowy przyłączy energetycznych.

8 ) Dlaczego w jednych materiałach używają Państwo sformułowania mówiącego o 6.4 Tbitps a w innych o 12 Tbitps ?

Informacje dotyczące ilości danych transmitowanych można uzyskać zarówno z oficjalnych stron DE-CIX i AMS-IX, jak i ze strony https://en.wikipedia.org/wiki/List_of_Internet_exchange_points_by_size. Według informacji z Wikipedii ilość ruchu w największym na świecie punkcie wymiany ruchu operatorskiego DE-CIX we Frankfurcie, do którego przyłączona jest nazwa.pl, wynosi w szczycie 6,4 Tbps, w przypadku węzła AMS-IX w Amsterdamie jest to kolejnej 5,5 Tbps, a w DE-CIX w Nowym Jorku - 0,3 Tbps. Łącznie suma ruchu wymienianego w powyższych węzłach wymiany ruchu operatorskiego, do których przyłączona jest bezpośrednio sieć nazwa.pl, wynosi 12,2 Tbps. Dziękujemy za zwrócenie uwagi na pomyłkę redakcyjną w materiałach prasowych nazwa.pl.

9) Na czym polega gigantyczność zaplecza technologicznego nazwa.pl? Na tym, że posiadają Państwo przepustowość 150 Gbps w kilku serwerowniach, czy na czymś jeszcze?

Dziękujemy za słowa uznania. Gigantyczność to Pana określenie, ale wiele elementów wskazuje na przewagi konkurencyjne nazwa.pl w stosunku do innych firm na polskim rynku:

- od 10 lat NetArt Registrar Sp. z o.o., należąca do nazwa.pl, jest jedynym w Polsce rejestratorem domen globalnych (.com, .net, .org, .biz, .info) posiadającym akredytację ICANN i umożliwiającym rejestrację tych domen bez pośredników https://www.icann.org/registrar-reports/accredited-list.html. Ilość obecnie obsługiwanych domen wynosi około 100 tys, co stanowi około 35% działających domen zarejestrowanych przez Polaków. W Polsce nikt poza nazwa.pl nie może się więc poszczycić działającym systemem do rejestracji domen globalnych i akredytacją ICANN,

- wg. raportu NASK za Q1 2018 r. nazwa.pl jest nr 1 w Polsce we wszystkich kluczowych obszarach: ilości nowych rejestracji domen - 34,2%, ilości obsługiwanych domen - 22,3%, ilości obsługiwanych abonentów - 23,04%, ilości domen zabezpieczonych DNSSEC - 91,2%,

- wg. informacji dostępnych dla Partnerów EURid na dzień dzisiejszy NetArt Registrar Sp. z o.o. obsługuje 96,8 tys. domen, czyli więcej niż 3 kolejne polskie firmy: Home.pl - 50,4 tys., Consulting Service - 23,8 tys., AZ.pl - 10,3 tys,

- nazwa.pl jako jedyna duża polska firma hostingowa wdrożyła DNSSEC dla wszystkich domen zarejestrowanych przez spółkę nazwa.pl i przekierowanych na serwery DNS Anycast nazwa.pl. Na dzień dzisiejszy jest to około 450 tys. domen zarejestrowanych w NASK (91,2% udziału w rynku) oraz około 150 tys. domen zarejestrowanych w rejestrach nadzorowanych przez EURid i ICANN, co w sumie daje około 600 tys. domen zabezpieczonych DNSSEC,

- nazwa.pl jest przyłączona do największych węzłów ruchu operatorskiego na świecie, co można sprawdzić na stronach: https://www.de-cix.net/en/locations/germany/frankfurt/connected-networks, https://www.de-cix.net/en/locations/united-states/new-york/connected-networks, https://ams-ix.net/connected_parties,

- nazwa.pl posiada bezpośrednią wymianę ruchu z większością polskich operatorów telekomunikacyjnych dostępnych w punktach wymiany ruchu operatorskiego: PLIX, TPIX, EPIX, Thinx, oraz z kilkoma największymi z nich w międzynarodowych punktach wymiany ruchu w DE-CIX i AMS-IX - poprzez Data Center we Frankfurcie i Amsterdamie,

- nazwa.pl wdrożyła serwery DNS Anycast w Data Center w Krakowie, Warszawie, Amsterdamie, Frankfurcie, dzięki czemu czasy dostępu do DNS Anycast nazwa.pl dla sieci podłączonych do punktów wymiany ruchu Internetowego: PLIX, TPIX, EPIX, Thinx, DE-CIX, AMS-IX, wynoszą poniżej 1 ms. Żadna inna polska firma hostingowa nie posiada połączenia do tylu węzłów wymiany ruchu, ani nie może poszczycić się tak niskimi czasami dostępu do serwerów DNS,

- usługi hostingu świadczone są w oparciu o technologię cloud ze zdublowanymi wszystkimi elementami architektury, umożliwiającą dowolne skalowanie ilości obsługiwanego ruchu, automatyczne równoważenie obciążenia pomiędzy wszystkimi serwerami wpiętymi w klaster, wyłączanie dowolnego elementu chmury bez wpływu na działanie chmury, migrację w czasie rzeczywistym danych pomiędzy macierzami dyskowymi, zabezpieczenie danych za pomocą sprzętowych macierzy RAID, a nawet migracją danych pomiędzy Data Center,

- usługi VPS świadczone są w najnowszej technologii opartej o KVM, najwydajniejsze na rynku dyski NVMe, a oprogramowanie pozwala w czasie rzeczywistym migrować kontenery Klientów zarówno pomiędzy serwerami w jednym Data Center, jak również pomiędzy Data Center oddalonymi od siebie o tysiące kilometrów, bez przerw w działaniu usług,

Miło nam również poinformować, że w przeciągu kolejnych kilku dni nazwa.pl wprowadzi kolejną kluczową innowację poprawiającą zarówno szybkość działania usług, jak również obniżającą koszty dla Klientów spółki. O szczegółach nie możemy niestety jeszcze dzisiaj zakomunikować, ale będzie to coś, co na trwałe odmieni polski rynek dostawców usług hostingu.

Edytowane 12 Lipca 2018 przez nazwa.pl

Adam Szendzielorz · 11 Lipca 2018

2 godziny temu, nazwa.pl napisał:

Warto zwrócić uwagę, że typowe opóźnienia w transmisji pomiędzy serwerem w Polsce, a klientem korzystającym z urządzenia mobilnego (3G) w Europie Zachodniej wynoszą około 100ms, ale trzeba mieć na uwadze, że w przypadku transmisji TCP realne rozpoczęcie przesyłania danych z uwagi na działanie protokołu TCP i three-way handshake (https://pl.wikipedia.org/wiki/Protok%C3%B3%C5%82_sterowania_transmisj%C4%85) następuje dopiero po pełnym nawiązaniu łączności, co oznacza około 3x100ms=300ms. Pierwsza porcja danych dociera więc do użytkownika dopiero po prawie 0,5s gdyż czas przesłania pierwszej porcji informacji również trwa 100ms. Skrócenie czasu o połowę do zapytania o DNS oznacza więc wczytanie każdej strony hostowanej w nazwa.pl o blisko 0,5s szybciej, niż w przypadku gdyby przekierowanie odbywało się do serwerów w Polsce.

Przecież DNS działa w oparciu o UDP, a nie TCP. Jakie 0,5 sek?

Skoro dane znajdują się fizycznie w Warszawie, czy Krakowie - pakiet z Europy zachodniej nadal będzie pokonywał tę trasę w identycznym jak wcześniej czasie. Przecież nie replikujecie VPSów, dedyków, czy hostingu na serwery w Niemcach / Holandii.

theqkash · 11 Lipca 2018

@nazwa.pl Dziękuję za bardzo szczegłówą wypowiedź.

2 godziny temu, nazwa.pl napisał:

Georedundancja o której mowa na stronie https://www.nazwa.pl/o-firmie/technologie/ oznacza rozproszenie geograficzne Data Center nazwa.pl, służące zapewnieniu ciągłości działania usług spółki nazwa.pl, oraz podniesieniu jakości świadczonych przez nią usług. Nie sposób ustrzec się przed wypadkami losowymi związanymi na przykład z naruszeniem działających traktów światłowodowych, przerwami w dostawach zasilania, klęskami żywiołowymi, awariami pojedynczych punktów wymiany operatorskiej, ale można te ryzyka obniżać poprzez zastosowanie redundancji infrastruktury. Ta redundancja może oznaczać działania prewencyjne na poziomie lokalnego Data Center (wykorzystanie traktów światłowodowych od wielu operatorów, dostaw zasilania z wielu Gwarantowanych Punktów Zasilania (GPZ), systemu agregatów i UPS), jak również rozproszenie infrastruktury pomiędzy geograficznie oddalone Data Center.
W przypadku nazwa.pl georedundancja Data Center pozwoliła już obecnie na całkowite przeniesienie świadczenia usług VPS z Krakowa do Warszawy (przeniesienie to jak warto wspomnieć odbyło się w sposób niezauważalny dla Klientów i nie wymagało nawet restartów maszyn wirtualnych i systemów operacyjnych w nich uruchomionych). Usługi hostingu świadczone są więc nadal w Krakowie, natomiast usługi VPS z Warszawy. Innym przykładem korzyści wynikających z georedundancji jest zastosowanie przez nazwa.pl rozproszonego systemu DNS Anycast, który z powodzeniem od czerwca 2018r działa w Krakowie i w Warszawie, a dniu dzisiejszym został rozszerzony o kolejne Data Center we Frankfurcie i Amsterdamie. Działanie tego systemu polega na rozgłaszaniu tych samych klas adresów IP w różnych lokalizacjach, dzięki czemu nie tylko został skrócony czas odpowiedzi serwerów DNS, ale przede wszystkim cały system DNS Anycast nazwa.pl stał się dużo bardziej odporny na ataki. Przykładowo próba przeciążenia serwerów DNS Anycast nazwa.pl z Europy Zachodniej z sieci z którymi nazwa.pl wymienia ruch w DE-CIX i AMS-IX zostanie skierowany tylko i wyłącznie na serwery zlokalizowane we Frankfurcie i Amsterdamie, nie czyniąc żadnej szkody użytkownikom łączącym się z Polski i korzystających z serwerów DNS Anycast nazwa.pl podłączonych w Data Center w Krakowie i w Warszawie.
Georedundancja w to również przyspieszenie działania wielu usług, poprzez możliwość zastosowania innych usług opartych o technologię Anycast. Warto zwrócić uwagę, że typowe opóźnienia w transmisji pomiędzy serwerem w Polsce, a klientem korzystającym z urządzenia mobilnego (3G) w Europie Zachodniej wynoszą około 100ms, ale trzeba mieć na uwadze, że w przypadku transmisji TCP realne rozpoczęcie przesyłania danych z uwagi na działanie protokołu TCP i three-way handshake (https://pl.wikipedia.org/wiki/Protok%C3%B3%C5%82_sterowania_transmisj%C4%85) następuje dopiero po pełnym nawiązaniu łączności, co oznacza około 3x100ms=300ms. Pierwsza porcja danych dociera więc do użytkownika dopiero po prawie 0,5s gdyż czas przesłania pierwszej porcji informacji również trwa 100ms. Skrócenie czasu o połowę do zapytania o DNS oznacza więc wczytanie każdej strony hostowanej w nazwa.pl o blisko 0,5s szybciej, niż w przypadku gdyby przekierowanie odbywało się do serwerów w Polsce.

Rozumiem te wszystkie superlatywy, natomiast dla mnie to nic nie zmienia. W praktyce bowiem dla przeciętnego Kowalskiego sytuacja się nie zmieni - jak coś padnie, to padnie. Z DNS Anycast nie korzysta większość z operatorów, bo zwykle nie ma takiej potrzeby. Odpowiedzi z serwerów DNS nie trwają 0,5s tylko znacznie krócej. Notabene końcowy odbiorca i tak nie korzysta z Waszych serwerów DNS, gdyż nie świadczycie o ile wiem usługi publicznych DNSów.

Poza tym, jeśli dobrze rozumiem posiadaliście Państwo zresztą DNS Anycast już od jakiegoś czasu (bo jak rozumiem nie ruszyło to teraz nagle), a mimo tego całkiem niedawno odnotowaliście gigantyczny pad DNSów co do którego nie zostały opublikowane żadne szczegóły, poza znaną wszystkim z komunikatów prasowych opowieścią o firmie nr 1 która zwalczyła gigantyczne zagrożenie.

Dla mnie zaletą georedundancji byłby fakt, gdyby w przypadku gdy serwerownia w Krakowie wyleci w powietrze, braknie prądu zupełnie, będzie powódź - cokolwiek, można w miarę szybko przywrócić działanie czegoś w innej lokalizacji. W praktyce natomiast to czym nazwa.pl się chwali jest niczym więcej, niż umieszczeniem różnych usług w różnych miejscach. Daleko temu do pojęcia redundancji, przynajmniej w moim rozumieniu tego słowa.

2 godziny temu, nazwa.pl napisał:

Większość Klientów nazwa.pl pochodzi z Polski, jednak nie oznacza to, że użytkownicy którzy korzystają ze stron Klientów nazwa.pl łączą się wyłącznie z Polski. Z uwagi na obecność Polski w strukturach Unii Europejskiej, 2,5mln obywateli polskich przebywających na emigracji zarobkowej, wymianę handlową z firmami i konsumentami zagranicznymi, dla wielu Klientów nazwa.pl bardzo ważne jest jak szybko ich usługi działają nie tylko w Polsce, ale i po za jej granicami. Szybkie działanie usług za granicą Polski jest szczególnie ważne w sezonie wakacyjnym, gdyż jak szacują eksperci ponad 5mln osób rok rocznie wybiera wczasy zagraniczne. Rozpoczęcie świadczenia usług w Data Center we Frankfurcie i Amsterdamie jest kluczowe z uwagi na topologię współczesnego Internetu. To w tych miastach znajdują się główne „skrzyżowania” (DE-CIX, AMS-IX) w których krzyżują się drogi przesyłania informacji operatorów telekomunikacyjnych z całego świata. Posiadanie własnych bezpośrednich połączeń z tym centrum gwarantuje, że Klienci nazwa.pl otrzymali od nazwa.pl dostęp do „autostrad” łączącej bezpośrednio ich usługi z Klientami w wielu państwach na świecie.
Na uwagę zasługuje również fakt, że postawienie na Data Center w tak kluczowych punktach jak punkty wymiany ruchu DE-CIX i AMS-IX pozwolą w najbliższej przyszłości na uruchomienie przez nazwa.pl usług jeszcze bardziej przyspieszających transmisję danych, poprzez zastosowanie technologii Content Delivery Network (CDN) nie tylko w zakresie usług DNS, ale również przykładowo dla usług WWW.

Ok, jak bardzo wpłynie prędkość otwierania się strony, która umieszczona jest na serwerze w Polsce lub w Niemczech dla 2,5mln obywateli polskich przebywających na emigracji zarobkowej etc.? W mojej ocenie mówimy o drobnych licznach, ciężko jest mówić jednak o jakiejś mega korzystnej zmianie.

2 godziny temu, nazwa.pl napisał:

Transmisja danych pomiędzy klientem z Australii, a serwerem w Polsce odbywa się poprzez trakty światłowodowe które tak czy tak krzyżują się w węzłach wymiany ruchu we Frankfurcie (DE-CIX) lub w Amsterdamie (AMS-IX). Każdy dostawca z Australii i z Polski może zdecydować jednak czy wykorzystać do transmisji do tych węzłów współdzielone transmisje międzynarodowe oferowane przez operatorów Tier1 (autobusy bez gwarancji miejsc siedzących na całym odcinku drogi), czy też zakontraktować dla siebie transmisję punkt-punkt o gwarantowanych przepustowościach (autostrady). Wykorzystanie transmisji zagranicznej oferowanej przez operatorów Tier1 jest wiec dużo gorszym rozwiązaniem niż zastosowanie dedykowanych połączeń Polska – Frankfurt, Polska-Amsterdam z których korzysta nazwa.pl, lub Frankfurt – Australia, Amsterdam – Australia z których korzysta część operatorów z tamtego regionu świata. Nazwa.pl gwarantuje więc największą możliwą szybkość transmisji do węzłów wymiany ruchu z operatorami zagranicznymi (DE-CIX, AMS-IX), czym niezależnie od miejsca kolokacji zapewnia minimalne czasy opóźnień zbliżone do granicy medium światłowodowego (ok. 1ms na 100km).

Poza liczbami, jaki istotny wpływ będzie ta zmiana miała dla przeciętnego klienta? Rozumiem serwery VPS, w przypadku gdy ping jest niski ma to znaczenie np. dla usług głosowych, natomiast w przypadku zwykłego hostingu w mojej ocenie nie ma kompletnie żadnego znaczenia.

2 godziny temu, nazwa.pl napisał:

Pytanie jest nie precyzyjne, gdyż nie wiadomo co miało by nie działać poprawnie. Wskazany link generuje stronę która prawidłowo pokazuje trasę przesłania pakietu pomiędzy routerem w Data Center zlokalizowanym w Krakowie a stroną nazwa.pl działającą w tym samym Data Center:

Na moment publikowania informacji, lg wyświetlał timeouty dla nazwa.pl, a jak zostało wspomniane w późniejszych wypowiedziach innych użytkowników, trasy są pomylone lub nie działają właściwie.

2 godziny temu, nazwa.pl napisał:

Dla wszystkich wskazanych powyżej spółek usługi hostingowe stanowią niewielki procent przychodów i skupiają się raczej na usługach telekomunikacyjnych i Data Center.

Czyli idąc Waszym tokiem myślenia, jeżeli postawię w mieście pizzerię, a ktoś będzie już wcześniej posiadał restaurację która sprzedaje również pizzę, to mam prawo pisać w reklamach, że jako pierwsza firma w mieście sprzedaję pizzę? Jeśli tak to prezentujecie bardzo pokrętną i niezrozumiałą logikę, co oczywiscie jest zrozumiałe z punktu widzenia marketingu jaki prowadzicie i klienta do jakiego kierujecie te opowiadania.

2 godziny temu, nazwa.pl napisał:

Uruchomienie działającego Data Center oprócz szaf wymaga więc posiadania własnego numeru AS, własnej numeracji IP dla danego Data Center, sesji BGP z co najmniej 2 niezależnymi sieciami AS posiadającymi pełny dostęp do Internetu, zainstalowania routerów, zaimplementowania polityk routingu, systemu DDoS, oraz reguł firewallingu.

Odnoszę takie dziwne wrażenie, że określacie Państwo formułki i definicje niektórych rzeczy tak jak Wam pasuje, aby potem podciągnąć to pod te marketingowe opowiadania na stronie biura prasowego. Z perspektywy na przykład definicji na wikipedii:

Centrum danych (ang. data center) – budynek lub pomieszczenie przeznaczone do przechowywania działającej infrastruktury informatycznej: serwerów, urządzeń przechowywania danych (storage) oraz infrastruktury sieciowej. Centra danych zawierają infrastrukturę techniczną, mechanizmy i procedury zwiększające bezpieczeństwo i ciągłość działania serwerów, taką jak: redundancja serwerów, elementów sieciowych i dysków, systemy wentylacji i chłodzenia, zabezpieczenia przeciwpożarowe i kontrolę wstępu.

Gdyby kierować się taką pokrętną logiką jaką kierują się Państwo w tej kwestii, nie ma znaczenia posiadanie lub nie posiadanie własnego numeru AS, własnej numeracji IP dla danego Data Center, sesji BGP z co najmniej 2 niezależnymi sieciami AS posiadającymi pełny dostęp do Internetu, zainstalowania routerów, zaimplementowania polityk routingu, systemu DDoS, oraz reguł firewallingu, a jedynie posiadanie pomieszczenia przeznaczonego do przechowywania działającej infrastruktury informatycznej. Chcąc na siłe podciągać marketingowo takie regułki pod siebie, mógłbym taką kolokację również określić jako posiadanie własnego data center w X miejscach na świecie. Tylko czy to nie wprowadza klientów w błąd?

2 godziny temu, nazwa.pl napisał:

Wszystkie urządzenia konieczne do świadczenia usług hostingowych wymagają bardzo dużej ilości prądu, dlatego ilość energii elektrycznej dostarczonej do budynku Data Center ma kluczowe znaczenie z punktu widzenia przydziału mocy na szafę kolokacyjną. Współcześnie w dobie miniaturyzacji to nie wielkość powierzchni kolokacyjnej stanowi bowiem ograniczenie, ale ilość urządzeń które można zasilić energetycznie i odprowadzić ciepło wytwarzane przez te urządzenia (klimatyzacja). Typowe wartości przydziału mocy na pojedynczą szafę 48U wynoszą w krajach Europy Zachodniej, Azji i Ameryki Północnej około 2-3kW. Oznacza to możliwość podłączenia zasilania jedynie do jednego serwera typu blade (https://pl.wikipedia.org/wiki/Serwer_kasetowy), który zajmuje zaledwie 25% miejsca w szafie (około 10U). Reszta miejsca w szafie kolokacyjnej jest więc w takim wypadku marnowana. Nazwa.pl korzysta jedynie z budynków Data Center o wysokiej dostępności mocy energetycznej na szafę rzędu 6-12kW, stosując serwery blade, co umożliwia spółce dostarczenie Klientom dużego zapasu mocy obliczeniowej i możliwość szybkiego rozbudowy klastrów serwerów, bez konieczności czasochłonnej rozbudowy przyłączy energetycznych.

Brakuje odpowiedzi na moje pytanie - jak to się ma do serwerów klientów? Czy moc liczona w MW wpływa w jakikolwiek sposób na to jak działają strony internetowe czy VPSy klientów? Dla mnie ta wartość jest kompletnie nieistotna z punktu świadczenia usługi i podawanie jej wydaje się być jedynie czysto marketingową papką dla osoby nie mającej zielonego pojęcia o informatyce. Podawanie przepustowości sieci w Tbitps ma już moim zdaniem większy sens, choć nadal w żaden sposób niczego nie określa dla potencjalnego klienta ponieważ ani on, ani jego strona nie jest w stanie tego wykorzystać, a w przypadku mocy w MW to już kompletnie nie ma sensu.

2 godziny temu, nazwa.pl napisał:

Dziękuję za słowa uznania.

Nie ma za co dziękować - zastanawia mnie jedynie dlaczego przyjęliście strategię polegającą na "liderowaniu", byciu "numerem 1 we wszystkim", podczas gdy ciężko jest poraktować Was jako lider w tej kategorii. Ja jako osoba nie korzystająca z Waszych usług odnoszę wrażenie, że z zewnątrz wszystko fajnie wygląda, chwalicie się sukcesami, ale dla przeciętnego klienta może nie wyglądać już tak fajnie, co można przeczytać bez problemu w sieci. Wasz bezpośredni konkurent, będący "numerem 1" w innych kategoriach, nie boryka się z aż takim problemem wizerunkowym. Czym to jest spowodowane?

kankan · 11 Lipca 2018

Kurcze, mam w vultr.com puszczona sesję bgp, firewalla i takie tam do mojego vpsa za 20 dolcow. Biorąc pod uwagę 14 lokalizacji w których mogę mieć instację w vultr mogę zacząć mówić, że mam 14 datacenter…

12 Lipca 2018

13 godzin temu, Adam Szendzielorz napisał:

Przecież DNS działa w oparciu o UDP, a nie TCP. Jakie 0,5 sek?

Skoro dane znajdują się fizycznie w Warszawie, czy Krakowie - pakiet z Europy zachodniej nadal będzie pokonywał tę trasę w identycznym jak wcześniej czasie. Przecież nie replikujecie VPSów, dedyków, czy hostingu na serwery w Niemcach / Holandii.

@Adam Szendzielorz

Zgodnie z dokumentacją „DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION” opisaną w RFC1035 https://www.ietf.org/rfc/rfc1035.txt w przypadku przekroczenia 512 bajtów danych konieczne jest użycie protokołu TCP: „Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header.”

Komunikacja przy użyciu protokołu TCP konieczna jest więc na przykład przy zapytaniu o rekord RRSIG dla strefy pl.
$ host -t RRSIG pl. ;; Truncated, retrying in TCP mode.
pl has RRSIG record NS 8 1 86400 20180809120000 20180710120000 58605 pl. YQ1WBi7XsKGN0tFdKCEVhwDlN/uVhibozXOarl449KVWOheOAa83L1tv T6BdBYbIKMgns0n5BOUP+gOch12+gaKII3ymByI/GIEjbx+F8Zx2+PFp fGaEliYdDgH/6pQEdwYi3qv/LQ+n6mu9ew5UWTAy4nYuscjNw/DgYWKM JCQ=

pl has RRSIG record DS 8 1 86400 20180724050000 20180711040000 41656 . AZ7ClsywZyq5cyfIs8sZAfyWRAnTnrmKBRcou17TPlnz/Wsws035xkDs sN3OXr8kposwIjsqQAqMg29fkpBVhfxDAnQKPQ6Cni+rYV88yMIT2/yS ik0PRLyvzMrlFIzXh8087jG6BbqF6DCDGs4YUpjpOfzqMWea5HolxJir RRfjtAdYp+fz3XVB0vyMY/XnPLXHRgfOPPy3/Vzs1LzpeWMSdFCzG46r BU/mGLHHM0N1SznRPG53s/K2nqHTYE7VgkeuznVOwrc/BcKtzL4LccHl g41bDnHSWZPARB9xMjt4+qLE0fa/ZSYcouly8Xz/fbyPAO/APlWEhUDI laQFxA==

Edytowane 12 Lipca 2018 przez nazwa.pl

Adam Szendzielorz · 12 Lipca 2018

8 minut temu, nazwa.pl napisał:

@Adam Szendzielorz

Zgodnie z dokumentacją „DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION” opisaną w RFC1035 https://www.ietf.org/rfc/rfc1035.txt w przypadku przekroczenia 512 bajtów danych konieczne jest użycie protokołu TCP: „Messages carried by UDP are restricted to 512 bytes (not counting the IP or UDP headers). Longer messages are truncated and the TC bit is set in the header.”

Komunikacja przy użyciu protokołu TCP konieczna jest więc na przykład przy zapytaniu o rekord RRSIG dla strefy pl.
$ host -t RRSIG pl. ;; Truncated, retrying in TCP mode.
pl has RRSIG record NS 8 1 86400 20180809120000 20180710120000 58605 pl. YQ1WBi7XsKGN0tFdKCEVhwDlN/uVhibozXOarl449KVWOheOAa83L1tv T6BdBYbIKMgns0n5BOUP+gOch12+gaKII3ymByI/GIEjbx+F8Zx2+PFp fGaEliYdDgH/6pQEdwYi3qv/LQ+n6mu9ew5UWTAy4nYuscjNw/DgYWKM JCQ=

pl has RRSIG record DS 8 1 86400 20180724050000 20180711040000 41656 . AZ7ClsywZyq5cyfIs8sZAfyWRAnTnrmKBRcou17TPlnz/Wsws035xkDs sN3OXr8kposwIjsqQAqMg29fkpBVhfxDAnQKPQ6Cni+rYV88yMIT2/yS ik0PRLyvzMrlFIzXh8087jG6BbqF6DCDGs4YUpjpOfzqMWea5HolxJir RRfjtAdYp+fz3XVB0vyMY/XnPLXHRgfOPPy3/Vzs1LzpeWMSdFCzG46r BU/mGLHHM0N1SznRPG53s/K2nqHTYE7VgkeuznVOwrc/BcKtzL4LccHl g41bDnHSWZPARB9xMjt4+qLE0fa/ZSYcouly8Xz/fbyPAO/APlWEhUDI laQFxA==

W/w zapytanie leci i tak do serwerów DNS NASKowych, więc Wasze dodatkowe lokalizacje data center nic w kwestii szybkości odpowiedzi nie zmieniają. Faktycznie zapomniałem o DNSSECu, który spowalnia odpowiedzi DNS kilkukrotnie (bo np. normalne DNSy zlokalizowane w Polsce odpowiadają na zapytania z USA w ciągu ok 120ms).

12 Lipca 2018

1 godzinę temu, Adam Szendzielorz napisał:

W/w zapytanie leci i tak do serwerów DNS NASKowych, więc Wasze dodatkowe lokalizacje data center nic w kwestii szybkości odpowiedzi nie zmieniają. Faktycznie zapomniałem o DNSSECu, który spowalnia odpowiedzi DNS kilkukrotnie (bo np. normalne DNSy zlokalizowane w Polsce odpowiadają na zapytania z USA w ciągu ok 120ms).

@Adam Szendzielorz
Przykład z „host -t RRSIG pl” zobrazował przypadek użycia TCP dla zapytań do DNS dla wszystkich domen zabezpieczonych przez DNSSEC w Polsce. W przypadku zapytania do domen przekierowanych na serwery DNS Anycast w nazwa.pl zapytania również są wykonywane z użyciem protokołu TCP. Przykład:
$ host -t RRSIG nazwa.pl
;; Truncated, retrying in TCP mode.
nazwa.pl has RRSIG record TXT 13 2 3600 20180726000000 20180705000000 19476 nazwa.pl. svnVA+hV+D5z3bhRjKVEDPXmQwYD0H0uzaAUFKaP4y3p6r8tvuGIas6t WKvEQ2TxnSDHlSzVbi/jKVGK/Ajs7A==
nazwa.pl has RRSIG record MX 13 2 3600 20180726000000 20180705000000 19476 nazwa.pl. lrr7I99cTQ2siKxLaTPac+mmmvX0CGDFwMdPZaDaoqQ75WJaOI/W6DS5 mEm7RY1Jtvzqi6Pi8WXZePPGGF4U0A==
nazwa.pl has RRSIG record NS 13 2 3600 20180726000000 20180705000000 19476 nazwa.pl. TIDnmvYjcASCJk/uiUfYfjf9QKLhBwjtrksykOTjJAd21uWfgbWybqR9 uMPpHFLlqcqGhGNN2/yYodM1F1Z05A==
nazwa.pl has RRSIG record A 13 2 3600 20180726000000 20180705000000 19476 nazwa.pl. /9lfna1j316bQh5DlewGMl/3HoihHZzpvBaiPcpd8RzK3AnkSJre1DnE QJEYi2UE+zGHLSqltPm/ogcQOSm2Ag==
nazwa.pl has RRSIG record DS 8 2 86400 20180810120000 20180711120000 58605 pl. e56Yv0ZPuvfeO4DYblEpg8TTvNC54bEHN/sxLUpDeSb4sPVEw4n4nrhi fD/FdKtVEdIRCl4IpScZrj+KoDBJuhlspT2R+gLaWNNyn9hjeljfvoZr /Qtv/v879sRfL2QdW7stoGapMRXKZQeOBO4a0JDWqxC2QCRMcMNC+j5L xTU=

W podanym przez Pana przykładzie czasy odpowiedzi DNSów zlokalizowanych w Polsce na zapytania z USA o rekord RRSIG wyniosą więc nie 120ms, ale 3 x 120ms na nawiązanie połączenia, oraz 120ms na transmisję. Razem 480ms. Różnica wynosi więc tyle co czas potrzebny na nawiązanie połączenia TCP – czyli 360ms i za każdym razem różnica będzie wynosiła 3x opóźnienie w transmisji. Warto więc stosować technologię DNS Anycast i dywersyfikować geograficznie rozmieszczenie serwerów.

patrys · 13 Lipca 2018

@nazwa.pl tak z innej beczki, piszecie, że priorytetem Waszej firmy jest bezpieczeństwo.

Czemu więc od kilku tygodni z Waszych serwerów przychodzą wiadomości zawierające złośliwe oprogramowanie w załącznikach?

Wiadomości to oczywiście "faktury", "deklaracje vat", czy dziś nawet "deklaracja zus".

Nie wygląda to na VPS, a serwery hostingowe/pocztowe.

Dwa maile z dziś:

Return-Path: <[email protected]>
Delivered-To: ***@netfs.pl
Received: by netfs.pl (Postfix, from userid 8)
    id A0607157CBC; Fri, 13 Jul 2018 05:07:50 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on con.netfs.pl
X-Spam-Level: ****
X-Spam-Status: No, score=4.3 required=5.0 tests=Nazwa1,RCVD_IN_RP_RNBL
    autolearn=no autolearn_force=no version=3.4.1
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=85.128.247.113; helo=aom113.rev.netart.pl; [email protected]; receiver=<UNKNOWN> 
Received: from aom113.rev.netart.pl (aom113.rev.netart.pl [85.128.247.113])
    by netfs.pl (Postfix) with ESMTP id 0C2AE157CBA
    for <***@netfs.pl>; Fri, 13 Jul 2018 05:07:48 +0200 (CEST)
Received: from eveijv (mail4.cargo-time.net [80.79.119.235])
    by gumbi.nazwa.pl (Postfix) with ESMTP id 036B243F9BD
    for <***@netfs.pl>; Fri, 13 Jul 2018 05:07:47 +0200 (CEST)
From: "Tomaszewski Jacek" <[email protected]>
Subject: deklaracja zus 07/18

+

Return-Path: <[email protected]>
Delivered-To: ***@netfs.pl
Received: by netfs.pl (Postfix, from userid 8)
    id B8A0F157CBC; Fri, 13 Jul 2018 04:41:47 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on con.netfs.pl
X-Spam-Level: ****
X-Spam-Status: No, score=4.3 required=5.0 tests=Nazwa1,RCVD_IN_RP_RNBL
    autolearn=no autolearn_force=no version=3.4.1
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=85.128.247.113; helo=aom113.rev.netart.pl; [email protected]; receiver=<UNKNOWN> 
Received: from aom113.rev.netart.pl (aom113.rev.netart.pl [85.128.247.113])
    by netfs.pl (Postfix) with ESMTP id 997BB157CBA
    for <[email protected]>; Fri, 13 Jul 2018 04:41:44 +0200 (CEST)
Received: from vddddrfger (mail4.cargo-time.net [80.79.119.235])
    by gumbi.nazwa.pl (Postfix) with ESMTP id B5EB71A630D
    for <***@netfs.pl>; Fri, 13 Jul 2018 04:41:43 +0200 (CEST)
From: "=?utf-8?B?SXdvbmEgSmXFvGFr?=" <[email protected]>
Subject: =?utf-8?B?RmFrdHVyYSBWQVQgLSBzcHJ6ZWRhxbx5ICBuci4gNjM4OC8wNi8yMDE4?=

Nie da się tego jakoś zabezpieczyć i filtrować wiadomości wychodzące ?

Czy trzeba pisać filtry by np. nie wpuszczać wiadomości z *.rev.netart.pl zawierających załącznik ?

Edytowane 13 Lipca 2018 przez patrys

kankan · 13 Lipca 2018

O tak, też to dostaje..

theqkash · 13 Lipca 2018

Podobną dyskusję widzę na forum webhostingtalk, gdzie odpowiedź została już w tej sprawie udzielona, ale w niezbyt dużym stopniu ucieszyła zainteresowanego.

Link: https://www.webhostingtalk.pl/topic/58408-uwaga-nazwapl/?do=findComment&comment=495191

13 Lipca 2018

@patrys
Problem wysyłania SPAMu dotyczy w równym stopniu każdego usługodawcy będącego operatorem serwerów poczty elektronicznej. Dla usługodawców posiadających małe bazy użytkowników, a w szczególności nie posiadających dużej rotacji Klientów jest to problem dużo mniejszy, niż w przypadku ponad milionowej bazy obsługiwanych kont pocztowych w nazwa.pl. Dużo większa percepcja ilości niepożądanych przesyłek przychodzących z nazwa.pl w porównaniu do innych mniejszych dostawców hostingowych wynika więc z zupełnie innej wielkości baz użytkowników, a nie z tego że nazwa.pl nie dba wystarczająco dobrze o zabezpieczenia przed SPAMem. Gdyby patrzeć przez pryzmat filtrowania o jakim Pan napisał to dla nazwa.pl największym spamerem były by google.com, allegro.pl, onet.pl, wp.pl i inne portale i wortale tematyczne. Zawsze można postawić chiński mur, tylko czy to jest rozwiązanie problemu? Dziennie do serwerów nazwa.pl dociera kilka milionów zawirusowanych wiadomości, a prawie 50% wiadomości, które przechodzą pomyślnie przez filtry antywirusowe jest spamem, który według odpowiednich filtrów jest odpowiednio oznaczany i usuwany według indywidualnych preferencji użytkowników poczty w nazwa.pl.

Nie możemy omawiać przypadku konkretnego Klienta na forum, jednak analiza wklejonych przez Pan nagłówków wiadomości wskazuje, że wiadomość została sprawdzona przez filtr antyspamowy SpamAssasin na Pana serwerze, natomiast brakuje nagłówków dotyczących sprawdzenia antywirusowego poczty na przykład za pomocą clamd. Gdyby taki filtr istniał na Pana serwerze pocztowym to wiadomości zostały by automatycznie odrzucone i nie stanowiły by problemu. Specyfika Internetu, oraz protokołu SMTP wymaga pełnej ochrony u każdego operatora serwerów pocztowych. W przypadku jak wskazanym przez Pana nie doszło do pomyślnej weryfikacji nadawcy wiadomości poprzez SPF/DKIM/DMARC więc nawet nie ma pewności czy wiadomości faktycznie zostały dostarczone przez serwery w nazwa.pl. Wiadomość taka mogła zostać dostarczona do Pana serwera przez dowolny serwer SMTP w sieci Internet.

Nazwa.pl nie stoi obojętnie wobec problemu SPAMu i od kilku miesięcy trwają prace w klastrze serwerów pocztowych, na serwerach DNS Anycast, oraz w wielu innych miejscach infrastruktury spółki mające na celu kompleksowe wdrożenie zabezpieczeń SPF/DKIM/DMARC dla ponad pół miliona domen obsługiwanych w nazwa.pl. Według badań spółki przeprowadzonych na ponad 2mln domen zarejestrowanych w NASK taki poziom zabezpieczeń funkcjonuje na poniżej 1 tys. domen pocztowych. Planowane wdrożenie będzie więc kolejnym przełomowym krokiem czynionym przez nazwa.pl – tyle tylko, że aby w pełni wykorzystać możliwości zmian, które wprowadzi nazwa.pl konieczne będzie wprowadzenie zmian również w oprogramowaniu Pana serwerów pocztowych i innych operatorów w Internecie, do czego wszystkich zachęcamy. Ochrona, o której napisaliśmy powyżej będzie w nazwa.pl działała z końcem trzeciego kwartału 2018 r.

patrys · 13 Lipca 2018

To nie była żadna zaczepka, chciałem po prostu zwrócić uwagę na problem który istnieje i fajnie było by go starać się wyeliminować dla dobra ogółu.

13 minut temu, nazwa.pl napisał:

Nie możemy omawiać przypadku konkretnego Klienta na forum, jednak analiza wklejonych przez Pan nagłówków wiadomości wskazuje, że wiadomość została sprawdzona przez filtr antyspamowy SpamAssasin na Pana serwerze, natomiast brakuje nagłówków dotyczących sprawdzenia antywirusowego poczty na przykład za pomocą clamd. Gdyby taki filtr istniał na Pana serwerze pocztowym to wiadomości zostały by automatycznie odrzucone i nie stanowiły by problemu.

Spamassassin na tym serwerze i tak miał już regułę podbijającą punkty za adres *.rev.netart.pl z uwagi na sporą ilość spamu, ale jak widać punktów było za mało.

Nie wiem co ma do tego Clamav, aczkolwiek też tam był i pełny log poniżej:

Return-Path: <[email protected]>
Delivered-To: ***@netfs.pl
Received: by netfs.pl (Postfix, from userid 8)
	id A0607157CBC; Fri, 13 Jul 2018 05:07:50 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on con.netfs.pl
X-Spam-Level: ****
X-Spam-Status: No, score=4.3 required=5.0 tests=Nazwa1,RCVD_IN_RP_RNBL
	autolearn=no autolearn_force=no version=3.4.1
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=85.128.247.113; helo=aom113.rev.netart.pl; [email protected]; receiver=<UNKNOWN> 
Received: from aom113.rev.netart.pl (aom113.rev.netart.pl [85.128.247.113])
	by netfs.pl (Postfix) with ESMTP id 0C2AE157CBA
	for <***@netfs.pl>; Fri, 13 Jul 2018 05:07:48 +0200 (CEST)
Received: from eveijv (mail4.cargo-time.net [80.79.119.235])
	by gumbi.nazwa.pl (Postfix) with ESMTP id 036B243F9BD
	for <***@netfs.pl>; Fri, 13 Jul 2018 05:07:47 +0200 (CEST)
From: "Tomaszewski Jacek" <[email protected]>
Subject: deklaracja zus 07/18
To: ***@netfs.pl
Content-Type: multipart/mixed; boundary="Hq7=_KwJ9NMdL8IcWnYGef5XJcx7Y8KZmm"
MIME-Version: 1.0
Reply-To: "Tomaszewski Jacek" <[email protected]>
Organization: PB Technik Sp. z. o.o.
Date: Fri, 13 Jul 2018 06:07:46 +0300
Message-Id: <[email protected]>
X-Virus-Scanned: clamav-milter 0.99.4 at con.netfs.pl
X-Virus-Status: Clean

Jak widać wiadomość przyszła z serwera aom113.rev.netart.pl i mogę nawet pokazać logi z serwera SMTP, jednak nie oto tu chodzi.

Wiadomości oczywiście jest więcej np.

Return-Path: <[email protected]>
Delivered-To: ***@netfs.pl
Received: by netfs.pl (Postfix, from userid 8)
    id 7AEAA157CBC; Thu, 21 Jun 2018 00:17:21 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on con.netfs.pl
X-Spam-Level: *
X-Spam-Status: No, score=1.5 required=5.0 tests=ZABOJCASPAMU_FROM_UNKNOWN
    autolearn=no autolearn_force=no version=3.4.1
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=85.128.149.224; helo=aks224.rev.netart.pl; [email protected]; receiver=<UNKNOWN> 
Received: from aks224.rev.netart.pl (aks224.rev.netart.pl [85.128.149.224])
    by netfs.pl (Postfix) with ESMTP id E6F56157CBA
    for <[email protected]>; Thu, 21 Jun 2018 00:17:19 +0200 (CEST)
Received: from evevetbtg (unknown [188.126.76.96])
    by garwolin.nazwa.pl (Postfix) with ESMTP id 44B35235D52
    for <***@netfs.pl>; Thu, 21 Jun 2018 00:17:18 +0200 (CEST)
From: "=?utf-8?B?RG9yb3RhIFd5Y3rDs8WCa293c2th?=" <[email protected]>
Subject: =?utf-8?B?WmFtw7N3aWVuaWU=?=
To: "***" <***@netfs.pl>
Content-Type: multipart/mixed; boundary="wPBDkbLyk=_e3K4ppYqbDRk2L8pxiVRNP8"
MIME-Version: 1.0
Reply-To: "=?utf-8?B?RG9yb3RhIFd5Y3rDs8WCa293c2th?="
 <[email protected]>
Date: Thu, 21 Jun 2018 01:17:15 +0300
Message-Id: <[email protected]>
X-Virus-Scanned: clamav-milter 0.99.4 at con.netfs.pl
X-Virus-Status: Clean

Podobny wątek znalazłem też na na grupie Mordplik choć akurat to dotyczy się innego rodzaju spamu: https://groups.google.com/forum/#!topic/pl.internet.mordplik/XE_elLF1NsY

Adam Szendzielorz · 13 Lipca 2018

54 minuty temu, nazwa.pl napisał:

Gdyby taki filtr istniał na Pana serwerze pocztowym to wiadomości zostały by automatycznie odrzucone i nie stanowiły by problemu. Specyfika Internetu, oraz protokołu SMTP wymaga pełnej ochrony u każdego operatora serwerów pocztowych.

Serio zrzucacie odpowiedzialność za wysyłane z Waszych serwerów spamy na odbiorcę? Chyba kogoś poniosło :-)

PS. Tych spamów jest całe mnóstwo i wychodzą przez wiele dni z jednego adresu IP należącego do Was.

Nie tłumaczcie się skalą - nie widzę różnicy w implementacji zabezpieczenia dla jednego, a dla tysiąca serwerów. Tylko trzeba takie zabezpieczenie posiadać.

kankan · 13 Lipca 2018

Jak zawsze winny user ;)… Zgadzam się, że jest tego jest na peczki…

Received: from abr174.rev.netart.pl ([77.55.43.174]) by xxxxxx.pl with esmtp (Exim 4.90_1) (envelope-from <X>) id 1fW2mX-000XZAz-XX for [email protected]; Fri, 22 Jun 2018 02:10:21 +0200
Received: from evevetbtg (unknown [46.22.211.188]) by mds-systems.nazwa.pl (Postfix) with ESMTP id 83cxDXDX30 for <xxx@xxxxx.pl> Fri, 22 Jun 2018 02:10:20 +0200 (CEST)
Message-Id: <X@mds-systems.nazwa.pl>


Received: from amk235.rev.netart.pl ([85.128.193.235]) by xxxxxx.pl with esmtp (Exim 4.90_1) (envelope-from <X>) id 1fX5eI-00XvX-XX for [email protected]; Wed, 27 Jun 2018 10:15:57 +0200
Received: from FGHVJKJLL (unknown [80.79.119.244]) by przygodalebo.nazwa.pl (Postfix) with ESMTP id 8X1XD78XX for <xxx@xxxxx.pl>; Wed, 27 Jun 2018 10:15:57 +0200 (CEST)
Message-Id: <X@przygodalebo.nazwa.pl>


Received: from aod166.rev.netart.pl ([85.128.238.166]) by xxxxxx.pl with esmtp (Exim 4.90_1) (envelope-from <X>) id 1fxx7V-2450fXM-Xz for [email protected]; Fri, 15 Jun 2018 00:52:33 +0200
Received: from sdvfvsvf (unknown [188.126.76.96]) by grupamaspecn.nazwa.pl (Postfix) with ESMTP id 1CF7X3XX6Z for <xxx@xxxxx.pl>; Fri, 15 Jun 2018 00:52:33 +0200 (CEST)
Message-Id: <X@grupamaspecn.nazwa.pl>


Received: from aly124.rev.netart.pl ([85.128.181.124]) by xxxxxx.pl with esmtp (Exim 4.90_1) (envelope-from <X>) id 1fYAZ-00A7XJ-AE for [email protected]; Thu, 28 Jun 2018 01:08:51 +0200
Received: from FGHVJKJLL (unknown [80.79.119.244]) by lamc.nazwa.pl (Postfix) with ESMTP id ACX3X2D6XX8 for < [email protected] >; Thu, 28 Jun 2018 01:08:52 +0200 (CEST)
Message-Id: <X@lamc.nazwa.pl>

Adam Szendzielorz · 13 Lipca 2018

8 minut temu, kankan napisał:

Jak zawsze winny user ;)… Zgadzam się, że jest tego jest na peczki…


Received: from abr174.rev.netart.pl ([77.55.43.174]) by xxxxxx.pl with esmtp (Exim 4.90_1) (envelope-from <X>) id 1fW2mX-000XZAz-XX for [email protected]; Fri, 22 Jun 2018 02:10:21 +0200
Received: from evevetbtg (unknown [46.22.211.188]) by mds-systems.nazwa.pl (Postfix) with ESMTP id 83cxDXDX30 for <xxx@xxxxx.pl> Fri, 22 Jun 2018 02:10:20 +0200 (CEST)
Message-Id: <X@mds-systems.nazwa.pl>


Received: from amk235.rev.netart.pl ([85.128.193.235]) by xxxxxx.pl with esmtp (Exim 4.90_1) (envelope-from <X>) id 1fX5eI-00XvX-XX for [email protected]; Wed, 27 Jun 2018 10:15:57 +0200
Received: from FGHVJKJLL (unknown [80.79.119.244]) by przygodalebo.nazwa.pl (Postfix) with ESMTP id 8X1XD78XX for <xxx@xxxxx.pl>; Wed, 27 Jun 2018 10:15:57 +0200 (CEST)
Message-Id: <X@przygodalebo.nazwa.pl>


Received: from aod166.rev.netart.pl ([85.128.238.166]) by xxxxxx.pl with esmtp (Exim 4.90_1) (envelope-from <X>) id 1fxx7V-2450fXM-Xz for [email protected]; Fri, 15 Jun 2018 00:52:33 +0200
Received: from sdvfvsvf (unknown [188.126.76.96]) by grupamaspecn.nazwa.pl (Postfix) with ESMTP id 1CF7X3XX6Z for <xxx@xxxxx.pl>; Fri, 15 Jun 2018 00:52:33 +0200 (CEST)
Message-Id: <X@grupamaspecn.nazwa.pl>


Received: from aly124.rev.netart.pl ([85.128.181.124]) by xxxxxx.pl with esmtp (Exim 4.90_1) (envelope-from <X>) id 1fYAZ-00A7XJ-AE for [email protected]; Thu, 28 Jun 2018 01:08:51 +0200
Received: from FGHVJKJLL (unknown [80.79.119.244]) by lamc.nazwa.pl (Postfix) with ESMTP id ACX3X2D6XX8 for < [email protected] >; Thu, 28 Jun 2018 01:08:52 +0200 (CEST)
Message-Id: <X@lamc.nazwa.pl>

Ja tego mam trochę więcej - z samego lipca z jednego z trzech MXów:

tail -n 1000000 mailstats.csv | grep ".nazwa.pl" | egrep -i "faktur|fv|zus" | grep "Jul 2018" | wc -l
4273

Zdecydowana większość to owe spamy. Z IP których Ty wkleiłeś mam:

tail -n 1000000 mailstats.csv | grep ".nazwa.pl" | grep 85.128.238.166 | wc -l
803

Przyjrzałem się im dokładniej - zdecydowana większość rozpoczyna się ok 23-00 i leci do 8-9 rano. Zapewne rejestrują w nocy serwery i spamują do rana. @nazwa.pl nie macie blokady dostępu SMTP dla nowych użytkowników albo chociaż solidne ograniczenia / monitoring? Wygląda na to że ludzie sobie spamują swobodnie przez noc kiedy admini śpią.

13 Lipca 2018

@patrys

Dziękujemy za rozsądne podejście i merytoryczne uwagi. Również zależy nam na ograniczeniu spamu zarówno przychodzącego, jak i tego który wysyłany jest z serwerów nazwa.pl. Można ten proceder ograniczać i zwalczać, ale nie da się go wyeliminować. Głównym źródłem spamu wychodzącego z serwerów nie są przecież Klienci firm hostingowych, ale „dziurawe” skrypty na stronach Klientów, przez które wysyłane są wiadomości. Szkodliwe oprogramowanie, które wysyłane jest w takich przypadkach można jeszcze wykryć, ale prawdziwym wyzwaniem jest rozróżnić w sposób automatyczny prawdziwe wiadomości od SPAMu, w taki sposób aby nie stać się cenzorem dla własnych Klientów.

Punktowanie na podstawie revers DNS *.rev.netart.pl nie wydaje się być dobrym rozwiązaniem bo użytkownicy poczty na Pana serwach mogą przez to mieć problemy z otrzymywaniem poczty przychodzącej z ponad 600 tys. domen, które obsługuje nazwa.pl, czyli z co czwartej domeny w Polsce.

Zmiany w systemie pocztowym nazwa.pl dotyczące SPF/DKIM/DMARC, o których napisaliśmy w poprzedniej wiadomości, rozwiążą dużą część przypadków nie autoryzowanych połączeń SMTP, tyle tylko, że tak jak pisaliśmy wcześniej konieczne będą zmiany również po stornie innych operatorów hostingowych w Polsce. Nasze ustawienia mogą sygnalizować nieprawidłowości, ale na ich podstawie zawsze ocena pozostanie po stronie serwera odbiorcy wiadomości.

Zaloguj się

Cześć!

Opinie o nazwa.pl

Rekomendowane odpowiedzi

Top użytkownicy w tym temacie

Popularne dni

Top użytkownicy w tym temacie

Popularne dni

Popularne posty

samu

Adam Szendzielorz

Adam Szendzielorz

Opublikowane grafiki

Gość nazwa.pl

Gość nazwa.pl

Gość nazwa.pl

Gość nazwa.pl

Gość nazwa.pl

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Zarejestruj nowe konto

Zaloguj się

Podobna zawartość

Ostatnio przeglądający 0 użytkowników

Powiadomienie o plikach cookie