Re: Eigene TopLevelDomain in BIND einrichten

On Wed, Apr 09, 2003 at 04:26:45PM +0200, Oliver Lehmann wrote:
> Hi,
>
> > In jedem Netz sollte ein Admin an den Hosteinträgen in seiner Zone
> > fummeln können, ohne das Abgleiche zwischen den NS notwendig sind. Das
> > Einträge nur an einem Master-NS verändert werden können wäre wohl am
> > umständlichsten (von multiplen Hosts aus gesehen), wenn auch am
> > übersichtlichsten.
>
> Das wuerde ich jedoch mit subdomains loesen. d.H. der master fuer
> "lan1.netz.tld" ist primary auf dem nameserver in lan1, und
> "lan2.netz.tld" ist primary im lan2 (und der jeweils andere dann
> secondary). Und netz.tld dann nur _einen_ master und _einen_ secondary. So
> koenne die "admins" auf beiden seiten "ihre" subdomain auf ihrem server
> anpassen, und diese sind auch in beiden netzen zur verfuegung. ansonsten
> koenne herliche probleme entstehen. dinge gehen in lan1, aber nicht in
> lan2 weil dort die nameservereintraege fehlen. Und alles in allem hat man
> mit 2 zu pflegenden DNS-servern auch doppelt so viel arbeit.
>
> LAN1 LAN2
> netz.tld primary secondary
> lan1.netz.tld primary secondary
> lan2.netz.tld secondary primary

Ich würde einen Primary für alles definieren und keine Extra Zonen
für die Standorte anlegen - Namentlich trennen kann man ja auch ohne
extra Zonen.
Damit dann jeder Standortadmin seinen Bereich selber verwalten kann
läst sich das ganze am einfachsten per CVS oder Subversion verwalten.
Wenn sich einer nicht an die Regeln hält, dann gibt es was auf die
Finger.
Alternativ kannst man ja immer noch extra Zonen anlegen und den
jeweiligen Standort DNS als Secondary definieren, dann hast du
auch im CVS die Möglichkeit andere Zonen zu sperren.
Bei Bedarf kannst du ja noch die Secondaries ins gleiche Repository
übernehmen.
Viele Primary sind Verwaltungstechnisch einfach unübersichtlich.
Es geht nichts über eine sauber zentralisierte Konfiguration.
In dem Fall ist auch das Backup einfacher, da auf einem Standortserver
keine relevanten Daten mehr liegen und man hat gleich eine Historie.
Fragen nach dem »wer hat es kaput gemacht« erledigen sich von selber.
Und da die meisten relevanten Fehlermeldungen vom Primary kommen hat
man das dann auch besser im Blick.
Zudem kannst du commits mit negativen Zonencheck sperren und
automatisiert die Seriennummer setzen.
Du glaubst nicht, wieviele Fehler das vermeided.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message