Websites klanten Digitalus en Webstekker verspreidden malware na dns-hack

De dns-servers van de Nederlandse hostingbedrijven Digitalus, VDX en Webstekker, die onder hetzelfde moederbedrijf vallen, lijken te zijn gekraakt. Daardoor hebben de domeinen van een onbekend aantal klanten doorverwezen naar malware.

Een van de drie getroffen hosters, Digitalus, laat weten dat er zondagnacht een storing op zijn centrale nameservers was opgetreden. Daarbij zouden een aantal domeinzones met 'verkeerde' ip-informatie zijn bijgewerkt. In de praktijk kwam het er op neer dat een onbekend aantal websites van klanten, waaronder de webwinkel Conrad, artiest Hardwell en de site van vakbond CNV, naar malware hebben doorverwezen. Daar werd de Blackhole-exploitkit aan bezoekers geserveerd; volgens VirusTotal herkenden slechts 4 van de 45 virusscanners de malware.

Het is onbekend wanneer de problemen zijn begonnen, maar vanmorgen hebben de webhosters samen met de SIDN de problemen weer rechtgezet. Doordat sommige isp's bij dns-wijzigingen er voor kiezen om de time to live-instellingen te negeren, kan het enige tijd duren voordat de wijzigingen in het dns-systeem overal zijn hersteld, tekent Digitalus aan. Bij de meeste providers zouden de websites nu echter weer moeten werken.

Volgens Erik Loman van beveiligingsbedrijf SurfRight kaapt de malware in kwestie de browser van de gebruiker. Chrome wordt niet getroffen, benadrukt Loman, maar Firefox en Internet Explorer wel. Bij getroffen gebruikers crasht Firefox telkens. Het zou dus om een trojan kunnen gaan die banktransacties onderschept of manipuleert. De Hitman Pro-software van het beveiligingsbedrijf zou de malware moeten kunnen opsporen.

De vermeende storing zou inmiddels zijn verholpen. Woordvoerder Sandra Ottens van Digitalus wil nog niet spreken over een hack van de dns-systemen omdat nog onduidelijk is hoe de dns-wijzigingen doorgevoerd zijn. De hoster zou de zaak in onderzoek hebben. Onduidelijk is nog hoe lang dit gaat duren.

Bron: PCWebPlus

Reacties (54)

[Backspin]

De hack zorgde er voor dat ns1.dn-s.nl en ns1.dn-s.nl beiden op een ander (frans) ip uitkwamen. Daar draaide een dns server en een webserver op.
Voor elk domein dat deze dns'en als authoritative had staan werd het dns verkeerd daardoor omgeleid naar die fake dns server.
Die dns server gaf voor elke query zijn eigen ip als respons. Hierdoor kwam elk verzoek uit op de webserver op diezelfde server, waar de malware stond.
Best een geniepige hack dus, met grote gevolgen.

Bovendien gaf deze fake dns server voor elke query een ttl van 60000-80000, dus effectief ca 20 uur.
Het is dus niet zo dat sommige isp's de TTL negeren, ze respecteren hem juist, en daardoor duurt het zo lang voordat de juiste settings (met korte TTL) weer opgehaald worden.

Volgens mij heeft de SIDN geen enkele invloed op het hele verhaal.

[TD-er]

Volgens mij heeft de SIDN geen enkele invloed op het hele verhaal.

Niet helemaal waar, ze zouden het domein dn-s.nl kunnen blokkeren.
Echter dan zit je nog steeds tegen de TTL aan te kijken van de caches bij de ISPs.

[scsirob]

Dit had ik vanochtend al uitgezocht. Wat ik echt kwalijk vond is dat het telefonische bandje opriep om op de site van Digitalus te kijken voor de oplossing. Dat was dus *de* manier om besmet te raken! Ik heb eerste iemand aan de telefoon gekregen bij ze, maar nadat ik het uitgelegd had en verzocht om dat bandje aan te passen werd de hoorn er op gekwakt en niet meer opgenomen. Lekker dan!

[Conrad Benelux]

Onze websites Conrad.nl en Conrad.be zijn inderdaad slecht tot niet te bereiken geweest wegens een issue met DNS-server bij onze provider. Op Twitter (@ConradNL en @ConradBE) houden we iedereen op de hoogte van de meest recente ontwikkelingen en nieuwtjes.

Het probleem is door de provider opgelost maar ondanks korte TTL kan het nog even duren voor alles weer naar behoren werkt en onze sites weer goed bereikbaar zijn.

Met vriendelijke groet,
Martijn
Conrad webcare

[Habbie]

Correctie: dankzij de korte TTL op de echte records zit in de meeste caches nog het IP met het virus - en die verwijzing heeft een TTL van een dag. 50% van de UPC-klanten moet het tot morgenochtend met een dode site doen, bijvoorbeeld.

Verder knap dat jullie de kop zo in het zand steken. Duizenden van jullie klanten zijn nu besmet met een virus maar op Twitter melden jullie alleen 'daar weten we niks van'.

[Señor Sjon]

Probeer het bericht over de malware van vorige week via de adserver van de Telegraaf maar eens op de site van de Telegraaf terug te vinden... Dat vind ik vele malen kwalijker dan iets waar Conrad helemaal niets aan kan doen in tegenstelling tot het bannerfest op de Telegraaf.

[Noxious]

Heel simpel, dit is niet de verantwoording van Conrad maar van de hoster. Aangezien Conrad hier ook helemaal niets aan kan doen is het vrij logisch dat dat de reactie is om tegen te gaan dat duizenden mensen bij Conrad aankloppen voor hun PC-support.

[Bram Heerink]

Ok, dus als mijn visleverancier besmette vis levert, dan ga ik als restaurant niks ondernemen naar mijn gasten ook al worden ze ziek of zijn ze ziek geworden van hetgeen er in mijn restaurant is genuttigd?

ConradNL heeft zeker wel een zorgplicht naar zijn klanten ook al zit de fout bij een leverancier van hen.

[Noxious]

Je zal het meer moeten vergelijken met een of ander chemisch stofje in de inkt van de folder van dat restaurant wat er in is gekomen door een fout van de bezorger.

[.SnifraM]

Je vergelijking komt helemaal niet overeen met het probleem in dit nieuwsbericht.

In ieder geval wel zo netjes als Conrad de bezoekers wijst op het feit dat zij besmet kunnen zijn door dit issue.

[Reactie gewijzigd door .SnifraM op 26 juli 2024 01:35]

[OddesE]

Een van de drie getroffen hosters, Digitalus, laat weten dat er zondagnacht een storing op zijn centrale nameservers was opgetreden.

Dat noem ik dus een eufemisme. Gehackt zijn is geen storing.

De vermeende storing zou inmiddels zijn verholpen.

Foei Tweakers, stop drinking the kool-aid.

Woordvoerder Sandra Ottens van Digitalus wil nog niet spreken over een hack

Nee. Dat er naar malware wordt doorverwezen is het toevallige gevolg van een storing. Geen reden om aan te nemen dat het eigenlijk een hack betreft.

een issue met DNS-server bij onze provider.

En weer een eufemisme. Een hack is een hack. Noem het beestje bij zijn naam!

Verder knap dat jullie de kop zo in het zand steken. Duizenden van jullie klanten zijn nu besmet met een virus maar op Twitter melden jullie alleen 'daar weten we niks van'.

Heel simpel, dit is niet de verantwoording van Conrad maar van de hoster.

Maar correcte communicatie is wel de verantwoordelijkheid van Conrad. Klanten hebben recht op kloppende informatie. Zeggen dat je ergens niks vanaf weet terwijl je dat wel weet (iedereen die ook maar iets van IT weet snapt binnen een minuut dat dit een hack is) is niet netjes imho. Het is niet de schuld van Conrad? Zeg dan gewoon: Onze hosting provider is gehacked. U wordt aangeraden extra voorzichtig te zijn en uw virusscanner bij te werken. Het probleem is inmiddels verholpen. Voor verdere informatie kunt u contact opnemen met Digitalus / VDX / Webstekker.

[TD-er]

Op Twitter (@ConradNL en @ConradBE) houden we iedereen op de hoogte van de meest recente ontwikkelingen en nieuwtjes.

Die Twitter-pagina van jullie is vrijwel onleesbaar, doordat er de hele tijd antwoorden staan op twitter-berichten van derden.
Echter wat de actuele status is (als die al ergens genoemd staat) is volstrekt niet duidelijk.

En inderdaad wordt er wel heel erg weinig aandacht geschonken aan het serveren van malware.
Dus een enkele regel met "scan uw PC op ongewenste software indien u vanochtend deze site heeft bezocht" lijkt me niet zo vreemd.

[janvanduschoten]

Onze website (Bosch Car Service bedrijf) lag er ook uit tot ergens vanmiddag. We kregen dan net ook het onderstaande bericht van Digitalus.

Geachte klant,

Vannacht hebben wij een storing aan onze DNS omgeving gehad, die inmiddels weer verholpen is. De oorzaak van deze storing hebben wij nog in onderzoek.

Vannacht zijn er een aantal zones geüpdatet met de verkeerde IP informatie. Dit is vanochtend hersteld en aansluitend daarop heeft de SIDN (de beherende instantie achter .nl domeinnamen) de zones rond 08:00 uur geüpdate. Hoewel de correctie snel heeft plaatsgevonden is het effect niet overal direct zichtbaar, ondanks dat wij hiervoor een lage DNS TTL (Time To Live) hanteren. Doordat sommige Internet Service Providers (ISP’s) de DNS TTL negeren kan het soms tot enkele uren duren alvorens alle websites correct worden weergegeven. Wij kunnen hierop helaas geen invloed uitoefenen.

Door deze storing is het mogelijk dat u ook onze NOC pagina niet kunt opvragen, welke te vinden is op http://noc.digitalus.nl. Om die reden zullen wij alle communicatie omtrent dit probleem inclusief updates tevens communiceren op de NOC pagina van IT-Ernity (moedermaatschappij Digitalus). Deze is te vinden op http://noc.it-ernity.nl.

Onze excuses voor het ongemak.

Met vriendelijke groet,

Digitalus

Helaas ook vrij vlot daarna een mail van Google Adwords.

Hallo,

Hierbij willen wij u melden dat een van uw sites ons advertentiebeleid schendt. We kunnen daarom geen van uw advertenties weergeven die een link naar die site bevatten. Nieuwe advertenties die naar die site verwijzen, worden ook afgekeurd.

U kunt het volgende doen om uw site te verbeteren en hopelijk uw advertenties weer te laten weergeven:

1. Breng de noodzakelijke wijzigingen aan op de site die momenteel ons beleid schendt:

Zichtbare URL: XXXXXX


Probleem met beleid: Malware
Details en instructies: http://support.google.com...um=email&utm_campaign=gen


2. Dien uw site opnieuw in waarbij u de instructies in de bovenstaande link volgt. Als uw site voldoet aan ons beleid, kunnen we de site goedkeuren zodat deze weer kan worden weergegeven.

Herhaalde schendingen van ons advertentiebeleid kunnen resulteren in een opschorting van uw AdWords-account. Daarom is het belangrijk alle problemen zo snel mogelijk aan te pakken door ons beleid te controleren. Meer informatie over het AdWords-beleid inzake opschortingen kunt u vinden op http://support.google.com...m=email&utm_campaign=spsu.

Met vriendelijke groet,
Team Google AdWords

[JoepW]

Nog steeds geen website of email. Wat een armoede.
Ik zou het fijn vinden als ik gewoon geïnformeerd werd (door digitalus!) over hoe lang het ongeveer gaat duren. Maar het is totaal stil op twitter en facebook.
Dan maar weer naar de server van het 'moederbedrijf' en daar vind ik dit:

We onderzoeken de oorzaak achter de problemen die afgelopen nacht zijn ontstaan, nadat de nameservers zijn aangepast. Om 03.30 uur vannacht is de zone van de nameservers binnen het DRS systeem van SIDN (door derden) voorzien van externe nameservers. Hierdoor kwamen alle DNS verzoeken niet bij ons uit, maar bij de nameservers van deze derden. Deze wijziging is vanaf 06.00 uur door ons opgemerkt, waarna onderzoek is gestart en wij de zone ook weer hebben hersteld. Deze wijziging is door de SIDN opgepakt vanaf 08.00 uur, het moment waarop SIDN haar zones ververst.

Hoewel de aanpassingen snel na constatering zijn hersteld, is het gevolg minder snel op te lossen. De onbekende nameservers hebben op alle DNS verzoeken een standaard zone gegeven met als doel alle website bezoeken door te zetten naar een website met daarop Malware. Elke zone is hierbij voorzien van een DNS Time To Live van 24 uur. Dit heeft als effect dat veel Internet Service Providers deze foutieve DNS zone tot 24 uur vasthouden en blijven serveren. Ondanks dat de zone bij SIDN snel hersteld is en ook spoedig daarna door SIDN is ververst komen er nog steeds websites uit op het verkeerde IP. Met de Service Provider achter het IP is contact gelegd en zij hebben direct de benodigde actie ondernomen om het IP, welk was voorzien van malware, offline te halen. Op dit moment worden de juiste DNS zones door de meeste publieke resolving nameservers goed opgepakt.

Hoewel er geen wijzigingen hebben plaatsgevonden op onze nameservers zijn deze toch onderhevig aan een intensief onderzoek. Dit intensieve onderzoek loopt nog. Samen met SIDN wordt dit incident verder onderzocht waarbij nauw contact onderhouden wordt.

Wij betreuren het ten zeerste dat deze problemen zich hebben voorgedaan en dat hierdoor klanten zijn gedupeerd. Wij bieden de getroffen klanten onze oprechte excuses aan. Wij zullen naar aanleiding van de uitkomsten van het onderzoek de benodigde maatregelen nemen om eventuele herhaling te voorkomen.

Dus ik ga er van uit dat ik mooi tot 6 of erger 8 uur morgenochtend uit de lucht ben

[TD-er]

Die TTL van DNS-records is wel vaker een probleem en de manier hoe ermee omgegaan wordt, zou eigenlijk aangepast moeten worden.
Zo zit je soms meer dan 24h tegen een oude DNS-instelling aan te kijken, terwijl zaken al lang bijgewerkt zijn.
De TTL waarde vrij kort houden kan er in de praktijk ook toe leiden dat ISP's ze helemaal negeren en dan zit je met een default waarde van veelal een dag.
Zo had ik eens de TTL op < 900 sec gezet vanwege de geplande verhuizing van een server (een week van te voren al geregeld), maar de praktijk was dat menig bezoeker naar een timeout zat te kijken doordat de TTL gewoon genegeerd werd.

Dit zal dus nog voor veel van de getroffen websites best wel lang blijven duren voordat het allemaal weer naar behoren werkt.

[Ezechiel]

Dit is ook exact de reden waarom het nuttig is om dit tijdig in te plannen en af te stemmen met de huidige hoster. Op die manier kan je op de oude locatie de website nog online houden, om deze na enkele dagen pas offline te halen. Daarna is het alleen nog een kwestie van het mergen van eventuele dynamische data.

[TD-er]

Klopt, maar ik heb zelf de beschikking over 1 server en dan is dat dus geen optie.
Dus toen ik die in een ander rack moest hangen en er ook een ander IP-adres bij kreeg zat ik dus in de problemen door foute configuratie van anderen.
Nu is het wel zo dat het dus absoluut geen bedrijfs-critische sites betreft (anders wel meer dan 1 server), maar feit blijft dat je het nog zo goed kunt plannen en toch nog dergelijke problemen kunt ondervinden.

[Ezechiel]

Ik schetste ook meer de situatie voor wanneer je van de ene hostingprovider/(web)server overstapt op de andere. In jouw situatie blijkt inderdaad maar weer eens dat sommige mensen nog een lesje nodig hebben en je altijd tegen onvoorziene omstandigheden aan kan lopen waar je zelf geen invloed op uit kan oefenen.

[Razwer]

dat is in veel gevallen niet handig als jet met een live database werkt. Zo krijg je scheve aanpassingen. Leuk voor een statische site, maar niet voor eentje met koppelingen naar andere systemen toe.

[Adamar]

Meestal blijkt dit een probleem te zijn bij dns servers van providers die hun cache niet vaak genoeg bij werken.

Bij ons is telenet hiervoor gekend.

Bij het gebruik van google public dns servers of opendns heb je dit probleem niet.

[Reactie gewijzigd door Adamar op 26 juli 2024 01:35]

[TD-er]

[..]

Bij het gebruik van google public dns servers of opendns heb je dit probleem niet.

Helaas (of eigenlijk gelukkig) heb ik als hoster heel weinig invloed op de DNS-server die de bezoekers gebruiken.
Dus dan blijf je dat probleem houden.

[Adamar]

Bij gewone bezoekers kan je weinig doen, maar je rechtstreekse klanten kan je wel aansporen om "betere" dns servers te gebruiken.

Het is vooral spijtig dat je door het geklungel van providers zo potentiele klanten misloopt.

[RGAT]

Ja maar wat vertel je je klanten dan?
Gebruik de Google DNS servers anders kan het gebeuren dat onze site niet werkt?
Reactie van gebruikers is dan al gauw dat jouw site onbetrouwbaar of zelfs als malafide wordt gezien en natuurlijk de vraag hoe de gewone gebruiker de DNS aanpast...
(Los daarvan vind ik het belachelijk dat DNS wijzigingen zo lang op zich laten wachten maar het enige wat je kan doen is als je meerdere servers hebt je oude servers alles redirecten naar de nieuwe via IP, totdat de DNS wijziging een dag of drie geleden was, en dan sluit je de oude servers af, maar ook hier kan een hoop mis gaan, in een situatie waar je meerdere servers hebt is de kans dat terwijl je de database verhuist er wijzigingen worden doorgevoerd en de webserver een time-out geeft en noem maar op, dus downtime heb je bijna altijd met een beetje applicatie)

[mvdejong]

Het probleem is natuurlijk dat die TTL met een goede reden niet te kort wordt gekozen. Als die te kort is, krijgen de name-servers natuurlijk wel erg veel requests voor informatie die eigenlijk allang bekend is bij de client. Alleen in onderhouds-situaties is een kortere tijd wenselijk, maar dan natuurlijk ook wel erg hard nodig.

Ik heb ook een tijdje gedetacheerd gezeten bij een bedrijf dat een eigen DNS-server had, maar omdat dat een extreem licht systeempje was (Sun IPX, met een 40 MHz processortje), hadden we de TTL op een week staan. Onderhoud betekende dus dat we een week van tevoren de TTL naar 1 dag terugzetten, en dan de dag daarvoor op 1 uur, en soms dan 2 uur voor het wijzigings-moment op 10-15 minuten.

Dat een provider zelfstandig een korte tijd weer oprekt naar een dag is natuurlijk wel erg bot, aan de andere kant zijn veel klanten net zo bot om een absurd korte TTL in te stellen zonder daarbij na te denken.

TTL's zijn lbest astig, een typo mijnerzijds (netjes een "dash" in de naam van de mailserver gezet i.p.v. de eigenlijk illegale "underscore") heeft het bedrijf een dag lang zonder mail gezet ...

[TD-er]

Klopt dat er zeker wel redenen zijn om de TTL korter te zetten.
Echter de cache-server/service die ze bij providers gebruiken zou bijvoorbeeld vaker in de achtergrond kunnen kijken of de DNS aangepast is.
Hiervoor hoeven ze alleen maar periodiek te kijken of een zojuist gegeven antwoord nog wel accuraat is door alleen even het SOA-record op te vragen.
Dit moet je natuurlijk niet de hele tijd doen, maar bijvoorbeeld maximaal 1x per uur. Dan krijg je vanuit elke ISP waarvan een klant jouw site bezocht heeft 1x per uur een request en dat zou toch af te handelen moeten zijn.

[mvdejong]

Het probleem is natuurlijk dat het systeem dat de gegevens eerder heeft opgevraagd dat nog steeds niet opnieuw gaat doen, omdat die bij het meest recente antwoord de garantie heeft gekregen dat dat antwoord minstens TTL seconden geldig is.

[Ezechiel]

Dat neemt niet weg dat hij van tijd tot tijd wel opnieuw even een controle kan doen, just to be sure zeg maar. En zo zit je natuurlijk ook sneller dan 'TTL' met de actuele gegevens.

Met je auto kan je ook wachten tot het lampje gaat branden dat de olie bijgevuld moet worden, je kan zelf ook van tijd tot tijd even de peilstok er uit trekken.

[TD-er]

Het probleem is natuurlijk dat het systeem dat de gegevens eerder heeft opgevraagd dat nog steeds niet opnieuw gaat doen, omdat die bij het meest recente antwoord de garantie heeft gekregen dat dat antwoord minstens TTL seconden geldig is.

Klopt, maar daar is ook sprake van een DNS-cache en die zou natuurlijk ook zelf hetzelfde kunnen doen als de DNS-cache van de provider.
Het principe is nog steeds gelijk en je behoud het voordeel van de snelle response in normale gevallen. Echter de TTL uitzitten is een beetje onzinnig en zou gewoon beter moeten kunnen tegenwoordig.

Dat vergt echter wel de nodige aanpassingen in de diverse OS-en die men thuis draait, dus dat zal nog wel even duren voor het zover is.

[Dorank]

Hiervoor hoeven ze alleen maar periodiek te kijken of een zojuist gegeven antwoord nog wel accuraat is door alleen even het SOA-record op te vragen.
Dit moet je natuurlijk niet de hele tijd doen, maar bijvoorbeeld maximaal 1x per uur. Dan krijg je vanuit elke ISP waarvan een klant jouw site bezocht heeft 1x per uur een request en dat zou toch af te handelen moeten zijn.

Schrijf effe een patch voor bind/powerdns (of stel het aan de devs voor), in al die tig jaar van DNS heeft niemand er aan gedacht om dit te implementeren.

[ahoffman518]

ik ben op dit moment blij dat ik Chrome gebruik, mijn mail werkte niet en ging naar mijn webmail en zag dat die ook niet werkte.
Digitalus heeft een tweetal e-mails gestuurd met uitleg over de situatie;


------------------------------------------------------
Van: Digitalus Internet Services [mailto:[e-mail]]
Verzonden: maandag 5 augustus 2013 12:20


Geachte klant,

Vannacht hebben wij een storing aan onze DNS omgeving gehad, die inmiddels weer verholpen is. De oorzaak van deze storing hebben wij nog in onderzoek.

Vannacht zijn er een aantal zones geüpdatet met de verkeerde IP informatie. Dit is vanochtend hersteld en aansluitend daarop heeft de SIDN (de beherende instantie achter .nl domeinnamen) de zones rond 08:00 uur geüpdate. Hoewel de correctie snel heeft plaatsgevonden is het effect niet overal direct zichtbaar, ondanks dat wij hiervoor een lage DNS TTL (Time To Live) hanteren. Doordat sommige Internet Service Providers (ISP’s) de DNS TTL negeren kan het soms tot enkele uren duren alvorens alle websites correct worden weergegeven. Wij kunnen hierop helaas geen invloed uitoefenen.

Door deze storing is het mogelijk dat u ook onze NOC pagina niet kunt opvragen, welke te vinden is op http://noc.digitalus.nl. Om die reden zullen wij alle communicatie omtrent dit probleem inclusief updates tevens communiceren op de NOC pagina van IT-Ernity (moedermaatschappij Digitalus). Deze is te vinden op http://noc.it-ernity.nl.

Onze excuses voor het ongemak.

Met vriendelijke groet,

Digitalus


-------------------------------------------------

Van: Digitalus Internet Services [mailto:[e-mail]]
Verzonden: maandag 5 augustus 2013 19:20


Zwolle, 5 august 2013 Digitalus onderzoekt de oorzaak achter de problemen die afgelopen nacht zijn ontstaan, nadat de nameservers van digitalus.nl zijn aangepast. Om 03.30 uur vannacht is de zone van digitalus.nl binnen het DRS systeem van SIDN (door derden) voorzien van externe nameservers. Hierdoor kwamen alle DNS verzoeken niet bij Digitalus uit, maar bij de nameservers van deze derden. Deze wijziging is vanaf 06.00 uur door Digitalus opgemerkt, waarna onderzoek is gestart en Digitalus de zone ook weer heeft hersteld. Deze wijziging is door de SIDN opgepakt vanaf 08.00 uur, het moment waarop SIDN haar zones ververst.

Hoewel de aanpassingen snel na constatering zijn hersteld, is het gevolg minder snel op te lossen. De onbekende nameservers hebben op alle DNS verzoeken een standaard zone gegeven met als doel alle website bezoeken door te zetten naar een website met daarop Malware. Elke zone is hierbij voorzien van een DNS Time To Live van 24 uur.

[JoepW]

Jij wel!
Ik heb helemaal NIKS ontvangen.
Besluit is dan ook genomen, met name door de steeds verder teruglopende kwaliteit van de service van Digitalus (zeker na de fusie / overname) om na ca. 9 jaar afscheid van Digitalus te nemen.

[ahoffman518]

Een calamiteit kan gebeuren en ga ik ze niet kwalijk nemen, maar de kwaliteit gaat er de laatste tijd behoorlijk op achteruit. Ook de service.
Ik wil ook al langere tijd overstappen, maar op het moment dat ik de factuur zie ga ik er maar weer een jaartje mee verder.
Ik kan je geen ongelijk geven in ieder geval!

[johnny2000]

Alles kwam inderdaad uit op 178.33.22.5 welke alleen een CNAME naar panningendeavor.net teruggaf. Lijkt mij dat dat ze niet helemaal transparant zijn

[Verwijderd]

Ik had vanochtend ook even een bedrijf gebeld dat hun website gehacked was (ook een lege pagina met "under construction" en een alert dat de website een Java aplet wilde uitvoeren. Blijkt dus hier mee te maken te hebben!

[Shinji]

Op dit moment doet hun eigen site het nog steeds niet. Ook nameserver1.digitalus.nl en nameserver2.digitalus.nl (zelfde IP) zijn beide niet te queryen.

Zag vanochtend ook inderdaad dat er verwezen werd naar localhost.

BTW: hoe is dit irrelevant, geen nameserver is geen nieuwe DNS queries.

[Reactie gewijzigd door Shinji op 26 juli 2024 01:35]