20 Października 2025

Mój smart home przestał być smart. Alexa milczała jak zaklęta. Ring doorbell pokazywał connecting… w nieskończoność. Snapchat, Fortnite i inne działające serwisy zamieniające się w ekrany: Uwaga - Przerwa Techniczna.

Nie był to cyberatak. Nie był to hardware failure. To były trzy litery: DNS.

Co się właściwie stało

Schemat wydarzeń, który mamy z oficjalnych stron AWS, prezentował się następująco:

23:49 PDT ─┐
           │ Błąd rozwiązywania DNS dla endpointów DynamoDB
           ├─> Błędy API DynamoDB (US-EAST-1)
           │
02:24 PDT ─┤ DNS NAPRAWIONY! 🎉 
           │ ...ale...
           │
           ├─> System uruchamiania EC2 padł (zależność od DynamoDB)
           │   └─> RDS, ECS, Glue - wszystko co używa EC2
           │
09:38 PDT ─┤ Awaria health checków Network Load Balancera
           │   └─> Środowiska wykonawcze Lambda
           │   └─> Metryki CloudWatch
           │   └─> Totalny chaos połączeń
           │
15:01 PDT ─┴─> PEŁNE PRZYWRÓCENIE (15h 12min później)

Dotknięte serwisy:
├─ Gaming: Fortnite, Roblox, PlayStation Network
├─ Social: Snapchat, Signal
├─ Finanse: Coinbase, Robinhood, Venmo, banki US
├─ Amazon własne: Alexa, Ring, Prime Video
├─ Atlassian: Jira, Confluence
└─ Infrastruktura: IAM, Zgłoszenia wsparcia, DynamoDB Global Tables

DNS czyli 12 bajtów które zatrzymały pół internetu

Czym właściwie jest DNS i dlaczego spowodował takie problemy i straty? `DNS to swego rodzaju książka telefoniczna internetu, dzięki której możemy w swobodny sposób się komunikować z internetem.

Załóżmy, że nie posługujemy się DNS - chcemy coś wyszukać w Google. Zamiast google.com musimy wpisać adres IP, na przykład 142.250.179.142.

Czy zamiast google.com byłbyś w stanie zapamiętać ciąg liczb? Pewnie nie! DNS to nasza książka telefoniczna, dzięki której możemy komunikować się za pomocą łatwych do zapamiętania adresów internetowych.

Jak to działa?

Kod jest wart więcej niż 1000 słów. Posługując się językiem C i tym oto bardzo uproszczonym programem, zapytajmy serwer DNS Amazon, jaki IP ma DynamoDb! (lub możesz użyć gotowych programów takich jak host albo nslookup)

#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main() {
    int sock = socket(AF_INET, SOCK_DGRAM, 0);
    struct sockaddr_in dns = {AF_INET, htons(53), {inet_addr("8.8.8.8")}};
    
    // To jest CAŁE pytanie DNS - tylko 12 bajtów nagłówka + nazwa domeny
    unsigned char q[] = {
        0xAA,0xAA,0x01,0x00,0,1,0,0,0,0,0,0,  // Header DNS
        8,'d','y','n','a','m','o','d','b',
        9,'u','s','-','e','a','s','t','-','1',
        9,'a','m','a','z','o','n','a','w','s',
        3,'c','o','m',0,
        0,1,0,1  // Type A, Class IN
    };
    
    unsigned char r[512];
    
    sendto(sock, q, sizeof(q), 0, (struct sockaddr*)&dns, sizeof(dns));
    int len = recvfrom(sock, r, 512, 0, NULL, NULL);
    
    // Odpowiedź DNS ma skomplikowaną strukturę, ale IP jest na końcu
    printf("IP: %d.%d.%d.%d\n", r[len-4], r[len-3], r[len-2], r[len-1]);
    
    return 0;
}

A odpowiedź wygląda następująco:

IP: 3.218.180.124

53 to port DNS. 8.8.8.8 to publicny serwer DNS Google (możesz użyć dowolnego serwera DNS). To wszystko, co potrzebne, żeby zapytać gdzie jest dynamodb.us-east-1.amazonaws.com.

Serwery DNS używają protokołu UDP, który jest bardzo uproszczony w stosunku do TCP/IP i dzięki temu bardzo szybki. Oczywiście jak każdy protokół posiada standardyzację, która jest oznaczona numerem RFC 1035.

Sama awaria dotknęła DynamoDB - nierelacyjną bazę danych, która jest używana do przechowywania i przetwarzania dużych ilości danych, szczególnie tych o dużej skali i natężeniu ruchu.

Także ci, co używają i nie używają DynamoDB, byli dotknięci awarią, bo na przykład EC2 używa wewnętrznie DynamoDB do trzymania metadanych.

DynamoDB jako architektura rozproszona

DynamoDB, jak i inne usługi AWS, działają w architekturze rozproszonej i możemy to zobrazować następującym diagramem:

🏗️ ARCHITEKTURA DynamoDB (rozproszona)

                    LOAD BALANCER VIP
                 (Virtual IP: 52.94.133.131)
                            ↓
        ┌───────────────────┼───────────────────┐
        │                   │                   │
    ┌───▼────┐         ┌───▼────┐         ┌───▼────┐
    │ Node 1 │         │ Node 2 │         │ Node 3 │
    │  AZ-1a │         │  AZ-1b │         │  AZ-1c │
    │   IP   │         │   IP   │         │   IP   │
    └────────┘         └────────┘         └────────┘
        ✅                 ✅                 ✅
     DZIAŁA              DZIAŁA             DZIAŁA

Skoro wszystko jest rozproszone, nawet serwery DNS, to co się wydarzyło? Cały system DNS dla us-east-1 miał problemy.

Jak się okazuje, “multi-region” wymaga prawdziwej niezależności, nie tylko replikacji danych.

Jak to się odnosi do naszego problemu DNS?

Wiele usług AWS, pomimo tego że były zlokalizowane w różnych miejscach, miały jeden punkt styku - w tym przypadku resolvowanie adresów DNS w us-east-1.

// Cała infrastruktura zależna od jednego serwisu
DynamoDB_IP = dns_resolve("dynamodb.us-east-1.amazonaws.com");
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                          Kiedy to failuje - wszystko failuje!

Co to oznaczało w praktyce?

Problem nie był w DynamoDB. Problem nie był w serwerach. Problem był w MAPIE.

Wszystkie usługi AWS pytały:

Gdzie jest dynamodb.us-east-1.amazonaws.com?

I nikt nie potrafił odpowiedzieć. Serwery działały. Dane były bezpieczne. Ale NIKT nie wiedział, jak tam dotrzeć.

Co to oznacza dla nas i jakie lekcje z tego możemy wyciągnąć ?

  • chmura to nie magia tylko czyjeś serwery które mogą ulec awarii
  • multiregion to nie to samo co nie zależność (zawsze coś może używać jednego miejsca o którym nie wiemy)
  • testuj awarie szczególnie uwzględniając awarie sieciowe takie jak np DNS
  • nie polegaj tylko na jednym providerze DNS