Skocz do zawartości
Mesharsky

Problem z DNS na serwerze dedykowanym OVH

Polecane posty

Napisano (edytowany)

Witam @OVH,

Mam problem z waszym firewallem który już trwa dobre miesiące, jednakże zanim skontaktowałem się z wami zrobiłem masę testów dzięki którym mogę stwierdzić że mitygacja (Automatyczna) blokuje użytkownikom dostęp do strony WWW. (Serwer dedykowany korzystam jako Hosting WWW oparty o cPanel).

Błąd podczas ataku: DNS_PROBE_FINISHED_NXDOMAIN

Najlepsze jest to że waszej mitygacji podczas ataku nie można wyłączyć a Firewall Rule's nie działają prawidłowo (Zgodnie z dokumentacją oraz zgodnie z modyfikacjami).

Rozmawiałem wczoraj z technikiem który posiada u was 5-6 serwerów, i tutaj jego wiadomość po 3 godzinach pracy w SSH na moim serwerze

image.png.596d5c11a713ccafaa3f74645128fc60.png

Problem który widnieje przez użytkowników oraz mnie po wykonaniu "PING" na byle jaką domenę na moim serwerze:

Ping request could not find host hostfox.pl. Please check the name and try again.

Proszę bardzo check-host:
https://check-host.net/check-report/bb9e7d5k897

Zapytałem się również znajomego w Polsce, sprawdził mi całego firewalla, bo może faktycznie mogłem ja coś źle zrobić, i natychmiastowo kazał mi się do was zgłosić tutaj (Bo telefonicznie praktycznie nigdy nie otrzymałem od was pomocy, a na tickety czeka się kilka tygodni).


Porty: 53 są otwarte zarówno UDP oraz TCP podczas ataku, komenda ping na adresy IP działa, SSH działa, tak jak w SS wyżej, jednakże nic innego nie działa, do póki atak się nie zakończy.
Do tego chciałbym nakreślić że to nie jest wina konfiguracji mojego serwera gdyż nie używamy żadnego firewalla / iptables rules, ani nic z tych rzeczy.
Tak samo dzieję się to na czystym serwerze dedykowanym jak i na tym obecnie, podczas ataku na adres IP mojego serwera, i gdy wy włączacie mitygację, strony nie odpowiadają.


Prosiłbym o jak najszybsze rozwiązanie problemu...
 

Edytowano przez Mesharsky

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
12 minut temu, l3szcz napisał:

@OVH mam dokładnie to samo, jest coś z mitygacją.

Po rozmowie z działem technicznym telefonicznie otrzymałem bardzo fajną wiadomość:

Nic ci nie pomożemy załóż ticketa i czekaj na odpowiedź, gdy mój serwer jest cały czas atakowany i wszystkie strony nie działają, niestety pan z działu technicznego nie ma żadnej możliwości natychmiastowej pomocy, ani aktualnego działania, mimo bardzo wielu próśb.

...

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
47 minut temu, l3szcz napisał:

@OVH mam dokładnie to samo, jest coś z mitygacją.

Nie z mitygacją a ze stanem twojej wiedzy. Niestety ale OVH w przypadku Ataku DoS/DDoS dla usług objętych filtracją Anty-DDoS Pro ucina wszystkie pakiety UDP na czas trwania filtracji. I dlatego kolega @Mesharsky ma takowy problem. Jednym z jego rozwiązań jest używanie kilku adresów ipv4 dla serwera DNS bądź zmiana gamy serwera na GAME która filtruje pakiety UDP a nie je całkowicie odrzuca.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
1 minutę temu, #Gremsonkowy# napisał:

Nie z mitygacją a ze stanem twojej wiedzy.

 


W przypadku ataku, którego nie miałem już od dłuższego czasu?
Blokada 24/7 dla różnych sieci?
No rzeczywiście.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
3 minuty temu, #Gremsonkowy# napisał:

Nie z mitygacją a ze stanem twojej wiedzy. Niestety ale OVH w przypadku Ataku DoS/DDoS dla usług objętych filtracją Anty-DDoS Pro ucina wszystkie pakiety UDP na czas trwania filtracji. I dlatego kolega @Mesharsky ma takowy problem. Jednym z jego rozwiązań jest używanie kilku adresów ipv4 dla serwera DNS bądź zmiana gamy serwera na GAME która filtruje pakiety UDP a nie je całkowicie odrzuca.

Mija się to z celem bo w niektórych krajach strony działają w 3 lub 4 krajach. (Np Francja).
Wszędzie indziej nie.

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
1 minutę temu, Mesharsky napisał:

Mija się to z celem bo w niektórych krajach strony działają w 3 lub 4 krajach. (Np Francja).
Wszędzie indziej nie.

 

Powiedz mi w takim razie jak to sprawdziłeś? Jeśli użyłeś check-hosta a oni prawdopodobnie używają serwerów z OVH to widać że nie wiesz jak działa Anty-DDoS w OVH. Ponieważ firewall na tilerach obsługuje ruch jedynie WAN natomiast ten w obrębie infry OVH nie jest przez niego limitowany.

  • Super! 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Napisano (edytowany)
6 minut temu, #Gremsonkowy# napisał:

Powiedz mi w takim razie jak to sprawdziłeś? Jeśli użyłeś check-hosta a oni prawdopodobnie używają serwerów z OVH to widać że nie wiesz jak działa Anty-DDoS w OVH. Ponieważ firewall na tilerach obsługuje ruch jedynie WAN natomiast ten w obrębie infry OVH nie jest przez niego limitowany.

Znajomy który wczoraj mieszka we Francji i sprawdzał mój serwer, na jego komputerze np wszystkie strony działały, jednakże jak wszedł sam na proxy innego kraju to już nie.

Czyli teoretycznie mówiąc, Francja ma dostęp do wszystkich stron, bo jak wejdziesz przez proxy francuskie byle jakie to wejdziesz na strony na hostingu.
NP: http://www.dedicated-proxy.info/

Czyli blackholing na 3-4 kraje ?

Edytowano przez Mesharsky

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
5 godzin temu, #Gremsonkowy# napisał:

Jednym z jego rozwiązań jest używanie kilku adresów ipv4 dla serwera DNS bądź zmiana gamy serwera na GAME która filtruje pakiety UDP a nie je całkowicie odrzuca.

Zapomniałem dodać że rozwiązanie z OVH game nie zadziała, miałem ten serwer, i problem był identyczny, dodatkowo OVH game ma problem z networkingiem jeżeli chodzi o połączenie się z innymi serwerami dedykowanymi (Nie wszystkimi, jednakże 1/4), wtedy dostałem w rekompensatę darmowe przedłużenie serwera żeby przenieść pliki i zmienić hosta, bo nie mogli się z tym uporać przez ponad 14 dni.

Także to rozwiązanie nie wchodzi w grę.

Aktualnie mogę zauważyć że wszystko działa w następujących krajach: Finlandia, Singapur, Włochy, Francja, Litwa. Reszta krajów = odcięta.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@Mesharsky Najpierw należałoby określić rodzaj ruchu kierowany na Twój serwer podczas ataku. Być może jednocześnie atakowany jest serwer DNS oraz serwer WWW. Przy ataku na sam serwer DNS, strony powinny odpowiadać jeszcze przez jakiś czas od momentu jego rozpoczęcia (czas zależny od konfiguracji serwera DNS).

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Przed chwilą, Suspect napisał:

@Mesharsky Najpierw należałoby określić rodzaj ruchu kierowany na Twój serwer podczas ataku. Być może jednocześnie atakowany jest serwer DNS oraz serwer WWW. Przy ataku na sam serwer DNS, strony powinny odpowiadać jeszcze przez jakiś czas od momentu jego rozpoczęcia (czas zależny od konfiguracji serwera DNS).

Flood na serwer, DNS, serwer ma blackholing.

 

@#Gremsonkowy# a czy Ty czasem nie świadczysz usług związanych z zabezpieczeniami a @Mesharsky nie był Twoim klientem? Idealnie widzę orientujesz się w jego sytuacji. 
 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

@Mesharsky OVH nie ma zwyczaju stosowania mechanizmu BGP blackholing. To właśnie ich sieć światłowodowa posiada spore capacity, dzięki czemu mogą skutecznie dealować ataki wolumetryczne (co w Polsce jest największym problemem: obsługiwać duże wolumeny). Jeżeli atakowane są serwery DNS wykorzystujące protokół UDP, nie jest zaskoczeniem, że taki ruch jest odrzucany (zgodnie z ofertą PRO).

 

Blackholing powinien być stosowany jako ostateczność: nie wiemy jak załagodzić DDoS-a/mamy sufit na rurach/whatever? Blackholing! Jako ostatnia i awaryjna linia obrony - jak najbardziej, natomiast jako stały mechanizm przy nawet znikomej ilości ruchu - już niekoniecznie :D

 

Wracając do tematu: bardziej w takim przypadku obstawiałbym DNS cache, dlatego w pojedynczych przypadkach mogą zdarzać się działające połączenia (co swoją drogą obrazuje, że atakowane muszą być tylko serwery DNS, jeżeli przy prawdopodobnie występującym cache'u Twoje strony internetowe działają poprawnie) ;)

 

Przechodząc do meritum: gdyby to był mój pacjent, poradziłbym setup slave'a w zupełnie innym środowisku (powinno się to wykonać na hoście poza OVH). Manewrowanie między kilkoma adresami IP zupełnie nic tutaj nie zmieni - tak na prawdę wystarczy załączyć wymuszone filtrowanie w OVH dla wszystkich adresów i problem powraca na czas ataku.

 

Ciężko tutaj też przewidywać, bo na razie sprowadzamy się do wróżenia z fusów. Wrzuć jak najwięcej informacji na temat problemu, który Cię dotyka, przed tym spróbuj wykonać to, co opisywałem wyżej oraz opisz feedback. Na pewno będzie nam prościej Ci pomóc.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
6 godzin temu, l3szcz napisał:

 


W przypadku ataku, którego nie miałem już od dłuższego czasu?
Blokada 24/7 dla różnych sieci?
No rzeczywiście.

Twój problem jest zupełnie inny. Skoro nie masz problemów tylko podczas trwania mitygacij po co piszesz "mam dokładnie to samo, jest coś z mitygacją." ?

Dodatkowo znów pokazuje to twoje niezrozumienie działania OVH, jak możesz mieć problem z mitygacją skoro ona w danym momencie nie jest włączona?

 

 

13 minut temu, l3szcz napisał:

Flood na serwer, DNS, serwer ma blackholing.

 

@#Gremsonkowy# a czy Ty czasem nie świadczysz usług związanych z zabezpieczeniami a @Mesharsky nie był Twoim klientem? Idealnie widzę orientujesz się w jego sytuacji. 
 

Kolejny raz używasz sformułowania którego kompletnie nie rozumiesz. BGP blackholing nie ma kompletnie nic wspólnego z działaniem Anty-DDoS PRO OVH w przypadku wykrycia Flooda nie ważne czy to tcp/udp, ruch na protokole UDP jest przycinany.

 

Co do współpracy z @Mesharsky czemu cię to tak interesuje?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Problemem nie jest OVH. Konkretnie, bez lania wody:
 

14 godzin temu, Mesharsky napisał:

Błąd podczas ataku: DNS_PROBE_FINISHED_NXDOMAIN

Tak jak przedmówcy zaznaczyli, błąd jednoznacznie potwierdza brak możliwości rozwiązania nazwy - nie warto rozpatrywać innych kwestii, tak jak to czynicie.
 

14 godzin temu, Mesharsky napisał:

Najlepsze jest to że waszej mitygacji podczas ataku nie można wyłączyć a Firewall Rule's nie działają prawidłowo (Zgodnie z dokumentacją oraz zgodnie z modyfikacjami).

Odkąd pamiętam, podczas enforced nie było możliwości manipulacji regułami fw, z resztą w chwili obecnej, technicznie byłoby to trudne dla obecnej infrastruktury OVH. 
 

14 godzin temu, Mesharsky napisał:

Rozmawiałem wczoraj z technikiem który posiada u was 5-6 serwerów, i tutaj jego wiadomość po 3 godzinach pracy w SSH na moim serwerze

Wyraźnie "technik" zaznaczył z czym jest problem - widać to i bez dostępu SSH, próbując resolvować podaną przez Ciebie domenę.
 

14 godzin temu, Mesharsky napisał:

Problem który widnieje przez użytkowników oraz mnie po wykonaniu "PING" na byle jaką domenę na moim serwerze:

Znów - DNS resolv?

 

14 godzin temu, Mesharsky napisał:

Podana domena nie resolvuje.
 

14 godzin temu, Mesharsky napisał:

Zapytałem się również znajomego w Polsce, sprawdził mi całego firewalla, bo może faktycznie mogłem ja coś źle zrobić, i natychmiastowo kazał mi się do was zgłosić tutaj (Bo telefonicznie praktycznie nigdy nie otrzymałem od was pomocy, a na tickety czeka się kilka tygodni).

 

Ciekawe, którego "znajomego" :)  Wszędzie tickety bez konkretów, informacji odnośnie środowiska, będą długo procedowane. Wybierasz usługę unmanaged, zatem powinieneś sam potrafić zarządzać swoim środowiskiem.

 

14 godzin temu, Mesharsky napisał:

Porty: 53 są otwarte zarówno UDP oraz TCP podczas ataku, komenda ping na adresy IP działa, SSH działa, tak jak w SS wyżej, jednakże nic innego nie działa, do póki atak się nie zakończy.

to komenda ping na dresy IP działa a na domeny nie? Może dlatego że nie resolvują? Próbowałeś (lub Twój technik na SSH) odpytać sam serwer www?

 

14 godzin temu, Mesharsky napisał:

Do tego chciałbym nakreślić że to nie jest wina konfiguracji mojego serwera gdyż nie używamy żadnego firewalla / iptables rules, ani nic z tych rzeczy.
Tak samo dzieję się to na czystym serwerze dedykowanym jak i na tym obecnie, podczas ataku na adres IP mojego serwera, i gdy wy włączacie mitygację, strony nie odpowiadają.

Pod nowy serwer, również próbujesz takiej samej konfiguracji serwera DNS, z tą samą strefą? Czy podnosiłeś serial w SOA?
 

14 godzin temu, l3szcz napisał:

@OVH mam dokładnie to samo, jest coś z mitygacją.

W jakim konkretnie DC z jakim ruchem? Pytam, bo nie mam większych problemów w Polskiej lokalizacji.
 

13 godzin temu, Mesharsky napisał:

Nic ci nie pomożemy załóż ticketa i czekaj na odpowiedź, gdy mój serwer jest cały czas atakowany i wszystkie strony nie działają, niestety pan z działu technicznego nie ma żadnej możliwości natychmiastowej pomocy, ani aktualnego działania, mimo bardzo wielu próśb.


Gdybyś doszedł do tego, o czym napiszę na końcu, prawdopodobnie zaoferowali by Ci pracę i to nie na 1wszej linii :)

 

13 godzin temu, #Gremsonkowy# napisał:

Nie z mitygacją a ze stanem twojej wiedzy. Niestety ale OVH w przypadku Ataku DoS/DDoS dla usług objętych filtracją Anty-DDoS Pro ucina wszystkie pakiety UDP na czas trwania filtracji. I dlatego kolega @Mesharsky ma takowy problem. Jednym z jego rozwiązań jest używanie kilku adresów ipv4 dla serwera DNS bądź zmiana gamy serwera na GAME która filtruje pakiety UDP a nie je całkowicie odrzuca.


Nie do końca ;) Anty DDoS Pro, tak samo jak Game, podczas "mitygacji" filtrują odpowiednie pakiety UDP - o ile ustawisz na firewall'u że dany ruch ma być zezwolony.
 

 

6 godzin temu, XaNeZ napisał:

@Mesharsky OVH nie ma zwyczaju stosowania mechanizmu BGP blackholing. To właśnie ich sieć światłowodowa posiada spore capacity, dzięki czemu mogą skutecznie dealować ataki wolumetryczne (co w Polsce jest największym problemem: obsługiwać duże wolumeny). Jeżeli atakowane są serwery DNS wykorzystujące protokół UDP, nie jest zaskoczeniem, że taki ruch jest odrzucany (zgodnie z ofertą PRO).

 

Otóż nie - w dużym uproszczeniu, każdy operator na pewnym etapie stosuje blackholing, również OVH :) "spore capacity" nie jest przecież złotym lekiem na zatory w ix'ach ;) Dodatkowo, byłoby całkiem dziwne, że zwykłe DNS queries są odrzucane od tak sobie. Nie wiem na jaką informację się powołujesz, bo nigdzie takowej nie ma.
 

 

7 godzin temu, XaNeZ napisał:

Blackholing powinien być stosowany jako ostateczność: nie wiemy jak załagodzić DDoS-a/mamy sufit na rurach/whatever? Blackholing! Jako ostatnia i awaryjna linia obrony - jak najbardziej, natomiast jako stały mechanizm przy nawet znikomej ilości ruchu - już niekoniecznie :D

 

nie "whatever", tylko poczytaj o BGP  - nie jest "ostatecznością", tylko częstą "praktyką", bo tak ma działać w tej warstwie, zaś "gdzie" i "z kim" w przypadku sporej ilości styków OVH, to co innego.

 

7 godzin temu, XaNeZ napisał:

Wracając do tematu: bardziej w takim przypadku obstawiałbym DNS cache, dlatego w pojedynczych przypadkach mogą zdarzać się działające połączenia (co swoją drogą obrazuje, że atakowane muszą być tylko serwery DNS, jeżeli przy prawdopodobnie występującym cache'u Twoje strony internetowe działają poprawnie) ;)

 

Źle obstawiasz - pocieszeniem jest fakt, że ponoć pracownik OVH również do tego nie dotarł.
 

 

7 godzin temu, XaNeZ napisał:

Przechodząc do meritum: gdyby to był mój pacjent, poradziłbym setup slave'a w zupełnie innym środowisku (powinno się to wykonać na hoście poza OVH). Manewrowanie między kilkoma adresami IP zupełnie nic tutaj nie zmieni - tak na prawdę wystarczy załączyć wymuszone filtrowanie w OVH dla wszystkich adresów i problem powraca na czas ataku.

 

Jaki jest sens wypchnięcia własnego DNS'a, poza OVH, bez ich ochrony, skoro działa ona prawidłowo? Chyba nie do końca rozumiesz różnicę w obecnym VAC'u między mitigation a enforced.
 

7 godzin temu, XaNeZ napisał:

Ciężko tutaj też przewidywać, bo na razie sprowadzamy się do wróżenia z fusów. Wrzuć jak najwięcej informacji na temat problemu, który Cię dotyka, przed tym spróbuj wykonać to, co opisywałem wyżej oraz opisz feedback. Na pewno będzie nam prościej Ci pomóc.

Te "fusy" leżą przed Tobą - wystarczy chcieć lub potrafić "poszukać".

Dalszych wypowiedzi nie ma sensu komentować. Przypominam że jest to temat opinii o marce OVH a nie dyskusja na temat "domysłów", często wymyślonych, jak działa obecna ochrona AntyDDoS.
Poziom wypowiedzi, niestety często jest adekwatny do rzeczywistości, zatem radzę przemyśleć kilka razy zanim publicznie zabierzemy głos w dyskusji.

Koniec końców - Twoim problemem @Mesharsky jest DNSSEC, a nie żadne AntyDDoS'y, jak "wujkowie dobre rady" radzą i na co wskazuje "czasowa dostępność" z niektórych lokacji, jeszcze korzystających ze starej strefy: https://dnssec-analyzer.verisignlabs.com/hostfox.pl  - wystarczy odpytać również dig'iem wszystkie NS"y - ustaw klucz DS po stronie rejestratora (w przypadku tej domeny, również OVH).

Pozdrawiam,
~Spoofy

  • Lubię 2
  • Super! 1

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
30 minut temu, Spoofy napisał:

W jakim konkretnie DC z jakim ruchem? Pytam, bo nie mam większych problemów w Polskiej lokalizacji.

Francja, OVH. 
Problemy zaczęły się kilka lat temu, podałem wątek kilka wypowiedzi wyżej.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
1 godzinę temu, l3szcz napisał:

Francja, OVH. 
Problemy zaczęły się kilka lat temu, podałem wątek kilka wypowiedzi wyżej.


Pytałem o konkretne DC, bo w GRA (co również widać po ostatnio zgłaszanych problemach), sam miałem różne "przeboje", ale to raczej kwestia routingu. Nie chcę robić offtopu w tym temacie > 

 

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Napisano (edytowany)
8 godzin temu, Spoofy napisał:

 

Otóż nie - w dużym uproszczeniu, każdy operator na pewnym etapie stosuje blackholing, również OVH :) "spore capacity" nie jest przecież złotym lekiem na zatory w ix'ach ;) Dodatkowo, byłoby całkiem dziwne, że zwykłe DNS queries są odrzucane od tak sobie. Nie wiem na jaką informację się powołujesz, bo nigdzie takowej nie ma.

 

Nie rozmawiamy o tym, co stosuje operator, a o tym, co stosuje Data Center do obrony przed atakami wolumetrycznymi. To, że OVH może samo wpinać się do internetu - to tylko zaleta i potwierdzenie teorii, że mają możliwość i powinni stosować mechanizm BGP Flowspec - sterowanie zaporą sieciową, ale na urządzeniach (pokrewnie operatorów), czyli zanim cokolwiek trafi na router core'owy.

 

Logiczne, że nie muszą stosować blackholing'u przy małych wolumenach, a inne DC w Polsce musiałoby to robić, co tylko pokazuje ich przewagę nad innymi w polskiej lokalizacji, gdzie trudno za fajne pieniądze dostać sensowne wpięcia.

 

8 godzin temu, Spoofy napisał:

nie "whatever", tylko poczytaj o BGP  - nie jest "ostatecznością", tylko częstą "praktyką", bo tak ma działać w tej warstwie, zaś "gdzie" i "z kim" w przypadku sporej ilości styków OVH, to co innego.

 

Nie mówię o precyzyjnym mechanizmie BGP blackholing, który będzie na przykład sterowany przez AI i fanie współgrał będzie z pozostałą częścią mechanizmu Anty DDoS, a o takim, jaki jest stosowany w większości przypadków w polskich lokalizacjach (raczej wiesz, na jakim poziomie w Polsce taki mechanizm jest stosowany). DDoS przekraczający 10 Gbit/s = blackholing, co robi na przykład redGuardian w ATM.

 

8 godzin temu, Spoofy napisał:

Jaki jest sens wypchnięcia własnego DNS'a, poza OVH, bez ich ochrony, skoro działa ona prawidłowo? Chyba nie do końca rozumiesz różnicę w obecnym VAC'u między mitigation a enforced.

 

Nie może działać ona prawidłowo, jeżeli nie akceptuje i wyłącznie pakietów UDP 53. Sam postanowiłem to sprawdzić - i miałem rację, tak jak opisywałem to we wcześniejszym moim komentarzu. Problemem nie jest atakowany web server czy żadna inna usługa, a tryb enforced, o którym wspominasz, podczas ataku UDP odfiltrowuje je w jeden sposób: blokuje cały ruch UDP.

Co samo jasno obrazuje, że pacjent posiada cPanel oraz uruchomiony na nim własny serwer DNS bez replikacji rekordów na host'a poza OVH (dlatego poradziłem setup slave'a w zupełnie innym środowisku, bo tak powinno zostać to wykonane, aby uniknąć podobnych problemów w przyszłości) i pakiety UDP odpowiedzialne za serwer DNS są najzwyczajniej w świecie odrzucane - jeżeli tak jak twórca wspominał, w panelu OVH faktycznie istnieje informacja o wymuszonym trybie filtrowania dla adresu IP serwera DNS, powinno to utwierdzić moim zdaniem słuszną sformułowaną hipotezę.

Uważasz to za złą poradę (slave w innym środowisku)? Bo obecnie wygląda to tak:

https://check-host.net/check-report/bbbe3ack1f
https://check-host.net/check-report/bbbe3cfked4

Sprawdź na ripe skąd są to adresy i przeanalizuj moją wiadomość jeszcze raz - bo dalej uważam, że dwa serwery DNS przypisane do jednego host'a, to nie jest dobry use case - gdzie moje zdanie na pewno poprą inni użytkownicy.

 

8 godzin temu, Spoofy napisał:

Koniec końców - Twoim problemem @Mesharsky jest DNSSEC, a nie żadne AntyDDoS'y, jak "wujkowie dobre rady" radzą i na co wskazuje "czasowa dostępność" z niektórych lokacji, jeszcze korzystających ze starej strefy: https://dnssec-analyzer.verisignlabs.com/hostfox.pl  - wystarczy odpytać również dig'iem wszystkie NS"y - ustaw klucz DS po stronie rejestratora (w przypadku tej domeny, również OVH).

 

PS. Źle ustawiony DNSSEC nie blokowałby resolve'a przypisanych serwerów DNS do domeny. Utrudniałby tylko i wyłącznie pracę, ale zwykły nslookup wpisów NS działałby poprawnie.


Oczywiście tylko w takim przypadku, jakim został ustawiony dla domeny hostfox.pl (najwidoczniej nie doczytałeś, to ja dopowiem): nie został ustawiony rekord DS po stronie operatora domeny, a tylko taki mechanizm (DNSSEC) został uruchomiony po stronie serwera(ów) - nie wiem jak określić dwa adresy IP przypisane do jednego host'a - w związku z czym nawet nie ma podstaw do kwestionowania problemów związanych z DNSSEC, jeżeli to ustawiony jest i wyłącznie DNSKEY, a nie rekord DS (w tym przypadku) w OVH.

 

Witamy w zespole wujków dobrych rad! 🙄

Edytowano przez XaNeZ
literówka

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Mam podobny problem na serwerze VPS w datacenter w Warszawie. U mnie problem występuje jedynie dla IPv6 i to w około 6-8 na 10 próbach odpytywania mojego serwera DNS jak i tego secondary od OVH (działa w 100% jedynie przy odpytywaniu po porcie 53 TCP). Nie mam żadnego aktywnego ataku, przy wyłączonym firewallu (tego w panelu i tego zainstalowanego na VPS) jest to samo. Problem jest również przy pingowaniu hostów w OHV (w tym wspomnianego DNS secondary), pingowaniule google.com przechodzi.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dołącz do rozmowy

Możesz pisać i zarejestrować się później. Jeśli masz konto,Zaloguj się teraz, aby publikować na swoim koncie.

Gość
Odpowiedz...

×   Wklejony jako tekst z formatowaniem.   Wklej jako zwykły tekst

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.


  • Podobna zawartość

    • Przez Sevos
      Nazwa hostingu
      HTTP/2
      Let’s Encrypt
      AntyDDoS
      Backend (np. Apache2)
      Bezpłatne powierzenie umowy (RODO)
      Lokalizacja serwerów
      SSH
      Atthost.pl
      ✔️ 
      ✔️ 
      ✔️ 
      N/A
      ✔️ 
      Francja
      (OVH)
      ✔️ 
      Hekko.pl
      ✔️ 
      ✔️ 
      ❌ 
      (od wyższego pakietu)
      N/A
      ✔️ 
      N/A
      ✔️ 
      Home.pl
      ✔️ 
      ❌ 
      ✔️ 
      Apache2 (nowi klienci)
      IdeaWebServer (starsi klienci)
      ✔️ 
      Polska
      ✔️ 
      Hostmark.pl
      ✔️ 
      ✔️ 
      ✔️ 
      Apache2
      ✔️ 
      Polska
      ✔️
      (opcjonalnie)
      Iq.pl
      ❌ 
      ✔️ 
      ✔️ 
      Apache2
      ✔️ 
      Polska

      (od wyższego pakietu)
      Jdm.pl
      ✔️ 
      ✔️ 
      ✔️ 
      Nginx
      ✔️ 
      Polska
      ✔️ 
      Kei.pl
      N/A
      N/A
      N/A
      N/A
      ✔️
       
      ✔️
      Mydevil.net
      ✔️ 
      ✔️ 
      N/A
      Nginx
      ✔️ 
      Polska
      (ATMAN)
      ✔️ 
      Nazwa.pl
      ✔️ 
      ❌ 
      ✔️ 
      N/A
      ❌ 
      Polska
      ❌ 
      (od wyższego pakietu)
      OVH.pl
      ✔️ 
      ✔️ 
      ✔️ 
      Apache2
      ✔️ 
      Francja
      ❌ 
      (od wyższego pakietu)
      Progreso.pl
      ✔️ 
      ✔️ 
      ❌ 
      Apache2
      N/A
      Polska
      (ATMAN)
      ✔️ 
       
      Prohost.pl
      N/A
      ❌ 
      ✔️ 
      LiteSpeed Enterprise
      ✔️ 
      Polska
      (IQ)
      ❌ 
      Smarthost.pl
      ✔️ 
      ✔️ 
      ✔️ 
      Apache2
      ✔️ 
      Polska
      ✔️ 
      Zenbox.pl
      ✔️ 
      ✔️ 
      ✔️ 
      LiteSpeed Enterprise
      ✔️ 
      Polska
      (Oktawave)
      ✔️ 

    • Przez Prawał
      Witam mam pytanie jaki wybrać serwer vps pod serwer Minecraft poczebuje minimum 16 G pamieci ramu i dobry procesor.              
      Myślami nad OVh lub lvlup.pro lub titanexe z ofertami podanymi na zdjęciach poniżej.
      https://iv.pl/image/GrMy6ae
      https://iv.pl/image/GrMyXAD
      https://iv.pl/image/GrMy7zp
      https://iv.pl/image/GrMyPu7 
      Myśłem też o dedyku od skynode.pl 
      https://iv.pl/image/GrMNedb
    • Przez tomik
      Cześć,

      Szukając taniego vps do testów trafiłem na ofertę ovh. Jednak jak nigdy zerknąłem do regulaminów:
      https://www.ovh.pl/pomoc/dokumenty/Szczegolowe_warunki_korzystania_serwer_VPS_2016.pdf?CampaignName=blackfriday
      i w punkcie 7.3:
       
       
      W innych firmach nie znalazłem takiego zapisu. Jak wygląda prawnie ta sprawa? Czy mam obowiązek przechowywania takich logów?
      Dla testów na początek chciałbym zainstalować serwer  TS3 + opcjonalnie LAMP (jakie logi miałbym przechowywać w każdym z przypadków?)

      Jeśli jest taki obowiązek to czy są jakieś gotowe rozwiązania do tego?
    • Przez proserwer.pl
      Witajcie!
       
      W tym wątku będziemy zamieszczać informacje na temat aktualnej oferty, promocji, nowości oraz wprowadzanych zmianach na PROSERWER.pl
       
      Kilka słów o firmie
      Istniejemy na rynku już 14 lat i ciągle rozszerzamy naszą ofertę o nowe usługi takie jak domeny, certyfikaty ssl, serwery vps, kreator stron www oraz e-sklep Przez cały czas intensywnie rozwijamy nasz autorski panel klienta, który ułatwia zarządzanie usługami oraz wzbogaca je o wiele funkcji niedostępnych w standardowym panelach (większość zadań można załatwić poprzez panel w pełni automatycznie) Długa obecność w branży i wieloletnie relacje z naszymi stałymi klientami pozwoliły nam na dopracowanie usług tak aby zarówno wykorzystywały najnowsze rozwiązania techniczne jak i  dostarczały oczekiwanych funkcjonalności Jesteśmy polską firmą z polskim kapitałem Wystawiamy faktury VAT  
      Ogólne informacje techniczne
      Cała infrastruktura (hosting, dnsy, serwery backupowe, serwery "pomocnicze") rozmieszczona w trzech centrach danych Wszystkie usługi umieszczane na serwerach dedykowanych z procesorami Intel® Xeon®, pamięcią RAM ECC oraz dyskami SSD Wysokie bezpieczeństwo danych dzięki redundancji dysków (RAID) oraz stałemu monitorowaniu stanu dysków kopii zapasowej przechowywanej w oddzielnym centrum danych kolejnej kopii zapasowej przechowywanej w jeszcze jednym (oddzielnym centrum danych) Ponad 10 letnia stała współpraca z dostawcami oprogramowania oraz centrami danych pozwoliła nam wypracować odpowiednie procedury minimalizujące ryzyko występowania problemów oraz skracające czas ich rozwiązywania  
      O usłudze hostingu www
      Bezpłatny okres testowy (14 dni) Dostęp do SSH Transfer danych bez limitu Autorski instalator stron www (uruchamia gotowe strony np. WordPress, PrestaShop, Joomla czy MyBB w polskiej wersji językowej) W pełni zautomatyzowane wgrywanie kopii zapasowej Możliwość zamówienia dedykowanego adresu IP Możliwość zawarcia "umowy powierzenia przetwarzania danych" na potrzeby RODO Możliwe przejście zarówno na wyższy jak i niższy pakiet Oprogramowanie: CL, Nginx + Apache + mod_lsapi + OPCache, PHP 7, cPanel, Let's Encrypt, HTTP/2, ionCube, WAF, AntySpam, Antywirus Bezpłatna migracja strony od innego dostawcy  
      Naszą pełną ofertę znajdziecie pod adresem:
       
      https://proserwer.pl
       
      Dane firmy
       
      PROSERWER Michał Kalenik
      ul. Łagiewnicka 108/3
      91-456 Łódź
      NIP: 726-246-92-33
      REGON: 100764444
       
      Zapraszamy do bezpłatny testów! A w przypadku pytań do kontaktu na maila info@proserwer.pl
  • Kto przegląda   0 użytkowników

    Brak zalogowanych użytkowników przeglądających tę stronę.

×
×
  • Utwórz nowe...

Ważne informacje

Korzystając z forum, wyrażasz zgodę na: Warunki korzystania z serwisu, Regulamin, Polityka prywatności.