Slovník pojmů

DNS

DNS převádí lidsky čitelná jména na informace potřebné pro síťové spojení. Je hierarchické, distribuované a cacheované; změna záznamu se proto neprojeví všude okamžitě.

Stručná definice

Telefonní seznam internetu, ne webový server ani URL.

DNS ukládá záznamy pro domény ve stromu zón. Prohlížeč, aplikace nebo e-mailový server se nejprve zeptá svého resolveru na jméno, například shop.example.cz. Resolver může odpověď vrátit z cache, nebo postupně zjistí autoritativní nameserver zóny, který je zdrojem aktuálního záznamu.

DNS řeší jméno a typ záznamu, nikoli URL cestu, HTTP metodu nebo obsah API. Záznam A či AAAA dá klientovi adresu, na kterou se má připojit; teprve URL určí schéma a cestu a webový server vybere aplikaci. DNS také sám nevydává TLS certifikát ani neověřuje uživatele.

K čemu se používá

Směrování webu, API, e-mailu a ověřovacích záznamů

Jedna doména může mít různé DNS záznamy pro web, API, poštu i technické ověření vlastnictví.

A a AAAA záznamy pro IPv4 a IPv6 adresu webu, API nebo jiné služby
CNAME alias pro subdoménu, která má následovat jiné kanonické jméno
MX záznamy určující servery přijímající e-mail pro doménu
TXT záznamy pro SPF, DKIM, DMARC, ověření domény nebo bezpečnostní politiky
delegace subdomény a oddělená správa DNS zóny pro jiný tým či poskytovatele

Praktický příklad

Web, API a e-mail pod jednou doménou

Doména example.cz má web na www, API na api a poštu směrovanou přes MX. API i web mohou mít rozdílné A či AAAA záznamy, ale obě služby po navázání spojení stále potřebují platný TLS certifikát a správný virtual host. TXT záznam pro SPF pomáhá příjemcům vyhodnotit, odkud smí doména odesílat e-mail.

Přesun API na nový load balancer začne snížením TTL s předstihem a ověřením nového cíle. Po změně se kontroluje autoritativní odpověď, reálné HTTP volání i to, zda starý cíl zůstává dost dlouho pro resolvery s dříve uloženou adresou.

api.example.cz.   300  IN  A     203.0.113.20
www.example.cz.   300  IN  CNAME web.example.net.
example.cz.       300  IN  MX    10 mail.example.cz.
example.cz.       300  IN  TXT   "v=spf1 include:mail.example.net -all"

Jak funguje

Od jména hostitele k autoritativní odpovědi

Resolver skládá odpověď z hierarchie DNS a ukládá ji podle TTL.

Klient požádá resolver Operační systém nebo aplikace se zeptá nastaveného rekurzivního resolveru na záznam, například A pro api.example.cz.
Cache se použije, pokud platí Resolver může vrátit dříve získanou odpověď, dokud nevyprší její TTL. To snižuje latenci i zátěž autoritativních serverů.
Kořen, TLD a delegace Při miss resolver postupně zjistí nameservery pro nejvyšší doménu a pak pro konkrétní zónu. Neprochází celý internet, následuje delegované autority.
Autoritativní server odpoví Server zóny vrátí platný záznam a TTL, případně odpověď, že jméno neexistuje. Resolver ji na omezenou dobu uloží.
Klient naváže službu S IP adresou může klient spojit HTTP, SMTP nebo jiný protokol. Následné TLS, Host hlavička a aplikace jsou další samostatné vrstvy.

Důležité záznamy

Typ záznamu určuje, jakou informaci DNS vrací.

Záznamy se nemají nahrazovat náhodnými aliasy. Každý typ má jiný účel a provozní dopad.

A a AAAA

A obsahuje IPv4 adresu, AAAA IPv6 adresu. Záznam neříká, jaký web nebo aplikace odpoví; to vyhodnotí až služba na dané adrese.

CNAME

CNAME dělá alias celého jména na jiné kanonické jméno. Není to obecný přesměrovací mechanismus HTTP a v jednom jménu nelze bez omezení míchat CNAME s jinými datovými záznamy.

MX

MX uvádí cíle pro doručení e-mailu a jejich prioritu. Nastavení webu přes A záznam automaticky nenastaví příjem ani odesílání pošty.

TXT

TXT nese textové údaje používané například pro SPF, DKIM, DMARC či ověření domény. Jeho obsah má přesný formát daný příslušným standardem, není to volná poznámka.

TTL a propagace

TTL říká, jak dlouho může resolver odpověď cacheovat. Změna autoritativního záznamu je hned platná na autoritě, ale klienti mohou mít starou odpověď až do vypršení cache.

Vztah k ostatním pojmům

DNS poskytuje síťový cíl, ostatní vrstvy řeší obsah a bezpečnost.

Při chybě je důležité rozlišit, zda nefunguje překlad jména, TLS, reverse proxy nebo samotná aplikace.

URL: URL obsahuje hostitele, který DNS obvykle přeloží. Cesta, query a fragment nejsou součástí DNS.
nginx: Po překladu adresy přijme nginx HTTP spojení a podle Host hlavičky směruje doménu na správnou aplikaci.
Docker: Interní jména služeb v Docker síti nejsou totéž co veřejná DNS zóna. Veřejný DNS záznam typicky ukazuje na proxy nebo load balancer.
API a e-mail: API potřebuje jméno hostitele a TLS, e-mailová infrastruktura vedle MX pracuje se SPF, DKIM a DMARC záznamy.

Výhody a omezení

Distribuce zvyšuje odolnost, cache zpomaluje změnu.

Přínosy

lidsky čitelná jména nezávislá na konkrétní IP adrese
delegace dovoluje oddělit správu zón a služeb
TTL snižuje zatížení resolverů a urychluje opakované překlady
různé typy záznamů propojují web, e-mail a ověřovací procesy

Rizika a chyby

vysoké TTL prodlouží přechod na novou infrastrukturu nebo opravu chyby
nízké TTL bez důvodu zvyšuje závislost na resolverech a provozní šum
CNAME není HTTP redirect a nevyřeší změnu URL cesty
špatná delegace nameserverů může odpojit celou doménu
neověřená změna MX nebo TXT záznamu může narušit doručitelnost e-mailu

Hranice použití

DNS plánovat jako součást změny infrastruktury, ne až po ní.

Před přesunem aplikace na novou IP či proxy je vhodné znát současné TTL, zachovat starý cíl po přechodnou dobu a ověřit odpověď z autoritativních nameserverů. Pouhá změna záznamu v jednom administrátorském rozhraní neznamená, že všichni uživatelé okamžitě dostávají novou adresu. Pro kritickou změnu patří do plánu monitoring, rollback a ověření webu i e-mailu.

DNS není správné místo pro aplikační logiku. Nemá vybírat konkrétního zákazníka, skrývat nefunkční API ani nahrazovat autorizaci. Rozdělení provozu podle země, health check nebo release strategie obvykle potřebuje load balancer, reverse proxy či aplikaci s vlastními pravidly.

Na co myslet

Změny ověřovat na autoritě i z pohledu skutečného klienta.

DNS je sdílená provozní závislost; jeho konfigurace má být dohledatelná stejně jako změna aplikace.

evidovat, kdo spravuje registraci domény, nameservery a jednotlivé zóny
před migrací upravit TTL s předstihem a zachovat možnost návratu na původní cíl
ověřit A, AAAA, CNAME, MX a TXT přes správný typ dotazu, ne jen načtením webu v prohlížeči
oddělit veřejné DNS od interního pojmenování služeb a omezit přístup k DNS administraci
pro e-mail měnit SPF, DKIM a DMARC s ohledem na současné odesílatele a monitorovat doručitelnost
neodvozovat funkčnost aplikace jen z DNS odpovědi; kontrolovat také TLS, HTTP stav a logy služby

Časté otázky

Jak DNS ovlivňuje dostupnost služby

Je DNS totéž co URL?

Ne. DNS překládá jméno hostitele na záznamy. URL navíc obsahuje schéma, cestu, query a další části potřebné pro adresování konkrétního zdroje.

Proč se změna DNS neprojeví hned?

Resolver nebo klient může používat dříve uloženou odpověď až do vypršení TTL. Je potřeba rozlišit okamžitou změnu na autoritativním serveru a postupné vypršení cache v síti.

Je CNAME přesměrování webu?

Není. CNAME je DNS alias pro jméno. Přesměrování z jedné HTTP URL na jinou cestu nebo doménu řeší webový server přes HTTP redirect.

Stačí A záznam pro e-mail?

Ne. Příjem e-mailu používá MX záznamy a doručitelnost odesílání běžně vyžaduje správně nastavené SPF, DKIM a DMARC.

Jak řeším provozní hranice aplikace

Domény, DNS, e-mail a HTTP konfiguraci beru jako jeden navazující provozní celek.

U backendů a integračních služeb řeším dostupnost, bezpečnou změnu infrastruktury a dohledatelnost problému napříč veřejnou i interní sítí.

Jak přemýšlím o architektuře aplikací Nezávazně probrat projekt