linux-l: dns-server

[Ralph Angenendt]

On Wed, Jan 09, 2002 at 01:01:42AM +0100, Markus Hubig wrote:
> Steffen Dettmer schrieb am Montag, den 07. Januar 2002:

[BIND, Security und Ersatz von BIND]

> Wenn aber schon das Konzept der Software auf Sicherheit ausgelegt ist,
> dann sind auch Fehler im Code nicht so tragisch.
> 
> Und gute Beispiele fuer ein hervorragendes sicherheitsbewustes 
> Software-Konzept sind nun mal djbdns, qmail und publicfile.

Komisch, dass mir noch nie jemand einen djbdns zeigen konnte, der mehr
als 1.000 Zonen beherbergt. Mit mehr als 50 Secondary Servern.
Eventuell sogar mit Hidden Primaries. Das sind aus irgendwelchen
Gründen immer BINDs.

>> Mag ja sein, daß Bind so schlecht ist; aber solange es nichts
>> gibt, was man als replacement verwenden kann, hilft's wieder nix.
 
> Also das ist kein Argument, denn djbdns kann IMHO bind vollständig
> ersetzen! Und wenn dir Zone-Trasfers so wichtig sind schau dir doch
> mal 
> 
> | http://cr.yp.to/djbdns/axfrdns.html 

Gut, der ist auch mir neu - bisher wurde immer von "nimm doch rsync"
gesprochen, wenn djbdns im Spiel war. 

> | Here's a table summarizing the situation as of July 2001:
> | 
> | 			     Zone transfers | rsync over ssh
> | ------------------------------------------------------------
> | Automatic handling of new zones	No  |	Yes

Bitte? Ich lege eine neue Slave-Zone in BIND an und sage BIND, er
solle die Config neu lesen: Neue Slave-Zonen werden neu eingelesen.
Wenn der Master neue Zonen hat, kann der Slave das nicht wissen. Auch
bei rsync nicht. Oder nimmt djbdns jedes neue Zonefile an, welches ich
im unterjubele, ohne beim Master nachzufragen?

> | ... and client differentiation	No  |	Yes

Was immer das heissen soll. Views? Kann Bind 9. 

> | ... and scheduled record changes	No  |	Yes

Errrm. Was soll das heissen? 

> | Replication soon			Yes |	Yes
> | ... which means now			No  |	Yes

Notification Requests an die Slaves gehen *sofort* raus, wenn eine
Zone geändert wird und BIND davon erfährt.

> | Success reported locally		No  |	Yes

Ach Quatsch. Wenn Fehler auftauchen, sehe ich das sofort im Log.
Erfolg sehe ich auch sofort. Nicht auf dem Master, aber auf den
Slaves. Mit rsync muss ich mir was eigenes basteln, was Fehler
anzeigt.

> | Errors reported locally		No  |	Yes

Quatsch. BIND zeigt Fehler in den Zonen sofort an. 

> | Compressed transfers			No  |	Yes

ZXFR existiert. Mann, das war der letzte grosse BIND-Exploit.

> | Incremental transfers			Yes |	Yes
> | ... of data added by hand		No  |	Yes

Huh? Okay, die ganze Zone wird transferiert. Und IXFR gibt es auch,
ich habe mir das aber noch nicht angesehen.

> | ... or by common web tools		No  |	Yes

Bitte? Natürlich gibt's Webtools um BIND-Zonen zu verwalten.

> | Encrypted transfers			No  |	Yes

Seit BIND9 (das gab's im Juli schon) ist das kein Problem.

> | Authenticated transfers		Yes |	Yes
> | Usable for other services		No  |	Yes

Ne. Klar. Unixphilosophie: Have One Tool Do One Job.

> | Supported by the BIND company		Yes |	No
> 
> ( Lesenswerte Quelle http://cr.yp.to/djbdns/faq/axfrdns.html )

Ach, Bullenscheisse. BIND ist unsicher - zumindest die 8er Version war
nicht toll. Dafür hat djbdns andere Nachteile: Die Zonenfiles sind
nicht dafür gedacht, von Menschen gelesen zu werden - klar, bei
kleinen Servern mag das kein Problem sein, aber bei mehr als 500 Zonen
auf einem Nameserver ist das echt nicht mehr feierlich. 

Mit rsync muss ich als Master auf Slaves schreiben können: Dafür
brauche ich einen SSH-Zugang - was ist, wenn der Kunde mir den nicht
geben will? 

djb mag ja sichere Software schreiben - djbdns mag auch bei kleinen
Setups echt toll sein (ich würde mir das mittlerweile auch für
kleinere Netze angucken, wenn ich sowohl Master als auch Slaves
verwalte), aber ansonsten ist das echt einfach nur Bullenscheisse. Wer
mag, kann sich ja mal den Streit zwischen Felix von Leitner und Daniel
Roesen in de.comp.os.unix.networking vom Anfang des letzten Jahres
ergooglen.

Ralph
-- 
/* Fuck me gently with a chainsaw... */
      --  David S. Miller
      	  in /usr/src/linux/arch/sparc/kernel/ptrace.c
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 232 bytes
Beschreibung: nicht verfügbar
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20020109/9141ce32/attachment.sig>