DNS

A DNS (Domain Name System) az internet egyik legalapvetőbb infrastruktúrája — egy globális, hierarchikus adatbázis, ami a domain-neveket (mint az eclick.hu) IP-címekké fordítja le, hogy a böngésződ tudja, melyik szerverhez kapcsolódjon. Lényegében az internet „telefonkönyve”. Egy webfejlesztési projekt során általában akkor találkozol vele érdemben, amikor új domain-t indítasz, hostingot vagy szolgáltatót váltasz, vagy egy beállítás (e-mail, CDN, SSL) nem úgy működik, ahogy várnád. A DNS hibák gyakran csendesek, és „véletlenül” tűnnek el — vagy nem.

Így is ismerheted

Magyarul leggyakrabban tartománynév-rendszer-ként vagy névfeloldó rendszer-ként emlegetik, de a szakmában gyakorlatilag mindenki a DNS rövidítést használja (Domain Name System). Kapcsolódó fogalmak: DNS-rekord (egy konkrét bejegyzés), DNS-szerver vagy nameserver (ahol a rekordok tárolva vannak), name resolution vagy névfeloldás (a folyamat maga). Egy domain-regisztrátor (pl. Namecheap, GoDaddy) ezt „DNS-zóna” vagy „DNS-management” néven kezeli az admin-panelben.

Hogyan működik egy DNS-lekérdezés?

Amikor beírod a böngészőbe, hogy eclick.hu, a következő láncolat indul el — másodperc tört része alatt:

1. A böngésződ rákérdez a resolver-re (általában az internet-szolgáltatód DNS-szervere vagy a 1.1.1.1 Cloudflare-szerver): „Mi az IP-címe az eclick.hu-nak?”
2. A resolver, ha nem tudja, megkérdezi a root DNS-szervert, az pedig irányítja a .hu TLD-szerverre.
3. A .hu TLD megmondja, melyik nameserver kezeli az eclick.hu-t (pl. Cloudflare nameserver-jei).
4. A resolver lekéri ettől a nameserver-től az IP-címet (pl. 185.51.190.31).
5. Visszaadja a böngészőnek, ami innentől HTTP-kérést küld erre az IP-re.

Az egész folyamat tipikusan 20–100 ms, de a resolver lokálisan cacheli az eredményt a rekord TTL-jének (Time To Live) megfelelően — így a következő látogatáskor nincs lekérdezés. Ez azért fontos, mert migrációnál a régi IP-t addig kapja a látogató, amíg le nem jár a TTL.

DNS-rekord típusok — amit minden projekten beállítasz

Egy átlag projekt DNS-zónájában 5–10 rekord van. A leggyakoribbak:

• A rekord — domain → IPv4-cím (eclick.hu → 185.51.190.31). A legfontosabb, e nélkül semmi nincs.
• AAAA rekord — domain → IPv6-cím. 2026-ban már alap, de még nem mindenhol kötelező.
• CNAME rekord — alias másik domain-re (www.eclick.hu → eclick.hu). A gyökér-domain (apex) NEM lehet CNAME.
• MX rekord — e-mail-szerver kijelölése (Google Workspace, Microsoft 365, vagy saját). Több MX prioritással is megadható.
• TXT rekord — szöveges adat. SPF (e-mail spam-védelem), DKIM, DMARC, domain-verifikáció (Google Search Console, Cloudflare).
• NS rekord — a domain nameserver-eit jelöli ki. Csak akkor kell hozzányúlni, ha DNS-szolgáltatót váltasz.

TTL és cache — miért lassú a változtatás?

Minden DNS-rekord-nak van TTL-je, ami megmondja, mennyi időre cacheli a resolver az eredményt. Tipikus értékek: 300 másodperc (5 perc) — agresszív, 3600 (1 óra) — átlag, 86400 (1 nap) — konzervatív. Ha most változtatsz egy A rekordon 86400-as TTL-lel, a változás 24 órán belül érvényesül globálisan — de a már lekérdezett resolverek a régi értéket tartják.

Praktikus trükk migráció előtt: csökkentsd a TTL-t 5 percre 24 órával előbb. Így az „új” TTL elterjed a resolver-ekben, és a tényleges migráció után 5 perc alatt minden átáll. Aztán a migráció után tedd vissza 1 órára vagy 1 napra a TTL-t. Erre a trükkre tipikusan akkor jövünk rá, amikor először migrálunk komolyabb forgalmú oldalt és nem értjük, hogy egyes felhasználók 12 óra múlva is a régi szerverre érkeznek.

Migráció és tipikus DNS-hibák

A DNS-migráció (pl. hosting-váltás) a legtöbb projekten a leglassabb és legkockázatosabb pont. Pár tipikus baki, amit többször láttunk:

• A apex-en CNAME van — pl. eclick.hu → cname.cloudflare.net. Ez nem szabványos (RFC szerint a zónacsúcs CNAME tiltott), egyes resolverek visszautasítják. Megoldás: ALIAS / ANAME rekord (Cloudflare, DNSimple), vagy A rekorddal egy fix IP-re.
• SPF rekord hiányzik vagy hibás — e-mailek spam-be mennek. v=spf1 include:_spf.google.com ~all minden Google Workspace-projekten kötelező.
• TTL túl magas migráció előtt — 24-48 órán át rossz IP-t kap a felhasználó.
• Hiányzó AAAA rekord — IPv6-os hálózaton (mobil 5G, Hetzner cloud) lassabb a kapcsolat fallback miatt.
• Vesszős CNAME-érték (pl. cname.cloudflare.net. a pont nélkül) — egyes szolgáltatók picky-k, a végén pontosan ott kell lennie.

DNS-tesztelő eszközök

A DNS-státusz ellenőrzéséhez ne a böngésződre támaszkodj — annak saját cache-e van, és gyakran régi adatot mutat. Használj célzott eszközöket: a dnschecker.org 20+ globális resolver-en mutatja egyidejűleg az aktuális választ. A dig (Linux/Mac) parancssoros tool ad pontos választ TTL-lel együtt: dig eclick.hu A +short. Windows-on a nslookup eclick.hu szolgál hasonló célt, csak kevésbé részletes.

SPF/DKIM/DMARC tesztelésére az mxtoolbox.com a klasszikus — ingyenes, gyors, és a problémát is megmondja közérthető szövegben.

Ha hosting-migrációval, DNS-átállással vagy domain-setup-tal foglalkoznál, és nem akarsz órákig nyomozni TTL-vel, lásd az egyedi weboldal-fejlesztés szolgáltatásunkat — ezeket gyakorlatból ismerjük, és el tudjuk vinni az áttelepítést úgy, hogy a látogató semmit ne érzékeljen. Kapcsolódó cikkek: CDN, Core Web Vitals, Robots.txt.