Skocz do zawartości
  • Cześć!

    Witaj na forum RootNode - aby pisać u nas musisz się zarejestrować, a następnie zalogować. Posty pisane z kont niezarejestrowanych nie są widoczne publicznie.

Rekomendowane odpowiedzi

Opublikowano (edytowane)

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...
 

Edytowane przez Mesharsky
Opublikowano
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.

...

Opublikowano
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.

Opublikowano
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.

Opublikowano
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.

 

Opublikowano
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
Opublikowano (edytowane)
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 ?

Edytowane przez Mesharsky
Opublikowano
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.

Opublikowano

@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).

Opublikowano
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. 
 

Opublikowano

@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.

Opublikowano
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?

Opublikowano

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
Opublikowano
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.

Opublikowano
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 > 

 

Opublikowano (edytowane)
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! 🙄

Edytowane przez XaNeZ
literówka
Opublikowano

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.

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

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

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