TransIP is getroffen door ddos-aanval - update 2

Hostingprovider TransIP meldt dat het last heeft van een ddos-aanval. Deze is volgens het bedrijf gericht op zijn nameservers. Dat leidt ertoe dat bepaalde sites en bijvoorbeeld e-maildiensten niet of niet goed bereikbaar zijn.

TransIP schrijft dat zijn technici op dit moment druk bezig zijn om de aanval te mitigeren. Het bedrijf biedt zijn excuses aan klanten aan, maar geeft nog geen indicatie van hoe lang het nog duurt voordat de problemen naar verwachting zijn opgelost.

Op onder meer Allestoringen.nl is zichtbaar dat de storing maandagmiddag zo rond 13.15 uur begon. Op Twitter maken allerlei mensen en bedrijven melding van het feit dat hun sites deels of geheel plat liggen. Ook wordt onder meer geklaagd dat Stack niet meer werkt. Dit is de online cloudopslag van TransIP.

Er zijn meerdere mensen die aanraden om een andere DNS-server te gebruiken, waarna de getroffen sites en diensten wel weer zouden moeten werken. Volgens meerdere gebruikers zouden de problemen via Ziggo vooralsnog aanhouden.

Update, 15:27 uur: TransIP meldt dat er sprake is van een tweede aanval die volgens het bedrijf 'heviger lijkt te zijn'. Een verwachte tijd voor wanneer de gevolgen van de aanvallen voorbij zullen zijn, kan TransIP nog niet geven.

Update 2, 16:33 uur: TransIP zegt dat er grotere vervolgaanvallen plaatsvinden die gericht zijn op de hele infrastructuur en niet alleen de nameservers. De hoster zegt diverse maatregelen genomen te hebben om de gevolgen van de aanvallen te minimaliseren. Omdat zowel de intensiteit als de doelwitten van de aanvallen variëren, is het nog niet duidelijk of het probleem geheel verholpen is, aldus het bedrijf.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (193)

Het lijkt allemaal weer up te zijn.
Tip: verhoog de TTL van je domeinen mocht het later vandaag of deze week weer gebeuren.

Transip:
16:20 - Waar de eerste aanval direct gericht was op onze nameservers waren de vervolg-aanvallen groter en gericht op onze gehele infrastructuur, waardoor we op meerdere fronten tegelijk zaken onder controle moesten brengen, dit maakt het afweren lastiger.

Inmiddels hebben we diverse maatregelen genomen om de gevolgen van de aanvallen te minimaliseren. Hierdoor zijn veel diensten van onze klanten weer bereikbaar. Omdat zowel de intensiteit als de doelwitten van de aanvallen variëren is het moeilijk vast te stellen of het probleem geheel verholpen is.

We houden de situatie nauwlettend in de gaten.

Status op www.transnoc.nl

[Reactie gewijzigd door patrickvdweide op 22 maart 2021 16:29]

Inmiddels hebben we diverse maatregelen genomen om de gevolgen van de aanvallen te minimaliseren. Hierdoor zijn veel diensten van onze klanten weer bereikbaar. Omdat zowel de intensiteit als de doelwitten van de aanvallen variëren is het moeilijk vast te stellen of het probleem geheel verholpen is.

Lees even de reactie van Blockchain: Blockchain in 'nieuws: TransIP is getroffen door ddos-aanval - update 2'

En zo te zien hebben ze nu last van een tweede, heviger aanval:

quote: https://www.transnoc.nl/

15:15 - Eerder vanmiddag zijn wij getroffen door een eerste DDoS aanval. Tijdens het afwenden van deze aanval en het oplossen van de gevolgen hiervan zijn we helaas getroffen door wat een tweede, hevigere aanval lijkt te zijn. Helaas kunnen we op dit moment nog geen duidelijke eindtijd noemen, maar onze engineers doen momenteel al het mogelijke om zo snel mogelijk weer online te zijn.

[Reactie gewijzigd door gorgi_19 op 22 maart 2021 15:20]

Na de vorige DDoS aanval heeft Transip zo te zien niets aangepast in hun netwerk. De DNS servers, die behoorlijk kritisch zijn voor hun eigen infrastructuur maar ook zeker voor de infrastructuur van hun klanten, is nog steeds 100% afhankelijk van 1 ASN. Dat is AS20857 die nu dus wederom eruit ligt.

Ze kunnen wellicht niks doen aan de DDoS aanval, maar dit is gewoon een waardeloze keuze in hun architectuur die ze zelfs na een major outage niet willen oplossen.

Nogmaals aan Transip het verzoek. Trek 1 of 2 van je authorative DNS servers naar een anders ASN.

Een ASN is niets anders dan een identificatienummer. Hoe de onderliggende netwerkstructuur eruit ziet of hoe redundant dat is hangt daar niet mee samen. Bedrijven als Cloudflare en Akamai gebruiken ook gewoon 1 ASN, daar is niets mis mee.

Jij noemt wel de uitzonderingen, en is leuk voor partijen die een globaal netwerk hebben. TI (en de meeste hosters) hebben dat niet. Dus prima stelregel.

TransIP kan prima met hun bestaande ASN op meerdere plekken connectiviteit inkopen, daar is niets uitzonderlijks aan. Het hebben van 1 ASN heeft gewoon niets te maken met hoe je netwerk eruit ziet, dat kun je dan ook niet stellen.

Meeste van dit soort partijen zetten materiaal onderling bij elkaar in een soort ruilhandeltje, waardoor dit opgelost is.

Op zich heb je gelijk, maar de 3 nameservers lijken allemaal op dezelfde manier geroute te worden.

Er wordt inderdaad voor alle nameservers via hetzelfde pad gerouteerd

r1-a0.r2.ams0.transip.net

Soms kom je even wat verder maar in een goede set-up zou je dit over meerdere paden laten lopen of een apart back-up pad los van de productie omgeving

Dat kunnen ze doen, maar ik zie niet in hoe dat een DDoS gericht op de nameservers tegen gaat houden. Een aanvaller vraagt de NS records op van transip.nl en gaat aanvallen whatever er als antwoord terug komt. Leuk dat ns1 en ns2 en ASN A draait en ns3 in ASN B, iedereen krijgt gewoon de DDoS voor z’n kiezen. En nee, ze hoeven dan niet de uplinks van 2 netwerken vol te gaan zetten, alleen de nameservers overbelasten is goed genoeg.

Ja, je nameservers over meerdere ASNs verdelen zorgt ervoor dat er nog iets bereikbaar blijft als je primaire ASN van het internet verdwijnt om de een of andere reden, maar ik zie niet in hoe het helpt tegen een DDoS aanval.

Een beetje provider, zeker eentje met de dergelijke grootte van TransIP heef tegenwoordig toch wel bescherming tegen volumetric DDoS aanvallen.

Bijv. via NaWas of andere technieken. Dit is wel heel erg slecht. Zelfs je VPS-je van 5 euro bij OVH kan simpel een terabit DDoS aanval overleven.

Totdat je server in rook op gaat

Totdat je server in rook op gaat

Leuk dat je die recente brand aanhaalt, maar laten we wel eerlijk (reëel) zijn en vooral blijven. Hoe vaak gaat er echt daadwerkelijk iets bij datacenters mis? TransIP is ook meerdere malen geen heiligboontje geweest en zo zijn er nog wel wat meer datacenters.

Hoe vaak branden datacenters volledig uit? imho bijna nooit. Des te verbazender vind ik het dat bij ovh zoveel is uitgebrand.
Ik begrijp niet goed hoe het kan dat een datacentrum kennelijk zo vol zit met brandbare materialen en zulke slechte brandblusinstallaties heeft dat dit heeft kunnen gebeuren.
Servers zijn qua gewicht 80% staal, het rack waar ze inhangen is ook van staal.
De datacentra waar ik ben geweest zijn gemaakt van beton+ staal.
Dat brandt allemaal niet en toch is die hele handel tot de grond afgefikt, alsof het allemaal in een houten schuur vol met hooi stond.

Waar was ovh haar argon installatie? Waarom bouw je multilevel datacentra zonder branddichte afslutiingen tussen ruimtes en verdiepingen. Hoe kan het dat ze er zo laat bij waren?
imho is ovh hiermee door de mand gevallen als betrouwbare hoster/datacentrum beheerder.
Je krijgt waar je voor betaald

[Reactie gewijzigd door telskamp op 23 maart 2021 10:05]

Een keer per 10 jaar
De laatste keer was 2012
nieuws: Vodafone kampt met regionale netwerkproblemen na brand - update

Ik heb zat servers bij OVH, maar gelukkig in andere DCs

Maar inderdaad dat kan gebeuren, shit happens. De kans is gelukkig niet zo heel groot.

Vrij zeker dat de holding waaronder TransIP valt, aangesloten is bij NaWas.

Wat hier dan nog mis loopt, is mij ook niet duidelijk.

Hangt dat niet af van hoe moeiijk de DOS-requests van echte te zijn onderscheiden? Een geavanceerde aanval kan gebeuren zonder een aanwijsbaar ritme, met geloofwaardige afzenders en met ip's waarnaar een traceroute er normaal uitziet, en die geen overeenkomende timeouts vertonen na bepaalde test-signalen erheen...

Als dat echt zo is, zou dat niet zo slim zijn. Is toch 1 van de eerste dingen leert als DNS beheerder. En volgens mij zijn er ook tld's die als technische eis stellen dat je minimaal 2 verschillende ASN gebruikt.

Overigens merk ik ook dat veel mensen (eind gebruikers TI) het makkelijk vinden om een belachelijk lage TTL in te stellen voor hun records. Gewoon minimaal 4 uur pakken zodat je bij dit soort problemen niet VOLLEDIG er uit ligt.

Edit: je hebt inderdaad gelijk!

[Reactie gewijzigd door johnny2000 op 22 maart 2021 14:49]

Dat doe ik eigenlijk ook altijd. Ga ze gelijk aanpassen.

Beter om ze wat langer te zetten, en aan te passen naar een kortere TTL als voorbereiding op een aanpassing.

Of juist niet, want voor portabiliteit is het wel handig als je snel kan switchen. Die keuze heb je niet altijd ver van tevoren, zoals wanneer je server afbrandt of TransIP er ineens grotendeels uitligt en je (tijdelijk) een back-up van je site ergens anders wil neerzetten

Klopt, maar het hangt dus van je situatie en voorkeuren af. Als je bijv een externe mailprovider als Google Mail (Workspace) gebruikt, dan is het best handig als je TTL gewoon op 1 dag staat. Dan zing je daarmee de meeste problemen wel uit.
Wat @SubSpace doet doe ik zelf ook en in mijn geval werkt dat uitstekend. Slechts in een enkele keer heb ik de noodzaak om opeens iets te wijzigen en meestal is dat doordat ik dan zelf iets sufs heb gedaan of niet van te voren heb nagedacht.

Overigens merk ik ook dat veel mensen (eind gebruikers TI) het makkelijk vinden om een belachelijk lage TTL in te stellen voor hun records. Gewoon minimaal 4 uur pakken zodat je bij dit soort problemen niet VOLLEDIG er uit ligt.

En dan liggen de servers zelf eruit, en wil je naar een andere machine maar zit je 4 uur te wachten tot de DNS is geüpdatet, elk nadeel hep s'n voordeel.

Los daarvan: binnen TransIP bestaat die optie überhaupt niet. Het is 1 minuut, 5 minuten, 1 uur of direct 1 dag.

Relevant draadje op Reddit: https://www.reddit.com/r/...se_scenario_happened_what

Noot: dit is niet transip

So, everything is fucked. We have (had) a custom DNS system built into our custom ERP software (don't ask). It had an integration to our old (bind) nameservers, which was stragith up awful and we've been trying to replace it for years. Well, on Friday it all broke down. All domain information was wiped out and records became null. Our company's domain is down, as well as our customer domains (we're a medium-sized MSP). Every person who knew how the custom DNS system worked has left the company years ago. Our backups are fucked. Our records are wiped from all domain servers out there. The company basically doesn't exist anymore. We don't even know what domains we own, the listing was hosted in the ERP which is now busted. Also our AD broke, we have no email, no messaging apps working, we don't even have a listing of our ~300 employees SMS numbers, so we don't have any way of informing our (now remote) workers that everything broke.

[Reactie gewijzigd door marapuru op 22 maart 2021 14:52]

Toevallig heb ik dit vanmorgen ook met bewondering gelezen. Zeer relevant en hopelijk dat netwerkbeheerders hier iets van kunnen leren.

Voor iedereen die benieuwd is hoe goed 't ervoor staat met jouw eigen domein, doe eens een DNS check op één van de volgende websites:

https://zonemaster.iis.se/en/
https://zonemaster.net/domain_check

1 van de lessons learned uit bovenstaand verhaaltje is dus dat je je medewerkers gewoon een SIM (liefst inclusief smartphone) van het werk moet geven. Dan kan je in ieder je workforce bereiken. Blijkbaar hebben ze zich afhankelijk gemaakt van 1 messaging dienst.

Ik krijg bijna een paniekaanval toen ik dit zat te lezen, omfg..

Ik zie geen enkel bedrijf met meer dan één ASN
https://www.whatismyip.com/asn/NL/

Dat kan je niet op die manier direct zien.Er zijn genoeg bedrijven in NL met meerdere BV's en verschillende AS'en.

Meer dan een ASN heeft niet zoveel zin, maar het is een simpele actie om verschillende nameservers in verschillende datacentra/AS-en te hangen.

Wat ik sowieso ook niet snap is dat blijkbaar hun resolvers er ook last van hebben. Ik mag aannemen dat dit niet dezelfde machines zijn? Dan is de vraag: waarom hebben mijn VPS'en ook zoveel problemen om externe DNS requests uit te voeren.

Volgens mij bevestigen jouw bevindingen jouw vermoeden dat de resolvers dezelfde machines zijn. In de tussentijd zou je er wat nameservers bij kunnen flotsen in `/etc/resolv.conf`, ik ben fan van 1.1.1.1

Ik dacht nog even dat er misschien intern een afhankelijkheid bestond met de transip domeinen. Maar volgens mij gaat alles op basis van IP.

Ik had inderdaad al op een paar kritieke machines wat bijgeplaatst

[Reactie gewijzigd door eborn op 22 maart 2021 16:42]

Ben ik ook benieuwd naar.

Precies dit!

Hoe zou het gebruiken van een andere DNS-server wel moeten werken?
Als de nameservers de IP's niet op kan halen bij nameservers TransIP heeft het toch weinig nut?

Ik heb veel domeinen geregistreerd via TransIP en gebruik hun DNS-servers als slave-servers, mijn eigen als master-server. Die domeinen hebben geen issues aangezien mijn eigen DNS-servers nog steeds bereikbaar zijn. Ik denk dat je deze passage andersom moet lezen - klanten van TransIP die een andere DNS-service gebruiken dan die van TransIP.

Hee, dat is een leuke feature. Ik wist niet dat TransIP dat ook aanbood. Mijn coloprovider heeft ook een secundaire dns server (in een ander netwerk en pand dan waaruit ze colodiensten aanbieden). TransIP is al m’n registrar, maar als ik DNS bij hun weg haal en het zelf ga doen (vind ik gewoon leuk om zelf te doen), dan is het ook slaven naar TransIP best een leuke ja.
Thnx voor de tip!

Kan zijn dat de cache daar nog wel actief is, of dat er juist een cache bij Ziggo actief is die alleen maar naar de getroffen DNS servers wil kijken bij het resolven van een DNS request.

Het artikel gaat, lijkt wel, over 2 issues: 1 bij TransIP en 1 bij Ziggo. Bij die van Ziggo is de oplossung een andere DNS-server gebruiken

Sowieso het beste om bij Ziggo een andere DNS server te gebruiken. of zijn ze de laatste tijd wel goed?

Ik ben niet helemaal bekend met hoe snel de NaWas kan worden ingezet, maar zou een bedrijf als TransIP dit niet gebruiken?

Theoretisch gezien is het rerouten van verkeer via de Nationale Wasstraat (NaWas) binnen 30-60 minuten secondes (bedoelde ik )wel te doen. Het is een BGP routing advertisement die verstuurd en ontvangen moet worden, dus veel langer hoeft het niet te duren.

De vraag is, is TransIP aangesloten bij de NaWas, en zo ja, is het noodzakelijk?

[Reactie gewijzigd door Equator op 22 maart 2021 14:44]

Dit kan binnen een paar secondes. Als je fastnetmon gebruikt bijv. kan je zo de dbt prefix binnen secondes over de Nawas knallen. Moet je natuurlijk wel een aansluiting hebben :-)

Als het een L7 aanval is, dan is het wel een stuk lastiger om te mitigeren dan een simpele volume aanval op L4.

Ik ben serieus 2 weken geleden begonnen met het afbouwen van de on-prem externe DNS servers om deze terug bij transIP te plaatsen....

Ik heb er alweer een soort van spijt van...

Je kan er ook voor kiezen om 2 DNS services te nemen.

Bijv. 1 nameserver bij transip en de twee nameservers van Cloudflare.

Je kan er ook voor kiezen om 2 DNS services te nemen.

Bijv. 1 nameserver bij transip en de twee nameservers van Cloudflare.

Is dat niet een betaalde service bij Cloudflare die best serieus geld kost als je redelijk wat domeinnamen hebt? Volgens mij kun je dan beter net zo goed zelf een (hidden) master draaien en TransIP en Hurricane Electric als 2nd, 3rd, 4th (etc) gebruiken. Volgens mij zit je dan al een heel stuk goedkoper.

Zou je kunnen uitleggen of linkjes geven naar wat dit exact inhoudt.
HE voor je 2 3 4, dat is een betaalde BGP service?
Om dan je DNS zelf te hosten en hun BGP/CDN te gebruiken?

Dan 1 ns van CloudFlare gebruiken, en de rest bij je Registrar en HE.
Hoe doe je zelfs 2 NS gebruiken?
Ik ben altijd overal verplicht minstens 2 in te geven, bij Neo, CloudFlare, TransIP, GoDaddy.

Zou je kunnen uitleggen of linkjes geven naar wat dit exact inhoudt.

In plaats van de master nameserver te vermelden in je zone-file doe je dat niet, je update je zone dus via de master maar iedere verandering wordt gewoon naar de slaves gestuurd. Die master geef je dan natuurlijk ook niet op bij je registrar...

Een link heb ik niet, maar jaren geleden eens gezocht op Google, "how to hide master nameserver" ofzo :-)

HE voor je 2 3 4, dat is een betaalde BGP service?

Neen, Hurricane Electric biedt allerlei diensten. DNS Service of bijvoorbeeld Tunnelbroker etc.

Dan 1 ns van CloudFlare gebruiken, en de rest bij je Registrar en HE.

Ik gebruik geen betaalde diensten van CloudFlare, bij CloudFlare kost het nogal wat om gebruik te maken van eigen/aangepaste DNS Services ...

Hoe doe je zelfs 2 NS gebruiken?

Kwestie van gewoon opnemen in je zonefile en toevoegen bij je registrar.

Ik ben altijd overal verplicht minstens 2 in te geven, bij Neo, CloudFlare, TransIP, GoDaddy.

Klopt, en in principe kun je daar zelf ook gewoon de keuze in maken welke je wilt gebruiken. Je kunt zoveel combineren als de registrar toelaat... Heb mezelf er niet heel erg in verdiept, weet niet of het bijvoorbeeld veel nut heeft om extra nameservers te gebruiken die niet bij de registrar aan het domein worden toegevoegd anders kan je nameserver lijst flink groot worden. Van BuddyNS, HE tot aan die van je eigen webhost er bovenop *lol*

ik heb 15 domeinen op de gratis versie draaien op een account. Vroeger moest je meerdere accounts aanmaken.

Ja klopt, alleen het voor voordeel bij TransIP ( ) is dat het gelijk 100% DNSSEC compliant is en zij deze standaard voor je inregelen.

Cloudflare ondersteund ook DNSSEC. Die staat naar mijn weten ook standaard aan. Dus dat zou geen issue mogen zij.

Helaas werkt dat voor Signing net anders dan ophalen.

https://developers.cloudf...registrar/enabling-dnssec

Cloudflare Registrar offers one-click DNSSEC enablement for free to all customers. You will not need to set the DS record details manually. However, your domain must be using Cloudflare as the authoritative DNS provider.

Het zou dus inhouden dat ik tussen TransIP en Cloudfare de DS keys allemaal moet gaan blijven syncen.

Dat is inderdaad niet handig. De meest pragmatische oplossing die ik tot zover heb gezien is om de TTL te verhogen om downtime in deze gevallen te beperken. Cloudflare is immers ook wel eens plat geweest op de DNS.

Staan ze niet toe.

Geeft je deze foutmelding

- U heeft een ongeldige nameservercombinatie opgegeven voor het domein '****.nl'. U kunt geen secondary draaien voor onze nameservers.

Sowieso is meer verschillende DNS aanbieders altijd een goed plan, er is opzich ook niks mis met on-prem DNS servers. mits goed ingericht.
Als secundaire DNS kun je dan altijd nog TransIP doen voor redudantie.

Hmm, mijn eigen sites liggen er idd uit. De browser kan de URLs niet resolven. Wel vreemd, want ik gebruik hier thuis gewoon de standaard Ziggo DNS. Blijkbaar doet die een lookup bij transip (daar zijn mijn domeinnamen geregistreerd en opgezet)?

Ja, zo werkt DNS.

Dus als de Nameservers eruit liggen, die authoritative zijn voor jouw domein, dan kunnen de nameservers die de bezoeker gebruikt, niet opvragen bij welk IP ze moeten zijn voor een dienst op een hostname op jouw domein.

Maar er word toch normaliter wel gecached denk ik?

Tenzij je cache op 5 minuten staat.

vaak wel, maar dan moet de DNS server waaraan jij jou request doet jou site al wel een keer verwerkt hebben.

depends, de DNS server waar mijn domein op staat, staat op een hele lage TTL. Dat heeft als effect dat veranderingen bijna instant worden overgenomen door andere DNS servers (handig bij mijn let's encrypt vernieuwingen).

Daarvoor heb ik een wildcard naar mijn server ip (thuis). Geen gedoe met caching

Zodat de hacker niet hoeft te raden achter welk subdomein je thuisadres te vinden is

hier ook last van.. heb aantal domain redirects op mn hosted domain bij transip. allemaal dood nu.

Ondertussen lijkt er weer wat te werken.

Hier dezelfde ervaring, monitoring is nu langzaam groen aan het worden en het gestuiter is eruit.

Hopelijk is het opgelost, vervelende DDoS kiddies..

Als een DDoS kiddy dit voor elkaar kan krijgen dan mogen ze zich bij TransIP wel even achter de oren krabben.

De mensen die een DDoS uitvoeren kopen deze vaak in, hebben zelf geen enkele inhoudelijke kennis. Lappen wat Bitcoins en gaan met de banaan.

Het is zorgwekkend dat een provider als TransIP zo getroffen kan worden. Het is een hele grote speler met veel technische kennis en middelen.

Dat snap ik maar dat is vaak niet wat er bedoeld wordt met een script kiddy (of DDoS kiddy). Vandaar mijn reactie.

Dat TransIP voor de tweede keer in relatief korte tijd zo onderuit kan gaan is inderdaad erg zorgelijk. Ze bieden een uptime garantie voor de VPS dienst maar daar valt dit natuurlijk niet onder. Want ondanks dat je VPS niet bereikbaar was werkte hij natuurlijk wel gewoon.

Ter info: paar dozijn VPS'en waren hier gewoon bereikbaar (eentje een paar minuten niet).

Via het IP adres was de VPS gewoon bereikbaar. En als je de hostnaam in je DNS cache had staan had je ook nergens last van.

Zeker zorgelijk, maar wel blij dat ze het zo snel opgelost hebben. Hopelijk nemen ze extra maatregelen.

Overigens waren er wel degelijk VPS'en niet bereikbaar, al was dat redelijk kortstondig.

Het probleem zit hem tegenwoordig gewoon in wie heeft de grootste pijp. Als die ddos maar zo groot mogelijk is en op zoveel mogelijk ip's dan heb je een ENORME uitdaging.

Ondertussen lijkt de cache bij diverse andere providers ook verlopen te zijn, meldingen stromen hier binnen vanuit diverse monitoringsystemen die sites/domeinen bij TransIP checken.

Klopt, dit is goed te zien in Google Analytics. In realtime zie je nu snel het aantal bezoekers live op de website terugvallen van 400 (2 uur geleden), naar 300 (1 uur geleden) en nu <100. Dus klopt, het zal niet lang meer duren voordat TransIP-sites overal niet meer werken.

Glijdende schaal. Goed moment om nieuwe releases te deployen

Nee serieus, laten we hopen dat het snel opgelost is. Vervelend voor alle getroffen klanten dit.

En ik kan m'n nameservers niet wijzigen omdat de transip.nl website blijkbaar gebruik maakt van dezelfde nameservers, waardoor ik niet kan inloggen op het controlepaneel

Haha dat trucje wilde ik ook uithalen, helaas

Statisch IP koppelen via de hosts file levert ook niets op (behalve een Service Unavailable pagina).

Afwachten dus. Gelukkig hangen hier niet heel belangrijke websites achter (die heb ik bij Route53).

[Reactie gewijzigd door redburn op 22 maart 2021 15:03]