linux-l: dns-server

[Thomas Knop]

* Ralph Angenendt <ralph at strg-alt-entf.org> [09.01.02]:
[..]
>Komisch, dass mir noch nie jemand einen djbdns zeigen konnte, der mehr
>als 1.000 Zonen beherbergt. Mit mehr als 50 Secondary Servern.
Aha, erst Zone im Master anlegen; Master per SIGHUP
neu starten und dann das auf 50 Slave Servern auch noch ... prima!
>Eventuell sogar mit Hidden Primaries. Das sind aus irgendwelchen
>Gründen immer BINDs.
Ja, weil große Bind Konfigurationen meist durch so tolle Software wie Lucent QIP gehandled wird,
damit auch Windoof-Looser damit umgehen könne und Oracle auch noch dran verdient.
Die verbreitung einer Sopftware sagt nix über die Qualität aus; oder doch? Schau dir mal die
verhältnisse Bind : djbdns und Windows : Linux an. Gute software == viel verbreitet? 
Das war dann wohl nix.

>> | 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.
Sowas von umständlich! Das machst du also auf 50 Slave Servern?

>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?
djbdns verwaltet jede zone, die du ihm anvertraust.
Zonenfiles so wie bei bind, die du von Hand editierst, gibt es nicht.

[..]
>> | ... and client differentiation	No  |	Yes
>
>Was immer das heissen soll. Views? Kann Bind 9. 
Nein, mit RDB's hat das nichts zu tun ;-)

[..]
>> | 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.
Nein. Bind braucht ewig und drei Tage bis Notifikation abgesprochen und der Transfer vollzogen ist.

>> | Success reported locally		No  |	Yes
>
>Ach Quatsch. Wenn Fehler auftauchen, sehe ich das sofort im Log.
Ach ja in den 50 Logfiles deiner 50 Slaveserver?
Oder läßt du alle 50 Slavserver auf einen Syslog-Server loggen und hast dann noch den
Durchblick ... ich zweifle daran.

>Erfolg sehe ich auch sofort. Nicht auf dem Master, aber auf den
>Slaves.
Nochmal auf den 50 Slaves?

> Mit rsync muss ich mir was eigenes basteln, was Fehler anzeigt.
Nein.

[..]
>> | Compressed transfers			No  |	Yes
>
>ZXFR existiert. Mann, das war der letzte grosse BIND-Exploit.
Bullschittiger Algorithmus mit miserablen Kompressionseigenschaften, der zusätzlich noch extrem
rechenaufwendig ist. Prima! Und dann noch fette Bugs einbauen. Es lebe Bind!

[..]
>> | ... or by common web tools		No  |	Yes
>
>Bitte? Natürlich gibt's Webtools um BIND-Zonen zu verwalten.
Siehe oben. Einer der der Gründe für Bind ist QIP. Ich gebe selbst zu, daß die Verwaltung
von Zonen mit mehreren tausend Clients und hunderten von Netzen hart ist. Da kommt man schnell
in die Versuchung zu so etwas wie QIP zu greifen. Das heißt dann aber _nicht_, das Bind gut ist.
 
>> | Encrypted transfers			No  |	Yes
>
>Seit BIND9 (das gab's im Juli schon) ist das kein Problem.
Toll doch schon seit 07/2001 ... whow ;-)
Nebenbei bei stark beanspruchten Servern ist djbdns 09/2001 immernoch(!!!) schneller als Bind 9.  

[..]
>Ach, Bullenscheisse. BIND ist unsicher - zumindest die 8er Version war
>nicht toll.
Die neuner ist genauso mist, weil sie auf dem gleichem Code basiert.
Eine Software die einmal richtig scheisse war, wird nicht besser wenn man neue Features hinzubastelt.

> Dafür hat djbdns andere Nachteile
Wurde nicht angezweifelt. Aber nochmal: DNS ist i.d.R. ein weltoffener Service. Wer dann
eine bekanntermaßen miese Software einsetzt ist selber Schuld.
In einer der letzten CT's oder XI's was dazu ein Beitrag; der hat ganz gut herausgearbeitet, warum
Bind _DIE_ Gefahr fürs _gesamte_ Internet ist. Da war nicht die Rede von Features :-)

[..]
>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.
Das mache ich; da ich Felix und sein Know How schon vor zehn Jahren kennen lernen durfte muss
ich doch mal wissen was der ander für'n Kerl ist ... wird bestimmt lustig.

Thomas