Egy weboldal-költözés technikailag két, egymástól független dologból áll. Az első: átmásolni a fájlokat és az adatbázist az új szerverre. A második: megmondani az internetnek, hogy ezentúl az új szervert keresse. Az első rész egy másolás, ezt a legtöbb szolgáltató rutinból megcsinálja. A második rész a DNS, és a gyakorlatban innen jön a bosszúságok nagy része.
Saját tapasztalat: a költözés kockázata a legtöbb kis- és középvállalkozásnál nem a weboldalon csattan, hanem a levelezésen. Ha a weboldal fél órára eltűnik, azt az ügyfelek jó eséllyel észre sem veszik. Egy elveszett vagy a régi, már nem figyelt szerverre befutott ajánlatkérő levél viszont nem jön vissza.
Mi az a DNS, és miért nem maga a weboldal költözik?
A DNS (Domain Name System) az internet címjegyzéke: a domainnevet fordítja le arra a numerikus IP-címre, ahol a tartalom valójában fut. A böngésződ nem tudja, mi az a pelda.hu, csak azt tudja, hogyan kérdezze meg. Amikor beírod a címet, egy kérdés indul el a te szolgáltatód feloldó szerveréhez, onnan a legfelső szintű .hu névszerverekhez, végül ahhoz a névszerverhez, amelyik a domain hivatalos válaszait tárolja.
Tovább a témában: WordPress karbantartás Budapest · Költözés új címre
Hivatalosan igazolt: ezt a felépítést az IETF RFC 1034 és RFC 1035 dokumentumai írják le, és a rendszer alapelvei ma is ugyanezek. Ami ebből a gyakorlat szempontjából fontos: a DNS szándékosan gyorsítótárazó rendszer. A válaszokat a köztes szerverek eltárolják egy ideig, hogy ne kelljen minden egyes kattintásnál végigjárni a láncot. Ez a gyorsítótárazás teszi gyorssá az internetet, és ugyanez teszi lassúvá a költözést.
Mit csinál pontosan az A, a CNAME, az MX és a TXT rekord?
Négy rekordtípus fedi le egy átlagos vállalkozói domain igényeinek nagy részét. Érdemes úgy gondolni rájuk, mint négy külön útjelző táblára, amelyek különböző forgalmat irányítanak.
A és AAAA rekord: hol van a weboldal
Az A rekord egy nevet egy IPv4-címhez rendel, például pelda.hu -> 185.12.34.56. Az AAAA ugyanez IPv6-cím esetén. Szerverváltásnál ez az a rekord, ami tényleg megváltozik: az új tárhely új IP-címet ad, és ezt kell beírni. Ha csak a weboldalt költözteted, gyakran ez az egyetlen módosítandó sor.
CNAME: átirányítás egy másik névre
A CNAME nem IP-címre, hanem másik névre mutat. Tipikus eset a www.pelda.hu, amely CNAME-ként a pelda.hu névre hivatkozik: így elég egy helyen karbantartani az IP-t. Külső szolgáltatások (hírlevélküldő, webshop-motor, CDN) is gyakran CNAME-et kérnek. Fontos korlát, hogy a domain gyökerére (a pelda.hu önmagában) a szabvány szerint nem tehető klasszikus CNAME, ezért egyes szolgáltatók saját megoldást kínálnak rá.
MX: hova menjen a levél
Az MX (Mail Exchanger) rekord mondja meg a küldő levelezőszervereknek, melyik gép fogadja a domainre érkező e-mailt. Ennek semmi köze az A rekordhoz. Ez a legfontosabb mondat az egész cikkben: a weboldal és a levelezés két külön rekordtípuson, két külön szerverre is mutathat. Több MX is megadható, mindegyik mellett egy prioritásszámmal; a kisebb szám élvez elsőbbséget.
TXT: igazolások és levélhitelesítés
A TXT rekord szabad szöveget tárol, és ma leginkább három dologra használjuk. Az első a tulajdonjog igazolása (Google Search Console, Microsoft 365, tanúsítvány-kibocsátás). A második az SPF, amely felsorolja, mely szerverek küldhetnek jogosan levelet a nevedben. A harmadik a DKIM és a DMARC, amelyek a levelek digitális aláírását és a szabálysértő levelek kezelését írják le. Hivatalosan igazolt: az SPF az RFC 7208, a DKIM az RFC 6376, a DMARC az RFC 7489 szabványban van rögzítve.
Mi az a TTL, és miért látja valaki még a régi oldalt?
A TTL (Time To Live) minden rekord mellett szereplő szám, másodpercben: ennyi ideig őrizheti meg a választ egy gyorsítótárazó szerver, mielőtt újra rákérdez. Ha a TTL 86400, az egy nap. Amikor átírod az A rekordot, azok a feloldó szerverek, amelyek öt perce kérdeztek rá, még majdnem 24 órán át a régi IP-t adják vissza a hozzájuk tartozó felhasználóknak.
Ez a magyarázata annak a jelenségnek, amit szinte minden költözésnél hallani: te már az új oldalt látod, a kollégád még a régit, a mobilneten pedig megint mást. Nem hiba, hanem a rendszer tervezett működése. A propagáció ezért a gyakorlatban nem egy pillanat, hanem egy sáv: jellemzően néhány perctől 48 óráig tart, a beállított TTL-től és az útközbeni szerverek viselkedésétől függően.
A gyorsítás módja egyszerű: a költözés előtt 24-48 órával állítsd a költöztetni kívánt rekordok TTL-jét alacsonyra, például 300 másodpercre. Meg kell várni, amíg a régi, hosszú TTL-lel kiadott válaszok lejárnak, ezért kell az előretartás. Amikor ez megtörtént, az éles váltás után a világ nagy része néhány percen belül az új szervert fogja látni. A sikeres költözés után egy-két nappal érdemes visszaemelni a TTL-t 3600 vagy 14400 másodpercre, mert a nagyon alacsony érték fölösleges terhelést és apró késleltetést jelent.
Szakmai feltételezés: a tapasztalt 48 órás felső határ ma inkább a rosszul viselkedő, a TTL-t figyelmen kívül hagyó köztes feloldókra és a helyi gépek saját gyorsítótárára vezethető vissza, nem magára a DNS-hierarchiára. Ezt egyedi esetben nehéz bizonyítani, ezért tervezz mindig a hosszabb változattal.
Hogyan ellenőrzöd a jelenlegi rekordokat?
Mielőtt bármit átírsz, készíts leltárt. A lekérdezés ingyenes, gyors, és nem módosít semmit.
Windowson a beépített eszköz az nslookup:
nslookup -type=A pelda.hunslookup -type=MX pelda.hunslookup -type=TXT pelda.hu
macOS és Linux alatt a dig részletesebb, és a TTL-t is kiírja:
dig pelda.hu A +noall +answerdig pelda.hu MX +noall +answerdig pelda.hu TXT +noall +answerdig pelda.hu NS +noall +answer
A válaszsor második oszlopa a TTL. Ha közvetlenül a hivatalos névszervert akarod megkérdezni, megkerülve a gyorsítótárakat, add meg a szervert: dig @ns1.szolgaltato.hu pelda.hu A. Ez a legmegbízhatóbb ellenőrzés arra, hogy a módosításod valóban mentésre került-e.
Ha nem szeretnél parancssort használni, az online lekérdezők ugyanezt adják böngészőből. A DNSChecker, a MXToolbox, a Google Dig eszköze és a Cloudflare nyilvános feloldója mind alkalmas rá, és a DNSChecker azt is megmutatja, a világ különböző pontjain milyen választ kap a domain. Ez a több országból végzett lekérdezés jól szemlélteti, hogy a propagáció nem mindenhol egyszerre fejeződik be.
Mi a leggyakoribb hiba, amitől leáll az e-mail?
A leggyakoribb hiba a névszerver-váltás következménye. Amikor az új tárhelyszolgáltató azt kéri, hogy a regisztrátornál írd át a névszervereket az övéire, a domain teljes DNS-zónája átkerül hozzájuk. Az új zóna viszont üresen indul, csak a webhez tartozó alapértelmezett rekordokkal. Ha a régi zónában volt MX rekord egy külön levelezőszolgáltatóhoz, az az új helyen nincs benne. Attól a pillanattól kezdve a domainre érkező levelek az új tárhely saját, üres postafiókjaiba mennek, vagy visszapattannak.
Ugyanígy tűnik el az SPF és a DKIM TXT rekord. Ennek a hatása alattomosabb: a levelezés látszólag működik, de a kimenő levelek egy része spam mappába kerül, mert a fogadó oldal nem találja a küldő szerverre vonatkozó felhatalmazást. Ezt gyakran csak hetekkel később veszi észre a cég, amikor kiderül, hogy több ajánlat nem ért célba.
A védekezés egyszerű: névszerver-váltás előtt kérdezd le és mentsd el az összes létező rekordot, majd az új szolgáltatónál hozd létre őket még a váltás előtt. Ez az egy lépés a tapasztalatom szerint a költözési hibák nagy részét megszünteti.
Mit jelent, ha a domain, a DNS és a tárhely három külön helyen van?
Ez a felállás gyakoribb, mint gondolnád, és önmagában nem hiba. Három szerep van, amit három különböző cég is elláthat.
- Regisztrátor: nála van bejegyezve a domain, ő kezeli a tulajdonosi adatokat, a megújítást, és nála állítod be, mely névszerverek felelősek a domainért.
- DNS-szolgáltató: az ő névszerverein él a zónafájl, itt vannak a tényleges A, CNAME, MX és TXT rekordok. Lehet a regisztrátor is, de lehet külön szolgáltató, például egy CDN.
- Tárhelyszolgáltató: nála futnak a fájlok és az adatbázis, tőle kapod az IP-címet.
A gyakorlati következmény: költözéskor pontosan tudnod kell, hol kell bejelentkezned a módosításhoz. Ha a domain az egyik cégnél van, de a névszerverek egy másikra mutatnak, akkor a rekordok szerkesztése nem a regisztrátornál történik. A dig pelda.hu NS parancs pontosan megmondja, ki a jelenlegi felelős. Ha ez nem egyezik azzal, ahol keresed a rekordokat, hiába írod át őket, semmi nem fog történni.
Hogyan néz ki egy biztonságos költözés 8 lépésben?
- Leltár. Kérdezd le és mentsd fájlba az összes jelenlegi rekordot: A, AAAA, CNAME, MX, TXT, és ha van, SRV és CAA. Jegyezd fel a jelenlegi névszervereket és azt is, ki a regisztrátor.
- TTL-csökkentés. A költözés előtt legalább 24, inkább 48 órával állítsd a webhez tartozó rekordok TTL-jét 300 másodpercre. A meglévő rekordok értékét csak csökkented, tartalmat nem módosítasz, így ez a lépés kockázatmentes.
- Másolás és tesztelés. Vidd át a fájlokat és az adatbázist az új szerverre, majd teszteld a hosts fájlon keresztül vagy a szolgáltató ideiglenes URL-jén. Az oldal működjön hibátlanul, mielőtt bármilyen DNS-hez hozzányúlnál.
- Rekordok előkészítése. Ha névszervert is váltasz, az új DNS-szolgáltatónál hozd létre a teljes zónát a mentés alapján, MX-szel és TXT-vel együtt. A váltás pillanatában már készen kell állnia.
- Tanúsítvány. Kérj SSL-tanúsítványt az új szerveren. Sok szolgáltató a DNS-váltás után automatikusan intézi, de ha kézzel kell, ez az a lépés, ami könnyen kimarad, és ilyenkor a látogató biztonsági figyelmeztetést kap.
- Éles váltás. Írd át az A rekordot az új IP-re, vagy váltsd a névszervereket. Alacsony forgalmú időszakban tedd, jellemzően késő este vagy hétvégén.
- Ellenőrzés több irányból. Egy óra múlva nézd meg
digvagy online lekérdező segítségével, mobilneten és céges hálózaton is. Küldj tesztlevelet egy külső címről a céges postafiókba, és onnan is kifelé. - Visszaállítás és utókövetés. A stabil működés után 24-48 órával emeld vissza a TTL-t. A régi szervert még legalább egy-két hétig tartsd meg elérhető állapotban, mert ez a biztonsági hálód.
Mire figyelj a költözés utáni első héten?
A hibák egy része nem azonnal jelentkezik. Az első napokban érdemes tudatosan végigmenni néhány ponton: érkeznek-e a weboldal űrlapjairól a levelek, jönnek-e a webshop rendelési visszaigazolásai, működnek-e az átirányítások, és a Search Console jelez-e új feltérképezési hibát. Hivatalosan igazolt: a Google Search Central dokumentációja szerint domainváltás nélküli szerverköltözésnél a keresési láthatóság jellemzően nem sérül, feltéve, hogy az URL-szerkezet és a válaszkódok változatlanok maradnak. Ez viszont nem garancia semmilyen helyezésre, csak azt jelenti, hogy a szerverváltás önmagában nem kell, hogy visszavessen.
Saját tapasztalat: a leggyakrabban elfelejtett elem a weboldalról kimenő rendszerlevél. A tárhelyváltás után a WordPress vagy a webshop új szerverről küld, amit a régi SPF rekord nem enged, így a visszaigazolások csendben a spam mappákba kerülnek. Ha a költözés után beállítod, hogy a rendszerlevelek is a hivatalos levelezőszolgáltatón át menjenek ki, ezt a hibát elkerülöd.
Források és további olvasnivalók
- IETF RFC 1034 és RFC 1035: Domain Names, Concepts and Facilities / Implementation and Specification
- IETF RFC 7208: Sender Policy Framework (SPF)
- IETF RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- IETF RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)
- Google Search Central: Site moves without URL changes
- Google Workspace Admin súgó: MX rekordok beállítása
- ICANN: Domain Name Registration Data és névszerver-kezelés
- Cloudflare Learning Center: What is DNS, DNS records, TTL
- MXToolbox és DNSChecker nyilvános lekérdező eszközök dokumentációja
- Az A és a CNAME rekord a weboldalt irányítja, az MX rekord teljesen külön úton a levelezést: a kettőt nem kötelező együtt költöztetni.
- A TTL határozza meg, meddig őrzik a köztes szerverek a régi választ, ezért látja egyes látogató még napokig a régi oldalt.
- A költözés előtt 24-48 órával érdemes a TTL-t 300 másodpercre csökkenteni, utána visszaállítani.
- A leggyakoribb és legdrágább hiba a névszerver-váltáskor át nem másolt MX, SPF, DKIM és DMARC rekord: ilyenkor a levelezés áll le, nem a weboldal.
- Költözés előtt írd össze, hol van a domain regisztrálva, hol kezelik a DNS-t, és hol fut a tárhely: ez a három gyakran három külön szolgáltató.
Gyakori kérdések
Mennyi ideig tart a DNS-propagáció?
A gyakorlatban néhány perctől 48 óráig terjed. A felső határt a rekordokon beállított TTL és a köztes feloldó szerverek gyorsítótára határozza meg. Ha a költözés előtt 24-48 órával 300 másodpercre csökkented a TTL-t, a váltás jellemzően percek alatt átfordul a legtöbb látogatónál.
Miért látom még mindig a régi oldalt, ha a rekord már át van írva?
Vagy a szolgáltatód feloldó szervere őrzi még a régi választ a lejáratlan TTL miatt, vagy a saját géped, illetve a böngésződ gyorsítótára. Ellenőrizd a valós állapotot a hivatalos névszervertől lekérdezve, például a dig @ns1.szolgaltato.hu pelda.hu A paranccsal, és próbáld ki egy másik hálózatról is.
Le kell-e állnia a levelezésnek, ha csak a weboldalt költöztetem?
Nem. Ha csak az A rekordot írod át, és a névszervereket nem váltod, az MX és a TXT rekordok érintetlenek maradnak, a levelezés zavartalanul működik tovább. A levelezés akkor kerül veszélybe, ha névszervert is váltasz, és az új zónában nem hozod létre előre az MX, SPF, DKIM és DMARC rekordokat.
Mi a különbség a névszerver-váltás és az A rekord átírása között?
Az A rekord átírása egyetlen sort módosít a meglévő zónafájlban, a többi rekord marad. A névszerver-váltás viszont az egész zóna kezelését átteszi egy másik szolgáltatóhoz, ezért ott minden rekordot újra létre kell hozni. A névszerver-váltás a nagyobb kockázatú művelet.
Hogyan nézem meg, hol kezelik a domainem DNS-ét?
Kérdezd le a névszervereket: dig pelda.hu NS, vagy Windowson nslookup -type=NS pelda.hu. A válaszban szereplő névszerverek gazdája kezeli a rekordokat. Ez gyakran nem ugyanaz a cég, ahol a domaint regisztráltad.
Vissza tudom vonni a költözést, ha valami elromlik?
Igen, ha megvan a rekordok mentése és a régi szerver még él. Írd vissza az eredeti értékeket, és a lecsökkentett TTL miatt a visszaállás is gyors lesz. Ezért érdemes a régi tárhelyet legalább egy-két hétig megtartani.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.