TXT záznamy a ověření domény

Modul 4: Záznamy pro e-mail · Doba čtení: 7 min

Cíl lekce: Po této lekci dokážete vytvořit TXT záznam pro ověření domény u nějaké služby a budete vědět, kdy může vedle sebe existovat více TXT záznamů a kdy ne.

Klíčové pojmy: TXT záznam, ověřovací kód, název se podtržítkem, uvozovky, textové úseky o 255 znacích, SPF/DMARC jako zvláštní TXT záznamy

Vzkaz ve Vaší DNS

TXT záznam je nejjednodušší záznam, jaký existuje: kousek textu u určitého názvu. DNS s ním samotná nic nedělá. Je určen pro jiné programy, které si tento text přijdou přečíst.

Proto je TXT oblíbeným záznamem služeb, které chtějí vědět, zda doména skutečně patří Vám. Google Search Console, Microsoft 365, Google Workspace, Facebook, Apple, GitHub, služby pro newslettery i platformy pro e-shopy fungují všechny stejně:

1. Služba Vám dá kód, například google-site-verification=Ab12Cd34... nebo MS=ms12345678.
2. Tento kód vložíte jako TXT záznam do DNS Vaší domény.
3. Služba si TXT záznam Vaší domény vyžádá. Pokud kód najde, ví: kdo mohl tento kód umístit, spravuje tuto doménu.

Takový záznam může umístit jen ten, kdo může měnit DNS dané domény. Proto jde o spolehlivou kontrolu.

Jak vypadá TXT záznam?

example.com.   3600  IN  TXT  "google-site-verification=Ab12Cd34Ef56"
example.com.   3600  IN  TXT  "MS=ms12345678"
example.com.   3600  IN  TXT  "v=spf1 mx include:spf.service.example ~all"

Pár věcí, které je dobré vědět:

• Uvozovky. V zónovém souboru je text uzavřen v uvozovkách. Ve většině panelů je nemusíte psát: panel je doplní sám. Pokud je přesto napíšete, po uložení zkontrolujte, že tam nejsou uvozovky dvojmo.
• Úseky po 255 znacích. Jeden textový úsek v TXT záznamu smí mít nejvýše 255 znaků (RFC 1035). Delší texty, například DKIM klíč, se rozdělí na více úseků v rámci stejného záznamu: "první část" "druhá část". Programy, které TXT čtou, tyto úseky zase spojí dohromady. Dobré panely dělí automaticky, u některých to musíte udělat sami.
• Záleží na velkých písmenech a mezerách. Kód kopírujte přesně, nejlépe pomocí kopírování a vložení. Mezera na konci nebo chybějící znak stačí k tomu, aby ověření selhalo.

Na jaký název?

Služba vždy uvede, na jakém názvu má záznam být:

• Na samotné doméně. Služba pak uvede "@", "root", "host prázdný" nebo jen example.com. Ve většině panelů pak napíšete @ nebo pole necháte prázdné.
• Na vlastním názvu. Některé služby chtějí samostatný název začínající podtržítkem, například _github-challenge-voorbeeldbedrijf nebo _acme-challenge. Podtržítko ukazuje, že nejde o běžný hostname (nelze na něm otevřít web). Do panelu napište jen tuto první část, Vaše doména se k ní připojí automaticky.

Častá chyba: vyplnění celého názvu do panelu, který za něj sám domenu doplní. Vznikne tak _github-challenge-voorbeeldbedrijf.example.com.example.com a služba nic nenajde. Po uložení zkontrolujte, jaký celý název panel zobrazuje.

Více TXT záznamů: je to v pořádku?

Ano. Na jednom názvu může být tolik TXT záznamů, kolik chcete. Ověření pro Google a ověření pro Microsoft si navzájem nepřekáží. Každá služba hledá mezi všemi TXT záznamy svůj vlastní kód.

Existují dvě výjimky a ty jsou důležité:

• SPF (začíná v=spf1): nejvýše jeden na daný název. Dva SPF záznamy způsobí, že Vaše SPF přestane platit (lekce 4.3).
• DMARC (na _dmarc, začíná v=DMARC1): nejvýše jeden. Při dvou záznamech se příjemce bude chovat, jako byste DMARC vůbec neměli (lekce 4.5).

Pokud Vás služba požádá: "přidejte tento SPF záznam", nevytvářejte tedy druhý SPF záznam, ale doplňte ten stávající.

Může se ověření zase odstranit?

To záleží na konkrétní službě. Mnoho služeb (například Google Search Console a Microsoft 365) kontroluje záznam i později znovu. Pokud záznam odstraníte, může se Vaše doména po čase znovu objevit jako "neověřená". Ponechte ho tam proto, pokud služba výslovně neřekne, že ho můžete odstranit. Starý ověřovací záznam služby, kterou už nepoužíváte, samozřejmě odstranit můžete.

Nefunguje to hned

Právě jste vytvořili záznam a služba hlásí "nenalezeno"? Obvykle za to může cache (modul 6). Pokud si služba Vaši doménu vyžádala ještě předtím, než záznam existoval, nějakou dobu si pamatuje, že tam nic nebylo. Počkejte čtvrt hodiny a zkuste to znovu. Mezitím si sami pomocí online nástroje pro dotazování DNS ověřte, že záznam skutečně existuje (lekce 8.2 a 8.3).

V praxi: jak to vypadá v panelu

V tomto příkladu používáme Můj WebOké. Přejděte k doméně, na záložku DNS, a klikněte na Přidat záznam. Zvolte typ TXT, do pole Název vyplňte @ (nebo název, který uvádí služba) a do hodnoty vložte kód. Uvozovky psát nemusíte. V DirectAdmin to funguje v sekci DNS stejně, tam u pole Typ TXT záznamu ponechte hodnotu Prostý.

V jiných panelech se pole někdy jmenují Host, Hostname nebo Name a Value, Content či Data, princip je ale stejný.

Shrnutí

• TXT záznam je text u určitého názvu. Služby ho používají ke kontrole, že doména patří Vám.
• Kód kopírujte přesně a umístěte ho na název, který služba uvede (často @, někdy název s podtržítkem).
• Více TXT záznamů na jednom názvu je v pořádku, kromě SPF a DMARC: z nich smí být nejvýše jeden.
• Pokud se ověření hned nepodaří, chvíli počkejte: odpověď může být stále uložená v cache.

Kvíz

Úkol

Úkol Z4.2: Vyhledání ověřovacího kódu. Vyhledejte TXT záznamy domény wikipedia.org. Mimo jiné tam najdete ověřovací kód od Google. Vložte celý ověřovací text, který začíná google-site-verification=.

Úkol O4.2: Nastavení ve vlastní cvičné zóně. Ve cvičné zóně použijete falešnou službu, u skutečné domény byste samozřejmě použili skutečný kód, který Vám služba poskytne. K úkolu dostanete osobní kód <Váš kód> (ten vypadá jako oefen-<kód>-<písmena>). Ve své cvičné zóně <code>.dnspractice.eu vytvořte dva TXT záznamy:

1. na názvu samotné zóny (@): dnscursus-verificatie=<Váš kód>
2. na názvu _cursus-challenge: pouze <Váš kód>

Další čtení

Kroky v těchto článcích platí pro panely WebOké, v jiných panelech to funguje obdobně.

• Příručka k DirectAdmin 5.6: TXT záznamy pro ověření (Google, Microsoft a další)
• Správa DNS záznamů v Můj WebOké (s příklady pro CNAME, TXT a externí služby)
• Příručka WebOké 5.4: Správa DNS: přidávání, úprava a mazání záznamů
• RFC 1035 odstavec 3.3.14 (TXT), RFC 7208 odstavec 3.3 (dlouhé SPF texty rozdělené do více úseků)