DNS w skali milionów rekordów: czego uczy przebudowa pipeline’u Cloudflare o selektywnych buildach

Cloudflare opublikował 2 listopada 2026 roku techniczny opis przebudowy swojego pipeline’u propagacji DNS. Z komunikatu wynika, że firma wprowadziła planer selektywnych przebudów stref (targeted zone builds) oraz nowy scheduler, które razem obniżyły szczytowe zużycie pamięci o 85% i skróciły o połowę czas od zmiany rekordu DNS do zapisania danych w Quicksilver, czyli rozproszonym magazynie klucz-wartość zasilającym autorytatywne serwery DNS Cloudflare. Zmiany ustawień strefy nie wymuszają już pełnej przebudowy stref liczących dziesiątki milionów rekordów.

To nie jest informacja o podatności ani o nowym produkcie dla klientów końcowych. Dotyczy architektury wewnętrznej operatora DNS i ma znaczenie przede wszystkim dla zespołów, które utrzymują własne serwery autorytatywne lub duże strefy DNS: pokazuje, gdzie realnie powstaje wąskie gardło przy propagacji zmian i dlaczego „przebuduj wszystko od zera” przestaje działać wraz ze wzrostem rozmiaru strefy. Dla polskich firm z własną infrastrukturą DNS to materiał do porównania własnych założeń, nie do bezpośredniego wdrożenia.

Co dokładnie się zmieniło

Według autora wpisu Zone Builder w 2022 roku odbierał około 250 zmian rekordów DNS na sekundę. Obecnie odbiera około 700 takich zmian oraz około 100 innych zdarzeń, takich jak zmiany ustawień strefy. Cloudflare zaznacza przy tym, że liczba zdarzeń nigdy nie była głównym problemem — problemem był rodzaj pracy, jaką część zdarzeń uruchamiała, i to, jak ta praca rośnie wraz z rozmiarem strefy. Niektóre strefy mają dziś ponad 20 milionów rekordów, a firma spodziewa się wzrostu w kierunku setek milionów.

Wprowadzone rozwiązanie składa się z dwóch elementów. Pierwszy to planer selektywnych przebudów, który wybiera najmniejszą operację, której bezpieczeństwo da się udowodnić. Drugi to scheduler łączący pracę dla tej samej strefy. Efekt: zmiany ustawień strefy nie powodują już przebudowy stref z dziesiątkami milionów rekordów, a dodatkowy zapas pamięci pozwolił skrócić oczekiwania, które pipeline utrzymywał dla odporności.

Tło techniczne bez żargonu

Strefa DNS to zbiór rekordów i ustawień dla domeny. Cloudflare opisuje pipeline, przez który zmiana w strefie trafia do sieci edge, w kilku etapach: klient zmienia rekord przez API lub panel albo inna usługa Cloudflare zmienia ustawienie strefy; zmiana trafia do bazy danych; baza lub inny system generuje zdarzenie w Kafce; agregator DNS Kafka łączy zdarzenia z kilku tematów i przekazuje je do Zone Buildera; Zone Builder odczytuje potrzebne dane strefy i konwertuje je na klucze zrozumiałe dla serwerów autorytatywnych; na końcu porównuje te klucze z Quicksilverem, zapisuje wyłącznie różnice, a Quicksilver propaguje je po sieci.

Warto podkreślić, że Zone Builder nie kopiuje wierszy bazy danych wprost na edge. Łączy rekordy z ustawieniami strefy, stosuje reguły serwowania DNS i porządkuje wynik tak, aby serwery autorytatywne mogły go szybko czytać.

Każde zdarzenie uruchamia zegar mierzący czas, po jakim zmiana staje się danymi używalnymi przez serwery autorytatywne. Ta praca nazywana jest buildem. Build odczytuje aktualny stan bazy, konwertuje go do formatu edge i zapisuje zmiany do Quicksilvera.

Dlaczego pełny build przestał się skalować

Pierwotny Zone Builder miał jedną cenną właściwość: nie musiał wiedzieć, dlaczego strefa się zmieniła. Odtwarzał stan docelowy z aktualnego stanu bazy. Pełny build czyta strefę i jej ustawienia, odczytuje każdy rekord, konwertuje rekordy na klucze Quicksilvera, porównuje nowe klucze z już zapisanymi, usuwa nieaktualne, zapisuje zmienione i aktualizuje metadane strefy.

Końcowy zapis zawiera tylko zmienione klucze. Ale sam build wciąż odczytuje, koduje i porównuje każdy rekord oraz trzyma całą strefę w pamięci. Dla małej strefy to tanio. Dla największych stref z dziesiątkami milionów rekordów strefa nie mieści się w pamięci w ogóle.

W 2022 roku buildy per-rekord były średnio 150 razy szybsze niż pełne buildy. Na strefie testowej z milionem rekordów były szybsze 4250 razy. Wtedy naturalnym kolejnym krokiem było zrobienie tego samego dla ustawień strefy. Jak przyznaje Cloudflare, właśnie dowiedzenie, kiedy taka operacja jest bezpieczna, zajęło najwięcej pracy.

Trudność, która nie wynika z wolumenu

Zdarzenie rekordu wskazuje, co się zmieniło. Zdarzenie strefy jest inne: może pochodzić z wielu produktów Cloudflare, nie musi mówić, dlaczego strefa się zmieniła, i może modyfikować dane współdzielone przez kilka stref o tej samej nazwie. Wybór zbyt dużej pracy marnuje moce, wybór zbyt małej może zostawić na edge nieaktualne lub błędne dane DNS.

Przykładem jest Universal SSL. Włączenie lub wyłączenie tej funkcji aktualizuje metadane i może zmienić rekordy CAA w apexie strefy, czyli w domenie bez subdomeny, na przykład example.com. Rekordy CAA informują urzędy certyfikacji, czy mogą wydać certyfikat dla domeny. Pełny build wystarczało, że wiedział, iż strefa się zmieniła. Selektywny build musi odpowiedzieć na trzy pytania: które nazwy DNS mogą się zmienić, czy mogą zmienić się współdzielone metadane lub lista publikowanych stref oraz jaki poprzedni stan trzeba usunąć z Quicksilvera.

Pięć problemów do rozwiązania

Cloudflare wymienia pięć kwestii, które trzeba było rozwiązać, aby selektywne przebudowy były poprawne:

1. Zdarzenia muszą mówić, co się zmieniło.
2. Każda zmiana musi być mapowana na najmniejszy build, który wciąż jest poprawny.
3. Buildy muszą uwzględniać dane współdzielone przez wszystkie strefy o tej samej nazwie.
4. Baza danych może się zmienić między zdarzeniem a buildem.
5. Łączenie pracy nie może gubić wiadomości Kafki.

W zakresie pierwszego problemu producent zdarzeń został zmieniony tak, aby zawierał zmienione pola i ustawienia strefy, z poprzednimi i nowymi wartościami, gdy były dostępne. Następnie każde ustawienie prześledzono przez kod generujący wynik DNS i sklasyfikowano, na co może wpływać. Nie każde zdarzenie jest tak precyzyjne: niektóre funkcje bazy aktualizują wyłącznie znacznik czasu, sygnalizując w praktyce „coś się zmieniło w strefie”. Czasem to nieszkodliwa czynność porządkowa, czasem oznacza zmianę danych w innym miejscu, którą trzeba odczytać ponownie. Takie przypadki wyglądają w zdarzeniu identycznie. Dopóki nie da się zidentyfikować wywołującego i jego celu, aktualizacja samego znacznika czasu nadal powoduje pełny build. Ta sama zasada dotyczy brakujących szczegółów, nieznanych zdarzeń i każdej zmiany, która może wpłynąć na rekordy w dowolnym miejscu strefy. Planer nigdy nie zamienia niepewności na mniejszą pracę.

Pięć typów przebudowy

Wynik w Quicksilverze ma dwie części istotne dla planera. Klucze rekordów zawierają odpowiedzi DNS dla jednej strefy i nazwy. Mniejszy, współdzielony klucz metadanych mówi serwerom autorytatywnym, jak używać strefy, w tym gdzie szukać rekordów specjalnych, takich jak serwery nazw i wildcardy. Część zdarzeń zmienia tylko klucze rekordów, inne muszą zaktualizować oba elementy.

Typ przebudowy	Zakres	Typowe zastosowanie
Resources only	Rekordy pod konkretnymi nazwami DNS, bez zmiany metadanych strefy	Zwykłe zmiany A, AAAA, TXT, CNAME
Resources and metadata	Konkretne nazwy oraz współdzielone metadane	Zmiany serwerów nazw i wildcardów
Apex and metadata	Apex strefy oraz metadane	Ustawienia, m.in. Universal SSL
Purge	Usunięcie strefy, która nie powinna być publikowana	Wycofanie strefy z publikacji
Full zone	Wszystkie rekordy	Gdy mniejszej pracy nie da się udowodnić jako bezpiecznej

Reguła jest prosta: każdy klucz zapisany przez selektywny build musi być bajt w bajt identyczny z tym, co zapisałby pełny build. Jeśli tego nie da się udowodnić, wykonywany jest pełny build. Usuwanie starego stanu działa jak przy buildach per-rekord z 2022 roku: zdarzenia rekordów obejmują rekordy usunięte i poprzednie wersje zaktualizowanych, a Zone Builder skanuje Quicksilvera pod każdą przebudowywaną nazwą i usuwa klucze, których nowy build nie zapisał.

Pełne buildy pozostają konieczne, gdy zmiana może wpłynąć na rekordy w dowolnym miejscu strefy albo gdy strefa może wymagać pierwszej publikacji. Jest jednak jeden świadomy wyjątek: powyżej ustalonego progu liczby rekordów Zone Builder nigdy nie eskaluje do pełnego buildu. Przebudowuje apex, metadane i każdą nazwę wskazaną przez zakolejkowane zdarzenia. Cloudflare przyjmuje ten kompromis, bo pełny build takich stref nie może się zakończyć, a podczas ponawiania blokuje wszystkie inne zmiany na swojej partycji Kafki. Wiele przypadków, które w innym razie wymagałyby pełnego buildu, dotyczy kilku stref współdzielących jedną nazwę, a blokady stref ograniczają to ryzyko, uniemożliwiając dodanie tej samej nazwy do innego konta. W rzadkich pozostałych przypadkach, takich jak włączenie strefy w innej sieci, pojedyncze nazwy można przebudować ręcznie.

Jedna nazwa, wiele stref

Quicksilver przechowuje klucze rekordów każdej strefy osobno. Przechowuje też jeden klucz metadanych współdzielony przez wszystkie strefy Cloudflare o danej nazwie domeny. Ten klucz działa jak katalog: mówi serwerom autorytatywnym, których wewnętrznych identyfikatorów stref mogą użyć przy odpowiadaniu na zapytanie.

Dlaczego jedna nazwa może mieć kilka identyfikatorów stref? Podczas wdrażania, wycofywania i innych zmian cyklu życia klienta może przez krótki czas istnieć kilka obiektów strefy Cloudflare dla tej samej publicznej domeny. Polityka priorytetów wybiera mały, ograniczony zbiór do publikacji. Cloudflare ilustruje to przykładem czterech wewnętrznych stref dla example.com — 101, 202, 303 i 404 — gdzie klucz metadanych wymienia 101, 202 i 303, a 404 istnieje, ale nie jest wybrana. Klient nadal widzi jedną nazwę domeny.

Zmiana rekordu TXT pod www.example.com w strefie 202 dotyczy tylko kluczy rekordów tej strefy, więc klucz metadanych się nie zmienia. Inaczej jest przy zmianach serwerów nazw i wildcardów: klucz metadanych przechowuje o nich informacje, więc takie buildy muszą zaktualizować zarówno rekordy strefy, jak i klucz metadanych.

Realne konsekwencje i scenariusze ryzyka

Opisany mechanizm jest wewnętrzny dla Cloudflare. Dla użytkowników oznacza przede wszystkim krótszy czas od zmiany do jej widoczności w sieci oraz mniejsze ryzyko, że duża zmiana ustawień zablokuje inne modyfikacje w tej samej strefie. To deklaracja producenta oparta na jego własnych pomiarach; wpis nie zawiera niezależnego audytu tych liczb.

Z perspektywy inżynierskiej warto jednak czytać ten materiał jako studium przypadku kompromisów, które pojawiają się w każdym systemie propagacji stanu. Ryzyka, które opisuje Cloudflare, są uniwersalne:

• Niepewność zamieniona w optymizm. Jeśli system nie potrafi udowodnić, że mniejsza operacja jest poprawna, a mimo to ją wykonuje, na edge mogą zostać nieaktualne dane. Cloudflare deklaruje, że w takiej sytuacji wybiera pełny build — poza strefami powyżej progu rozmiaru.
• Zdarzenia bez kontekstu. Aktualizacja samego znacznika czasu jest nieodróżnialna od realnej zmiany danych. Dopóki nie da się ustalić wywołującego, każda taka aktualizacja ciągnie za sobą ciężką pracę.
• Dane współdzielone. Klucz metadanych wspólny dla stref o tej samej nazwie oznacza, że operacja pozornie lokalna może wymagać szerszej przebudowy.
• Wyścig między zdarzeniem a buildem. Baza może się zmienić w czasie między wygenerowaniem zdarzenia a wykonaniem przebudowy, co wymusza dodatkowe zabezpieczenia.
• Utrata wiadomości przy łączeniu pracy. Agregacja zadań dla tej samej strefy musi gwarantować, że żadne zdarzenie nie zniknie.
• Blokada partycji. Nieudany lub ponawiany build blokuje inne zmiany na swojej partycji Kafki, co przy dużych strefach może kumulować opóźnienia.

Osobno trzeba potraktować świadomy wyjątek dla największych stref. Rezygnacja z pełnego buildu oznacza, że w rzadkich przypadkach wymagających odtworzenia całego stanu operator musi interweniować ręcznie. To założenie akceptowalne przy znajomości własnej infrastruktury, ale w firmie bez procedur awaryjnych byłoby źródłem długiego przestoju w propagacji.

Jak sprawdzić, czy problem dotyczy Twojej organizacji

Nie chodzi o sprawdzanie, czy „dotyczy Cię awaria Cloudflare”. Chodzi o ustalenie, czy Twoja infrastruktura DNS ma te same właściwości, które sprawiły, że pełne przebudowy przestały się skalować.

1. Policz rekordy w największych strefach i sprawdź, czy mieszczą się w pamięci procesu budującego stan.
2. Ustal, czy Twój system propagacji rozróżnia zdarzenia rekordów od zdarzeń strefy i czy zdarzenia strefy niosą informację o zakresie zmiany.
3. Sprawdź, czy istnieją ustawienia, które modyfikują rekordy w wielu miejscach strefy — certyfikaty, przekierowania, reguły — i czy są traktowane jako zmiany lokalne.
4. Zweryfikuj, czy dane metadanych są współdzielone między strefami o tej samej nazwie i jak wybierana jest strefa publikowana.
5. Przeanalizuj, co się dzieje, gdy build się nie powiedzie: czy blokuje kolejkę i na jak długo.
6. Sprawdź, czy masz procedurę ręcznej przebudowy pojedynczych nazw lub całej strefy, gdy automat nie może wykonać pełnego buildu.

Plan reakcji krok po kroku

Poniższy plan dotyczy organizacji utrzymującej własny pipeline DNS lub dużą strefę w usłudze zewnętrznej. Kolejność ma znaczenie: najpierw pomiar, potem zmiany.

1. Zinwentaryzuj zdarzenia. Wypisz wszystkie źródła zmian w strefach: API, panel, integracje, certyfikaty, reguły. Dla każdego ustal, czy zdarzenie mówi, co się zmieniło.
2. Zmierz rozkład czasu propagacji. Zbierz dane o opóźnieniu między zmianą a widocznością w serwerach autorytatywnych, z podziałem na typy zmian i rozmiar strefy.
3. Zidentyfikuj operacje ciężkie. Wskaż te, które rosną wraz z rozmiarem strefy, a nie z liczbą zmienionych rekordów.
4. Zdefiniuj regułę bezpieczeństwa. Przyjmij zasadę, że mniejsza operacja jest dopuszczalna tylko wtedy, gdy jej wynik da się wykazać jako identyczny z pełną przebudową.
5. Wprowadź klasyfikację przebudów. Zacznij od podziału na rekordy, rekordy z metadanymi, apex z metadanymi, usunięcie i pełną strefę.
6. Dodaj agregację pracy. Łącz zadania dla tej samej strefy, ale z gwarancją, że żadne zdarzenie nie zostanie utracone.
7. Ustal próg rozmiaru. Zdefiniuj, powyżej jakiej liczby rekordów pełna przebudowa jest niewykonalna, i opisz procedurę zastępczą.
8. Przygotuj procedurę ręczną. Opisz, kto i jak przebudowuje pojedyncze nazwy, gdy automat nie może wykonać pełnej operacji.
9. Wdróż stopniowo. Najpierw na strefach testowych i mniejszych produkcyjnych, z porównaniem wyników wobec pełnego buildu.
10. Monitoruj po wdrożeniu. Śledź opóźnienia, zużycie pamięci i przypadki eskalacji do pełnego buildu.

Typowe błędy

• Traktowanie liczby zdarzeń jako głównego problemu. Cloudflare wprost pisze, że wolumen nigdy nie był sednem — sednem był rodzaj pracy rosnący z rozmiarem strefy.
• Zakładanie, że zdarzenie strefy mówi, co się zmieniło. Część zdarzeń to wyłącznie znaczniki czasu bez wskazania przyczyny.
• Pomijanie danych współdzielonych. Klucz metadanych wspólny dla stref o tej samej nazwie potrafi zamienić lokalną zmianę w szerszą operację.
• Optymistyczne zawężanie zakresu. Wybór zbyt małej przebudowy bez dowodu poprawności kończy się nieaktualnymi danymi na edge.
• Brak obsługi wyścigu z bazą. Pominięcie faktu, że stan bazy może się zmienić między zdarzeniem a buildem, prowadzi do niespójności.
• Agregacja bez gwarancji dostarczenia. Łączenie pracy dla tej samej strefy musi mieć mechanizm potwierdzeń, inaczej część zmian przepada.
• Ignorowanie blokad kolejki. Ponawiany build blokuje inne zmiany na partycji, co przy dużych strefach kumuluje opóźnienia.
• Brak planu na największe strefy. Rezygnacja z pełnego buildu bez procedury ręcznej to luka operacyjna.

Działania krótkoterminowe i długoterminowe

Krótkoterminowo (dni do tygodni)

• Zbierz dane o opóźnieniach propagacji i rozmiarach stref, aby ustalić, czy problem w ogóle występuje.
• Wypisz źródła zdarzeń strefowych i oceń, które niosą wystarczający kontekst.
• Zidentyfikuj ustawienia modyfikujące rekordy w wielu miejscach strefy i oznacz je jako potencjalnie ciężkie.
• Sprawdź zachowanie systemu przy nieudanym buildzie: czas blokady kolejki i widoczność problemu w monitoringu.
• Opisz procedurę ręcznej przebudowy pojedynczych nazw.

Długoterminowo (kwartały)

• Przebuduj producentów zdarzeń tak, aby zawierały informację o zmienionych polach i ustawieniach.
• Wprowadź klasyfikację ustawień według wpływu na wynik DNS i utrzymuj ją wraz ze zmianami w kodzie.
• Zbuduj planer wybierający najmniejszą bezpieczną operację z jawną regułą eskalacji do pełnego buildu.
• Dodaj scheduler łączący pracę dla tej samej strefy z gwarancją dostarczenia wiadomości.
• Zdefiniuj próg rozmiaru strefy, powyżej którego pełny build jest wykluczony, i procedury zastępcze.
• Utrzymuj testy porównujące wynik selektywnego buildu z pełnym, klucz po kluczu.

Checklista operacyjna

• Czy znasz liczbę rekordów w największych strefach i czy mieszczą się w pamięci procesu budującego?
• Czy zdarzenia strefowe niosą informację o zmienionych polach i ustawieniach?
• Czy masz listę ustawień wpływających na rekordy w wielu miejscach strefy?
• Czy dane metadanych są współdzielone między strefami o tej samej nazwie i czy wiesz, jak wybierana jest strefa publikowana?
• Czy każda selektywna przebudowa jest weryfikowana jako identyczna z pełną?
• Czy agregacja pracy gwarantuje brak utraty zdarzeń?
• Czy masz próg rozmiaru wykluczający pełny build i procedurę ręczną?
• Czy monitorujesz opóźnienia propagacji z podziałem na typy zmian?
• Czy wiesz, jak długo nieudany build blokuje kolejkę?
• Czy masz plan komunikacji na wypadek opóźnionej propagacji zmian?

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy nie musi znać szczegółów implementacji Quicksilvera, ale powinien zadać zespołowi kilka pytań i wymagać konkretnych odpowiedzi.

Pytania do zespołu technicznego:

• Jak duże są nasze największe strefy i czy nasz pipeline propagacji ma limit rozmiaru, po którym przestaje działać?
• Które zmiany w naszym środowisku powodują ciężką pracę rosnącą wraz z rozmiarem strefy?
• Czy potrafimy udowodnić, że wąska przebudowa daje ten sam wynik co pełna?
• Co się dzieje, gdy przebudowa się nie powiedzie — jak długo blokuje inne zmiany?
• Jak szybko wykrywamy nieaktualne dane DNS na serwerach autorytatywnych?
• Czy mamy procedurę ręcznej interwencji i kto jest za nią odpowiedzialny?

Decyzje do podjęcia:

• Ustalenie akceptowalnego czasu propagacji dla poszczególnych typów zmian i powiązanie go z umowami z klientami wewnętrznymi.
• Zapewnienie budżetu na przebudowę producentów zdarzeń i klasyfikację ustawień, jeśli zespół wykaże, że obecny pipeline nie skaluje się.
• Wpisanie do procedur awaryjnych scenariusza, w którym automat nie może wykonać pełnej przebudowy.
• Wymóg testów porównawczych przed każdym wdrożeniem optymalizacji propagacji.
• Monitorowanie opóźnień propagacji jako metryki operacyjnej, a nie wyłącznie technicznej ciekawostki.

Granice odpowiedzialności: opis Cloudflare dotyczy jego własnej infrastruktury i jego pomiarów. Nie należy zakładać, że liczby — 85% mniej pamięci, o połowę krótszy czas — przełożą się na inne systemy. Warto je traktować jako punkt odniesienia i dowód, że problem jest rozwiązywalny, a nie jako gwarancję rezultatu u siebie.

Wnioski dla polskich zespołów utrzymujących DNS

Najważniejsza lekcja z materiału Cloudflare nie dotyczy konkretnej technologii, lecz sposobu myślenia o propagacji stanu. System, który odtwarza cały stan przy każdej zmianie, jest prosty i odporny na nieznane przyczyny zmian — dopóki strefa mieści się w pamięci. Gdy przestaje się mieścić, prostota zamienia się w blokadę. Przejście na selektywne przebudowy wymaga jednak czegoś więcej niż optymalizacji: wymaga dowodu, że mniejsza operacja daje identyczny wynik.

Dla zespołów w Polsce utrzymujących własne serwery autorytatywne, duże strefy dla klientów lub wewnętrzne systemy service discovery oparte na DNS, praktyczny wniosek jest taki: zanim wprowadzicie selektywne przebudowy, zainwestujcie w jakość zdarzeń i w testy porównawcze. Bez tego optymalizacja prędzej czy później skończy się nieaktualnymi danymi, a wykrycie takiego błędu w DNS bywa znacznie droższe niż utrzymanie pełnych przebudów o kilka sekund dłużej.

Drugi wniosek dotyczy danych współdzielonych. Klucz metadanych wspólny dla stref o tej samej nazwie to przypomnienie, że w DNS granica między „lokalną” i „globalną” zmianą bywa płynna. Każdy system, który publikuje stan dla wielu obiektów o wspólnym identyfikatorze, prędzej czy później stanie przed tym samym problemem.

Trzeci wniosek jest operacyjny: świadoma rezygnacja z pełnego buildu dla największych stref jest decyzją architektoniczną, nie obejściem. Wymaga procedur ręcznych, monitoringu i jasnego podziału odpowiedzialności. Cloudflare opisuje taki wyjątek wprost — i to jest prawdopodobnie najbardziej wartościowa część całego materiału, bo pokazuje, gdzie kończy się automatyzacja, a zaczyna dyscyplina operacyjna.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. How we halved DNS build delay and cut memory use by 85% (blog.cloudflare.com)

Zdjęcie wyróżniające: panumas nikhomkhai / Pexels.