Záznamy DNS: A, CNAME, SRV, TXT, MX a TTL

DNS je vyhledávací tabulka s cache před sebou a téměř všechno matoucí na něm je právě ta cache. Samotné záznamy jsou jednoduché, vytvoříš jich asi šest druhů a pravidla, o která lidé zakopávají, se dají spočítat na prstech jedné ruky: CNAME nemůže být na apexu, MX nemůže obsahovat adresu, TTL, které nastavíš dnes, se projeví až po vypršení toho starého, a „propagace“ není proces, který by se s tvou změnou dělal - jsou to cizí cache, které zastarávají vlastním tempem.

Tento článek popisuje, co který záznam dělá, jakou má přesnou podobu, jak ho resolver najde a jaké příkazy ti řeknou pravdu, když webové rozhraní tvrdí, že je záznam uložený, a nic nefunguje.

Jak vyhledávání doopravdy funguje#

Když něco potřebuje adresu pro play.example.com, zapojí se obvykle čtyři různé stroje a vědět, který z nich má tvou odpověď, je většina diagnostiky.

Stub resolver v tvém operačním systému nedělá žádnou skutečnou práci. Ptá se resolveru, který mu byl nastaven, obvykle přes DHCP, a odpověď si krátce uloží. Prohlížeče si nad tím drží vlastní cache, a proto se stránka může dál překládat na starou adresu, i když jsi vše ostatní vyprázdnil.

Rekurzivní resolver - od tvého ISP nebo veřejný, například 1.1.1.1 či 8.8.8.8 - odvádí skutečné dohledávání. Pokud už odpověď v rámci jejího TTL má, vrátí ji a nic dalšího se neděje; to je případ naprosté většiny dotazů a také důvod, proč se zdá, že tvoje změna je ignorována.

Kořenové servery a servery TLD drží delegace, ne odpovědi. Kořen ví, které servery spravují .com; servery .com vědí, které nameservery jsou autoritativní pro example.com. Ani jedny o play nikdy neslyšely.

Autoritativní nameservery drží tvou zónu: skutečné záznamy, které jsi zadal. Cokoli řeknou, je pravda. Vše výše je kopie s datem expirace.

Dva důsledky, které stojí za to si pamatovat. Změna, kterou uděláš, je na autoritativních serverech platná okamžitě - žádná fronta ani distribuční krok neexistuje. A resolver, který má odpověď v cache, se znovu nezeptá, dokud mu nevyprší TTL, ať máš pravdu jakkoli.

Typy záznamů a k čemu který slouží#

A a AAAA budeš vytvářet nejčastěji. Mapují jméno na adresu a jedno jméno jich může mít víc - klient si vybere jednu, obvykle první, kterou dostane, a pořadí se střídá. Je to nejprimitivnější forma rozkládání zátěže a nemá žádnou kontrolu stavu: pokud je jedna z adres nedostupná, část návštěvníků dostane chybu.

CNAME říká „toto jméno je ve skutečnosti tamto jméno“. Resolver, který na něj narazí, začne vyhledávání znovu u cíle. Hodí se na nasměrování www na apex nebo subdomény na jméno hostitele poskytovatele, aby mohl adresu pod tím měnit, aniž by ti to řekl. Jeho pravidlům se věnuje další kapitola, protože způsobují víc potíží než všechno ostatní dohromady.

MX míří na jméno hostitele s číslem priority, nižší je preferovanější. Dvě pravidla, která se porušují neustále: cílem musí být jméno hostitele, nikdy IP adresa, a toto jméno musí mít záznam A nebo AAAA a nesmí být samo CNAME. MX je také záznam, který nemá s herním serverem nic společného. Pošta je samostatná služba na samostatném stroji a RE:NODE e-mail vůbec nehostuje - pokud ho potřebuješ, je to jiný poskytovatel a jeho záznamy žijí vedle ostatních. Záznamy TXT, které rozhodují o tom, zda se tvé poště věří, pokrývá článek SPF, DKIM a DMARC vysvětleno.

TXT je libovolný text, a proto nasbíral tolik úkolů. Ověření vlastnictví domény pro Google, Microsoft a desítky dalších; SPF jako řetězec začínající v=spf1; veřejné klíče DKIM pod selektorem na selector._domainkey.example.com; politika DMARC na _dmarc.example.com. Pro jedno jméno smí existovat jen jeden řetězec SPF - dva jsou chyba konfigurace, která potichu zlomí autentizaci pošty, aniž by kdekoli, kam se podíváš, vznikla chyba.

SRV vtěsná službu, protokol, hostitele, port, prioritu a váhu do jednoho záznamu, a tak adresa Minecraftu skrývá nestandardní port. Jméno má pevný tvar s úvodními podtržítky, _minecraft._tcp.play, a cílem musí být jméno hostitele s vlastním záznamem A. Záznamy SRV pro Minecraft rozebírá každé pole a ukazuje příkazy dig, které dokážou, že to funguje.

CAA je ten, se kterým se lidé potkají náhodou. Uvádí, které certifikační autority smějí pro tvou doménu vystavovat, a pokud máš záznamy CAA, které neobsahují autoritu, kterou používá tvůj hosting, vystavení certifikátu selže s chybou, která CAA zmíní někde ve třetím odstavci. Většina domén záznamy CAA nemá, což znamená, že vystavovat smí jakákoli autorita; to je výchozí stav a je v pořádku.

CNAME a proč nemůže být na apexu#

Pravidlo je starší než většina internetu, na kterém ho lidé používají: jméno, které má CNAME, nesmí mít žádné jiné záznamy. Ani MX, ani TXT, ani NS. CNAME je celá odpověď a resolver ho má následovat, ne hledat cokoli dalšího.

Tvůj apex - example.com bez subdomény - musí mít záznam SOA a záznamy NS, protože právě to z něj dělá zónu. Takže CNAME mít nikdy nemůže. Každý poskytovatel DNS to vynucuje a chybová zpráva bývá nepříliš nápomocná.

Řešení v pořadí, v jakém je zkoušej:

1. Použij záznam A na apexu a nasměruj ho na adresu. Jednoduché, správné, a znamená to, že ho musíš upravit, když se adresa změní.
2. Použij ALIAS, ANAME nebo CNAME flattening svého poskytovatele. Nejsou to skutečné typy záznamů. Poskytovatel cíl přeloží za tebe a výsledek vydává jako záznam A, který na pozadí obnovuje. Cloudflare tomu říká flattening a dělá to automaticky pro CNAME na apexu; Route 53 tomu říká alias záznam; jiní tomu říkají ANAME. Funguje to dobře, ale jen u poskytovatele, který to implementuje, takže to přesun nepřežije.
3. Apex nepoužívej. Dej službu na www nebo na subdoménu a apex na ni přesměruj HTTP přesměrováním z něčeho, co umí na apexu odpovídat. www versus apex doména a přesměrování popisuje, kterou zvolit jako kanonického hostitele a proč na tom u webu záleží víc, než by se zdálo.

Druhé pravidlo plynoucí ze stejného omezení: CNAME nemůže stát vedle záznamu TXT pro stejné jméno. Pokud po tobě služba chce přidat ověřovací TXT na www a www už je CNAME, jedno z nich se musí přesunout.

TTL, cache a mýtus o propagaci#

TTL je počet sekund připojený ke každému záznamu. Říká resolveru, jak dlouho smí odpověď držet, než se zeptá znovu. To je celý mechanismus.

Past spočívá v tom, že snížení TTL se neprojeví, dokud nevyprší staré TTL. Pokud tvůj záznam seděl na 86400 a hodinu před migrací ho snížíš na 300, resolvery, které odpověď už mají, si ji nechají po zbytek svého dne bez ohledu na to. Sniž TTL aspoň o jedno staré TTL dřív, než ho potřebuješ, což obvykle znamená den předem.

Existuje druhá cache, o které většina lidí nikdy neslyší. Když se resolver zeptá na jméno, které neexistuje, uloží si i tuto odpověď „neexistuje“, na dobu převzatou ze záznamu SOA zóny, ne z žádného záznamu, který jsi vytvořil. Proto může jméno, které jsi právě vytvořil, ještě několik minut vracet NXDOMAIN, i když je vše správně - otestoval jsi ho před vytvořením a servíruje se ti tvoje vlastní negativní cache.

„Propagace“ je pro to všechno špatné slovo a dělá skutečné škody, protože naznačuje proces s ukazatelem průběhu. Nic se nepropaguje. Tvoje autoritativní servery jsou správně ve chvíli, kdy uložíš, a každá zastaralá odpověď na světě je cache někde, která odpočítává svůj vlastní časovač. Praktický rozdíl: u tvého poskytovatele není na co čekat a cizímu resolveru urychlit nemůžeš nic.

Registrátor, nameservery a DNS hosting jsou tři role#

Spousta zmatků pochází ze tří samostatných úloh, které často vykonává stejná firma.

• Registrátor je ten, od koho doménu kupuješ a kdo drží registraci. Do DNS zasahuje jedině tím, že uchovává, které nameservery jsou autoritativní.
• DNS hosting provozuje tyto nameservery a drží tvoje záznamy. Tady vytvoříš záznam A. Často je to registrátor, ale nemusí být.
• Webový nebo herní hosting provozuje server, na který záznamy míří. Bývá to jiná firma a obvykle nemá žádné rozhraní pro DNS.

RE:NODE je ta třetí role a jen ta. V panelu není žádný editor zón, žádná registrace domén a žádný e-mailový hosting - záznamy vytváříš u toho, kdo provozuje tvoje DNS, a míříš je na adresu zobrazenou na stránce serveru. Nameservery versus záznamy DNS popisuje, jak přesunout jednu ze tří rolí, aniž bys narušil zbylé dvě, což je úkol, který lidé pokazí zhruba jednou na doménu.

Změna nameserverů je jiná operace než změna záznamu a pomalejší. Delegace žije na úrovni TLD a často má TTL měřené ve dnech. Zkopíruj všechny stávající záznamy k novému poskytovateli před přepnutím, ne po něm, aby resolvery, které dorazí k jedné či druhé sadě nameserverů, dostaly během překryvu stejné odpovědi.

Záznamy pro herní server a pro web#

U herního serveru jde celá práce obvykle o dva záznamy nebo jeden.

node       300  IN  A     203.0.113.10play       300  IN  CNAME node.example.com._minecraft._tcp.play  300  IN  SRV  0 5 25571 node.example.com.

Záznam A drží adresu. CNAME jí dává přívětivější jméno, takže přesun serveru je jedna úprava na jednom místě. Záznam SRV, jen pro Minecraft Java, umožní hráčům port vynechat. Nic dalšího se nepoužívá: žádný MX, žádný TXT a žádné proxy. Pokud tvůj poskytovatel DNS nabízí HTTP proxy - Cloudflare s oranžovým obláčkem je ta, kterou potká každý - musí být vypnutá u každého záznamu, který bude používat herní klient, protože proxy zprostředkovává HTTP a HTTPS a nic jiného. Cloudflare pro weby a herní servery přesně říká, kde ta hranice leží.

U webu vypadá podoba takto:

@     3600  IN  A     203.0.113.20www   3600  IN  CNAME example.com.@     3600  IN  TXT   "v=spf1 -all"@     3600  IN  CAA   0 issue "letsencrypt.org"

@ znamená apex. Záznam SPF s -all na doméně, která neposílá poštu, je malá laskavost vůči všem, protože říká přijímajícím serverům, že nic, co se hlásí k tobě, není pravé. Záznam CAA je volitelný a má smysl ho přidat, jen když víš, která autorita ti certifikáty vystavuje.

Pořadí záleží, když je do toho zapojený certifikát. Záznam se musí překládat na server dřív, než se pokusíš o vystavení, protože ověření funguje tak, že se autorita připojí k danému jménu. Postup uvádí Tvoje doména a její certifikát a totéž pro herní případ dělá Připojení domény k herního serveru. Pokud počítáš s více servery, dej každému od začátku vlastní jméno - subdomény pro servery vysvětlují, proč je to snazší než dodatečná úprava.

Kontrola záznamu pomocí dig a nslookup#

Nikdy nepovažuj seznam záznamů u poskytovatele za důkaz, že je záznam publikovaný. Zeptej se resolveru.

# The short answer from your default resolver$ dig +short A play.example.com203.0.113.10# Ask a specific public resolver, bypassing your ISP's cache$ dig @1.1.1.1 +short A play.example.com# Ask the authoritative servers directly, removing every cache$ dig +trace play.example.com$ dig NS example.com +short# Other types$ dig +short MX example.com$ dig +short TXT _dmarc.example.com$ dig +short SRV _minecraft._tcp.play.example.com# The TTL as it is right now, counting down in a cache$ dig A play.example.com | grep -A1 'ANSWER SECTION'

Na Windows bez dig dělá totéž nslookup -type=MX example.com 1.1.1.1 a důležité je uvést resolver na konci. Dotaz na 1.1.1.1 výslovně ti řekne, co vidí cizí člověk; dotaz na tvůj výchozí ti řekne, co si zapamatoval tvůj router.

Přečíst si stavový řádek v plné odpovědi dig ušetří spoustu hádání:

• NOERROR s prázdnou odpovědí znamená, že jméno existuje, ale nemá záznam toho typu. Vytvořil jsi záznam A a ptáš se na AAAA, nebo ses ptal na SRV u jména, které má jen A.
• NXDOMAIN znamená, že jméno neexistuje. Překlep, zóna připojená dvakrát, nebo jsi uvnitř okna negativní cache.
• SERVFAIL obvykle znamená rozbitý nebo nedostupný nameserver, nebo selhání ověření DNSSEC. Téměř nikdy neznamená, že je záznam špatně.
• REFUSED znamená, že server, na který ses ptal, není autoritativní a nebude pro tebe rekurzivně dohledávat.

Vyprázdnění vlastních cache, když potřebuješ čistý test: ipconfig /flushdns na Windows, sudo dscacheutil -flushcache následované sudo killall -HUP mDNSResponder na macOS a resolvectl flush-caches na Linuxu se systemd. Chrome má vlastní na chrome://net-internals/#dns, a proto se prohlížeč může mýlit, i když je všechno ostatní v pořádku.

Proč se tvoje změna neprojevila#

Zhruba v pořadí podle toho, jak často je která odpovědí:

1. Něco pořád drží starý záznam. Tvůj resolver, router, operační systém nebo prohlížeč, tak dlouho, jak dovolovalo předchozí TTL. Otestuj proti 1.1.1.1 a uvidíš pravdu.
2. Jméno se připojilo dvakrát. Většina webových rozhraní přijímá relativní jméno, takže zadání play.example.com do pole hostitele vytvoří záznam pro play.example.com.example.com. Podívej se na existující záznam, jakou konvenci formulář používá. V seznamu záznamů to není vidět, pokud ho nečteš pozorně.
3. Upravil jsi zónu u poskytovatele, který není autoritativní. Nameservery u registrátora míří jinam, často na hosting, který jsi před měsíci opustil. dig NS example.com to rozhodne jedním řádkem.
4. Jsi uvnitř negativní cache. Zkontroloval jsi před vytvořením, dostal NXDOMAIN a resolver si to smí pamatovat po dobu minima ze SOA.
5. Záznam je správně a služba nejede. DNS mířící na zavřený port vypadá přesně jako nefunkční DNS. Port otestuj zvlášť - jak to udělat zvenčí, popisuje porty herních serverů vysvětleně.
6. Cestu blokuje proxy. Proxovaný záznam vydává adresu proxy, ne tvého serveru, což je pro HTTP správně a pro cokoli jiného osudové.

Rutina, která se tomu všemu při plánované změně vyhne, je nudná a funguje: sniž TTL o den dřív, vyčkej na vypršení starého, proveď změnu, ověř pomocí dig proti veřejnému resolveru a nech staré místo určení několik hodin běžet. Zbytek najdeš v článku Přesun serveru bez ztráty hráčů.

FAQ#

Jak dlouho trvá, než DNS změna začne fungovat?

U tvého poskytovatele okamžitě. Pro každého, kdo to jméno už vyhledával, až po dobu starého TTL. Zbrusu nové jméno, které nemá nikde nic v cache, obvykle funguje do několika sekund, a proto se vytvoření záznamu zdá rychlejší než jeho změna.

Proč nemůžu dát CNAME na kořenovou doménu?

Protože jméno s CNAME nesmí mít žádné jiné záznamy a kořen zóny musí mít záznamy SOA a NS. Použij místo toho záznam A, nebo funkci ALIAS, ANAME či CNAME flattening svého poskytovatele, pokud nějakou má.

Jaký je rozdíl mezi nameserverem a záznamem DNS?

Nameservery jsou stroje, které odpovídají na otázky o tvé doméně, nastavují se u registrátora. Záznamy jsou odpovědi, které dávají, vytvářejí se u toho, kdo tyto nameservery provozuje. Změna nameserverů přesune celou zónu; změna záznamu upraví jednu odpověď.

Potřebuju záznam MX pro svůj herní server?

Ne. Záznamy MX jsou pro poštu a nic jiného a pošta by nikdy neměla mířit na herní server. Pokud máš záznamy MX mířící na poskytovatele pošty, nech je být, zatímco měníš záznam A svého serveru.

Jaké TTL mám použít?

3600 sekund pro běžný provoz, den před plánovanou změnou snížit na 300 a potom vrátit zpět. 60 používej jen pro dynamické DNS, kde se adresa opravdu mění bez varování.

Jak zkontroluji záznam, aniž bych čekal na cache?

Zeptej se veřejného resolveru jménem pomocí dig @1.1.1.1 +short A example.com, nebo jdi rovnou na autoritativní servery pomocí dig +trace. Oba způsoby obejdou cokoli, co si zapamatovala tvoje vlastní síť.