linux-l: dns-server

Steffen Dettmer steffen at dett.de
Mo Jan 7 13:11:39 CET 2002


* Thomas Knop wrote on Mon, Jan 07, 2002 at 11:23 +0000:
> * Steffen Dettmer <steffen at dett.de> [07.01.02]:
> >* Thomas Knop wrote on Fri, Jan 04, 2002 at 13:22 +0000:
> [..]
> >Na ja, die neuen Versionen wurden ja nun nicht wegen der Bugs
> >entwickelt. Bind 8 kann eben mehr und schicker als 4 und 9 kommt

> genau liegt der Haken. Die Entwickler haben eine
> grundsätzliches Prinzip von guter  und sicherer Software nicht
> verstanden: Ein Programm erledigt (genau) eine Aufgabe; das
> aber _gut_ und _sicher_ [1].

Was natürlich immer ein Kompromiß ist. Gerade sicher wird bei DNS
schnell sehr aufwendig. Sicher ist überhaupt fast immer sehr
aufwendig.

> 1. Neue Konfigurationsdatei. Toll, der Parser ist um Faktor N
> aufwendiger und somit auch um Faktor N*N fehleranfälliger.
> Wofür dieser Aufwand?

Ich finde nicht, daß er fehleranfälliger ist. Die Strukturierte
Konfiguration sollte eher einfacher zu parsen sein. Damit sind
dann auch i.d.R. die Fehlermeldungen viel besser. es passiert mit
größerer Wahrscheinlichkeit das, was man möchte, oder ein Fehler.
So muß das sein.

> 2. ACL's: Unnötig. Es gibt ander Programme die das besser können.

Wie jetzt? Ich finde Zone-Transfer ACLs ziemlich wichtig, denn
ich hab in etlichen Zonen eben Namen drin, die man lieber nicht
über ein Zonetransfer kriegen soll - z.B. die IPs von
Kunden-Mailservern, die nicht direkt kontaktet werden können.
Wozu also muß jemand die IP kennen? Ich brauche sie für
gelegentliche Adminstration...

Dynamische Zoneupdates sowieso. Meistens dürfen das nur ein ganz
paar. Bei mir meistens localhost, wo das über SSH und wrapper
gemacht wird. Dann meist noch ein Slave oder sowas, je nach dem,
wo geupdatet wird.

> 3. ZonenTransfer: Horror! Unverschlüsselt 

Ja, wie das ganz DNS, genau.

> und (sehr) langsam.

Ja, sicher? Was soll an einem einfachen TCP-Stream mit wenig
Overhead langsam sein? Ich fand immer, daß das gut funktioniert.
Selbst wenn man 200 Zonen neulädt, geht weder das Netz platt noch
die Maschine, die Zonetransfers werden nicht beliebig parallel
sondern dann auch sequentiell gemacht.

> Es gibt bessere Programme.  

Welche denn?

> 4. Ohne Ende neue Log-Möglichkeiten: Super. Endlich eine
> Möglichkeit einen Namserver so aufzusetzten, das er 98% Load
> nur mit loggen über den syslogd verbringt.

Ja, das benutze ich i.d.R. überhaupt nicht. Ich glaub, ich hab
noch ne Logdatei für alles im chroot, falls syslogd mal nicht da
ist. Aber brauche ich nicht.

> Zu guter Letzt: Was soll das mit DNSSec in Bind 9? Willst Du
> wirklich eine Authentifizierungsstelle?

Eine? Na, muß natürlich mit den root-servern anfangen. Wäre dann
ein Ende von spoofs. Ist wichtig, wenn man z.B. IPSec keys mit
DNS verwalten will. Bringt ja nix, Keys in einer ungeschützten
Datenbank zu haben.

> Womöglich dann noch kostenpflichtig, so wie SSL Zertifikate? 

Du kannst SSL-Zertifikate problemlos selbst basteln. Kostet nix,
gibt ja openSSL. Außerdem sind 200 Dollar nicht viel, wenn Du ein
SSL-Zertifikat brauchst, dann stehen da i.d.R. die zehnfachen
Kosten dahinter. Das ist für mich gar kein Grund für irgentwas.

> Trotzdem hat natürlich jeder/jede die Freiheit Bind weiterhin
> zu benutzen (und regelmäßig auf Sicherheitsupdates zu prüfen).

Mag ja sein, daß Bind so schlecht ist; aber solange es nichts
gibt, was man als replacement verwenden kann, hilft's wieder nix.
Und ob ein Server gut cachen kann oder nicht, ist für micht
weniger interessant. Da muß man ja auch bei bind nix weiter
machen, geht immer. Bloß eben viele Zonen verwalten, die dann
teils von anderen Slaves bedient werden und so, daß ist nicht so
ganz einfach. Da braucht's dann NOTIFICATIONs und sowas, geht
eben nicht anders. Ich hab auch lieber sorgfältig entwickelte und
saubere Software, aber nur, wenn sie auch funktioniert :) Und
soweit ich mich erinnere, konnte die "kleinen" Server immer
mindestens eine wichtige Funktion nicht...

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.



Mehr Informationen über die Mailingliste linux-l