Redundás DNS szolgáltatás?

Hálózatok általános

Tervezek egy viszonylag hibatűrő clustert, ám van benne egy komoly SPF, mégpedig a DNS szerver. Ha az megpukkan, vagy nem érhető el, lásd a minapi VH-beli delejszünetet, akkor a zóna adatai nem módosíthatóak, ám erre - különösen átterhelés esetén - szükség van.
Létezik-e olyan szolgáltató, aki ad olcsó pénzért valami kényelmesen használható, ám nagy rendelkezésre állású DNS szolgáltatást?

--- Update :

Nos, kialakult bennem a kép az ideális szolgáltatásról, amit keresek. Lenne egy kényelmesen használható, egyszerű felület, amilyet pl. a DynDNS is tud adni. Normál esetben ezen keresztül lehetne adminisztrálni a zónát. A delegált, bejegyzett szerverek viszont itthon vannak, és a "webes" szerverből szedik az oxigént, a kliensek ezeket a szervereket kérdezgetik. Ha a zóna módosítására van szükség, _és_ nem érhető el a webes felület, akkor akár kézzel is meg lehet módosítani a zóna adatait.

Tudom, hülye ötleteim vannak :D

  • 2212 megtekintés

( mauzi v | 2009. 07. 21., k – 18:04 )

ha a DNS fizikailag máshol van, mint ahol a védendő redundáns rendszer, akkor matematikailag igen kicsi a valószínűsége, hogy egyszerre legyen üzemzavar mindkét helyen.

márpedig, ha a védendő rendszeren van kiesés, akkor tudsz DNS-t módosítani, ha pedig a primary DNS esik ki, akkor jó eséllyel nem kell pont akkor zónát módosítanod, a kiszolgálást pedig elvégzik a slave-ek.

jól sejtem?

Jól, csak ebben az esetben nekem kell +1 gépet hostolnom valahol. Különösen, hogy a védendő rendszer is két helyen van, két külön kerületben, egy harmadik helyre kéne betennem a plusz gépet. Nem beszélve arról, hogy ha komolyan akarja az ember csinálni, akkor rendes szerver kéne, esetleg cluster, esetleg olyan cluster, ami két külön gépteremben van. Sok-sok plusz munka, amit hátha valaki már megcsinált :D

DNS-nek tok felesleges a cluster, de meg a "rendes" szerver is (felteve persze, hogy nincs komolyabb terhelese). A lenyeg, hogy legyen belole minel tobb.

Ilyet egyebkent csinalnak tobben is, pl. a dyndns, backupdns, etc, a google tele van veluk.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Ezzel is az a baj, ami a többivel, hogy "csak" másodlagos DNS. Ennek is kell egy forrás, aminek viszonylag megbízható gépen kell lennie, a clustertől független hálózaton/szolgáltatónál, szóval nem nyerek vele semmit. Nekem primary vagy primary/secondary kell, ahol akár webes felületen, akár parancssorból vagy valahogy el tudom tárolni a zónámat, de nem nekem kell fenntartani a DNS szervert.
Értem én, hogy a primary lehetne akár az itthoni gépem is, és replikálhatom a rettenetesen nagy zónát (van benne vagy tíz bejegyzés) huszonhét másik szerverre, és nagyjából elég csak akkor működnie amikor változtatni akarok valamit. De azt hittem, hogy van valami olyasmi szolgáltatás, amit a hosting vagy domain reg. cégek adnak a csomagba, hogy lehet matatni a zónákat, ahogy jólesik. Mégegyszerűbben: hasonló kéne mint a webmin (már ha jól tudom, hogy mi az a webmin :))

Igen, van fuss foresztfuss accountom is, ám ott csak a náluk regelt domaineket tudom matatni, ami még nem is lenne baj, de a domainadmin felülete szerintem bonyolultabb mint egy kaptárhajó vezérlése :D Update: egyébként tökéletes lenne, de most kb. 5 perc alatt nem találtam meg az "ismerős" admin felületet, mert alighanem frissítettek :D

( janoszen v | 2009. 07. 21., k – 20:02 )

PowerDNS-t LDAP-pal és replikációval, akkor tudod frissíteni a zónáidat kimaradásnál is.

( andrej_ v | 2009. 07. 21., k – 20:33 )

Írtam volna privátot de akkor leírom ide. :)

Vegyél valahol egy VPS-t és tedd meg elsődleges NS-nek. Ez legyen tőled független hosztnéven és IP-n regisztrálva a rootns-ben is. A clusteredet tedd meg másodlagos és harmadlagos NS-nek, amik lehetnek már "szép hosztnéven". Bónuszként a jófej VPS szolgáltató a saját NS-én is tud neked adni egy negyedlegest. Általában ilyenkor az a helyzet, hogy ha egyik sem elérhető, akkor már mind1 a clusternek. :P

Még az jutott eszembe, hogy csinálj egy úgymond alvó elsődlegest is, ahonnan a másodlagos ns-ek elfogadnak axfr-t meg notify-t.

A VH-ban egyébként csak néhány dízelmentes területen nem volt áram tudtommal. A VH-n kívül pedig egészen jó az élet: ProServer újpalotán, IW terem délbudán és még sorolhatnám...

Tudom, van több gépem a VH-ban, és egyik se panaszkodott. Proservernél is van, matávnál is van, ez nem gond :D
Viszont megint az eredeti probléma: miért csináljak magamnak munkát a VPS-el, binddel (Os frissítés, bind - vagy az ami - frissítés, ugye mindenki emlékszik még a nem is olyan régi ssh hisztire?) ha van már erre megoldás? Már ha van. Mert egyébként én is erre gondoltam, hogy veszek egyet és hajrá. De akkor plusz egy gép, amit illene monitorozni, miegyéb. Nem beszélve arról, hogy egy általam elképzelt szolgáltatás mondjuk kb. pártíz USD egy évre, egy vps meg havonta annyi. Vagy több.
És nem mellesleg nem csak nekem kell érteni hozzá, hanem másnak is, tehát nem jó az, ha a ssh dns010@nec.artec.ic.ac.doc.uk "~/bin/update_ns.sh primary takeover -now -nonotify -mail -log -restore" paranccsal kell pl. módosítani a zónát. Bár nekem tetszik :D

Most vagy akarsz ilyet vagy nem. Occóért max másodlagos ns-t vagy nyomkodós NS-t kapsz küffődön, aztán az itthon nem biztos hogy mindíg mindenhonnan jó lesz (legalábbis kevésbé, mint egy hazai).

SSH nélkül pedig elég nehéz lesz, ami van NS és MySQL based (mint pl. mydns) azok nemnagyon támogatnak notify-t példul. Mondjuk egy notify jó eséllyel összehozható valamilyen curl-os szolúcióval.

Milyen SSH hisztire gondolsz? Lassacskán kb. alap hogy default porton nem futtatunk ssh-t és hogy pl. dsa vagy rsa kulcsos és ha olyan akkor még ezt is csak adott gépekről engedjük tűzfalilag.

"Milyen SSH hisztire gondolsz? Lassacskán kb. alap hogy default porton nem futtatunk ssh-t és hogy pl. dsa vagy rsa kulcsos és ha olyan akkor még ezt is csak adott gépekről engedjük tűzfalilag."

Default porton én már csak akkor üzemeltetek SSH-t ha direkt be akarom engedni a támadót. :D
Otthon egy elszeparált gépen játszottam egy ilyet és felvettem rá pár fake usert, azt néztem mi történik.
Persze gonosz kismanó módjára egy két portot letiltottam a GW-en, hogy azért ne spammolhasson mint állat.

Persze lehet üzemeltetni default porton is de nem hiszem, hogy valaki önszántából szeretne bogarászni naponta pár ezer soros naplófájlokat
és keresgélni benne, hogy melyik volt a bot és melyik, akitől félni is kell. Hogy is van a mondás? Tűt a szénakazalban?

Bocs, nem ssh, ssl :D (DSA-1571-1) Értem én, hogy az ssh-t nem standard porton futtatja az ember (én mondjuk igen, és 4 címről engedek csatlakozást), de azzal, hogy nem standard porton van futtatva nem oldod meg a problémát, csak esetleg elfeded.

De az tény, hogy a plusz gép az plusz munka, plusz egy dolog amire figyelni kell, plusz egy dolog, amin keresztül a gonoszok entitások árthatnak.

Az SSH-t érő támadások 99%-a bot és rendesen karbantartott rendszeren nem fog bejönni. Ez az, amitől meg tudsz a más porton üzemeltetéssel szabadulni.
A maradék 1% pedig akkor játszik ha mégis valamely csúnya ok folytán be kell engedni valakit SSH-n de az a valaki szeret utazgatni. Stb Stb stb....

Én ettől az 1%-tól félnék jobban mint a botoktól.

( Fisher v | 2009. 07. 28., k – 10:23 )

Nos, kipróbáltam a DynDNS-t, és nem jó, mert csak a saját szervereit engedi a zónadelegálásba bejegyezni. Én viszont a saját szervereimet akarom ott tartani, hogy ha a DynDNS felülete nem érhető el, akkor kézzel át tudjam írni a zónákat.
Értem, hogy kizárt, hogy a DynDNS felülete ne legyen elérhető, ám tegnap este pont belefutottam egy nem tervezett karbantartásba. Azt is értem, hogy ennek ellenére elképesztően csekély az esélye annak, hogy épp a cluster halálakor lenne elérhetetlen a DynDNS, ám az átterhelést nem csak géphalál esetén akarom megcsinálni, hanem minden frissítéskor, így egyrészt nem felejtődik el a tennivalók listája, másrészt nem hiba esetén fog kiderülni, hogy miért is nem lehet átterhelni az egyik lábról a másikra.
Nem beszélve arról, hogy ha a zónainformációt (illetve egy A rekordot) csak a DynDNS felületén tudom módosítani az SPF, és én épp ezt akarom elkerülni.