Nový VPS, nová IP: hromadné přepsání DNS přes Cloudflare API

Kdo spravuje víc webů a serverů, dřív nebo později zažije den D: starý stroj dosluhuje a produkci je potřeba přestěhovat na nový VPS — s novou IP adresou. Zkopírovat data a rozjet služby je ta snazší půlka práce. To otravné přijde potom: přepsat DNS. Desítky A (a AAAA) záznamů napříč doménami, které pořád míří na starý origin, musí začít ukazovat na nový.

Přes klikací UI to jde taky — po jednom, u pár záznamů. Jenže u několika desítek napříč doménami je to nuda, zdržení a hlavně ideální příležitost udělat překlep zrovna u toho jednoho důležitého záznamu. Přesně tady se nám roky vyplácí, že skoro všechno provozujeme za Cloudflare — protože se to dá ovládat programově. Pojďme na to prakticky.

Co je Cloudflare a proč ho nasazujeme skoro na všechno

Zjednodušeně: Cloudflare sedí jako vrstva mezi návštěvníkem a vaším serverem. Dělá dvě věci zároveň — je autoritativní DNS pro vaše domény a reverzní proxy před originem. Návštěvník se zeptá DNS, dostane IP Cloudflare, připojí se k jeho nejbližšímu datacentru a to teprve sáhne na váš origin server. Z téhle architektury plyne většina přínosů.

DNS hosting

Rychlé a spolehlivé anycastové DNS zdarma. Zóna se spravuje přehledně, změny se propisují prakticky okamžitě a nemusíte si sami provozovat žádné nameservery. I kdybyste nic jiného z Cloudflare nevyužili, tohle samo o sobě stojí za to.

Proxy (oranžový mrak)

Když u záznamu zapnete proxy (oranžový mrak), provoz teče přes Cloudflare. To má tři důsledky: skryje se IP vašeho originu (útočník nevidí, kam vlastně mířit), Cloudflare za vás terminuje TLS a cachuje statiku blíž k uživateli. Samotné skrytí originu je bezpečnostní výhra zdarma.

Bezpečnost

Na všech plánech včetně free běží neměřená ochrana proti DDoS. V placených plánech přidáte pokročilá pravidla WAF, rate limiting a bot ochranu. Ale i na free platí, že když nikdo nezná vaši origin IP, půlka útoků nemá kam.

HTTPS zdarma

Pro proxovaná jména vystaví Cloudflare automaticky Universal SSL certifikát — pokrývá apex doménu i první úroveň subdomén. Žádný certbot, žádné hlídání obnovy. Prostě to má platný cert.

Výkon

CDN cache blíž k uživateli, HTTP/2 i HTTP/3 (QUIC přes UDP) a Brotli komprese. Statika lítá z edge, origin má klid.

Štědrý free tier

Pro velkou část webů — prezentace, blogy, menší aplikace — bezplatný plán bohatě stačí. Platí se, až když opravdu potřebujete pokročilé věci.

Proč zrovna my

Spravujeme víc projektů na víc serverech. Cloudflare nám dává jedno místo pro DNS, bezpečnost i výkon, sjednocuje SSL napříč doménami a schová originy. Ten hlavní důvod, proč ho máme rádi u správy více věcí najednou, je ale tenhle: dá se ovládat přes API. Rutinní věci pak neděláme ručně po jednom. A migrace serveru je přesně taková rutinní věc, která ručně bolí.

Jádro: jak nám API zachránilo migraci na nový VPS

Situace z praxe: stěhujeme weby na nový VPS s novou IP. Všechny A záznamy, které mířily na starý origin (řekněme 192.0.2.10), musí začít ukazovat na nový (203.0.113.10). Cloudflare má plnohodnotné REST API v4 (plus Terraform provider a oficiální knihovny), takže to celé uděláme skriptem.

1. Nejdřív API token — ne Global API Key

V dashboardu My Profile → API Tokens → Create Token si vytvořte token s minimálním oprávněním:

• Permissions: Zone → DNS → Edit
• Zone Resources: omezeno jen na konkrétní zóny, kterých se migrace týká

Nikdy nepoužívejte starý Global API Key — ten má práva na celý účet a nedá se zúžit. Token navíc jde časově omezit a svázat s konkrétní IP.

Hned po vytvoření si ověřte, že token žije:

export CF_TOKEN="vas-cloudflare-token"
curl -s "https://api.cloudflare.com/client/v4/user/tokens/verify" \
  -H "Authorization: Bearer $CF_TOKEN" | jq -r '.result.status'

Vrátí-li se active, jdeme dál.

2. Předem snižte TTL

Krok, na který se zapomíná. U DNS-only záznamů (šedý mrak) vidí resolvery přímo vaši origin IP a drží si ji po dobu TTL. Když máte TTL na hodiny, po přepnutí budou uživatelé ještě dlouho chodit na starý server. Proto den dopředu snižte TTL na 60–300 s, ať se změna propíše rychle.

U proxovaných záznamů (oranžový mrak) tohle řešit nemusíte — navenek se stejně vidí IP Cloudflare s jeho vlastní krátkou TTL a origin přepnete jen změnou pole content, což Cloudflare začne směrovat prakticky hned. (Proxovaný záznam má TTL stejně vynucené na auto — v API je to hodnota 1.)

3. Zálohujte si zónu

Před jakýmkoli hromadným zásahem si vyexportujte současný stav. Cloudflare umí zónu vypsat jako BIND soubor:

curl -s "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records/export" \
  -H "Authorization: Bearer $CF_TOKEN" -o zaloha-zony.txt

Když se něco pokazí, máte se kam vrátit.

4. Dry-run: nejdřív jen vypsat, co by se změnilo

Klíčové endpointy jsou dva: GET /zones vylistuje zóny a GET /zones/{zone_id}/dns_records s filtrem type=A&content=... najde záznamy se starou IP. Filtr content dělá ve výchozím stavu přesnou shodu hodnoty (navíc case-insensitive), takže dostanete rovnou jen to, co chcete přepsat. Novější API umí i modifikátory content.contains, content.startswith a content.endswith; holý content=IP ale dál platí a odpovídá přesné shodě (content.exact).

Tenhle skript nic nemění — jen ukáže, čeho by se to týkalo:

#!/usr/bin/env bash
set -euo pipefail
: "${CF_TOKEN:?Chybí CF_TOKEN}"

API="https://api.cloudflare.com/client/v4"
OLD_IP="192.0.2.10"
NEW_IP="203.0.113.10"
auth=(-H "Authorization: Bearer $CF_TOKEN" -H "Content-Type: application/json")

# vylistovat všechny zóny
zones=$(curl -s "${auth[@]}" "$API/zones?per_page=50" | jq -r '.result[].id')

for zone_id in $zones; do
  # najít A záznamy se starou IP
  curl -s "${auth[@]}" \
    "$API/zones/$zone_id/dns_records?type=A&content=$OLD_IP&per_page=100" \
  | jq -r --arg z "$zone_id" \
      '.result[] | "[dry-run] \($z) \(.name) \(.content) proxied=\(.proxied) id=\(.id)"'
done

Výstup si v klidu přečtěte. Sedí počty? Nejsou tam záznamy, které přepsat nechcete? Teprve pak pustíte ostrou verzi.

Pozor na stránkování: příklady pro přehlednost čtou jen první stránku výsledků. Když máte víc zón nebo víc shod v jedné zóně, než je nastavené per_page, dolistujte přes parametr page — ať vám část záznamů tiše nepropadne.

5. Hromadný přepis

Na změnu jednoho záznamu použijeme PATCH — ten dělá částečnou úpravu, takže pošleme jen nové content a proxied stav i TTL zůstanou beze změny. To je přesně to, co chceme. Kdybychom použili PUT, museli bychom poslat celé tělo záznamu a snadno bychom si přepsali třeba proxied na špatnou hodnotu.

#!/usr/bin/env bash
set -euo pipefail
: "${CF_TOKEN:?Chybí CF_TOKEN}"

API="https://api.cloudflare.com/client/v4"
OLD_IP="192.0.2.10"
NEW_IP="203.0.113.10"
auth=(-H "Authorization: Bearer $CF_TOKEN" -H "Content-Type: application/json")

zones=$(curl -s "${auth[@]}" "$API/zones?per_page=50" | jq -r '.result[].id')

for zone_id in $zones; do
  records=$(curl -s "${auth[@]}" \
    "$API/zones/$zone_id/dns_records?type=A&content=$OLD_IP&per_page=100" \
    | jq -r '.result[].id')

  for rec_id in $records; do
    ok=$(curl -s -X PATCH "${auth[@]}" \
      "$API/zones/$zone_id/dns_records/$rec_id" \
      --data "{\"content\":\"$NEW_IP\"}" | jq -r '.success')
    echo "$zone_id / $rec_id -> $ok"
  done
done

Pro AAAA záznamy stačí totéž s type=AAAA a IPv6 hodnotami (pro dokumentaci třeba 2001:db8::10 → 2001:db8:1::10).

Máte-li opravdu hodně záznamů, jde použít batch endpoint POST /zones/{zone_id}/dns_records/batch, který zvládne víc úprav v jednom volání:

{
  "patches": [
    { "id": "{record_id}", "content": "203.0.113.10" }
  ]
}

Celá migrace DNS, která by v UI znamenala hodinu klikání, je hotová během chvíle. A protože je to skript, je opakovatelná i auditovatelná — a rollback je triviální: prohodíte OLD_IP a NEW_IP a pustíte znovu.

Proxied vs DNS-only: na co nezapomenout

Ještě jednou to zdůrazním, protože se v tom lidé pletou. U proxovaných záznamů (oranžový mrak) navenek pořád svítí IP Cloudflare — content je origin adresa, kterou používá jen Cloudflare k tomu, kam poslat provoz. Přesto ji musíte mít správně, jinak proxy směřuje na mrtvý server. U DNS-only (šedý mrak) je content to, co uvidí celý svět. V obou případech přepisujete content; jen si u DNS-only pohlídejte tu TTL z kroku 2.

Bezpečnost a opatrnost u API

Pár pravidel, která u nás platí bez výjimky:

• Token nikdy do gitu ani do veřejného kódu. Držte ho v proměnné prostředí, v .env mimo repozitář, nebo v secret manageru.
• Minimální rozsah — jen Zone → DNS → Edit a jen na zóny, kterých se to týká. Žádný Global API Key.
• Nejdřív jedna zóna. Otestujte celý postup na jediné doméně, ověřte výsledek, teprve pak to pusťte na všechny.
• Záloha před zásahem — export zóny z kroku 3.
• Vždycky dry-run. Nejdřív vypsat, co se stane, přečíst to, pak teprve měnit.

Nic z toho není zdržení. Je to pět minut, které vás jednou podrží.

Závěr

Cloudflare u nás není „ještě jedna služba navíc". Je to DNS, bezpečnost a výkon na jednom místě — a hlavně je to programovatelné. Díky API se z migrace, která by ručně znamenala hodiny klikání a reálné riziko překlepu v produkci, stane rutina na pár minut: token, snížit TTL, zálohovat, dry-run, přepsat. Opakovatelně, auditovatelně a s rollbackem po ruce.

A přesně o tomhle je moje řemeslo — weby a aplikace, které fungují, na serverech, které nespadnou. I ve chvíli, kdy se ten server zrovna mění za nový.