A „propagáció”: miért látja az egyik már, a másik még nem

6. modul: Idő, cache és domain átvitele · Olvasási idő: 8 perc

Tanulási cél: E lecke után meg tudja magyarázni, miért nem látható egy DNS-módosítás mindenhol egyszerre, meg tudja becsülni, mennyi ideig tart, és meg tudja oldani a problémát, ha csak Ön látja még a régi állapotot.

Kulcsfogalmak: „propagáció”, cache, negatív cache (NXDOMAIN), SOA-minimum, delegálási TTL, névszerverváltás, cache ürítése

Egy félreértés egyetlen szóban

Ön módosított egy rekordot. A kollégája már látja az új weboldalt, Ön még a régit. Az interneten ilyenkor azt olvashatja: „csak várjon, a DNS-nek még propagálódnia kell.” A propagáció (terjedés) szó azt a benyomást kelti, mintha a módosítás hullámként söpörne végig az interneten, szerverről szerverre.

Ez nem így működik. A módosítás azonnal megjelenik a domain autoritatív névszerverein (vagy néhány percen belül, ha a DNS-szolgáltatója több névszervert szinkronizál). Semmi nem kerül körbeküldésre. Amit Ön tapasztal, az a cache-ek lejárta: minden resolver a régi választ adja, amíg a cache-ében lévő TTL le nem jár (6.1. lecke). Mivel minden resolver más pillanatban kezdett számolni, az egyik hamarabb látja a módosítást, mint a másik.

A „propagáció” tehát valójában azt jelenti: várni, amíg az összes cache kiürül. Ez a felismerés segít, hiszen most már pontosan tudja, mire vár, és legfeljebb mennyi ideig.

Mennyi ideig tart?

Ez attól függ, mit módosít.

Meglévő rekordok

Itt egyszerű a helyzet: a régi TTL a maximum. Ha a rekordnak 3600-as TTL-je volt, mindenki legkésőbb egy órával a módosítás után látja az új választ. Ha valaki több mint egy óra múlva is még a régit látja, akkor a probléma máshol keresendő (lásd lentebb).

Új rekordok és a negatív cache

Egy új rekord gyakran azonnal működik, kivéve ha valaki már lekérdezte a nevet, amikor az még nem létezett. A resolver ekkor az NXDOMAIN („ez a név nem létezik”) vagy „ez a név létezik, de nincs ilyen típusú rekordja” választ kapta. Ezt a „nem”-et is megjegyzi. Ezt hívjuk negatív cache-nek.

Az, hogy meddig őrződik meg egy „nem”, nem szerepelhet egy nem létező rekordban. Ez a zóna SOA-rekordjából származik: az RFC 2308 szerint a két érték közül a kisebbik számít, vagyis a SOA-rekord saját TTL-je és a SOA-rekord utolsó mezője (a „minimum”). Példa:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
                             2026110701 ; sorozatszám
                             14400      ; refresh
                             3600       ; retry
                             1209600    ; expire
                             300 )      ; minimum

Itt egy „nem” legfeljebb 300 másodpercig őrződik meg (a 3600 és a 300 közül a kisebbik). Más zónáknál ez akár egy óra vagy több is lehet.

Ezért az aranyszabály: ne nyisson meg egy új aldomaint a böngészőjében, mielőtt létrehozta volna. A számítógépe és a resolvere ugyanis megjegyzi, hogy nem létezik, és Ön lesz az egyetlen, akinek várnia kell.

Névszerverek módosítása

Névszerverváltáskor valami másra vár: a kiterjesztése nyilvántartójánál szereplő NS-rekordokra. Ezek a rekordok mondják meg a resolvereknek, hol találhatók a domain névszerverei (2.1. lecke), és ezeket is megjegyzik. Minden nyilvántartó saját TTL-t választ ehhez. 2026 novemberében mérve:

Ehhez jön még, hogy a nyilvántartó néha nem azonnal teszi közzé a módosítást, és hogy a korábbi szolgáltató névszerverei időközben gyakran még a régi zónával válaszolnak. Ezért névszerverváltáskor számoljon néhány órával, .com esetén pedig legfeljebb két nappal. Ügyeljen arra, hogy a váltás idején mindkét félnél ugyanazok, helyes rekordok szerepeljenek (6.3. lecke).

Csak Ön látja még a régit?

Egy online ellenőrző eszköz szinte minden resolvernél már az új választ mutatja, de Önnél nem? Akkor a régi válasz az Ön közelében van elraktározva. Haladjon végig ezeken a lépéseken, a gyorstól az alaposig:

1. Privát ablak vagy másik böngésző. A böngészője DNS-válaszokat és oldalakat is tárol.
2. Telefon 4G-n vagy 5G-n, wifi nélkül. Így a mobilszolgáltatója resolverét használja az otthoni hálózata resolvere helyett.

3. A számítógép cache-ének ürítése.

   • Windows (Parancssor): ipconfig /flushdns
   • macOS (Terminál): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux systemd-resolved esetén: resolvectl flush-caches
4. Router újraindítása. Sok router kis resolverként működik, saját cache-sel.
5. Hosts-fájl ellenőrzése. Tesztelt már korábban egy új szervert úgy, hogy a címet a hosts-fájlba írta (C:\Windows\System32\drivers\etc\hosts vagy /etc/hosts)? Az ott szereplő sor megelőzi a DNS-t. Törölje azt. Ezt gyakran elfelejtik.
6. Közvetlenül a forrásnál ellenőrizni. Kérdezze le a rekordot az autoritatív névszervertől (dig A example.com @ns1.hosting.example). Ha ott is még a régi válasz szerepel, akkor a módosítás nem lett megfelelően elmentve, vagy rossz helyen végezte el.

A várakozási idő után sem változik semmi?

Ha a TTL már régen lejárt, és az online eszközök is még a régi választ mutatják, akkor a várakozás hiábavaló. Ilyenkor valami más áll a háttérben. A három leggyakoribb ok:

• Rossz helyen módosított. A domain egy másik fél névszervereit használja (például Cloudflare vagy egy webépítő szolgáltatás), Ön pedig a tárhelyszolgáltatójánál módosította a rekordokat. Nézze meg, mely névszervereket használja a domain (2.1. lecke), és ott végezze el a módosítást.
• Elgépelés vagy hiányzó pont. A mail.example.com pont nélkül sok panelben mail.example.com.example.com-má válik (2.2. lecke).
• A névszerverek nincsenek egymással összhangban. Egy domainnek legalább két névszervere van. Ha ezek nem szinkronizálnak megfelelően, az egyik az új, a másik a régi választ adja. Hasonlítsa össze a SOA-sorozatszámot minden névszervernél: ezeknek egyezniük kell.

dig +short SOA example.com @ns1.hosting.example
dig +short SOA example.com @ns2.hosting.example

A gyakorlatban: így néz ki egy panelben

Ha meg szeretné nézni, mit válaszolnak a resolverek a világ különböző pontjain, használjon egy olyan online DNS-ellenőrzőt, amely országonként kérdez le egy resolvert (például dnschecker.org). A példapanelben, a Fiókom felületen a Domain név / E-mail egészségi állapota kártya ellenőrzi a domain névszervereit és rekordjait az autoritatív névszervereknél, a DNS-diagnosztika pedig összehasonlítja a névszerverek sorozatszámait. Más szolgáltatóknál gyakran hasonló ellenőrzés található a panelben; ha nem, akkor a dig és a 8.3. leckében szereplő online eszközök ugyanazt az eredményt adják.

Összefoglalás

• Semmi nem „terjed”: Ön arra vár, hogy a cache-ek lejárjanak.
• Egy módosított rekord legkésőbb a régi TTL elteltével mindenhol látható; egy új rekord általában azonnal, kivéve ha valaki korábban már lekérdezte a nevet (negatív cache, amelyet a SOA-rekord határoz meg).
• A névszerverváltás a nyilvántartónál szereplő TTL-től függ: .nl esetén egy óra, .com esetén két nap.
• Csak Ön látja még a régit? Privát ablak, 4G, cache ürítése, router újraindítása és a hosts-fájl ellenőrzése.
• Még mindig régi az autoritatív névszervernél? Akkor a várakozás hiábavaló: keresse meg a hibát.

Kvíz

Feladat

Feladat Z6.2: Delegálási TTL és negatív cache. Két kérdés, mindkettő megválaszolható a dig paranccsal vagy egy online dig-eszközzel:

1. Hány másodpercig jegyzik meg a resolverek a .com nyilvántartó szerint a google.com névszervereit? Kérdezze le egy .com szervertől: dig NS google.com @a.gtld-servers.net és nézze meg a TTL-t az AUTHORITY részben.
2. Hány másodpercig jegyzi meg egy resolver, hogy egy sidn.nl alatti név nem létezik? (A sidn.nl a SIDN, a .nl domainek holland nyilvántartójának weboldala.) Kérdezze le a sidn.nl SOA-rekordját az ns1.sidn.nl szervertől, és alkalmazza a leckében tanult szabályt (a SOA-TTL és a SOA-minimum közül a kisebbik).

További olvasnivaló

Az ezekben a cikkekben szereplő lépések a WebOké paneleire vonatkoznak; más paneleknél hasonlóan működik.

• Mennyi ideig tart egy nameserver- vagy DNS-módosítás, és mi a teendő, ha nem látja a változást?
• A weboldal vagy az e-mail nem működik költözés vagy DNS-módosítás után: ellenőrizze a domainjét
• DirectAdmin útmutató 5.11: Mikor lép életbe egy módosítás? Várakozási idő és TTL
• Aldomén létrehozása, és teendők, ha az nem működik
• WebOké útmutató 5.17: Domain és e-mail állapota: ellenőrzés és javítás