← Všechny produkty

DNS

Cloudflare poskytuje autoritativní DNS ze své anycastové sítě, včetně podepisování DNSSEC, CNAME flattening a řízení proxy na úrovni jednotlivých záznamů. Tato stránka popisuje průběh překladu, model záznamů, postup DNSSEC, limity a dostupnost podle plánu.

Řízení dokumentu

Dana
Technická redaktorka, Integrity Czech Republic s.r.o.

Přehled

Autoritativní DNS odpovídá na dotazy pro danou zónu. Je nezbytnou součástí každého připojení k doméně, ať už jde o web, e-mail nebo komunikaci mezi zařízeními. Pokud autoritativní DNS selže, doména se stane nedostupnou bez ohledu na stav serverů, které za ní stojí.

Cloudflare poskytuje autoritativní DNS ze své anycastové sítě. Podle Cloudflare její síť funguje ve 348 městech (https://www.cloudflare.com/network/, staženo 2026-08-28).

Zveřejněné žebříčky výkonu resolverů sestavují třetí strany na základě vlastních metod a vzorků měření. Tato stránka neuvádí žádné pořadí ani medián doby odezvy, protože taková hodnota má smysl jedině společně s názvem benchmarku, datem měření a místy měření. Pokud je doba odezvy vaším požadavkem, změřte ji na vlastním vzorku klientů.

Cloudflare DNS je zároveň vstupním bodem pro zbytek platformy. Záznam může být buď DNS-only, kdy Cloudflare vrací vámi nakonfigurovanou adresu, nebo proxovaný, kdy Cloudflare vrací své vlastní adresy a provoz daného názvu hostitele prochází sítí Cloudflare.

Architektura

Nameservery Cloudflare sdílejí sadu IP adres, které Cloudflare ze svých datových center oznamuje pomocí anycastu. Resolver, který se na tyto adresy dotazuje, se dostane do nejbližší lokality, která je oznamuje. Když některá lokalita přestane být dostupná, dotazy se přesměrují jinam běžným chováním BGP, ne mechanismem DNS failoveru.

Změny zóny provedené v dashboardu nebo přes API se distribuují do obslužné infrastruktury. Při plánování rozlišujte dvě věci, které se často zaměňují:

• Změna autoritativní odpovědi. Odpověď, kterou Cloudflare vrací na nový dotaz, se změní krátce po uložení úpravy.
• Změna viditelná pro resolver. Navazující rekurzivní resolvery nadále poskytují předchozí odpověď, dokud v jejich cache nevyprší TTL záznamu. Některé resolvery a klientské stacky uchovávají odpovědi i po vypršení TTL.

Doba, za kterou se změna projeví u všech klientů, je tedy omezená předchozí hodnotou TTL, nikoli rychlostí aktualizace na autoritativním serveru. Přechod je proto potřeba naplánovat podle TTL, které platilo před změnou.

Zónu lze nastavit několika způsoby. Úplné nastavení dělá z Cloudflare autoritativní zdroj pomocí delegace jmenných serverů u registrátora. Částečné nastavení (CNAME) ponechává autoritu u jiného poskytovatele a deleguje jednotlivé názvy hostitelů. U sekundárního DNS je Cloudflare pomocí přenosů zóny sekundárním serverem pro externí primární server, nebo naopak.

Možnosti

Model konfigurace

Zóna obsahuje záznamy, z nichž každý má typ, název, obsah, TTL a u adresních a CNAME záznamů také stav proxy. Je-li záznam proxovaný, jeho TTL spravuje Cloudflare a vrácený obsah je adresa Cloudflare, nikoli nastavená adresa origin serveru.

Mezi podporované typy záznamů patří běžné typy používané pro web a e-mail i typy sloužící k objevování služeb a ověřování. Podpora je široká, ale ne univerzální; konkrétní typ si ověřte v referenčním přehledu podporovaných typů záznamů.

Klíčová nastavení ovlivňující chování při překladu DNS:

• TTL. Konfigurovatelné pro každý záznam v režimu DNS only. Určuje, jak dlouho mohou resolvery odpověď cachovat, a tedy i to, za jak dlouho se změna projeví všude.
• Stav proxy. Určuje, zda je název hostitele obsluhován prostřednictvím sítě Cloudflare. Poštovní záznamy a další záznamy služeb mimo HTTP musí zůstat DNS-only.
• CNAME flattening. Nastavuje se jen pro apex, nebo pro všechny záznamy CNAME v zóně.
• DNSSEC. Zapíná se pro každou zónu zvlášť a vytváří hodnoty záznamu DS, které je potřeba zveřejnit u registrátora.

Záznamy lze spravovat přes dashboard, API, Terraform provider nebo importem a exportem souboru zóny. Pokud zóny spravujete jako kód, udržujte soubor zóny ve verzovacím systému, aby měl přechod kontrolovatelný diff a vratný stav.

Limity a omezení

• Viditelnost změny je omezena hodnotou TTL platnou před změnou a chováním mezipaměti navazujících resolverů a klientských stacků. Rychlá aktualizace autoritativní odpovědi na straně Cloudflare toto omezení nezkracuje.
• Počet záznamů na zónu a počet zón na účet je omezený a liší se podle plánu. Aktuální hodnoty si ověřte na https://developers.cloudflare.com/dns/manage-dns-records/ (staženo 2026-08-28) před importem velké zóny.
• Podporovaných typů záznamů je celá řada, ale ne všechny jsou univerzální. Neobvyklý typ si vždy ověřte podle https://developers.cloudflare.com/dns/manage-dns-records/ (staženo 2026-08-28) před migrací.
• Proxované záznamy vracejí adresy Cloudflare. Pokud externí systém ověřuje vaši origin adresu podle DNS nebo se připojuje k hostname na jiném než HTTP portu, musí použít záznam typu DNS-only.
• DNSSEC vyžaduje záznam DS u registrátora. Cloudflare přidává záznam DS automaticky jen u domén využívajících Cloudflare Registrar a u domén .ch a .cz; u ostatních registrátorů ho musí zveřejnit provozovatel domény (https://developers.cloudflare.com/dns/dnssec/, staženo 2026-08-28).
• Sekundární DNS a konfigurace s více poskytovateli jsou funkce dostupné v plánu Enterprise.
• Failover založený na kontrolách stavu není součástí DNS. Vyžaduje samostatně zpoplatněný produkt Load Balancing.
• Doba uchování dat Analytics a protokolů auditu se liší podle plánu.

Dostupnost podle tarifu

Nasazení

Předpoklady.

• Exportujte aktuální zónu od stávajícího poskytovatele a zaznamenejte si každý záznam, včetně těch, které vytvořily třetí strany kvůli ověření domény, autentizaci e-mailu a vydávání certifikátů.
• Zaznamenejte si aktuální hodnoty TTL, protože určují časové okno pro přechod.
• Zjistěte kompletní konfiguraci pošty: MX, SPF, selektory DKIM, DMARC a případné ověřovací záznamy specifické pro daného poskytovatele.
• Identifikujte názvy hostitelů, které musí zůstat v režimu DNS-only, včetně poštovních serverů, koncových bodů VPN a služeb na portech mimo HTTP.
• Zkontrolujte, zda je DNSSEC pro doménu u registrátora aktuálně povoleno.
• Ověřte přístup k registrátorovi a možnost měnit name servery a DS záznamy v plánovaném časovém okně.

Postupné ověřování. Importujte zónu do Cloudflare bez změny delegování. U každého záznamu se dotazujte přímo nameserverů Cloudflare a porovnejte odpovědi se stávajícími produkčními odpověďmi, záznam po záznamu. Rozdíly vyřešte, než budete pokračovat. Pokud je k dispozici částečné nastavení (CNAME), ověřte s ním nejdřív na produkčním provozu jen část názvů hostitelů.

Konfigurace.

1. Stav proxy nastavujte u každého záznamu cíleně. Poštovní záznamy a záznamy služeb mimo HTTP ponechejte jako DNS-only.
2. Snižte TTL u stávajícího poskytovatele na krátkou hodnotu alespoň jeden interval předchozího TTL před přechodem, aby staré hodnoty vypršely z mezipamětí resolverů ještě před změnou delegace.
3. Zdokumentujte postup pro vrácení změn: předchozí sadu jmenných serverů, exportovaný soubor zóny a kroky u registrátora potřebné k jejich obnovení.
4. Ověřte, že je DNSSEC u registrátora vypnutý a že DS záznam už není publikovaný v nadřazené zóně.

Přepnutí provozu. Změňte nameservery u registrátora v dohodnutém časovém okně. Zónu u předchozího poskytovatele ponechte naplněnou a funkční po dobu předchozího TTL plus rezervu, aby resolvery, které stále používají staré delegování, dostávaly správné odpovědi.

Ověření.

• U každého kritického záznamu se dotažte nových jmenných serverů i několika veřejných resolverů a porovnejte výsledky s očekávanými hodnotami.
• Odešlete a přijměte testovací e-mail a v hlavičkách zprávy zkontrolujte výsledky vyhodnocení SPF, DKIM a DMARC.
• Ověřte, že postupy vydávání a obnovy certifikátů závislé na ověření přes DNS stále fungují.
• Ověřte, že ověřovací záznamy domény od třetích stran lze stále přeložit přes DNS.
• DNSSEC v Cloudflare povolte a vygenerovaný záznam DS zveřejněte u registrátora teprve poté, co potvrdíte správnost překladu jmen. Před uzavřením změny ověřte, že řetězec důvěry prochází ověřením bez chyb.

Vrácení změn. Obnovte předchozí nameservery u registrátora. Pokud jste již povolili DNSSEC u Cloudflare, odstraňte záznam DS u registrátora a před obnovením předchozí delegace počkejte, až zmizí z nadřazené zóny, jinak ověřující resolvery selžou. I rollback je omezený TTL, proto držte TTL nízké, dokud si neověříte, že je migrace stabilní.

Provozní hlediska

Záznamy spravujte pokud možno jako kód. Změny DNS mají velký dopad, snadno se provedou, ale zpětně se obtížně kontrolují. Zóna ve verzovacím systému s revizí diffu tomuto typu incidentů předchází.

Povolte protokolování auditu a upozorňování na změny záznamů a omezte, kdo smí u registrátora měnit nameservery a záznamy DS. Přístup k registrátorovi dává nad doménou nejvyšší kontrolu a často stojí mimo běžný proces změn, kterým prochází zbytek infrastruktury.

Hodnoty TTL nastavujte cíleně. Dlouhé TTL zvyšují odolnost vůči problémům v řídicí rovině, ale prodlužují dobu potřebnou pro každou plánovanou změnu. Krátké TTL umožňují rychlé změny, zvyšují ale objem dotazů a zkracují dobu, po kterou vás při výpadku chrání zastaralá odpověď z mezipaměti.

Překlad sledujte externě z několika různých sítí, nespoléhejte pouze na interní kontroly, a stav validace DNSSEC sledujte samostatně: problém s podpisem nebo klíčem se u validujících resolverů projeví jako úplný výpadek, zatímco nevalidující resolvery budou fungovat dál.

Režimy selhání, se kterými je třeba počítat: záznam DS ponechaný beze změny při přechodu mezi poskytovateli, vypršelý podpis DNSSEC, proxovaný záznam nastavený na e-mailovém hostiteli a automatizační skript, který znovu vytvoří záznam se špatným stavem proxy.

Známá úskalí

• U většiny registrátorů nejde aktivace DNSSEC o jediný krok. Cloudflare vygeneruje hodnoty záznamu DS, ale jejich zveřejnění u registrátora je odpovědností provozovatele, s výjimkou domén u Cloudflare Registrar a domén .ch a .cz.
• Před změnou jmenného serveru je nutné deaktivovat DNSSEC a odstranit záznam DS. Po změně je pak potřeba DNSSEC znovu aktivovat.
• DNSSEC chrání klienty, jejichž resolvery provádějí validaci. Klientům s nevalidujícími resolvery DNSSEC žádnou ochranu nepřináší, takže riziko podvržených odpovědí snižuje, ale zcela neodstraňuje.
• Rychlé aktualizace na autoritativním serveru nezkracují navazující cachování omezené hodnotou TTL. Přechody proto plánujte podle předchozí hodnoty TTL.
• Anycast odstraňuje závislost na jediné lokalitě při obsluze dotazů, chyba řídicí roviny nebo konfigurace ale zůstává společným způsobem selhání. Proti tomu pomáhá revize změn a externí monitoring; architektura sama tomu nezabrání.
• Proxování záznamu změní odpověď, kterou dostane každý klient. Systémy, které očekávají origin adresu, včetně některých konfigurací monitoringu a allow-listů, přestanou fungovat.
• Podpora typů záznamů je široká, ale ne úplná; před migrací si neobvyklé typy ověřte.

Interoperabilita

Přepínač proxy je bodem napojení pro CDN, WAF, DDoS ochranu, Bot Management a Workers routes. Aby se tyto produkty vztahovaly na jeho provoz, musí být název hostitele proxovaný.

Cloudflare Load Balancing funguje nad úrovní DNS a poskytuje směrování na základě kontrol stavu. Konfiguruje se samostatně a může cílit jak na proxované, tak na DNS-only koncové body.

Vydání certifikátu pro proxované názvy hostitelů závisí na ověření přes DNS, takže konfigurace DNS a životní cyklus certifikátu jsou vzájemně provázané. Po každé úpravě zóny ověřte, že ověřovací záznamy zůstávají zachovány.

Email Security, Email Routing a e-mailové platformy třetích stran závisí na záznamech MX v režimu pouze DNS a na záznamech TXT pro SPF, DKIM a DMARC. Tyto záznamy nejsou ovlivněny stavem proxy a nesmí být proxovány.

S Cloudflare Registrar se DNSSEC řeší jinak: záznamy DS se odesílají automaticky.

Časté dotazy

Jak dlouho trvá, než se změna záznamu projeví u všech klientů? Až do doby TTL, které platilo před změnou, plus jakékoli další cachování navazujícími resolvery a klientskými stacky. TTL snižte s předstihem před plánovanou změnou.

Je při přechodu s DNS na Cloudflare nutné používat i CDN a bezpečnostní produkty? Ne. Záznamy lze nastavit na DNS-only, v takovém případě Cloudflare funguje pouze jako autoritativní DNS. Proxování lze později povolit pro jednotlivé názvy hostitelů.

Co je potřeba k povolení DNSSEC? Povolte DNSSEC pro zónu v Cloudflare a poté zveřejněte vygenerovaný záznam DS u registrátora. Cloudflare přidává záznam DS automaticky pouze pro domény u Cloudflare Registrar a pro domény .ch a .cz.

Zdroje

• https://developers.cloudflare.com/dns/, staženo 2026-08-28.
• https://developers.cloudflare.com/dns/dnssec/, staženo 2026-08-28.
• https://developers.cloudflare.com/dns/zone-setups/, staženo 2026-08-28.
• https://developers.cloudflare.com/dns/cname-flattening/, staženo 2026-08-28.
• https://developers.cloudflare.com/dns/manage-dns-records/, staženo 2026-08-28.
• https://developers.cloudflare.com/dns/proxy-status/, staženo 2026-08-28.
• https://developers.cloudflare.com/load-balancing/, staženo 2026-08-28.
• https://www.cloudflare.com/network/, staženo 2026-08-28.

Snímek obsahu: 2026-08-28.

Changelog