Dns-storing Akamai maakte groot aantal websites onbereikbaar

Donderdagavond waren veel websites wereldwijd onbereikbaar en de oorzaak lijkt bij een dns-storing bij Akamai te liggen. Onder andere in Nederland en België waren een groot aantal websites niet te bezoeken, waaronder die van banken.

In Nederland waren donderdagavond onder andere de sites van de NS, de politie, Albert Heijn en DPG Media-titels zoals AD en Nu.nl onbereikbaar. Wereldwijd ging het om veel sites, zoals die van AirBnB, Amazon, HBO Max en Steam. Op Downdetector is de omvang van de storing zichtbaar. Daar is ook te zien dat de storing ook AWS en Cloudflare trof.

De bron van de storing lijkt bij cdn-provider Akamai te liggen. Dat bedrijf meldt een storing bij zijn Edge dns-dienst te hebben. Akamai meldt de storing te onderzoeken. Details zijn verder nog niet beschikbaar en getroffen websites lijken rond 18.45 weer online te komen. De ceo van Cloudflare, Matthew Prince, laat weten dat de oorzaak in ieder geval niet bij hen ligt. Op de statuspagina van Oracle Cloud is te lezen dat de oorzaak bij een Edge dns-partner van Oracle ligt.

Begin vorige maand vond eveneens een grote storing plaats. Die werd veroorzaakt door een probleem bij cdn-provider Fastly dat kampte met een ‘performance-impact bij de cdn-diensten'. Er werden toen heel wat sites getroffen waaronder Reddit, Twitch, Amazon, CNN, PayPal, Twitter en Stackoverflow.

Update, 19.10 uur: Akamai zegt op Twitter het probleem te hebben geïdentificeerd en opgelost.

Reacties (161)

[TYZ]

Ergens een onprettig idee dat er een paar héle grote partijen zijn die eigenhandig grote delen van het internet plat kunnen leggen. Cloudflare, Amazon AWS, Azure, enz.

[YangWenli]

Allemaal Amerikaanse bedrijven. Ja het internet is van de wereld maar niet heus

[Megamind]

Niemand forceert het AD om een Amerikaanse CDN te gebruiken toch?

[jvwou123]

Is er een fatsoenlijke Nederlandse CDN? Of misschien een Europese?

De bekende CDN's, allemaal Amerikaans.

[Adr01]

KeyCDN is volgensmij zeer degelijk, Zwitserland.

[sebastienbo]

Soms is het niet meer transparant, als er een tussenpartij is die de cdn als een service doorverkoopt. Of bij AWS zou je het ook niet zo maar geweten hebben dat ze er gebruik van maken. Dit is echt wel een schoolvoorbeeld van de nadelen van de cloud, je weet niet wat er op de achtergrond allemaal draait en waar het draait en hoe het in elkaar steekt voor veiligheid issues etc...

De cloud maakt dingen niet veiliger en ook niet magisch redundanter zie hieronder.
Het kan dingen wel scalable maken (als je weet waar je mee bezig bent, want je app in de cloud zetten maakt het NIET scalable, je moet je app wijzigen om het scalable te maken)
Maar je hebt dus heeel veel nadelen aan een cloud, als kleine bedrijf is dat vaak wel acceptabel, grote bedrijven moeten goed nadenken hoe ze er gebruik van maken en echt wel experten aannemen.

[Kalder]

Er waren ook genoeg Nederlandse websites door uit de lucht.

[Ryen]

Precies het punt van @YangWenli

[Kalder]

Ah verkeerd gelezen dan

[xFeverr]

Als ze dat expres zouden doen zijn ze natuurlijk binnen korte tijd failliet. Ik zou me daar niet zo druk om maken.

Mocht het echt zo zijn dat een grote jongen uitvalt voor een lange tijd (dagen, weken, ...), Is het natuurlijk ook mogelijk om ergens anders je spullen te plaatsen. (Ervan uitgaande dat je geen exclusieve diensten afneemt van een bepaalde cloudprovider.)

Als ik bijvoorbeeld naar mijn eigen werk kijk dan kunnen we gewoon deployen naar een andere cloud als het echt moet. Dat zal even tijd in beslag nemen, en zal zeker niet van een leien dakje gaan, maar is gewoon mogelijk. Desnoods pakken we wat oudere desktops bij elkaar en hosten we het daar op. Niet ideaal, maar in nood lukt dat nog wel.

[biteMark]

De website van een bank of de politie ga je niet hosten op een oude desktop, het netwerk weet dan überhaupt niet wat het met al dat verkeer moet - laat staan die oude desktop. Het gaat hier niet om opa's hobby-site hè?

En qua deployen naar een andere cdn: dat is waarschijnlijk niet een kwestie van even een paar docker containers copy-pasten. Je hebt te maken met allerlei beveiligde databases, links met andere systemen, Joost mag weten wat voor netwerkinstellingen (DNS records en dergelijke) en ga zo maar door. Daar zijn ook allerlei contracten voor afgesloten en voorwaarden aan verbonden, zéker als het gaat om bijvoorbeeld bankzaken. En verder zit je inderdaad met de lock-in van je cdn en moet je maar afwachten of dat simpel te overbruggen is.

Nou zullen systemen als van aws, cloudflare, akamai etc. inderdaad niet zomaar bewust worden platgelegd maar één persoon met de juiste kennis kan een heel eind komen. Kan zomaar zijn dat een kwaadwillende netwerk-admin gisteren heeft zitten prutsen in de DNS - dan heeft ie geen systeem te hoeven hacken om tóch de hele boel plat te gooien. Eén zwak punt in het netwerk zou genoeg kunnen zijn.

Dus ik ben het volledig eens met @TYZ dat het heel zorgelijk is dat grote en belangrijke delen van het internet lamgelegd kunnen worden door aanvallen op een klein aantal bedrijven, al helemaal gezien onze maatschappelijke afhankelijkheid ervan. En het is, zoals genoemd, heel bijzonder dat belangrijke Europese diensten bij Amerikaanse cdn's worden gehost - waar blijft Europa met dergelijke diensten?

[teacup]

Keerzijde is wel dat hoe meer cloudaanbieders in een bedrijfsnetwerk betrokken raken hoe groter de kwetsbaarheid wordt voor een aanval.

De beweging naar cloudaanbieders die ik nu zo collectief zie plaatsvinden zie ik daarom ook als een varkenscyclus. Dat is trouwens een veilige veronderstelling, dat begrijp ik. Zodra deze ontwikkeling dominant wordt op IT gebied gaan we onherroepelijk kennis maken met de keerzijdes.

Die keerzijdes zijn nu al wel te beredeneren, om een voorbeeld te geven: grotere afhankelijkheid van externe factoren. Wat dit precies betekend moeten we eerst aan den lijfe ondervinden voordat het echt betekenis krijgt. Wat dat betreft moeten we onszelf eerst aan een steen stoten voordat we ons gedrag aanpassen.

[Reactie gewijzigd door teacup op 23 juli 2024 12:25]

[ictinc]

Als je ziet hoeveel procent van de grote websites tegenwoordig afhankelijk is van AWS zegt dat eigenlijk al voldoende. In 2020 ging AWS onderuit wat een effect had op 1000en sites, 64% van enterprises die in de cloud werkt maakt op 1 of andere manier gebruik van AWS.
Cloud is leuk totdat er een storing is.

[sebastienbo]

Wat mij altijd stoort bij cloudalgemene problemen, dat is dat er zoveel websites tegelijkertijd problemen ondervinden dat ik altijd denk dat er iets met mijn lijn aan de hand moet zijn, dus verlies ik altijd veel tijd met iets te troubleshooten dat er niet is...

[ToolkiT]

True, multicloud is dan de oplossing, dan spreid je het risico.
Maar vergeet niet dat legacy on-prem applicaties vaak minder stabiel en secure zijn dan een goed geimplementeerde cloud oplossing.
Bij cloud heb je dingen als availability zones, load balancers etc waarmee je het risico enorm mee kan verminderen. Maar als er een vendor-wide probleem is dan houd je een probleem waar HA niet tegen helpt.. tenzij je dus in parralel op meerdere cloud vendors draait.
Maar dit heeft natuurlijk gevolgen voor het kostenplaatje.. dus de meeste bedrijven doen daar een baten-kosten analyse op (of gokken erop ) en nemen het risico..

Geen enkele oplossing is fool proof, maar je kan wel het zo betrouwbaar mogelijk maken binnen je budget door goed in te richten..

[Mooraalkikker]

Maar ook weer prettig dat er ook een sterke infrastructuur achter zit. Tuurlijk klinkt het allemaal heel fragiel als 1 van deze partijen de stekker eruit trekt, maar had je 100.000 verschillende partijen gehad die met elkaar moeten samenwerken dan is het 1 grote wirwar van stabiliteit. En heb je een probleem, dan gaan zij allemaal naar elkaar wijzen. Uiteindelijk heeft ook niemand van deze partijen er baat bij om de stekker eruit te rekken.

[janbaarda]

Dit maakt het maar weer eens duidelijk dat het goed zou zijn dat ook Europa groeit in dit segment. Hoe minder concentratie op een continent hoe beter.

[rjmno1]

Ik had het op het nieuws gehoord, maar ik wis niet dat het akamai was

[Stemis]

Het gaat hier natuurlijk niet om het internet zelf wat plat lag.

DNS is een layer 7 protocol in de OSI-layer. DNS is dus een systeem dat bovenop het internet draait, net zoals HTTP dat is. Als we het puur over het internet hebben, dan hebben we het echt over Layer 3 en lager. DNS kan dus "het internet" niet eens platleggen.
Het is wel is eerder voorgekomen dat het internet zelf plat lag, maar dan heb je het dus over Layer 3 en lager issues, kijk bijvoorbeeld maar is naar BGP, dat gaat nog wel is mis!

Natuurlijk is het niet goed als je teveel afhankelijkheid hebt op 1 partij, echter is dit puur een keuze en vinden mensen er pas wat van tot het fout gaat, het internet zelf is vrij open, en je kan zelf kiezen bij welke partij je je dingen host.

[sebastienbo]

vanuit het perspectief van een gebruiker ligt het internet wel degelijk plat als je niet kan resolven, of als de achterliggende services niet kunnen resolven.

Wat heb je aan servers waar de webapps op draaien als je er niet naartoe kan , en wat als de achterliggende services van jouw app toch kapot maken omdat je backend ook dns nodig heeft

[Reactie gewijzigd door sebastienbo op 23 juli 2024 12:25]

[Dannyvrf]

Akamai geeft al aan via Twitter dat ze het hebben opgelost: https://twitter.com/Akamai/status/1418251400660889603

[JayStout]

Bedankt, toegevoegd aan het artikel.
Jay

[dutchgio]

Dat klinkt als een interne verstoring, en niet een DDoS aanval of iets dergelijks.

[Mel33]

Nu maar hopen dat ze geen ransomware hebben doorgesmokkeld in deze storing, die dan later heel de wereld nog een keer plat legt.

Staat als reactie in deze Twitter thread.
Vind dit iig waardig om te noemen

[MatthiasL]

Zou niet de eerste keer zijn bij Akamai..

[dasiro]

als ik op die link klik een foutmelding van twitter:

Something went wrong. Try reloading.

the irony

[mvrhrln]

Mooi, en dan te bedenken dat het internet ooit is opgericht om te zorgen dat je altijd bereikbaar bent. Met al die cachingdiensten is er een SPOF gecreëerd.

[Reactie gewijzigd door mvrhrln op 23 juli 2024 12:25]

[Stemis]

Het redundant uitvoeren van zaken, kost extra tijd, complexiteit, geld en overhead.
Uiteindelijk kiezen partijen zelf voor de SPOF, het risico is dan te laag voor het extra werk wat het kost.

Bijvoorbeeld, je kan meedere nameservers achter een domein hangen bij de registry (ie Route 53, en Akamai DNS). Waardoor je niet afhankelijk bent van de DNS servers van een bepaalde partij.

Het enige waar je dan tegen aanloopt is dat je 2 DNS configuraties moet bijhouden, en deze ook in sync moet houden. Dat is (kennelijk) teveel moeite voor bovenstaande partijen waardoor je afhankelijk bent van een enkele provider.

[Reactie gewijzigd door Stemis op 23 juli 2024 12:25]

[bbstreams]

klopt, maar het probleem is dat al die grote partijen zoals CF en Akamai en AWS R53, elkaar ook in sync houden, dus als er 1 is met krakke setting dan zit je vaak tijdelijk zonder werkende site. meestal is dat de direct schuld van een site owner dan.

hele systeem zou beter werken als ze stict gescheiden diensten zouden leveren of tenminste een goede error correcties handteren, maar dan nog hoeft het dus maar bij eentje mis te gaan om het halve internet plat te leggen voor een paar uur.

[Reactie gewijzigd door bbstreams op 23 juli 2024 12:25]

[PolarBear]

En dat kan nog steeds met dit soort diensten maar dan moet je er wel meerdere combineren. Cloudproviders bieden heel veel voordelen maar kunnen ook falen.

[Frame164]

De kans dat iets faalt als je het allemaal zelf doet is vele malen groter.

[arjankoole]

De kans dat iets faalt als je het allemaal zelf doet is vele malen groter.

Dat is helemaal niet gezegd.

Het is mogelijk duurder. Maar het kan ook zijn dat het simpeler is qua opzet.

Ik beheerde met m’n collega’s in 1999 al een platform dat global redundant was. Dat was een heel simpel mechanisme en dat heeft in al die jaren nooit gefaald.

[b12e]

1999 was ook een andere tijd. Global redundancy eind jaren 90 betekende lang niet zoveel als nu - een website was toen veelal nog een aantal HTMLs die naar elkaar linkten, al dan niet met een frameset.

Tegenwoordig is dat nét iets ingewikkelder, met database clusters, CDNs en veelal veel meer data dat veel sneller van A naar B moet. Denk aan hele javascript libraries die ingeladen moeten worden vanaf je CDN en tientallen zoniet honderden grafische assets. Vroeger was dat een gifje 😊

[DeCo]

Tja, en hoeveel van die hoeveelheid is overhead? Dat had je vroeger niet. Het is niet erg efficiënter geworden.

[b12e]

Dat is dan weer een heel ander probleem. Het hoeft niet efficiënt, want de capaciteit is er om het inefficiënt te doen. Vroeger werden er trucs uitgehaald om een game op een CD of zelfs floppy te krijgen, nu is een game 140GB of meer. Een webbrowser hoeft niet meer rekening te houden met 256MB RAM, elke computer heeft nu standaard 8GB of meer. En die Pentium 2 die het niet kon trekken als je grafisch wat te veel berekeningen wilde maken? Dat is tegenwoordig een quadcore, octacore of zelfs meer processor die op XX Ghz draait ipv 300-400 Mhz clockspeed.

Een website moest heel beperkt zijn in grafische assets en code, want haal maar eens 10MB aan Javascript libraries binnen, en evenveel grafische assets, via een inbel of ADSL verbinding.

Het is er vast allemaal niet beter op geworden op dat gebied. Al denk ik nog wel nostalgisch terug aan Kazaa, Gnutella en eDonkey. een MP3 bestand downloaden en eigenlijk gewoon een worm binnentrekken. Aan MSN (en Messenger Plus) en ICQ. Ik zou toch echt niet meer terug willen naar het internet van eind jaren 90 / begin 2000.

[TheDutchChief]

Afgezien van de content, veel eenheidsworst tegenwoordig, zoeken naar informatie in plaats van de volgende aanbieding is een kunst, buiten de gebaande paden. In de jaren negentig mensen die hun best deden om in html hun hobbieprojectjes te tonen en met meta-keys hogerop te komen op ilse, hotbot of yahoo. Oh ja, en een tellertje op je site ;-)

[Reactie gewijzigd door TheDutchChief op 23 juli 2024 12:25]

[ejabberd]

Niemand verbiedt je om vandaag een statische website te maken.

[arjankoole]

1999 was ook een andere tijd. Global redundancy eind jaren 90 betekende lang niet zoveel als nu - een website was toen veelal nog een aantal HTMLs die naar elkaar linkten, al dan niet met een frameset.

Je onderschat heel erg de site waarvoor we dat deden

[foaly]

voor welke site deed je dat dan?

[tfro71]

Dat was niet echt het doel. Doel was vooral om elkaars apparatuur te kunnen gebruiken. Het voorkomen van SPOF's zat er wel deels in maar was niet de hoofdreden.
Dat internet komt toch een beetje uit de tijd dat men uberhaupt blij was met elkaar te kunnen communiceren.

[wica]

Dat was het doel wel van ARPANET, waar internet uit gekomen is.

Het netwerk moest bij een atoomaanval blijven werken.

[Frame164]

Dat is het requirement. Maar dat wil niet zeggen dat het ook altijd maar dan ook echt altijd beschikbaar is. Ook voor Arpanet zou niemand z'n handen in het vuur hebben gestoken dat het altijd werkt.

[wica]

Nee daarom maakt je ook gebruik van verschillende partijen en tld.

Bij partij a host je tweakers.eu als nameserver
Bij partij b host je tweakers.be als nameserver
En bij partij c host je tweakers.nl als nameserver.

Bij tweakers.net stel je de bovenstaande in als nameserver.

Nu kan 2/3 uitvallen en doet tweakers.net het nog steeds.

[ACM]

En toch is dat niet zo simpel.

Tweakers is via 2 gescheiden netwerken met eigen ip's beschikbaar.

Sowieso wil je liefst via al die drie locaties dezelfde informatie treffen en niet op A artikel 1, op B artikel 2 en op C artikel 3, alleen maar omdat dat nou eenmaal door round-robin dns toevallig zo terecht kwam.

Maar als er bijvoorbeeld bij in de centrale aansturing of synchronisatie wat misgaat (want hoe moet jouw browser weten welke van de twee ie moet hebben?) dan kan het alsnog als geheel down gaan

En effectief doen Akamai en de in het artikel genoemde Fastly juist ruwweg wat je hier beschrijft. Alleen ook hij hun moet e.e.a. gesynchroniseerd worden en kan daar wat misgaan. Of zoals bij Fastly, doordat ze alle data van alle klanten over alle locaties verspreiden, kan het ook misgaan als er blijkbaar een bug zit in de gedeelde software.

[bbob]

Als ik naar veel getroffen sites kijk maken ze gebruik voor veel zaken van akamai CDN. Als die dan niet werkt door dns update (https://www.telegraaf.nl/...ernet-legt-halve-web-plat)
Dan is je site wel bereikbaar maar kom je niet ver. Zag dat bijv bij belgsiche bank, je kreeg wel de hoofdpagina maar zonder opmaak. Idem bij sommige Nederlandse sites, wel bereikbaar maar geen opmaak.

Dus zelfs al heb je alles zoals hierboven omschreven voor elkaar dan is CDN nog een probleem.

[ACM]

Mijn punt is dan ook dat het CDN zelf die taak op zich heeft genomen; van geografische spreiding over meerdere machines. Die N staat niet voor niets voor Network.

Maar ook bij hen zijn er punten die dan alsnog zodanig mis kunnen gaan dat het er als geheel uit ligt.

@wica het CDN is het startpunt waar gebruikers binnenkomen; je kan niet zomaar een 2e in je 'code opnemen' en dat je dan vanzelf wel goed zit. Je kan zelfs niet zomaar meer naar een andere overschakelen als de eerste eruit ligt, dat hangt dan af van hoe lang DNS-records her en der gecached werden en of je uberhaupt bij de beheerportal kan om daar aanpassingen aan te doen.
CDN's nemen namelijk juist ook je DNS-requests over om er voor te zorgen dat gebruikers in Australië via de Australische servers lopen of als de Nederlandse locatie er uit ligt, dat Nederlanders dan via het dichtstbijzijnde alternatief worden geleid.

Als je 2 CDN's tegelijk wilt ondersteunen moet je dus voor die CDN's weer een of andere DNS-constructie hebben die je verkeer naar een van die twee leidt. Los van dat dat dus complex is in relatie tot die functionaliteit van het CDN zelf, kan ook dat stuk gaan...

[Reactie gewijzigd door ACM op 23 juli 2024 12:25]

[bbob]

Probleem met cdn wat ik vaak zie is dat het voor veel bedrijven overbodig is. Het zou een verhoging van de snelheid geven als zaken meer lokaal staan en dat klopt natuurlijk.

Maar neem ik nu abnamro, die richt zich vooral op Nederland, waarom heb je dan een cdn nodig, zorg dat je eigen servers snel genoeg zijn.
Richt je je alleen op de benelux, zie ik voordeel van een cdn ook niet echt in.
soms krijg ik het idee dat er bij veel bedrijven standaard iets met cdn gedaan wordt waarbij het de vraag is of dat nodig is.

Voor kleinere website heeft het een bijkomend nadeel. Afbeeldingen kun je ook een seo naam geven hetgeen helpt voor je ranking, loopt dat via cdn dan helepen ze niet mee aan ranking in googlle, url is niet jou url.

[wica]

In de code van een website, kan je meerdere CDN's opnemen.
Je hoeft niet afhankelijk te zijn van 1 partij, het is een keuze.

[sebastienbo]

Hangt af van het probleem, de dns probleem kan ook langs de provider kant liggen van je client, of bij de service provider can je provider, of bij je client tout court.

[KvanC]

Wellicht zeg ik nu iets heel doms.

Maar dat je dns het niet doet zegt toch niet dat de nodes (ip adressen) niet beschikbaar zijn ... toch?

[orvintax]

Klopt, maar als niemand kan vertellen welk IP adres aan nu.nl zit gekoppeld hebben we daar niks aan

[KvanC]

Nee dat klopt.

Ik reageerde hier op

"Het netwerk moest bij een atoomaanval blijven werken."

Het internet op zichzelf werkt hier nog steeds zoals het bedoelt is.

Alleen niet voor de hedendaagse luie mens. Dat was meer mijn punt.

[wica]

DNS met zijn root servers en top level servers zijn ontworpen, dat een deel mag uitvallen zonder dat het hele internet er last van heeft.
Echter als de halve wereld bij 1 partij hun DNS onderbrengt, heb je weinig aan dit ontwerp.

[ToolkiT]

In tijden van ARPAnet hadden de military nodes gewoon een static IP en was alles hard coded (hosts file etc).
Hedentendage is de structuur een stuk complexer

[Kastermaster]

Is het niet een ontwerpfout dat DNS centraal bijgehouden wordt dan? Dat lijkt me typisch iets wat je decentraal kunt doen. Of zie ik dat verkeerd?

[ToolkiT]

DNS is ook distributed
https://en.wikipedia.org/..._Name_System#Name_servers
Maar als jouw client alleen naar 1 DNS server kijkt heb je een SPOF..

En hier gaat het ook over een CDN systeem (https://en.wikipedia.org/wiki/Content_delivery_network), wat een (paar) laag(en) hoger is dan de network layer..
Het is een netwerk dat content 'lokaal' cached zodat de latency lager is dan als alle clients naar de main server moeten..

[Reactie gewijzigd door ToolkiT op 23 juli 2024 12:25]

[orvintax]

Je kunt het ook bij meerdere partijen neerzetten, maar aangezien het hier gaat om een CDN heeft dat wel wat nadelen.

[R4gnax]

Dat was niet echt het doel. Doel was vooral om elkaars apparatuur te kunnen gebruiken. Het voorkomen van SPOF's zat er wel deels in maar was niet de hoofdreden.

Andersom. Het voorkomen van volledige uitval van cruciale communicatiewegen, en dus het voorkomen van een single point of failure (SPoF) was wel degelijk het hoofddoel van de ontwikkeling van ARPANET - de precursor voor het internationale internet.

Het feit dat het ook gebruikt kon worden om destijds zeer schaarse computing resources onderling te delen en beter te benutten binnen de wetenschap was een mooie bijkomstigheid en inderdaad de reden dat veel van de wetenschap bereid was om er aan mee te werken; maar was niet het ultieme doel. Het een project werd geleid; financieel gedragen; en ook voornamelijk uitgevoerd door de Defense Advanced Research Projects Agency (DARPA) van het Amerikaanse leger - welke de techniek wilde door-ontwikkelen tot landelijke schaal om in een tijd van nucleaire dreiging een redundant uitgevoerde; geografisch breed gespreidde command&control structuur in de lucht te kunnen houden.

[Reactie gewijzigd door R4gnax op 23 juli 2024 12:25]

[OruBLMsFrl]

It was from the RAND study that the false rumor started, claiming that the ARPANET was somehow related to building a network resistant to nuclear war. This was never true of the ARPANET, but was an aspect of the earlier RAND study of secure communication. The later work on internetworking did emphasize robustness and survivability, including the capability to withstand losses of large portions of the underlying networks
https://en.wikipedia.org/wiki/ARPANET#Debate_on_design_goals

Robuustheid was altijd al deel van de uitgangspunten van het internet. Al van voor 1973 zelfs, toen met e-mail het echte doelgerichte communiceren voor eindgebruikers begon. Elkaars apparatuur gebruiken zeker hoofdreden, maar ook dat wil je betrouwbaar kunnen doen. Het moest zelfs toen wel echt al goed blijven werken, net als telefoonnetwerken, liefst nog wat beter.

[BitProcessor]

Een SPOF bedoel je

[mvrhrln]

gecorrigeerd

[Webgnome]

nog niet veel van gemerkt eigenlijk. Maar misschien komt dat omdat ik een pihole met eigen unbound server heb draaien.

[RvdMeer]

Ook jouw pihole doet een DNS lookup. Als een domein bij Akamai is ondergebracht en die DNS server is niet beschikbaar zal jouw pihole dus niet kunnen achterhalen wat het juiste IP adres is. Lokale cache in combinatie met de TTL (geldigheidsduur) kan ervoor zorgen dat het bij de een wel werkt en bij de ander niet.

[Meekoh]

Het gaat om websites welke hun DNS zones hosten bij Akamai.

[Vorkie]

Dat heeft hier niets mee te maken, de authoritive domain servers, de genoemde NS servers, hebben storing. Daar kan jou lokale dns ook geen verzoek meer doen.

[xoniq]

Heeft er niet mee te maken. Die DNS server heeft vooral invloed zodra de DNS van jou ISP eruit ligt. (Wat regelmatig is gebeurt bij Ziggo)

Dit ging om de endpoint van Akamai.

[hcQd]

Alleen als je cache-min-ttl flink verhoogd hebt.

[tfro71]

Neh. De sites deden het wel deels maar onderliggende interfaces konden elkaar niet bereiken. En die zijn niet op jou pihole aangesloten.

[mocean]

Het is gewoon suf dat DNS storing binnen 1 uur voor problemen zorgt. Caching op DNS zou makkelijk op 24u kunnen staan, en/of DNS queries zouden een cache kunnen gebruiken als de aangewezen DNS server even geen antwoord geeft.

[overhyped]

DNS wordt tegenwoordig ook veel gebruikt voor failover en voor geolocation. Zaken die niet werken met een hoge TTL.

Voor belangrijke zaken is een stukje diversiteit in CDN’s wel te overwegen, na de fastly outage laatst heeft ThousandEyes daar een mooi blog over geschreven.

https://www.thousandeyes....lysis-and-lessons-learned

[ToolkiT]

A haiku about DNS –
It’s not DNS.
There is a no way it’s DNS.
It was DNS.

[SN4K3]

Ik was al bezig met klooien aan netwerkinstellingen op mijn PC. Het is 'gelukkig' niet een probleem aan mijn zijde gebleken.

[Lemn8]

Haha ja ik hetzelfde ik kreeg een lege STEAM store met een 105 fout en dan moet je je router herstarten volgens veel stukjes op het internet. Maar dit is dus duidelijk een ander probleem.

[vosss]

Beter dat de halve wereld een probleem heeft, nietwaar?

[SN4K3]

Gedeelde smart is halve smart.

[dasiro]

ik had het al een tijdje door vandaag dat facebook en youtube plaatjes niet of maar gedeeltelijk geladen werden en toen had ik al een donkerbruin vermoeden dat een of andere CDN problemen had. Daarna kwamen er plots hln.be en zelfs tweakers bij die helemaal niet bereikbaar waren en dan wist ik al hoe laat het was, dus heb zelfs de moeite niet gedaan om te beginnen klooien

[MPAnnihilator]

hln.be deed het ook niet bij, tweakers.net wel. Kan ook logisch zijn, niet alles van dpgmedia draait op dezelfde infra

[smiba]

Volgens mij is het echt niet alleen DNS geweest, mijn eigen DNS resolver cached resultaten even, dus toen de storing gaande was kon ik nog bijna alles resolven

De IPs die ik resolved reageerden ook niet op ping

Heb nog screenshots van de traceroute, upload ze nu even

EDIT: Blijkbaar is de grap op mij, want funda.nl of airbnb.nl reageren blijkbaar hoe dan ook niet op ping -- Handig als je dat als bedrijf in je firewall blocked

[Reactie gewijzigd door smiba op 23 juli 2024 12:25]

[ouweklimgeit]

Niet zo gek hoor, ooit gehoord van een icmp flood?

[bazzi]

mwah met een beetje rate limiting op icmp kom je een heel eind en is dat eigenlijk verleden tijd. Al kan ik me de tijd nog wel herinneren dat ik het mocht mitigeren.... (opa verteld terwijl hij in zijn schommelstoel zit....)

[batjes]

Ping floods worden op de hops/switches doorgaans al gedropped en komen bij de meeste providers hun netwerk niet eens meer uit.

Pings blokkeren doet men om het "veiliger" te maken, vorm van security through obscurity.

[smiba]

Ja toen ik oude verhalen las uit 1990

Als je server nu nog last heeft van ICMP floods denk ik dat het wel eens tijd is voor een upgrade, de processing power hebben we inmiddels. Denk dat eerder je internetlijntje vol zit.. en of een firewall nou dat pakket dropt of niet, binnenkomen over die lijn gebeurt dan sowieso.

Als je echt bang voor ICMP floods of bijvoorbeeld een asymmetrische verbinding hebt (lagere upload) kan je natuurlijk wel hier een ratelimit op zetten, nf_conntrack op linux via iptables is vrij simpel. Als je dit ook nog eens enkel op ICMP toepast voegt dit ook geen extra overhead toe aan niet ICMP pakketten.

[Reactie gewijzigd door smiba op 23 juli 2024 12:25]

[MiesvanderLippe]

Lijkt net weer opgelost te zijn. Ik kan de UPS en AH weer bereiken.

[Mel33]

Nee het gaat af en toe weer goed, en dan weer mis.

[sygys]

Rabobank app lijkt ook offline

[willyb]

nu.nl bleef het hier gewoon doen, maar die bezocht ik ook nog minder dan uur geleden (dns cache?)

[RGAT]

www.nu.nl werkte prima, nu.nl dan weer niet, die had DNS problemen
Mogelijk dat je browser automatisch de www ervoor zetten.

[mocem]

Tegenwoordig zetten zoveel mensen de TTL zo laag dat het snel fout gaat. Dit is dan het resultaat.

[MPAnnihilator]

dat mes snijdt langs 2 kanten, voor changes is dat dan weer ideaal

[Creepy]

Opzich is DNS behoorlijk decentraal. Maar als we dan ineens allemaal dezelfde DNS boeren gaan gebruiken, dan is de impact ineens een stuk groter als zo'n boer plat gaat. Al zo vaak gehoort dat je een CDN moet gebruiken want "dan is alles sneller" zonder dat er verder gekeken wordt waarom het niet snel genoeg is.

[Frame164]

De enkele keer dat het een keer niet werkt weegt op tegen de gigantische kosten die je moet maken om het anders te doen. Jij koopt ook niet 2 auto's of 2 huizen voor het geval er een keer iets is met die ene auto of huis.