Re: nächtliche mails an root?

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Tue, 2 Mar 2010 16:22:02 +0100 (CET)

Bernd Walter wrote:
> Oliver Fromme wrote:
> > Wenn es Bedarf dafür gibt, dass der Provider etwas manuell
> > editieren muss, dann hat er irgendwas falsch gemacht.
>
> Das setzt voraus, dass die Daten, die der DNS liefert automatisch
> erzeugbar sind und das ist einfach nicht garantiert.

Du missverstehst mich -- Warum sollte der Provider an
Kundendaten herumeditieren? Das hat maximal der Kunde
selbst zu tun. Aus den Daten, die der Kunde liefert,
wird dann die Zone generiert, und zwar direkt in
binärer Form in der DB, ohne unnötigen Umweg über ein
ASCII-Zonefile.

(Das wäre zumindest der Idealfall. Dass das in der
Praxis nicht unbedignt immer genau so funktioniert,
sei mal dahingestellt.)

> > > Klingt alles nett, aber das ist Augenwischerei.
> > > Du willst einen A-Record für foo auf 1.2.3.4 haben.
> > > Du kannst dir das jetzt aussuchen, ob du das in einer Weboberfläche,
> > > einem Zonenfile oder sonst wo schreibt.
> > > Du wirst aber immer die gleichen Datenmenge verwalten müssen, oder dich
> > > in den Möglichkeiten einschränken.
> >
> > Ich muss gar nichts verwalten. Genau dafür ist die SQL-
> > Datenbank da (mit einem hoffentlich sinnvoll geplanten
> > Datenbankschema).
>
> So ein A-Record ist also _immer_ Gott gegeben und man muss den
> demzufolge auch nicht verwalten?
> Das ist doch Unsinn.
> Wenn ich foo auf 1.2.3.4 haben will, dann weil ich _ich_ das so
> entschieden habe - wenn Automatismen meine Gedanken lesen können
> wäre ich froh und entsetzt zugleich.
> Ergo muss ich das auch selber verwalten.
> Klar reicht es für dynamische IPs sich automatisch erzeugbare
> Namen zu erfinden, aber das ist doch nicht immer anwendbar.

Wir reden schon wieder aneinander vorbei, wahrscheinlich
weil wir uns über den Begriff "verwalten" nicht einig
sind. :-)

Selbstverständlich darfst Du foo auf 1.2.3.4 haben, wenn
Du das willst. Aber verwalten tut das trotzdem die DB.

> > > Wo ist der Vorteil bei SQL?
> > > Ich sehe da immer nur den Overhead.
> >
> > Zum Thema SQL gibt's hunderte von guten Büchern. Daher will
> > ich da jetzt nicht die Vorteile auseinanderklamüsern.
>
> Die Vorteile von SQL kenne ich.
> Ich sehe nur keinen Nutzen im Bereich DNS.

Ich sehe keinen Nutzen darin, Daten, die ohnehin einmal
geparst und validiert werden und in maschinenlesbarer
Form vorliegen, in hunderttausend einzelnen ASCII-Dateien
vorzuhalten.

> > Bei einem guten SQL-Server (also nicht mysql ;-) ist der
> > Overhead nicht nennenswert höher, als wenn der BIND erst
> > eine ASCII-Zone-Datei parsen muss.
>
> Klar, aber das der Overhead nicht nennswert höher ist macht
> die Sache ja nicht besser.
> Aber schon mal Zonen signiert, die im SQL liegen?
> Klar geht das, aber die vemeintliche Eleganz vom SQL ist dahin.

Ich persönlich finde SQL ohnehin nicht besonders elegant.
Es kommt halt immer auf den praktischen Nutzen an.

Theoretisch könnte man die Zonen natürlich auch in einer
nichtrelationalen Datenbank verwalten, z.B. dokumenten-
basiert. Würde hier vielleicht sogar Sinn ergeben.
Ich weiß aber nicht, ob es Provider gibt, die das in der
Praxis machen.

Es kommt natürlich auch immer auf den Provider an.
Billige Massenhoster, die DNS als Gratis-Dreingabe machen,
investieren natürlich nicht allzuviel Hirnschmalz in die
ganze Sache. Da muss man mit Einschränkungen leben.
In diesem Punkt hast Du sicherlich (leider) recht.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"A misleading benchmark test can accomplish in minutes
what years of good engineering can never do." -- Dilbert (2009-03-02)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 02 Mar 2010 - 16:22:24 CET

search this site