Névszerverek tündöklése és bukása, avagy dnscache probléma

Djb papa dnscache-e üzemel egy qmail mellett, mivel enélkül a qmail nem elég megbízható. Majd egy évtizede teszi mindegyik a dolgát. Bár hajdani fényük mára már igencsak megkopott, ám eleddig megmagyarázhatatlan jelenségeket még nem produkáltak.
Eleddig!Most azonban a dnscache egy domainhez elkezdett olyan A rekordot generálni, ami nincs neki. Régen volt, de ma már nincs.
A domain elsődleges névszervere szerint az A rekord az új, megfelelő érték.
A domain másodlagos névszervere szerint az A rekord az új, megfelelő érték.
Bármelyik névszervert is kérdezem, a domainről az új, hiteles adatokat szolgáltatják.
Kivéve, az én saját dnscache-emet.
Töröltem a cache-t. Ezek után rövid idegi a megfelelő új értéket szolgáltatja, majd egy idő múlva újra megjelenik a régi IP cím is, azaz két darab A rekordot rendel a névhez.
Próbáltam az elsődleges névszerveren sorszámot növelni, de nem változtat a problémán.
Egy ideig rendben volt a növelés után, de most ismét megjelent a régi, hiteltelen adat is.
Elképzelésem sincs, honnan származhat az információ.
A szervert kiszolgáló névszerver is a helyes friss adatokat szolgáltatja, de a dnscache, ha jól tudom, nem innen veszi az információkat, hanem a gyökérszerverektől.
Lehet, hogy valamelyik fránya szerver még tárolja a hiteltelen régi adatot, és djb papa épp onnan olvassa azt ki?
Ennek a dnscache-nek még a logja is olyan emberbarát, hogy annak alapján sem tudtam kideríteni, honnan származhat a fals adat.
Sajnos a dnscache nem megkerülhető, mivel ez az A rekord a domain MX rekordja, amit pedig a qmail szolgálna ki, a dnscache alapján.

Ha véletlen tudtok, a dnscache leváltására valami megbízható helyi névszervert, amit nem túl friss rendszerekre is viszonylag könnyen lehet telepíteni, és lehetőleg nem egy BIND 9, akkor azt is megöszönném.

Hozzászólások

Ez pontosan milyen rendszeren fut es mennyire publikus szerver?

Egy elég régi Ubuntu rendszer, debián 4.0-ának mondja magát a debian_version fájl alapján.
A névszerver kívülről nem elérhető, publikusan nem lehet tesztelni a problémát. Bármilyen külső névszervert használva a helyes értékeket mutatja a domain, csak a belső dnscache szennyeződik el. Ráadásul úgy jelenik meg két A rekord a domainhez, hogy soha nem volt olyan konfiguráció, amiben két A rekord lett volna megadva a mail zónához. Tehát nem jó elképzelés az sem, hogy valahonnan olvas egy régi állapotot, mert nem volt ilyen állapot soha.
Mivel ma jelezték újra a hibát - nem tudom, mióta volt rossz megint - két érdekes dolgot mégis megemlítenék, bár véleményem szerint egyiknek sem lehet köze a problémához.
- Az egyik, hogy most 3 napot állt a domain másodlagos névszervere. Az elsődleges rendben üzemelt.
- A másik, hogy a mai nap a rendszerben található RAID 1 egyik lemeze meghibásodott, és csak 3-szori cserére sikerült jóval helyettesíteni.
Bár egyik esemény sem befolyásolhatja a jelenséget, annyira ötletem sincs, hogy mégis megemlítem ezeket.

Mondjuk egy belső pl. wifi router dnsmasq-ja / saját dns-e például.?
--
God bless you, Captain Hindsight..

Megnéztem a dnsmasq leírását, és valóban állítja, hogy cache-el. Mégis fura, hisz kis rendszerek nem arról híresek, hogy túl sok helyi erőforrásuk lenne. Nehezen tudom elképzelni, hogy nagy mennyiségű névszerver adat elférjen egy routeren...
Használ valaki dnsmasq-ot helyi névszerver cache-nek? Így látatlanban éles rendszeren nem merném kipróbálni.