Post-Quantum DNSSEC właśnie stało się rzeczywistością: 2420-bajtowy poradnik dla operatorów backendów gier

Odpowiedzi DNS właśnie urosły 38-krotnie

Każda milisekunda, którą Twoja gra czeka na rozwiązywanie DNS, zanim połączy graczy z backendem, to milisekunda spędzona przez nich przed ekranem ładowania. 3 września resolver Cloudflare 1.1.1.1 zaczął walidować podpisy DNSSEC tworzone za pomocą ML-DSA-44 — postkwantowego algorytmu podpisu znormalizowanego przez NIST. Każdy podpis ML-DSA-44 ma 2420 bajtów, czyli prawie 38 razy więcej niż podpisy ECDSA P-256 (64 bajty), których dziś używa większość stref zabezpieczonych DNSSEC.

Jeśli obsługujesz własne domeny dla backendu gry, matchmakingu, CDN lub punktów dostarczania zasobów, ta zmiana ostatecznie przekształci Twoją infrastrukturę DNS. Konkretne skutki:

• Odpowiedzi DNS, które dziś z łatwością mieszczą się w jednym pakiecie UDP, przekroczą konserwatywny limit 1232 bajtów dla pakietów UDP
• Serwery autorytatywne będą zwracać odpowiedzi z uciętymi danymi (truncation), wymuszając ponowienie zapytań przez TCP
• Strefy korzystające z dwóch algorytmów w oknie migracji tworzą powierzchnię ataków typu downgrade
• Wszystko to dodaje opóźnienia do pierwszego skoku sieciowego, jaki wykonują Twoi gracze

To runbook (poradnik) do wykrywania, łagodzenia skutków i przygotowania na postkwantowe DNSSEC w infrastrukturze backendu gier.

Dlaczego backendy gier dbają o rozmiary podpisów DNSSEC

Ściana rozmiaru UDP

DNS przez UDP ma długą historię ograniczeń rozmiaru pakietów:

Limit	Źródło	Bajty
Oryginalne maksimum DNS UDP	RFC 1035 (1987)	512
Typowa wartość domyślna EDNS(0)	Różne implementacje	1232
Zalecane maksimum	RFC 9715 (2025)	1400
Sam podpis ML-DSA-44	NIST ML-DSA-44	2420
Klucz publiczny ML-DSA-44	DNSKEY RRset	1312

Pojedynczy podpis ML-DSA-44 sam przekracza każdy z tych limitów, zanim jeszcze dodamy podpisany RRset, nazwy domen, nagłówki i inne rekordy DNSSEC. Fragmentowany UDP jest zawodny — Cloudflare i inni wprost odradzają go od DNS Flag Day 2020 — więc praktycznym rozwiązaniem awaryjnym jest TCP.

Jaki koszt dla graczy niesie fallback na TCP

Według Cloudflare Radar około 85% zapytań do 1.1.1.1 przychodzi przez UDP. We wszystkich usługach na platformie Big Pineapple (która zasila również Gateway DNS) około 60% przychodzi przez UDP. Oznacza to, że 15–40% ruchu DNS już korzysta z TCP, DoT lub DoH — ale to dobrowolne połączenia nie-UDP.

Gdy UDP zawiedzie i klient ponowi próbę przez TCP, płacisz pełny koszt uzgadniania TCP: ~1 RTT na SYN/SYN-ACK/ACK, zanim resolver w ogóle wyśle zapytanie. Dla gracza łączącego się z Twoim backendem gry z opóźnieniem 80 ms to dodatkowe 80 ms czasu połączenia, zanim zacznie się uwierzytelnianie.

W praktyce przejście na TCP zachodzi między resolverem a autorytatywnym serwerem nazw, a resolver cache'uje wyniki. Najgorzej jest, gdy:

1. Cache jest zimny — pierwsze wyszukiwanie po wygaśnięciu TTL lub nowy gracz łączący się z regionu bez wcześniejszego ruchu
2. Odpowiedź DNSKEY strefy jest duża — dokładnie tak jest w okresie migracji z dwoma algorytmami
3. Wiele delegacji powoduje duże odpowiedzi — łańcuch 3–4 stref, z których każda zawiera zarówno konwencjonalne, jak i postkwantowe klucze

Limity czasu uruchamiania sesji już nękają backendy multiplayer w normalnych warunkach DNS — w poprzednim artykule szczegółowo omówiliśmy diagnostykę problemów z timeoutami na poziomie sieci w Unreal Engine. Postkwantowe DNSSEC sprawi, że te timeouty będą częstsze, jeśli nie zaplanujesz obsługi większych odpowiedzi.

Pułapka migracji z dwoma algorytmami

ML-DSA-44 nie może z dnia na dzień zastąpić konwencjonalnych algorytmów podpisu. Strefy muszą publikować zarówno konwencjonalne (ECDSA/RSA), jak i postkwantowe (ML-DSA-44) klucze, aby zachować wsteczną kompatybilność. W tym oknie odpowiedź DNSKEY dla strefy może zawierać:

• Konwencjonalny klucz publiczny (np. 91 bajtów dla ECDSA P-256)
• Klucz publiczny ML-DSA-44 (1312 bajtów)
• Konwencjonalny podpis RRsetu DNSKEY (64 bajty)
• Podpis ML-DSA-44 RRsetu DNSKEY (2420 bajty)

To łącznie około 3900 bajtów samego materiału DNSSEC, znacznie powyżej każdego limitu ładunku UDP. Rotacje kluczy dodają kolejne bajty. Resolver musi przejść na TCP.

Powierzchnia ataku downgrade

Oto problem bezpieczeństwa, który czyni z tego coś więcej niż problem opóźnień. RFC 6840 mówi, że walidatory „POWINNY akceptować dowolną pojedynczą poprawną ścieżkę”. Oznacza to, że jeśli strefa publikuje zarówno zestaw walidatorów ECDSA, jak i ML-DSA-44, resolver obsługujący oba zaakceptuje którykolwiek z nich.

Gdy komputery kwantowe będą w stanie złamać klucze ECDSA, atakujący będzie mógł sfałszować odpowiedzi tylko z ECDSA, a resolver obsługujący postkwantowe algorytmy nadal je zaakceptuje. To jest atak typu downgrade:

1. Resolver gracza odpytuje api.your-game-backend.com i otrzymuje odpowiedź podpisaną tylko ECDSA
2. Resolver akceptuje podpis ECDSA, ponieważ znajduje się on na liście „dowolna poprawna ścieżka”
3. Atakujący sfałszował tę odpowiedź przy użyciu klucza prywatnego uzyskanego za pomocą komputera kwantowego
4. Gracz łączy się z serwerem atakującego zamiast z Twoim

To nie jest teoretyczne zagrożenie. Naruszenie danych w Star Citizen pokazało, jak pojedynczy kompromis infrastruktury może przerodzić się w masowy wyciek danych uwierzytelniających. Kompromis na poziomie DNS jest gorszy: przekierowuje każdego gracza, który rozwiązuje Twoją nazwę hosta, na punkt końcowy kontrolowany przez atakującego.

1.1.1.1 rozwiązuje ten problem, używając rekordu DS jako uwierzytelnionego sygnału: jeśli RRset DS strefy nadrzędnej zawiera rekord dla obsługiwanego algorytmu postkwantowego, resolver egzekwuje bardziej rygorystyczną politykę wymagającą co najmniej jednej poprawnej postkwantowej ścieżki walidacji. Jeśli żadna ścieżka ML-DSA-44 nie przejdzie walidacji, walidacja kończy się niepowodzeniem.

To dobrze — ale oznacza, że strefy, które zamierzają oferować bezpieczeństwo postkwantowe, muszą publikować rekordy DS ML-DSA-44, a każda delegacja powyżej w łańcuchu musi zrobić to samo. Skompromitowany klucz w dowolnym miejscu łańcucha pozwala atakującemu sfałszować wszystko poniżej: „złam raz, fałszuj wszędzie”.

Wykrywanie wpływu postkwantowego DNSSEC na Twoją infrastrukturę

Krok 1: Sprawdź aktualne rozmiary odpowiedzi DNS

Zanim zmierzysz wpływ, potrzebujesz punktu odniesienia. Użyj dig z flagą +dnssec, aby zobaczyć aktualne rozmiary odpowiedzi dla domen Twojej gry:

# Measure current DNSKEY response size for your authoritative zone
dig +dnssec +bufsize=4096 NS your-game-backend.com @your-ns.example.com +short

# Check the full DNSKEY response with size tracking
dig +dnssec +bufsize=4096 DNSKEY your-game-backend.com @your-ns.example.com
# Look at the MSG SIZE stat near the bottom of the output

# Measure a typical A-record query with DNSSEC signatures attached
dig +dnssec +bufsize=4096 A api.your-game-backend.com @your-ns.example.com

Dla porównania odpowiedź DNSKEY z ECDSA P-256 ma zwykle około 200–400 bajtów. Przy opublikowanym obok ML-DSA-44 spodziewaj się 3500–5000 bajtów. Zapisz bieżące liczby — przydadzą Ci się do wykrywania degradacji.

Krok 2: Sprawdź, jakiego algorytmu używa Twoja strefa

# Extract algorithm numbers from your DNSKEY records
dig +dnssec DNSKEY your-game-backend.com @your-ns.example.com | \
  grep -E "DNSKEY|RRSIG" | awk '{print $5}' | sort -u

Numer algorytmu mówi Ci, jaki algorytm podpisu jest używany:

Algorytm	Numer	Status
RSA/SHA-256	8	Szeroko stosowany, podatny na komputery kwantowe
ECDSA P-256/SHA-256	13	Najczęstszy współczesny wybór, podatny na komputery kwantowe
ED448	16	Podatny na komputery kwantowe, ale duży (~114 bajtów)
ML-DSA-44	18	Postkwantowy, 2420 bajtów, nowo przypisany przez IANA

Jeśli Twoja strefa używa obecnie algorytmu 13 (ECDSA P-256), znajdujesz się w najpopularniejszym współczesnym nurcie. Migracja do algorytmu 18 jest na etapie planowania w większości ekosystemu DNS — ale powinieneś zrozumieć harmonogram.

Krok 3: Monitoruj wskaźniki przejść na TCP za pomocą analizatora logów zapytań

Jeśli prowadzisz autorytatywne serwery nazw lub masz dostęp do logów resolwera, śledź stosunek zapytań TCP do UDP. To najwyraźniejszy wczesny sygnał, że rozmiary odpowiedzi uderzają w ścianę UDP.

#!/usr/bin/env python3
"""
Post-Quantum DNSSEC TCP Fallback Monitor.
Tracks TCP/UDP query ratios from BIND-style query logs
as a proxy for large-response fallback pressure.

Usage:
    python3 pq_dns_monitor.py --log /var/log/named/queries.log --window 2
"""

import re
import argparse
from collections import Counter
from datetime import datetime, timedelta

LOG_PATTERN = re.compile(
    r"(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2})\.\d+Z"
    r"\s+(\w+)\s+query:\s+\S+\s+(\S+)\s+(\S+)"
)

def analyze_dns_traffic(log_path: str, window_hours: int = 1) -> None:
    cutoff = datetime.utcnow() - timedelta(hours=window_hours)
    transport_counts = Counter()
    rrtype_counts = Counter()
    tcp_by_qtype: Counter = Counter()

    with open(log_path, "r") as f:
        for line in f:
            m = LOG_PATTERN.search(line)
            if not m:
                continue
            ts_str, transport, qname, qtype = m.groups()
            try:
                ts = datetime.strptime(ts_str, "%Y-%m-%dT%H:%M:%S")
                if ts < cutoff:
                    continue
            except ValueError:
                continue

            transport_counts[transport] += 1
            rrtype_counts[qtype] += 1
            if transport == "tcp":
                tcp_by_qtype[qtype] += 1

    total = sum(transport_counts.values())
    if total == 0:
        print("No queries found in the specified time window.")
        return

    tcp_count = transport_counts.get("tcp", 0)
    tcp_pct = (tcp_count / total) * 100

    print(f"=== DNS Transport Breakdown (last {window_hours}h) ===")
    print(f"  UDP: {transport_counts.get('udp', 0):>8} ({100 - tcp_pct:.1f}%)")
    print(f"  TCP: {tcp_count:>8} ({tcp_pct:.1f}%)")
    print(f"  Total: {total:>6}")
    print()

    if tcp_pct > 15.0:
        print(f"  ⚠  ALERT: TCP fallback rate is {tcp_pct:.1f}%.")
        print("     Large DNSSEC responses may be forcing TCP retries.")
        print("     Check whether any upstream zones have added post-quantum keys.")
    elif tcp_pct > 8.0:
        print(f"  ⚡ NOTICE: TCP fallback rate is {tcp_pct:.1f}%. Monitor for increases.")
    else:
        print(f"  ✓  TCP fallback rate ({tcp_pct:.1f}%) is within normal range.")

    # Show which query types incur the most TCP fallback
    if tcp_by_qtype:
        print()
        print("=== TCP Fallback by Query Type ===")
        for qtype, count in tcp_by_qtype.most_common(5):
            pct = (count / rrtype_counts[qtype]) * 100 if rrtype_counts[qtype] else 0
            print(f"  {qtype:<10} {count:>5} TCP / {rrtype_counts[qtype]:>5} total  ({pct:.0f}%)")

    print()
    print("=== Query Type Breakdown ===")
    for qtype, count in rrtype_counts.most_common(10):
        print(f"  {qtype:<10} {count:>6}")

    # Recommendation
    print()
    if tcp_by_qtype.get("DNSKEY", 0) > tcp_by_qtype.get("A", 0) * 0.5:
        print("  ➜  DNSKEY queries have a notably high TCP fallback rate.")
        print("     Your zones or upstream zones may already be publishing")
        print("     large post-quantum keys alongside conventional ones.")


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="DNS TCP fallback monitor for PQ-DNSSEC readiness")
    parser.add_argument("--log", required=True, help="Path to BIND query log file")
    parser.add_argument("--window", type=int, default=1, help="Time window in hours")
    args = parser.parse_args()
    analyze_dns_traffic(args.log, args.window)

Uruchamiaj to regularnie na logach swojego autorytatywnego serwera nazw. Jeśli zapytania TCP o rekordy DNSKEY lub DS przekraczają 10%, Twoje resolwery uderzają w ścianę UDP, a prawdopodobną przyczyną są odpowiedzi o rozmiarach postkwantowych.

Krok 4: Zmierz opóźnienie resolver–serwer autorytatywny

Użyj dnsperf, aby przetestować pod obciążeniem czasy odpowiedzi swojego autorytatywnego serwera, w tym zapytania generujące duże odpowiedzi:

# Create a test query file focused on DNSSEC-heavy queries
cat > /tmp/dnssec-bench.txt << 'EOF'
your-game-backend.com DNSKEY
your-game-backend.com DNS
api.your-game-backend.com A
match.your-game-backend.com A
assets.your-game-backend.com A
EOF

# Run with 20 concurrent clients for 20 seconds
dnsperf -s your-ns-ip -d /tmp/dnssec-bench.txt -l 20 -c 20

Porównaj średnie opóźnienia i wskaźniki ucinania TCP przed dodaniem rekordów ML-DSA-44 do strefy testowej i po nim. Potrzebujesz mierzalnych liczb, a nie zgadywania.

Remediacja: Wzmacnianie DNS pod kątem odpowiedzi postkwantowych

1. Maksymalizuj rozmiary buforów EDNS(0) na serwerach autorytatywnych

Twoje autorytatywne serwery nazw powinny reklamować największy obsługiwany ładunek UDP. Nie zapobiega to przejściu na TCP dla odpowiedzi DNSKEY — podpisy ML-DSA-44 są po prostu zbyt duże — ale zapewnia, że odpowiedzi inne niż DNSSEC i mniejsze podpisy nadal mieszczą się w UDP, a sygnał ucięcia dociera do klientów szybciej.

# BIND 9 — named.conf
options {
    edns-udp-size 1232;
    max-udp-size 1232;
    tcp-fast-open 256;
};

Ustawienie 1232 bajtów zostało wybrane celowo: 1280 (minimalne MTU IPv6) − 40 (nagłówek IPv6) − 8 (nagłówek UDP) = 1232. Zapobiega to fragmentacji na każdej ścieżce obsługującej minimalne MTU IPv6.

# NSD — nsd.conf
server:
    ipv4-edns-size: 1232
    ipv6-edns-size: 1232

2. Włącz TCP Fast Open na wszystkich serwerach nazw, które kontrolujesz

TCP Fast Open (TFO) pozwala resolverowi wysłać zapytanie DNS w pakiecie SYN, eliminując jedną rundę (round trip) z procesu nawiązywania połączenia TCP. Zmniejsza to przejście na TCP z ~2 RTT (uzgadnianie + zapytanie/odpowiedź) do ~1 RTT.

# Linux: enable TFO for both inbound and outbound connections (mode 3)
sudo sysctl -w net.ipv4.tcp_fastopen=3

# Verify
cat /proc/sys/net/ipv4/tcp_fastopen
# Expected output: 3

TFO musi być również włączone w Twoim oprogramowaniu DNS. BIND 9 (9.18+) i Knot Resolver go obsługują. Sprawdź dokumentację swojej wersji. W Unbound jest ono domyślnie włączone w najnowszych kompilacjach.

Efekt netto: zapytanie DNS przez TCP, które wcześniej kosztowało ~160 ms (dwie rundy po 80 ms), teraz kosztuje ~80 ms (jedna runda). Nadal jest gorzej niż w UDP (~80 ms), ale kara jest o połowę mniejsza.

3. Rozwiązuj i cache'uj nazwy hostów przy starcie gry — nigdy w trakcie rozgrywki

Najskuteczniejszym środkiem łagodzącym opóźnienia DNS w klientach gier jest unikanie wyszukiwania DNS na ścieżkach krytycznych dla rozgrywki. Rozwiąż wszystkie nazwy hostów backendu przy inicjalizacji i cache'uj rozwiązaną adresację IP na czas trwania sesji.

// Unreal Engine C++ — resolve game backend hostnames at startup
// and cache IP addresses so players never wait for DNS during connect

void UGameBackendSubsystem::Initialize(FSubsystemCollectionBase& Collection)
{
    Super::Initialize(Collection);

    // All hostnames the game needs during a session
    TArray<FString> Hostnames = {
        TEXT("api.your-game-backend.com"),
        TEXT("match.your-game-backend.com"),
        TEXT("assets.cdn.your-game-backend.com"),
    };

    ISocketSubsystem* Sockets = ISocketSubsystem::Get();

    for (const FString& Host : Hostnames)
    {
        // Resolve at startup — resolves once, not on first connect
        FResolveInfo* ResolveInfo = Sockets->GetHostByName(
            TCHAR_TO_ANSI(*Host)
        );

        // Block until resolution completes (acceptable during loading screen)
        ResolveInfo->WaitUntilComplete(5.0f);

        FInternetAddr Result;
        if (ResolveInfo->GetErrorCode() == 0)
        {
            Result = ResolveInfo->GetResolvedAddress();
            FString ResolvedIP = Result.ToString(false);
            CachedEndpoints.Add(Host, ResolvedIP);
            UE_LOG(LogGameBackend, Log,
                TEXT("Pre-resolved %s -> %s (cached for session)"),
                *Host, *ResolvedIP);
        }
        else
        {
            UE_LOG(LogGameBackend, Warning,
                TEXT("DNS resolution failed for %s (error %d)"),
                *Host, ResolveInfo->GetErrorCode());
            // Store empty — will re-resolve on demand with exponential backoff
            CachedEndpoints.Add(Host, FString());
        }
    }
}

FString UGameBackendSubsystem::GetResolvedAddress(const FString& Hostname) const
{
    const FString* Cached = CachedEndpoints.Find(Hostname);
    if (Cached && !Cached->IsEmpty())
    {
        return *Cached;
    }
    return Hostname; // Fallback to hostname (will trigger real DNS)
}

Oznacza to, że Twoi gracze nigdy nie czekają na DNS podczas łączenia z serwerem lub pobierania zasobów. Nawet jeśli rozwiązywanie DNS zajmie 200 ms z powodu przejścia na TCP i zimnego cache'u, dzieje się to po cichu na ekranie ładowania — a nie podczas odliczania matchmakingu.

4. Używaj DNS-over-HTTPS do zapytań infrastrukturalnych

DoH działa przez HTTP/2 lub HTTP/3 (oba oparte na TCP lub QUIC w warstwie transportowej), więc całkowicie omija ograniczenie rozmiaru UDP. Jeśli serwery backendu gry, skrypty wdrożeniowe lub pipeline'y CI/CD odpytyją DNS programistycznie, skonfiguruj je do korzystania z DoH:

# Resolve a hostname using Cloudflare's DoH endpoint
# (requires curl 7.76+)
curl -sS \
  "https://cloudflare-dns.com/dns?name=api.your-game-backend.com&type=A" \
  -H "Accept: application/dns-json" | jq -r '.Answer[0].data'

# For Kubernetes pods, configure CoreDNS to forward to a DoH-capable
# recursive resolver. In practice, this means setting upstream to
# a resolver that natively supports DoH, such as 1.1.1.1 or 8.8.8.8

Jest to szczególnie istotne w przypadku skryptów health-check monitorujących dostępność backendu, pipeline'ów weryfikacji wdrożeń oraz systemów orkiestracji kontenerów, w których pody domyślnie korzystają z konfiguracji resolwera węzła.

5. Przeaudytuj rekordy DS swojej strefy i gotowość algorytmiczną

Jeśli obsługujesz własną strefę autorytatywną, sprawdź, czy Twoje rekordy DS odpowiadają bieżącemu algorytmowi i czy nie nosisz nieaktualnych danych delegacji.

# Check DS records from the parent zone
dig +short DS your-game-backend.com

# Compare with actual DNSKEY data in your zone
dig +short DNSKEY your-game-backend.com

# Use delv to trace the full DNSSEC validation chain
delv +rtrace api.your-game-backend.com A

Jeśli widzisz osierocone rekordy DS dla algorytmów, których już nie używasz, mogą one powodować niepotrzebną logikę awaryjną w resolverach. Posprzątaj je podczas najbliższego okna konserwacyjnego.

Najlepsze praktyki: lista kontrolna gotowości na postkwantowe DNSSEC

1. Określ punkt odniesienia dla rozmiarów odpowiedzi DNS już dziś. Uruchom dig +dnssec wobec wszystkich stref, od których zależy Twoja infrastruktura. Zapisz MSG SIZE dla zapytań DNSKEY, DS i typowych zapisów A. Potrzebujesz tych liczb, aby wykryć przyszłą degradację, gdy strefy nadrzędne zaczną publikować rekordy postkwantowe.

2. Włącz TCP Fast Open na każdym serwerze nazw, który kontrolujesz. Ta pojedyncza zmiana flagi jądra zmniejsza opóźnienie przejścia na TCP o jedną pełną rundę (~80–160 ms w zależności od geografii). W połączeniu z agresywnym cache'owaniem DNS sprawia, że przejście na TCP jest dla graczy niemal niewidoczne.

3. Rozwiązuj nazwy hostów przy starcie gry, nigdy w trakcie rozgrywki. Wszystkie punkty końcowe backendu, CDN i matchmakingu powinny być rozwiązywane na ekranie ładowania i cache'owane w pamięci. Odświeżanie w tle co kilka minut obsługuje wygaśnięcie TTL bez blokowania rozgrywki.

4. Monitoruj wskaźniki przejść na TCP co tydzień. Skonfiguruj powyższy analizator logów zapytań lub odpowiednik. Utrzymujący się wskaźnik TCP powyżej 10% dla zapytań DNSKEY sygnalizuje, że rozmiary odpowiedzi przekraczają limity UDP. Traktuj to jak naruszenie SLA dla opóźnień.

5. Zaplanuj harmonogram migracji algorytmów DNSSEC. Jeśli podpisujesz własną strefę, zacznij testować ML-DSA-44 w subdomenie stagingowej. Opublikuj klucze dwualgorytmiczne i zmierz wpływ na rozmiar odpowiedzi. Nie czekaj, aż pojawi się zagrożenie kwantowe — migracja w DNS trwa latami, a nie sprintami. Migracja algorytmów w DNSSEC to problem na poziomie infrastruktury, a bezpieczeństwo Twoich kont, tablic wyników i danych zapisów w chmurze zależy od integralności ścieżek rozwiązywania nazw, które w pierwszej kolejności dostarczają graczy do tych usług.

Harmonogram: kiedy to ma dla Ciebie znaczenie

Włączenie przez Cloudflare 1.1.1.1 walidacji ML-DSA-44 to pierwsze duże wdrożenie w resolverach. Oto przybliżony harmonogram:

Okres	Co się dzieje
Teraz (2025)	Cloudflare 1.1.1.1 waliduje ML-DSA-44; pierwsi użytkownicy zaczynają testy
2025–2027	Kolejne resolwery dodają walidację; wczesne strefy zaczynają publikować klucze dwualgorytmiczne
2027–2029	Szersza adopcja w strefach; resolwery mogą egzekwować ostrzejsze polityki ochrony przed downgrade
2029+	Cloudflare celuje w pełne bezpieczeństwo postkwantowe; algorytmy konwencjonalne uznawane za niebezpieczne

Nic z tego nie zepsuje Twoich serwerów gier jutro. Ale wzorzec migracji jest jasny.

Operatorzy backendów gier, którzy zaczną przygotowania już teraz — cache'owanie DNS, włączanie TFO, audyt algorytmów stref, monitorowanie wskaźników przejść na TCP — nie zauważą, kiedy ta transformacja się zakończy. Ci, którzy czekają, będą debugować opóźnienia przejść na TCP i błędy walidacji DNSSEC podczas premiery gry na żywo, czyli dokładnie wtedy, gdy najmniej mogą sobie na to pozwolić.

Gotowy, aby skupić się na tworzeniu rozgrywki zamiast na zarządzaniu infrastrukturą? horizOn zajmuje się uwierzytelnianiem kont, zapisami w chmurze, tablicami wyników i raportowaniem crashy, dzięki czemu możesz poświęcić wysiłek infrastrukturalny warstwom DNS, sieci i bezpieczeństwa, które wymagają Twojej uwagi. Sprawdź dokumentację horizOn, aby zobaczyć, co jest dostępne od razu po wyjęciu z pudełka.

---

Źródło: 1.1.1.1 obsługuje już postkwantowe DNSSEC, wszystkie 2420 bajtów