DNS: teljes útmutató

A DNS, vagyis a tartománynévrendszer, a domainneveket IP-címekre fordítja, hogy a böngésző és a Googlebot megtalálja a szervert. SEO szempontból akkor számít, ha hibázik vagy lassú: ha a névfeloldás nem sikerül, a kereső nem éri el a webhelyet, a látogató pedig hibaoldalt lát. Költözésnél, CDN-váltásnál és a Search Console ellenőrzésénél a DNS-rekordok helyes kezelése dönti el, hogy a webhely zavartalanul elérhető marad-e.

Alapfogalmak

Az interneten a gépek IP-címekkel azonosítják egymást, az emberek viszont neveket jegyeznek meg. A DNS a kettő közötti fordító: amikor valaki beírja a böngészőbe a pelda.hu címet, a DNS mondja meg, melyik IP-címen található a szerver. Ez a lépés minden új kapcsolat előtt megtörténik, a böngészőnél és a keresőrobotnál egyaránt. Ha a DNS nem ad választ, vagy rossz címet ad, a kapcsolat létre sem jön, és hiába hibátlan a webhely.

A DNS elosztott rendszer. Nincs egyetlen központi adatbázis, amely minden domaint ismerne. A felelősség hierarchikusan oszlik meg: a gyökérkiszolgálók tudják, hol vannak a legfelső szintű tartományok, például a .hu vagy a .com kiszolgálói, azok pedig tudják, melyik névkiszolgáló felel egy adott domainért. A domainhez tartozó rekordokat a mérvadó névkiszolgáló tárolja, amelyet jellemzően a domainregisztrátor, a tárhelyszolgáltató vagy egy külön DNS-szolgáltató üzemeltet.

A leggyakoribb rekordtípusok

Rekord	Mire való	SEO- és webhelyüzemeltetési szerep
A	Névhez IPv4-címet rendel	Ezen múlik, hogy a domain a megfelelő szerverre mutat-e
AAAA	Névhez IPv6-címet rendel	Ha van, annak is működő szerverre kell mutatnia
CNAME	Egy nevet egy másik névhez rendel álnévként	Aldomainek CDN-hez vagy külső szolgáltatáshoz kötése
NS	Megadja, mely névkiszolgálók felelnek a domainért	Szolgáltatóváltáskor ez dönti el, melyik zóna érvényes
MX	A domain levelezőszervereit adja meg	Közvetlenül nem SEO, de költözéskor könnyű elrontani
TXT	Szabad szöveges információ	Search Console domainellenőrzés, levelezési hitelesítés
CAA	Megadja, mely hitelesítésszolgáltatók állíthatnak ki tanúsítványt	Hibás beállítás megakadályozhatja a HTTPS-tanúsítvány megújítását
HTTPS (SVCB)	A szolgáltatás paramétereit, például a támogatott protokollokat közli	Segítheti, hogy az első kapcsolat is HTTP/3-on induljon

A TTL szerepe

Minden DNS-rekordnak van egy élettartama, a TTL (time to live), másodpercben megadva. Ez mondja meg, mennyi ideig tárolhatják a rekordot a gyorsítótárak, mielőtt újra lekérdeznék. A hosszú TTL kevesebb lekérdezést és stabilabb működést jelent, de egy változtatás lassabban terjed el. A rövid TTL gyorsabb változtatást enged, cserébe több lekérdezéssel jár. A DNS-propagációnak nevezett jelenség valójában ez: a régi rekord addig marad érvényben a különböző gyorsítótárakban, amíg a TTL-je le nem jár.

Mit jelent a DNS a keresőnek?

A Googlebotnak is fel kell oldania a domaint, mielőtt bármit lekérne. A Search Console feltérképezési statisztikák jelentésében a gazdagép állapota között külön szerepel a DNS-feloldás. Ha a névfeloldás tartósan hibázik, a kereső nem tudja elérni a webhelyet, és visszafogja a feltérképezést. Rövid, átmeneti hibák általában nem okoznak tartós kárt, a hosszan elhúzódó elérhetetlenség viszont az oldalak indexben tartását is veszélyeztetheti. A DNS emellett a Search Console-ban a domaintulajdon ellenőrzésének eszköze is, egy TXT rekord formájában.

Hogyan működik?

A névfeloldás több szereplő együttműködése. A folyamat a felhasználó gépén indul, és a lehető legtöbbet gyorsítótárból próbál megoldani, mert egy teljes feloldás több kérést igényel különböző kiszolgálók felé.

A feloldás lépései

Helyi gyorsítótár. A böngésző és az operációs rendszer megnézi, ismeri-e már a nevet egy korábbi feloldásból.
Rekurzív feloldó. Ha nem, a kérés a rekurzív feloldóhoz megy, amelyet jellemzően az internetszolgáltató vagy egy nyilvános DNS-szolgáltatás üzemeltet. Ez végzi el a munkát a kliens helyett.
Gyökérkiszolgáló. Ha a feloldó sem tudja a választ, megkérdezi a gyökérkiszolgálót, amely a legfelső szintű tartomány névkiszolgálóihoz irányítja.
Legfelső szintű tartomány. A .hu vagy .com kiszolgálói megmondják, melyik névkiszolgáló felel a konkrét domainért.
Mérvadó névkiszolgáló. Ez adja meg a tényleges rekordot, például az A rekord IP-címét.
Gyorsítótárazás. A feloldó a választ a TTL idejéig megőrzi, így a következő kérdezőnek már nem kell végigjárnia az utat.

A DNS és a betöltési idő

A névfeloldás minden új domain első kapcsolata előtt megtörténik, ezért beleszámít abba az időbe, amíg a böngésző megkapja az első bájtot. Ha a feloldás gyorsítótárból jön, szinte észrevehetetlen. Ha végig kell járni a láncot, vagy a mérvadó névkiszolgáló lassú, érezhető késleltetést adhat. Egy oldal, amely sok különböző domainről tölt be erőforrást, minden domainhez külön feloldást igényel. A böngésző ezt előre elvégezheti, ha az oldal dns-prefetch vagy preconnect tippel jelzi, mely domainekre lesz szükség. Erről a prefetch útmutató ír részletesen.

CNAME és a zóna csúcsa

A CNAME rekord egy nevet egy másik névre irányít, ami kényelmes, ha egy aldomaint CDN-hez vagy külső szolgáltatáshoz kell kötni. A DNS szabványa szerint azonban a zóna csúcsán, vagyis a www nélküli fő domainen nem lehet CNAME, mert ott más rekordoknak, például az NS-nek és az SOA-nak is lenniük kell. Erre a DNS-szolgáltatók saját megoldásokat kínálnak, amelyek a háttérben feloldják a célnevet, és A rekordként adják vissza. Ez az egyik oka annak, hogy CDN használatakor sok webhely a www-s változatot választja elsődleges címnek.

Anycast és DNS-szolgáltatók

A nagyobb DNS-szolgáltatók ugyanazt az IP-címet a világ több pontján hirdetik, így a kérés a legközelebbi kiszolgálóhoz érkezik. Ez gyorsabb feloldást és nagyobb hibatűrést jelent. Egy saját, egyetlen szerveren futó névkiszolgáló ezzel szemben egyetlen hibapont: ha leáll, a domain feloldhatatlanná válik, akkor is, ha a webszerver él.

Fő módszerek

A DNS-kezelés SEO szempontból a megbízhatóságról és a gondos változáskezelésről szól. A napi működésben a DNS láthatatlan, a problémák szinte mindig egy változtatás, egy lejárat vagy egy szolgáltatóváltás körül jelentkeznek.

1. Megbízható DNS-szolgáltató

A mérvadó névkiszolgálók legyenek redundánsak, több, egymástól független helyen. A nagy DNS-szolgáltatók és a CDN-ek DNS-szolgáltatása ezt alapból biztosítja. A regisztrátori alapszolgáltatás kisebb webhelyeknek elegendő lehet, de érdemes ellenőrizni, hogy több névkiszolgáló szerepel-e, és azok ténylegesen válaszolnak-e.

2. Tudatos TTL-kezelés

Stabil állapotban a hosszabb TTL a jó választás, mert kevesebb lekérdezést és nagyobb hibatűrést ad. Tervezett változtatás előtt, például szerverköltözésnél, érdemes a TTL-t előre lecsökkenteni, legalább a régi TTL idejével a váltás előtt. Így a váltáskor a gyorsítótárak hamar átveszik az új értéket. A váltás után, ha minden stabil, a TTL visszaállítható.

3. Költözés átfedéssel

Szerverköltözéskor a régi szerver maradjon működőképes, amíg a gyorsítótárakban a régi rekord le nem jár. Ebben az időszakban a látogatók és a Googlebot egy része még a régi címre érkezik. Ha a régi szerver ekkor már nem válaszol, vagy elavult tartalmat ad, a kereső hibákat vagy régi oldalakat lát. A két szerver párhuzamos működése a legegyszerűbb biztosíték.

4. A teljes zóna átvitele szolgáltatóváltáskor

Amikor a domain névkiszolgálóit egy új szolgáltatóra állítják át, az új zónában minden rekordnak meg kell lennie: A, AAAA, CNAME, MX, TXT, CAA. Gyakori hiba, hogy csak a webhely rekordjait viszik át, és a levelezés, a Search Console-ellenőrzés vagy egy aldomain rekordja kimarad. Az NS-váltás előtt az új zónát érdemes közvetlenül az új névkiszolgálótól lekérdezve ellenőrizni.

5. A domain és a regisztráció védelme

A domain lejárata a DNS legsúlyosabb hibája, mert ilyenkor a teljes webhely elérhetetlenné válik. Az automatikus megújítás, a naprakész kapcsolattartói e-mail-cím és a regisztrátori fiók kétlépcsős védelme mind ide tartozik. A DNSSEC a rekordok hamisítása elleni védelmet ad, de hibás bevezetése maga is feloldási hibát okozhat, ezért csak gondos beállítással érdemes használni.

Döntési szabály: mit állíts be?

Helyzet	Teendő
Stabil webhely, nincs tervezett változás	Hosszabb TTL, redundáns névkiszolgálók, automatikus domainmegújítás
Szerverköltözés előtt	TTL csökkentése előre, a régi szerver működtetése a váltás után is
DNS-szolgáltató váltása	A teljes zóna átvitele és ellenőrzése az NS-módosítás előtt
CDN bevezetése	CNAME az aldomainen, vagy a szolgáltató csúcsrekord-megoldása a fő domainen
Search Console domaintulajdon	TXT rekord felvétele, és megtartása az ellenőrzés után is
HTTPS-tanúsítvány automatikus megújítása	Ha van CAA rekord, szerepeljen benne a használt hitelesítésszolgáltató

Kidolgozott példa: szerverköltözés leállás nélkül

Egy szakmai portál új tárhelyre költözött. A csapat egy héttel a költözés előtt lecsökkentette az A rekord TTL-jét. Az új szerveren felállították a webhely másolatát, és a saját gépükön a hosts fájl módosításával tesztelték, hogy minden oldal, az átirányítások és a HTTPS is működik. A váltás napján átírták az A rekordot, a régi szervert pedig több napig változatlanul működtették, a tartalomszerkesztést erre az időre befagyasztva. A szervernaplókban követték, ahogy a forgalom és a Googlebot kérései fokozatosan átkerülnek az új szerverre. Amikor a régi szerveren már nem jelent meg forgalom, leállították, és a TTL-t visszaállították a korábbi értékre.

Kidolgozott példa: a kimaradt rekordok

Egy cég a DNS-kezelést átköltöztette egy CDN-szolgáltatóhoz. Az automatikus importálás a legtöbb rekordot átvette, de a Search Console domainellenőrzéséhez használt TXT rekordot és egy régi, a képeket kiszolgáló aldomain CNAME rekordját nem. Az aldomain feloldhatatlanná vált, a termékoldalakon a képek nem töltődtek be, a Search Console pedig később jelezte, hogy a tulajdon ellenőrzése nem érvényes. A javítás gyors volt, de a hiba napokig élt, mert senki nem hasonlította össze a régi és az új zónát. Azóta a csapat minden NS-váltás előtt rekordonként összeveti a két zónát egy lekérdező eszközzel.

Gyakori hibák

A DNS-hibák közös vonása, hogy nagy hatásúak és sokszor későn derülnek ki. Egy elírt rekord az egész webhelyet vagy egy fontos aldomaint elérhetetlenné teheti, a gyorsítótárazás miatt pedig a hiba egyes felhasználóknál már jelentkezik, másoknál még nem, ami megnehezíti a felismerését.

Tipikus hibák

Lejárt domain. A megújítás elmaradt, a névkiszolgálók a regisztrátor parkolóoldalára vagy sehova sem mutatnak.
Hiányos zóna szolgáltatóváltás után. Egy aldomain, a levelezés vagy egy ellenőrző TXT rekord elveszik.
Hibás AAAA rekord. Az IPv6-cím egy olyan szerverre mutat, amely nem szolgálja ki a webhelyet. Az IPv6-ot használó látogatók és robotok hibát kapnak, a többiek nem, ezért a hiba nehezen észrevehető.
Magas TTL a költözés napján. A régi rekord még sokáig él a gyorsítótárakban, miközben a régi szerver már nem működik.
Egyetlen névkiszolgáló. Ha az leáll, a domain feloldhatatlan.
CAA rekord a régi hitelesítésszolgáltatóval. A tanúsítvány automatikus megújítása elbukik, és a HTTPS lejár.
Törölt ellenőrző TXT rekord. A Search Console-hozzáférés elveszhet.
Túl sok külső domain. Minden erőforrás-domain külön feloldás, ami a betöltést lassítja.

Tévhit: a DNS-propagáció 48 óráig tart, és nem lehet mit tenni

A propagáció nem egy rögzített idő, hanem a gyorsítótárak lejárata. Az, hogy egy változás mennyi idő alatt ér el mindenkit, elsősorban a régi rekord TTL-jén múlik. Aki előre lecsökkenti a TTL-t, a váltást gyorsan végigviheti. A névkiszolgálók cseréje, vagyis az NS-rekordok módosítása a legfelső szintű tartomány szintjén más ütemben terjedhet, ezért erre nagyobb tartalékot érdemes hagyni.

Tévhit: a gyorsabb DNS-szolgáltató jobb helyezést hoz

A DNS-feloldás sebessége a betöltési időnek csak kis része, és a gyakran látogatott domainek feloldása sokszor gyorsítótárból érkezik. A DNS-szolgáltató megválasztása a megbízhatóság miatt fontos, nem a rangsorolás miatt. Egy megbízhatatlan szolgáltató kárt okozhat, egy kicsit gyorsabb viszont önmagában nem hoz helyezést.

Ellenpélda: a hiba, amelyet csak a kereső látott

Egy webhely tulajdonosa nem értette, miért jelez a Search Console gazdagép-problémát, amikor a webhely a saját gépéről tökéletesen működött. Kiderült, hogy a két névkiszolgáló közül az egyik hibás, elavult zónát szolgált ki, amelyben rossz IP-cím szerepelt. A tulajdonos feloldója a jó kiszolgálót kérdezte, a Googlebot kérései egy része a rosszat. A hibát a két névkiszolgáló közvetlen lekérdezése mutatta ki. A tanulság, hogy a DNS-t minden mérvadó névkiszolgálón külön kell ellenőrizni, nem elég egy böngészős próba.

Mérés

A DNS mérése három kérdésre felel: helyesek-e a rekordok, minden névkiszolgáló ugyanazt válaszolja-e, és elég gyors, megbízható-e a feloldás. A Search Console a kereső szemszögét mutatja, a parancssori és nyilvános eszközök a technikai részleteket.

Lekérdező eszközök

A dig és az nslookup parancs közvetlenül lekérdezi a rekordokat, akár egy megadott névkiszolgálótól is. Így ellenőrizhető, hogy minden mérvadó névkiszolgáló ugyanazt a választ adja-e, és mekkora a rekord TTL-je. Nyilvános, több földrajzi helyről lekérdező szolgáltatásokkal látható, hol él még a régi rekord egy változtatás után. A DNSSEC-et használó domaineknél külön ellenőrző eszközök mutatják meg, érvényes-e az aláírási lánc.

Search Console

A feltérképezési statisztikák jelentés gazdagép-állapot része külön mutatja a DNS-feloldás problémáit. Ha itt hibák jelennek meg, érdemes összevetni őket az időponttal, amikor a DNS-ben változás történt. Az URL-vizsgáló eszköz egy-egy oldalnál megmutatja, sikerült-e a lekérés, és ha nem, mi volt az ok.

Monitorozás és teljesítmény

A külső rendelkezésre állás-figyelő szolgáltatások rendszeresen feloldják a domaint és lekérik a webhelyet, így a DNS-hibát hamar jelzik. A domain és a tanúsítvány lejáratát is érdemes figyelni. A böngésző fejlesztői eszközeiben és a laboratóriumi mérőeszközök vízesésdiagramján látszik a névfeloldás ideje az egyes domaineknél, ami megmutatja, mely külső domainek lassítják a betöltést.

Ellenőrzőlista

Ellenőrzés	Eszköz	Jó eredmény
A és AAAA rekordok	dig, nslookup	Mindkettő működő szerverre mutat
Névkiszolgálók egyezése	Lekérdezés minden NS-től külön	Minden kiszolgáló ugyanazt válaszolja
Redundancia	NS rekordok	Több, független névkiszolgáló
TTL	dig	Stabil állapotban hosszabb, költözés előtt csökkentett
CAA	dig	A használt hitelesítésszolgáltató engedélyezve
Search Console TXT	dig	Az ellenőrző rekord megvan
Gazdagép állapota	Search Console feltérképezési statisztikák	Nincs DNS-feloldási probléma
Domain lejárata	Regisztrátor, monitorozó eszköz	Automatikus megújítás, riasztás lejárat előtt

Mérési ritmus

A DNS-t nem kell naponta nézni, ha a monitorozás be van állítva. Minden változtatás után, különösen szolgáltatóváltáskor és költözéskor viszont kötelező a teljes ellenőrzőlista, és a következő napokban a Search Console gazdagép-állapotát is érdemes figyelni. Évente egyszer érdemes a teljes zónát átnézni, és kitörölni a már nem használt, régi szolgáltatásokra mutató rekordokat, mert ezek biztonsági kockázatot is jelenthetnek.