AWS introduceert functie om DNS-storingen in US East sneller te herstellen

Amazon Web Services heeft de functie Accelerated recovery voor zijn DNS-dienst Amazon Route 53 aangekondigd. Daarmee kunnen klanten sneller hun functionaliteit herstellen bij DNS-storingen in de AWS-regio US East (Northern Virginia).

Het bedrijf schrijft dat de bedoeling van de functie is om klanten binnen 60 minuten na een storing de mogelijkheid te geven om hun DNS-instellingen te wijzigen. Door de nieuwe functie behouden beheerders tijdens failoverscenario's toegang tot bepaalde Route 53-api's, zoals ChangeResourceRecordSets, GetChange, ListHostedZones en ListResourceRecordSets.

De functie is onder meer in te schakelen in de AWS-managementconsole, de AWS commandline-interface en de AWS-softwaredevelopmentkit. Klanten hoeven volgens het bedrijf geen nieuwe api's te leren of applicaties of scripts aan te passen. Er zijn geen extra kosten aan het gebruik van de tool verbonden.

Amazon Web Services schrijft dat 'klanten die applicaties draaien die bedrijfscontinuïteit vereisen' aan het bedrijf hebben laten weten dat zij meer DNS-veerkracht nodig hebben om te voldoen aan zowel de vereisten voor bedrijfscontinuïteit als de wet. Het bedrijf noemt onder meer banken en bedrijven in de fintech- en SaaS-sector. Het bedrijf heeft de afgelopen jaren meermaals grote storingen gehad in zijn datacenter US-East-1. Vorige maand waren meerdere diensten, waaronder Signal en Snapchat, een aantal uur onbereikbaar door een storing in US-East-1. Later bleek dat die storing was veroorzaakt door een probleem in de DNS-records.

Amazon Web Services Accelerated recovery

Door Imre Himmelbauer

Redacteur

28-11-2025 • 18:33

25

Submitter: Tribits

Reacties (25)

Sorteer op:

Weergave:

Waarom zo'n omweg in plaats van het oplossen van het SPOF dat us-east-1 heet?

Is het oplossen zo moeilijk dat het blijkbaar makkelijker en voor hun aanvaardbaar is om een pleisteroplossing als dit aan te bieden aan klanten?

Ik mis misschien wat details over waarom us-east-1 zo belangrijk is (los van dat het volgens mij hun eerste region was?) maar inmiddels zou je toch verwachten van zo'n grote club dat ze gewoon capabel genoeg zijn om dit fatsoenlijk op te lossen?
edit:
Oh ja, volgens mij staat IAM alle daar ook? Maar dan nog. Kan toch niet zo onmogrlijk ingewikkeld zijn lijkt me?

[Reactie gewijzigd door keranoz op 28 november 2025 18:40]

Het is een soort bottleneck for the services van amazon zelf aan te sturen. Vorige keer lag daardoor alles plat. Dat was het grootste voorbeeld dat europa te afhankelijk geworden is van de verenigde staten, want ook europa lag plat, voor iets dat gebeuren in de US , ook al hebben we onze eigen regions.

Blijkbaar kan het dus toch mislopen als het misloopt op us-east-1, en dat is intussen al 3 keer gebeurd in de laatste 2 jaar.

Hetzelfde trouwens voor cloudflare, alles zit zogezegd in alle regios, maar elke keer er iets gebeurd in de states ligt het ook bij ons in EU plat.

Tot nu toe waren het altijd niet intentionele voorvallen.

Voor hackers, terroristen of oorlogen moet dat fantisch zijn, je legt us east plat en je hebt heel de westerse wereld lam gelegd. Zelf onze telecom en emergency services maken gebruik van AWS.
Tja, vergeet 2002 niet waar 9 DNS servers werden platgelegd door een aanval en bijna het hele internet eruit lag. Of de DDoS-aanval op Dyn in 2016. Het systeem is inmiddels wat robuuster, maar het blijft eigenlijk toch een achilleshiel.

Het lastige aan DNS is dat een fout vrij gemakkelijk reproduceert en de systemen aan elkaar geknoopt zijn. Loskoppelen van AWS of andere niet-EU partijen geeft nog steeds bar weinig garanties, tenzij je echt onafhankelijk van elkaar kunt opereren. Met alle nadelen van dien.
Menselijke fouten zouden allesinds niet twee wereld regios tegelijkertijd plat zetten.

En kwadelijke acties zouden erg nauwkeurige coordinatie verreisen.

Op zich vind ik het al vreemd dat AWS het niet zelf redundant WIL maken, want als het wel redundant is (two masters active-passive) dan zou de rest van america ook nog werken dankzij infra uit europa.
Je overdrijft nu een beetje. Er was een storing, maar niet alles lag plat. Wij maken bijvoorbeeld helemaal geen gebruik van AWS en merkten niks van de storing. Zelfs als de cloud die wij gebruiken een paar uur eruit ligt is er niks aan de hand. Vervelend voor klanten, maar niet meer dan dat.

Vanuit de EU heb je tegenwoordig ook te maken met Dora, waardoor je als bedrijf met dit soort risicos rekening dient te houden. 100% voorkomen wordt lastig, maar dat je zsm weer online bent, en dat is de extra dienst die AWS nu aanbiedt zolang ze dit probleem niet structureel hebben opgelost (makkelijker gezegd dan gedaan vermoed ik), klanten en snellere recovery tijd leveren.
het aantal bedrijven dat aan Dora moet voldoen is gewoon belachelijk veel en de bureaucratische nachtmerrie die het met zich meebrengt om al je ICT-toeleveranciers zelf door te lichten, zelfs al val je onder de minder strikte regels.
Zelfs applicaties gehost op AWS lagen vaak niet plat. Mijn website bleef vrolijk online in eu-west-1, maar ik ken ook veel complexere applicaties die geen downtime ondervonden. Het zat hem in wat globale endpoints die eruit lagen en natuurlijk in us-east-1 zelf.
Dit heeft niks met afhankelijkheid van de van VS te maken. Dat is gewoon hoe zo’n clouddienst werkt. Een Europese clouddienst zou dezelfde opzet kunnen hebben en dan hoef je ook alleen de main region daarvan plat te leggen.

Aws had ook een andere opzet kunnen kiezen, maar dat was in de wereld van toen niet logisch. Bovendien zou dat weer andere nadelen hebben.

Terug naar hoe het vroeger was. Ieder z’n eigen servetje online in een colo! ik denk dat we dan veel vaker een storing zouden hebben. Weliswaar met beperktere impact.
We zijn ook dom natuurlijk om onze kostbare eieren al te vaak bij een Amerikaans bedrijf neer te leggen.

En we zijn ook altijd maar al te blij om lekker alleen in de cloud te stoppen ipv gewoon lekker on-prem want die hadden die problemen niet meegemaakt.


Waarom is het moeilijk om een extra beheerder in dienst te nemen? Uiteindelijk gaat Ai jou en mij vervangen. We zijn niet nodig. Dat is waar alle naar toe werken.
Je hebt de memo niet ontvangen? We willen een wereld met minder beheerders, niet méér.
Het idee achter IT is om zoveel mogelijk te automatiseren, niet om mensen aan een baan te helpen. Ook dit DNS probleem was ontstaan door een menselijke fout.

AWS is een goed voorbeeld van hoe schaal en automatisering werkt. Een outage zoals deze is zeer zeldzaam. Het artikel hierboven lijkt te suggereren alsof het schering en inslag is, wat aantoonbaar onjuist is. Dat us-east-1 zelf outages heeft gehad, klopt wel. Normaal, als je als AWS klant je infra ontwerpt voor beschikbaarheid, heb je nagenoeg geen downtime. Mijn website, gehost in eu-west-1, was ook bij dit zeer groot uitgemeten incident gewoon in de lucht.

Als je werkelijk denkt dat je een hogere beschikbaarheid haalt als je het op eigen hardware in een rack gaat zetten t.o.v. een goed ontworpen architectuur bij AWS, dan geloof je in een platte aarde.
Kan toch niet zo onmogrlijk ingewikkeld zijn lijkt me?
Jij wordt de nieuwe minister van Digitale Zaken hoor ik al :p
Nog steeds verbaasd over de opmerking dat Signal eruit lag bij de AWS storing. Zelf nergens last van gehad.
Waarom is dit nieuws? Ieder zichzelf respecterende cloud engineer gaat toch de releases van AWS in de gsren houden...allez, dat verwacht ik toch...

Aws bracht afgelopen weken wel een kleine 100 nieuwe features of verbeteringen uit.
Dit is momenteel juist nieuws omdat er een dikke storing is geweest in Route 53 in us-east-1 waardoor het halve internet platlag, en er dus actief maatregelen wordt genomen om zo'n impact nog een keer te voorkomen.

Tuurlijk hoeft T.net niet ieder nieuwtje te papegaaien (die hoor ik van m'n AWS account manager wel) - maar vandaar dus dat hier wel nieuwswaarde aan zit.
Minder dan 20% is inderdaad ergens in de buurt van de helft. Leuk om hier de reacties te lezen van mensen die er nog 46% minder verstand van hebben.
Gelukkig is dns een protocol dat een vorm van redundancy heeft ingebouwd: De meeste systemen kunnen 2 of meer dns-servers geconfigureerd hebben. Doe dat naar verschillende dns-providers. Toegegeven, in de meeste gevallen zal de eerste gebruikt worden zolang ze beschikbaar is en de volgende pas als de eerste er niet meer is.

Daarnaast is dns alleen maar een netwerk-centrale variant op het /etc/hosts bestand (voor msWindows zit die iets dieper in de boom). Dus de echt belangrijke (en vaste) naam-ip-combinaties kan je altijd daar neer zetten.

Uiteindelijk is er een dns-server voor elk dns-domein. Als je echt zo onafhankelijk mogelijk wilt zijn, gebruik je een dns-resolver die zo snel mogelijk direct naar de dns-server van het gevraagde domein gaat. Daarmee heb je alleen last van omvallende dns servers voor de domeinen die ze bedienen.
Laten we een nieuwe standaard bouwen! Die zal veel beter zijn en voor null andere problemen veroorzaken.. of toch niet. Het ding is is dat DNS zelf niet een slechte standaard is, alleen voor het vaak gebruikt waar dat niet moet en wordt het op zo veel plekken gebruikt dat statistisch gezien het gewoon fout gaan.
Goed idee, lekker allemaal IPv4 en IPv6 adressen uit ons hoofd leter, veel beter dan af en toe een storing door DNS 8)7
Maar dan ook echt alle! Load balancing wordt een feestje!
Euh... hoe zie je dat precies voor je? Ik geef toe dat DNS verre van onfeilbaar is, maar wat zijn de alternatieven?
Heerlijk die reacties hier van mensen die je veel te serieus nemen }:O
En als het DNS niet is, is het wel de firewall, die moet er dus ook overal uit.
BGP & NTP zijn het met u eens
Ik ben oprecht benieuwd naar jouw voorstel hoe het dan wél moet. Waar kan ik je RFC lezen?

[Reactie gewijzigd door iqcgubon op 28 november 2025 20:09]


Op dit item kan niet meer gereageerd worden.