DNS cache mulatozás

 ( maszogep | 2018. december 7., péntek - 12:53 )

...ööö, ehhez lövésem sincs igazából, de érdekes: adott egy szerver, adott az IPje. Van egy másik szerver, másik IPvel.Az egyik szerverről átköltöznek a honlapok a másikra. A domain átregisztrálásra kerül, az átreget követően a zóna az új szerver IPjére mutat. Namost. T-home hálózatból a napokkal ezelőtt átregelt domainek némelyike (nem mind) random egy szemvillantás alatt a régi helyről hozza a tartalmát. Cache természetesen ürítve, router reboot megvolt, többször is. Az érdekelne, hogy ez a hiba honnan keletkezhet? Valamelyik T névszerver baszakodása? Csak mert elég bsosszantó, hogy amikor az új szerveren elhelyezett honlap adminjába belépve, meló közben egyszer csak bontja a munkafolyamatot, és ha újra be akarok jelentkezni, akkor a régi szerverre léptet be. Ilyenkor a host -t A is mutatja szépen a régi szerver IPjét. Legyalulni onnan még nem akarom a cuccot, mert ha valamit nem jól mentettem le, akkor egyszerűbb így online elérni az új szerverről a zóna átirányításával.

Amikor így kidob, akkor 10-12 perc múlva egyszer csak magától visszaáll az új IPre, és lehet megint dolgozni.

Ezt okozhatja az, hogy két helyen is megvan a zónafájl, vagy ez valami T-átokverése?

mellékesen van egy olyan jelenség is, hogy a legtöbb oldal letöltése előtt szüttyög egy-három perc intervallumban, "szerver azonosítása" címszó alatt, majd villámgyorsan letölt. Speedtest.net gyönyörűen hoz mindent, ping, up/down sebesség korrekt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Lesd meg azt is hogy nincs-e IPv6-os cím megadva a domain record-ban (AAAA-val kezdődik), lehet az okozza az anomáliát

A régi helyen tuti nincs, az újnál egyetlen sort látok, amiben az ip6 egyáltalán szerepel, de az se AAAA:

@ 3600 TXT "v=spf1 ip4:94.125.179.20/32 ip4:78.24.186.224/28 ip4:78.24.185.80 ip6:2a01:270:2034::/120 ?all"

...ráadásul ez az összes hozzájuk vitt domain zónájában benne van, de csak néhány szarakodik, a többi megy szépen. Semmit észrevehető különbséget nem látok a jól működők zónabeállításai és a random működők beállításai közt. :/

---
Ó, hogy a hatalmas Kublaj kán üssön rajtad, és a házad népén!

Gondolom az történt, hogy a rekordok TTL értéke jó nagy (mondjuk egy hét) volt az átállás előtt és emiatt azt sokan és hosszú időre gyorsítótárazták.
Most persze veszett fejsze nyele, de az átállás előtt legalább TTL idővel a TTL mező értékét kicsire kell venni (pl 1 perc) az átállás után mehet vissza a nagy TTL ettől minden gyorsítótárból kiesik és gyorsan elterjed a jó érték.

+1
manapság már nem divat a 24/48 órás TTL, főleg a klódvilágban, ahol ált 15 percre leveszik, ha kiesés van gyorsan átálljanak a népek az új szerverre. A DNS szervereket meg senki nem kérdezte :)
--

Ez lehetett a megoldás, mert ma már teljesen normálisan ment a kérdéses domain, nem volt vele probléma.

szerk.: egy jó négy órán keresztül ment, aztán újra előjött a hiba. :/
---
Ó, hogy a hatalmas Kublaj kán üssön rajtad, és a házad népén!

nekem is volt hasonlo problemam, a megfejtes az volt, hogy a problemas domaint a T-tol koltozttettuk el, es az egyik T nevszerverbol nem toroltek a domaint; tehat ans0.t-online.hu -bol toroltek, ans1.t-online.hu -bol meg nem, es amelyiket eppen megkerdezi a geped, annak megfeleloen valtozik az ip.
nslookuppal hamar kiderul.

--
HUP te Zsiga !

Pontosan ez volt egyszer a problemam Hungarotel-nel is (beke poraira a rohadek cegnek). Hungarotel ugyfelek a regi oldalt lattak, mindenki mas az ujat. Benne maradt a DNS-ben atreg utan. Hogy ez hogyan fordulhatott elo (aka root cause) arra diszkreten nem valaszoltak.

Szerk.: Soha tobbe az eletben nem regeltem domaint ISP-nel.
____________________
echo crash > /dev/kmem

Ha jól van konfigurálva a name szerver olyan nincs, hogy az egyikből törlöd a másikból nem. Az elsődleges name szerverben (amire a zóna SOA rekordja mutat) kell megváltoztatni és a másodlagosak meg szépen átveszik egy idő után.
A gond akkor van, ha a SOA rekordban levő időtartamokat per has állította valaki és emiatt a másodlagosak ritkán frissülnek. Ha egy másodlagos egy ideig nem éri el az elsődlegest szolgáltathat régit de csak az expire ideig, amit szintén a SOA rekordból kap, annak a lejárta után el kell dobni.
Szóval akié a master name szerver ezzel a zóna SOA rekordja annak érteni kell hozzá. Ez az ember lehet a szolgáltatónál is, de lehetsz te is ha hozzáférsz a domainedhez tartozó SOA rekordhoz.
A DNS rendszer igen robosztus, tehát akár teljesen elrontott zóna fájlokkal is tud működni, csak telerakja a logokat üzenettel és ha valami változtatás van akkor inkonzisztens lesz. Így aztán aki nem ért hozzá az is azt gondolja, hogy igen, hiszen az idő igen nagy részében működik.

"Ha jól van konfigurálva a name szerver olyan nincs, hogy az egyikből törlöd a másikból nem."

Már hogyne lenne. Ha neked A dns szerveren van egy domained melyet B kliens használ névfeloldásra, akkor A és B honnét tudná, hogy te ezt a domain elköltöztetted egy C dns szerverre? Kisebb ISP-knél régebben divat volt (meg talán most is az), hogy ez nem így van, azaz az ügyfeleiknek szolgáltatott rekurzív dns egyben az elsődleges/másodlagos, illetve az atoritatív is (persze lentebb írta valaki, hogy a T-nél nem így van), ezért gyakori volt ez a hiba, hiszen elég csak az ügyintézőnek elfelejtenie, hogy törölje onnét, és már meg is van a baj.

"Az elsődleges name szerverben (amire a zóna SOA rekordja mutat) kell megváltoztatni és a másodlagosak meg szépen átveszik egy idő után."

Ennek semmi köze a másodlagoshoz, egyik dns infrából vitte a domaint a másikba, ez a dolog nem technikai jellegű (vagy legalábbis nem úgy...), regisztrátor ütötte át neki. A két infra elsődleges ÉS másodlagos szerverei erről mit sem tudnak, így ha a régi helyen nincs törölve, akkor az vígan szolgáltatni fogja a régi bejegyzéseket az idők végezetéig (vagy amíg ki nem törlik).

Persze lentebb kiderült, hogy nem ez volt a gond, de ettől még simán lehetett volna a fentiek együttállása esetén. Azt persze tegyük hozzá, hogy ebben az esetben "billegés" kizárt, fixen a régi/hibás rekorodkat kapta volna a böngésző.

Ez akkor lenne így, ha a T-nél nem lenne szétválasztva az auth és a rekurzív NS. De szét van. Szóval ott valami más baj volt (illetve benne volt még az az NS is a zóna NS rekordjai között).

Kivették tegnap az ipv6 cuccot a szolgáltatásból, azóta megy mindenem rendesen. Egyébként nincs több ötletük, de úgy tűnik, ez bevált.
---
Ó, hogy a hatalmas Kublaj kán üssön rajtad, és a házad népén!

Nagyon egyszerű: változott a SOA recordban a serial és végre lefrissítette az összes nameserver node a zónátokat :). Amúgy a legtöbb szolgáltató -sajnos- leszarja a bállított ttl-eket..

Miért szarná le? Ez valami urban legend.

Caching nameserverek (pl. az ISP-nél) simán override-olhatják a TTL-t.
--

igen, de ki csinál ma ilyet?

"igen, de ki csinál ma ilyet?"
Főleg azok akik botrányvezérelten működnek: nincs botrány és nem dől össze az adott gép: nem változtatnak rajta semmit.

A Datanet 10 éve valóban így tett, de már rég nem tapasztaltam ezt sehol.

tapasztalat, bár valóban nem reprezentatív felmérésen alapul, csak saját tapasztaláson :)

Nem biztos hogy leszarja, egyszerűen nem vette át a változást. Új serial érték miatt most már igen. Nem hiba hanem jelenség ;)

Hibajelenség =D