Public DENIC mailinglist

["Sabine Dolderer/Denic" <dolderer AT denic.de>]

Lieber Stefan,

On 01.02.01 11:15 Stefan Paletta <sp-denic-public-l AT WRonline.de> wrote:

[..]

ich habe schon hinlänglich zu erläutern versucht, daß wir gleich reagiert 
haben und danach Schritt für Schritt unsere Server upgedate haben und das 
braucht eben seine Zeit.


> Der Rechner des Angreifers antwortet mit einer IP Adresse unter seiner
> Kontrolle. Dort hat der Angreifer einen Webserver laufen der so
> aussieht wie der Ihnen vertraute. Sie melden sich mit Passwort an.
> Der Angreifer stiehlt Ihr Geld.
> 
> Es kommt noch viel herber:
> ; <<>> DiG 2.2 <<>> @beer.pilsnet.sunet.se version.bind CHAOS TXT +norec
> VERSION.BIND.   0       TXT     "4.9.6-REL"
> 
> beer.pilsnet.sunet.se ist NS fuer sunet.se und sunic.sunet.se ist NS
> fuer de. Damit kontrolliert ein Nameserver mit einer seit mindestens
> 1998 obsoleten Software, in einer auch noch veralteten Version mit
> bekannten Sicherheitsluecken alle Ihre de-Domains.

wobei Sie die IP in aller Regel da als Glue-Record in der SE-Zone 
enthalten von dort bekommen. Sie sollten also die SE-Zone auf die 
Versionskorrektheit testen.

> Schaut man sich die vertrauten Nameserver fuer die de-Zone an, stellt
> man fest dass durch die nicht-.denic.de Server eine ganze Menge z.T.
> mehrfach indirekt vertrauter Rechner (viel .edu und .au, aber auch
> US-Backbones) hinzugezogen werden.
> Ich bin mir bewusst dass das Denic dem mit der Umstellung auf das
> shared secondary system Rechnung traegt und damit die Sicherheit und
> Zuverlaessigkeit der de-Zone erhoeht. Dies begruesse ich
> ausdruecklich. Es ist jedoch nicht geschafft, solange SUNIC.SUNET.SE,
> DNS.NIC.XLINK.NET und AUTH03.NS.DE.UU.NET noch secondaries fuer die
> de-Zone sind.
> 
> Doch nicht die fremden Server sind es, die mir mehr Sorgen machen.
> 
> Wann wird das Denic auf ihren Nameservern Software einsetzen, die
> nicht RFC-widrige Antworten liefert? Die Antwort auf z.B.
> ; <<>> DiG 2.2 <<>> @dns.denic.de ns.wronline.de A +norec
> verletzt die Anforderungen von RFC2181, Abschitt 5.5.

Nach einem schnellen Blick in die RFCs bin ich mir nicht so ganz sicher, 
inwieweit wir dies verletzten, dort steht nur, daß ein RR nicht mehrmals 
angezeit gerden sollt, es sei denn, dies würde in der Definition des 
folgenden RRs verlangt und in der Definition des NS-RR wird eine "usual" 
Additional Section vorgeschrieben (rfc 1033).

Aber ich bin gerne bereit diese - eher akademische - Diskussion privat per 
eMail weiter zu vertiefen, da mir im Moment die Zeit dafür fehlt.

> 
> Wann wird das Denic auf ihren Nameservern nicht mehr Software
> einsetzen, von der sich selbst der Hersteller wegen ihrer Fehler und
> Geschichte voller Sicherheitskatastrophen distanziert?

??? Ich habe wirklich keine Lust, dies auf eine Liste zu diskutieren, 
stehe aber privat gerne zur Verfügung.

> 
> Wann wird das Denic auf ihren Nameservern Software einsetzen, die
> einen reload von Daten relevanter Groesse innerhalb von Sekunden
> (wieviele Stunden dauert ein kompletter reload der de-Zone jetzt?)
> durchfuehren kann und zur Verteilung nicht das langsame Zonen-
> transferprotokoll einsetzt? Diese Software ist verfuegbar!

Ja, das funktioniert aber mit den Partner, die die anderen Secondaries 
betreiben nicht und für die eigenen arbeiten wir daran.

> Wenn man auch ueber den Sinn mehrfacher Updates der Nameserver
> pro Tag streiten kann (ich bin mir bewusst dass alleine schon
> die Generierung der Daten ein laengerer Prozess ist), wuerden es
> die Kunden nicht begruessen? Wuerden nicht alle begruessen wenn dies
> moeglich gewesen waere bei den in der Vergangenheit erlebten Fehlern
> in der de-Zone? (Nungut, da das Denic fuer den Normalsterblichen
> am Wochenende nicht arbeitet und man die Zone "sowieso" erst am Montag
> neu erstellt, ist die Moeglichkeit einer schnellen Fehlerbehebung
> wenig relevant in dem Fall dass z.B. einige Delegationen fuer ein
> Wochenende schlicht in der de-Zone fehlten und Kunden dadurch Schaden
> entstand.)

Wir können ja wohl schlecht auf unterschiedlichen Servern unterschiedliche 
Zonen fahren und mit einer Umstellung auf incr. Updates, würden unsere 
Partner im Ausland nicht arbeiten können. Aber die Umstellung auf ein 
weltweit selbst gemanagtes Servernetz dauert.

Daneben besteht die Fehlerbehebung am Wochenende durchaus und unsere 
Bereitschaft ist verpflichtet, diese auch zu beheben. Was wir nicht 
können, ist Fehler, die bei Providern entstanden sind, weil Updates nicht 
oder zu spät losgeschickt wurden, individuell zu beheben. Das ist bei 
tausenden von Requests am Tag nicht mehr möglich.

Falls für den 1. Fall Complaints existieren, bitte ich um Nachricht an 
mich,

viele Grüße
Sabine Dolderer


>
 
> Stefan
> 
> --
>  junior guru                                                  SMP@IRC
> 
> 
Sabine  Dolderer 
DENIC eG
Wiesenhüttenplatz 26
D-60329 Frankfurt

eMail: Sabine.Dolderer AT denic.de
Fon: +49 69 27235 0
Fax: +49 69 27235 235