Re: nächtliche mails an root?

On Tue, Mar 02, 2010 at 03:53:57PM +0100, Marian Hettwer wrote:
> On Tue, 2 Mar 2010 14:24:57 +0100 (CET), Oliver Fromme
> <olli(at)lurza.secnetix.de> wrote:
> >
> > Wenn es Bedarf dafür gibt, dass der Provider etwas manuell
> > editieren muss, dann hat er irgendwas falsch gemacht.
> >
> Genauso sehe ich das auch.
>
> > Bei einem guten SQL-Server (also nicht mysql ;-) ist der
> Und ich hätte im originalpost beinahe mysql geschrieben. Habe aber dann
> noch die Kurve bekommen, um nicht weitere Angriffspunkte zu bieten ;-)
>
> > Overhead nicht nennenswert höher, als wenn der BIND erst
> > eine ASCII-Zone-Datei parsen muss.
> >
> ACK.
>
> > weiß so mancher "DNS-Experte" nicht richtig). Die Syntax-
> > Regeln für Zone-Files sind ja durchaus nicht einfach, und
> > es gibt zahlreiche fiese Stolperfallen. Aber diejenigen
>
> Aber ja. Genau. Ich bekomme in meinen Kopf nicht rein, was bind gegen ne
> raute (#).
> Das kommentarzeichen ist halt ein semikolon. Klingt komisch, ist aber so.

Zugegeben - das ist anders als an vielen anderen Stellen.
Aber deswegen ist es ja nicht gleich unbenutzbar.

> > Kunden, die sich damit auskennen und wissen, was sie tun,
> > können dann ja meinetwegen auch das "Eingemachte" editieren.
> > Einige ISPs ermöglichen das z.B. per Mail-Templates, was
> > wiederum kundenseitige Automatisierung ermöglicht.
> >
> Der hetzner domain robot beispielsweise. Für meine private handvoll
> domains im Einsatz und eigentlich bin ich damit ziemlich glücklich.

Der kann Zonen signieren?
Das fängt schon damit an, dass ich zum signieren meinen eigenen Schlüssel
nicht unbedingt rausgeben mag.
Der bietet dir dynamischen Zugriff per RFC2136?
Ja - das brauchen die meisten nicht, aber es gibt durchaus
Anwendungsfälle.

> > Aber egal, wie die Daten vom Kunden kommen, in der Regel
> > landen sie in einer SQL-Datenbank, die gleichzeitig auch
> > die Versionierung übernimmt. Backup und HA ergibt sich
> > durch SQL-Replikation automatisch. Was will man mehr?
> >
> Nochmal ACK.
>
> > Ganz ehrlich: Wenn Firma XYZ eine Abteilung mit zwanzig
> > neuen Kisten ausrüstet, oder eine Serverfarm um hundert
> > Blades aufgestockt wird, dann hockt sich da keiner hin
> > und hackt die ganzen DNS-Daten in irgendeine Textdatei.
> > Das will keiner. Nicht in diesem Jahrtausend.
> >
> Es gibt leider noch genug firmen die sowas machen *grusel*.

Mir gruselt es eher beim Gedanken, dass bei vielen Firmen DNS zu
Absurdität verkümmert ist.

> Und zone files via helper scripte zu erweitern ist irgendwie auch keine
> option.

Ansichtssache.
Ich mag mich jedenfalls nicht einschränken, weil alle exitierenden
Features im bind durchaus Anwendungsfälle haben, von denen ich die
allermeisten schon gebraucht habe.
Ich gehe meist einen Mischweg, indem ich Files komplett aus SQL
erzeugen lasse und andere komplett händisch pflege.
Dazu gehört auch die named.conf, die per includes in automatische
und händische Files unterteilt ist.
Aber bisweilen macht es auch Sinn die automatisch erzeugten Files noch
mal nachzutunen und auch das geht sehr leicht.
Oftmals anzutreffen sind auch komplett getrennte Nameserver, wobei
dann kein tunen mehr möglich ist und man Zonenfiles zwangsläufig
komplett aus dem Automatismuss nehmen muss.
Leider viel öfters anzutreffen ist Schulterzucken.
Arcor z.B. konnte letztens CNAMEs im Reversemapping mit deren System nur
in einer neuen Unterzone anlegen, die die aber immerhin frei delegieren
konnten, reichte mir aus, aber deren Möglichkeiten sind begrenzt.
Ich hätte die gerne in der bereits exitsierenden Forward-Zone verwaltet,
was in der Praxis für Clients weniger Requests bedeutet hätte.
Man muss aber heutzutage dankbar sein, wenn man bei einem großen
Anbieter überhaupt CNAMEs bekommen kann.

> Der syntax von einem bind zonenfile geht mir persönlich auf den senkel. Da
> stoße ich an meine schnöden sed und perl kenntnisse ;)

Habe ich vermutlich schon viel zu oft gemacht, um da noch Hindernisse
zu sehen.
So manche Klassiker, wie Umbennennung der MX sind in SQL natürlich
leicht umzusetzen, aber das ist auch nicht der Punkt.
08/15 Zonen in SQL zu verwalten ist auch Ok, nur sehe ich am Ende
eben gerne echte Zonenfiles.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message