[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Planung DNS-Migration
[Thread Prev] | [Thread Next]
- Subject: Re: Planung DNS-Migration
- From: Stefan Hagen <sh@xxxxxxxxx>
- Date: Thu, 21 May 2020 21:49:29 +0200
- To: uugrn@xxxxxxxxxxxxxxx
Marc Haber wrote: > On Wed, May 20, 2020 at 09:29:10PM +0200, Stefan Hagen wrote: > > Marc Haber wrote: > > > Wenn H _UND_ Jpru weg sind, ist im aktuellen Szenario die Domain > > > sofort weg. Die 1000 Stunden greifen bei einem Ausfall des > > > DNS-Masters; so lange sind die DNS-Slaves noch willig, die Daten > > > autoritativ auszuliefern (wenn sie denn noch da sind). > > > > Da hast du natuerlich recht. Fuer nen Verein dennoch ausreichend. Aber > > ich wuerde dann vielleicht Ausschau halten nach nem weiteren Slave. Beim > > Stammtisch meinte Sur5r er haette auch noch ne Kiste in Helsinki mit DNS. > > Die koennte noch Slave mit machen. > > Das ist dann aber auch im Hetzner AS, und Routingstoerungen sind haeufiger > als RZ-Ausfaelle. _jaha_. Schuetzt nicht gegen Routingprobleme aber gegen Hochwasser, Stromausfall, Wartungsfenster, Kabelstolperer und dergleichen... > > > Behaelt sie bei so einem Umzug ihre IP-Adresse? Sonst muesste man die > > > Slaves zusaetzlich noch anfassen und ggf. die Nameserver-Objekte bei > > > den Registraren aendern. > > > > Nur wenn man den Master umzieht oder? > > Der Umzug des Masters waere ja der Fall wenn man die VM nach Finnland > zieht. Nene, das meinte ich nicht. Ich meinte einen Slave in Finnland. Dann haben wir 2 auslieferende DNS Server bei H, aber eben nicht im Rack nebeneinander, sondern in unterschiedlichen RZ. > > Die Slave IP wuerde man ja auf dem > > Master aendern - und den haben wir ja im Griff. > > Andersrum. Auf dem Slave wird eingestellt, wo der Master ist. Beides eigentlich. Der Slave muss natuerlich wissen wo der Master steht. Der Master kennt normal aber auch seine Slaves und laesst nicht jeden AXFERn. Zumindest mein nsd will das wissen. > > Umziehen geht tatsaechlich nicht. Standort aendern geht indem man von > > einer VM nen Snapshot zieht, sie dann loescht und am neuen Standort > > wieder aus dem Snapshot heraus erstellt. > > > > Loeschen und neu erstellen gibt einem immer eine neue IP. > > Das taugt also nicht als "Umzug", das ist ein neuer Server, aus Sicht > des DNS. Macht Aufwand und braucht zeitlich koordinierten Zugriff auf > alle Slaves. Wir reden doch grade vom Initial-Setup, oder? Es gibt ja bis jetzt weder Master (aktiv) noch Slaves. Also quasi Null Aufwand, weil wir das ja eh noch alles machen muessen. Aber ich meinte das auch anders: 1 (hidden) Master bei H in Falkenstein 2 Slaves von Dwalin Damit koennen wir schon live gehen und sind von Top unabhaengig. Wir koennen den Master auch erst mal nicht hidden setzen, dann haetten wir zwei AS abgedeckt. Optionen haetten wir dann spaeter mit: 3 Noch einen Slave bei H in Falkenstein. Der hidden Master liefert ja selbst nichts aus. Der koennte also neben dem Master stehen. (ich hab meinen eigenen DNS da und koennte auch Slave machen) 4 Slave bei sur5r in Finnland (auch H, aber andere Location) 5 Slave bei Dir In der kleinen Ausbaustufe haetten wir dann den Master bei uns und eigentlich nur die Dwalin Slaves, die ausliefern, richtig? Das ist genauso wie jetzt auch und reicht zum loslegen. In voller Ausbaustufe haetten wir dann: Anbieter/AS: 3 Geografische Orte: 4 Das ist fuer nen Verein schon verdammt ordentlich und vermutlich mehr als die meisten Firmen haben. Koordination mit Dwalin gibts unter der Annahme dass wir uugrn.org/.de jeweils eine Zone geben bei der kleinen Ausbaustufe einmal. Wenn wir weiter ausbauen brauchen wir ihn nicht dazu, weil wir nur Slaves hinzufuegen und die voneinander nichts wissen muessen. > Ich habe die Wikiseite aktualisiert. Ok, schau ich mir an. Kommst du zum Jitsmi eigentlich mal dazu? Das Jitsi laeuft inzwischen recht ordentlich. Bis denne, Stefan -- Stefan Hagen | (gopher|https)://codevoid.de/0/gpg CBD3 C468 64B4 6517 E8FB B90F B6BC 2EC5 52BE 43BA