Měním hosting: co udělat s doménou, DNS a e-mailem?
Web, doména a pošta mohou běžet u různých firem. Kontrolní seznam ukazuje, které DNS záznamy zachovat, jak přepnout web a jak ověřit příjem i odesílání pošty.
Změna hostingu neznamená automaticky změnu registrátora domény ani poskytovatele e-mailu. Web, DNS a pošta mohou běžet u tří různých firem. Právě jejich záměna je častým důvodem, proč po přesunu web sice funguje, ale přestanou chodit zprávy. Před jakoukoli změnou si proto nakreslete jednoduchou mapu: kde je doména registrovaná, kdo spravuje její DNS zónu, kam směruje web a kdo přijímá e-mail.
Čtyři různé role, které se často pletou
Registrátor vede doménu a umožňuje měnit její delegaci na jmenné servery. DNS poskytovatel zveřejňuje záznamy, podle kterých ostatní služby najdou web či poštovní server. Webhosting obsluhuje návštěvníky webu. Poštovní služba přijímá a odesílá e-maily. Jedna společnost může zajišťovat všechny role, ale není to nutnost. Náš článek Kde registrovat doménu? vysvětluje, proč má smysl tyto úlohy rozlišovat už při jejím pořízení.
Pokud pouze měníte server webu a současný správce DNS zůstává stejný, obvykle stačí upravit adresní záznamy webu. Pokud měníte jmenné servery, přesouváte celou DNS zónu: musíte nejprve připravit všechny potřebné záznamy u nového DNS poskytovatele, včetně těch pro e-mail a ověření jiných služeb.
Které DNS záznamy zkontrolovat
| Typ | K čemu slouží | Typický problém při přesunu |
|---|---|---|
A a AAAA | Směrují jméno na IPv4 a IPv6 adresu. | Jedna adresa ukazuje na nový server, druhá zůstane na starém. |
CNAME | Směruje jméno na jiné jméno, často www. | Varianta s www zůstane zapomenutá. |
MX | Určuje servery pro příjem pošty. | Pošta se začne doručovat jinam nebo vůbec. |
TXT | Často nese ověření domény a údaje pro SPF či DMARC. | Ztratí se ověření služby nebo autentizace odesílané pošty. |
CAA, SRV a další | Podle potřeby ovlivňují certifikáty a doplňkové služby. | Méně viditelná služba přestane fungovat až po čase. |
Seznam není vyčerpávající. Neodhadujte záznamy podle obecného návodu; vyexportujte aktuální zónu a porovnejte ji s požadavky používaných služeb. Cloudflare při přesunu DNS výslovně doporučuje ručně zkontrolovat záznamy, které automatické načtení nemusí najít.
Scénář A: stěhuje se jen web
U nového hostingu nejprve připravte funkční web a zjistěte cílovou IPv4 a případně IPv6 adresu. V současné DNS zóně pak změňte záznamy pro doménu a www podle konfigurace poskytovatele. Poštovní MX, autentizační TXT a další nesouvisející záznamy ponechte beze změny. Pokud nový hosting IPv6 nepodporuje, zkontrolujte, zda starý AAAA záznam neposílá část uživatelů jinam; správný postup závisí na cílové konfiguraci.
Pokud byla pošta součástí starého hostingu, zjistěte před jeho zrušením, zda bude fungovat samostatně. Změna samotného webového záznamu ji automaticky nepřenese. Je-li nutné přestěhovat i schránky, naplánujte export zpráv a přepnutí pošty jako samostatnou práci.
Scénář B: mění se jmenné servery
Nejdříve vytvořte novou DNS zónu a přeneste do ní všechny používané záznamy. Ověřte ji ještě před přepnutím delegace u registrátora: adresy webu, www, poštovní záznamy, ověřovací TXT, případné subdomény a služby třetích stran. Teprve potom změňte jmenné servery. Starou zónu ponechte dostupnou po dobu přechodu, protože část resolverů může ještě pracovat se starou delegací.
Pokud má doména zapnutý DNSSEC, postupujte podle návodu původního a nového DNS poskytovatele. Při změně jmenných serverů mohou nesprávně navazující klíče a DS záznamy způsobit chybu ověřování, i když ostatní záznamy vypadají správně. Cloudflare tuto situaci ve své dokumentaci výslovně popisuje; univerzální bezpečný postup bez znalosti konkrétní zóny neexistuje.
TTL: plánujte čas, neslibujte okamžitý přepínač
TTL říká, jak dlouho se DNS odpověď může držet v cache. Před plánovanou změnou lze u některých záznamů TTL snížit, aby se nová hodnota po přepnutí šířila rychleji. Zkrácení ale nevymaže odpovědi uložené dříve s delším TTL a různé sítě se mohou během přechodu chovat odlišně. Proto je rozumné držet starý i nový web připravený, dokud testy neukazují stabilní stav.
Jak nepřijít o e-mail
MX určuje, kam se doručují příchozí zprávy. SPF uvádí systémy oprávněné odesílat poštu za vaši doménu, DKIM přidává kryptografické ověření zpráv a DMARC pomáhá stanovit, jak zacházet se zprávami, které autentizací neprojdou. Tyto záznamy mají různé úlohy; funkční příjem ještě neznamená správné odesílání.
Před přechodem sepište všechny systémy, které odesílají e-mail pod vaší doménou: běžné schránky, kontaktní formulář, newsletter, fakturační aplikaci a případně CRM. Při změně poštovního poskytovatele nastavte požadované záznamy podle jeho dokumentace. Nepřidávejte bez rozmyslu druhý samostatný SPF záznam pro stejnou doménu; pokud odesílá více služeb, jejich požadavky je potřeba správně zkombinovat. DKIM klíče a další ověřovací hodnoty opisujte ze skutečné administrace používané služby.
Po přepnutí pošlete zprávu na vlastní doménu z externí adresy, odpovězte z nové schránky zpět a otestujte zprávu z webového formuláře. U e-shopu prověřte také potvrzení objednávky. Sledujte chybová hlášení a hlavičky testovacích zpráv; samotné zobrazení „odesláno“ ve formuláři nezaručuje doručení.
Kontrolní seznam před zrušením staré služby
- Vím, u koho je doména, DNS, web a pošta.
- Mám uloženou úplnou původní DNS zónu a přístup k registrátorovi.
- Nový web funguje na obou používaných variantách domény a přes HTTPS.
- Zkontroloval jsem
A,AAAA,www,MXa všechny potřebné TXT záznamy. - Při změně jmenných serverů mám vyřešený DNSSEC.
- Otestoval jsem příjem a odeslání pošty i zprávy z aplikací.
- Mám plán návratu a staré služby neruším před dokončením kontrol.
Teprve po tomto testu má smysl starý hosting ukončit. Kdo chce změnu využít k výběru lepšího poskytovatele, může začít v našem srovnání hostingů; samotný přesun domény a pošty je však potřeba plánovat odděleně od výběru tarifu.
Jak ověřit změnu bez hádání
V administračním rozhraní DNS porovnejte zadané hodnoty se seznamem od nového poskytovatele. Potom z veřejné sítě ověřte odpovědi pro doménu i www. Na počítači lze použít příkazy jako nslookup nebo dig; důležité je sledovat konkrétní typ záznamu a hodnotu, ne jen to, že se stránka otevře. Pokud využíváte CDN nebo reverzní proxy, může veřejná IP patřit této službě, nikoli vašemu původnímu serveru. Proto porovnávejte výsledek s dokumentovaným cílem, ne s odhadem.
U e-mailu ověřte samostatně MX a požadované autentizační záznamy. Pošlete testovací zprávy oběma směry a zkontrolujte, že se zpráva doručí i na další běžně používanou službu. Testujte také odesílání z aplikace, protože může používat jiný SMTP server než běžné schránky. Chybové hlášení příjemce si uložte celé; bývá užitečnější než prostá informace, že e-mail nedorazil.
Časté omyly při změně DNS
„Doména je u nového hostingu, takže DNS už spravuje on.“ Registrace domény, DNS delegace a webhosting jsou oddělené služby. Vždy se podívejte, které jmenné servery jsou skutečně nastavené a ve které administraci je autoritativní zóna.
„Změnil jsem A záznam, tedy je hotovo.“ Může existovat AAAA pro IPv6, samostatný záznam www, subdomény nebo proxy. Změnu ověřte pro každou používanou adresu.
„Pošta se přestěhuje společně se soubory webu.“ Schránky a staré zprávy vyžadují vlastní postup. DNS záznamy pouze směrují komunikaci; obsah schránek nepřenesou.
„Krátké TTL znamená, že všichni okamžitě uvidí nový server.“ Existující cache mohou držet předchozí odpověď až do jejího vypršení. Při změně jmenných serverů vstupuje do hry také delegace a případně DNSSEC. Plánujte souběh staré a nové služby.
„Když funguje příjem, funguje i odesílání.“ Pro příchozí poštu je zásadní zejména MX; odesílání se posuzuje i podle nastavení použitého serveru a autentizace domény. Obě cesty vždy testujte zvlášť.
