Skip to Content.
Sympa Menu

public-l - Re: Re: Re: Re: [DENICpublic-l] Nameserver im selben Subnetz

public-l AT list.denic.de

Subject: Public DENIC mailinglist

List archive

Re: Re: Re: Re: [DENICpublic-l] Nameserver im selben Subnetz


Chronological Thread 
  • From: "Sabine Dolderer/Denic" <dolderer AT denic.de>
  • To: Daniel Roesen <dr AT cluenet.de>
  • Cc: public-l AT denic.de
  • Subject: Re: Re: Re: Re: [DENICpublic-l] Nameserver im selben Subnetz
  • Date: Wed, 31 Jul 2002 00:51:23 +0200


Hallo Daniel,

On 31.07.2002 00:18 Daniel Roesen <dr AT cluenet.de> wrote:
>
> Hallo Sabine,
>
> [wann benutzt ihr eigentlich endlich mal nen Mail-Client, der Threads
> nicht zerstoert? Wuerde das Lesen doch deutlich vereinfachen. Ich mein,
> das bekommt selbst Microsoft Ware hin...]

ja, aber unserer ist ziemlich Virusrobust und die Replikationsfähigkeit ist
unerreicht. (Was nicht heisst, dass ich unter manchen Features nicht leide
;-).

>
> On Tue, Jul 30, 2002 at 11:51:45PM +0200, Sabine Dolderer/Denic wrote:
> > > 1) "robuste Anbindung zu schaffen"
> > > ==> das prueft dieser Check in keinster Weise
> >
> > doch, sonst wäre z.B. microsoft.com letztes Jahr nicht über genau
dieses
> > Problem gestolpert.
>
> Falsch, Microsoft ist darueber gestolpert, dass die Nameserver alle
> non-redundant angebunden waren. Ob die Nameserver im gleichen /24
> liegen ist dafuer KEIN ausreichendes Kriterium um das zu beurteilen!

Ja, un ein /24 ist zwar nicht der Beweis, aber (immer noch) ein Indiz
dafür.
>
> > Ich sage ja nicht dass es immer und in jeder Situation hilft.
>
> Doch. Ihr lehnt Delegationen auf Basis dieses "Checks" ab.
>
> > Aber es hilft im typischen 95% Fall.
>
> Wenn Euer Check eine signifikante false positive Quote hat (und 5% sind
> verdammt viel), warum basiert ihr darauf Delegationsentscheidungen?

Wenn ich mit anschaue, dass in anderen TLD's 70% aller Delegationen lame
sind (und die 5% waren geschätzt/fiktiv), ist die Qualitätsverbesserung
signifikant.

>
> > > 2) "reduziert bei den Nutzern den Frust"
> > > ==> man darwin
> >
> > das Argument verstehe ich nicht.
>
> Tja, Du arbeitest auch nicht in der freien Wirtschaft, wo sich
> schlechter Service (z.B. Nameserver Screwups durch mangelde Redundanz)
> durch zur Konkurrenz fluechtende Kunden (eine Art Darwinistisches
Prinzip)
> quittiert werden. Deine Kunden koennen nicht fluechten, weil die
> Alternativen Anbieter fehlen (und nun komm' bitte nicht mit GTLD Domains
> als Alternative...). :-)

Warum nicht? Jeder Job hat seine Herausforderungen und die Tatsache, dass
man grundsätzlich (egal wie man es macht) eine Menge Kritiker hat (weil die
ja angeblich keine Wahl haben), kann auch Antrieb sein. Und wir stehen
eigentlich (hoffentlich) dafür, dass wir nicht nachlassen diese Ernst zu
nehmen und uns auch zu verbessern. Wir sind innerhalb von 5 Jahren zur
größten ccTLD und zur zweitgrößten TLD weltweit gewachsen, ohne auch nur
annähernd Verisign-ähnliche Dimensionen zu haben. Dass dieses Wachstum auch
mal Probleme hat und dass wir viele der potentiellen
Registrytypischen-Probleme als Erste haben, dürfte nicht überraschend sein.

>
> Wenn wir unsere Maintenance works und planned outages regelmaessig zu
> bester Geschaeftszeit durchfuehren wuerden und non-emergency 17-Stunden-
> Ausfaelle mit weniger als 48 Stunden Vorwarnung ankuendigen wuerden,
> haetten wir bald keine Kunden mehr. Das kann DENIC natuerlich viel
> gelassener sehen, das is mir schon klar... :-)

Wir versuchen natürlich unsere (nach außen sichtbaren) Wartungen auch nicht
zu den Geschäftszeiten zu machen, wir sind allerdings dazu übergegangen
auch die "eigentlich nicht sichtbar sein sollenden" anzukündigen. Daneben
gibt es oft widerstreitende Interessen, darüber, was betrieblich notwendig
und was noch warten könnte.

>
> Soviel mal nur kurz zu "man darwin". ;-)
>
> > > 3) "erhöht die generelle Qualität."
> > > ==> das erlangt dieser Check nicht.
> >
> > die alten NetWizard Statistiken sprechen da aber eine ganz klare
Sprache.
>
> OK, ich habe mich undeutlich ausgedrueckt offenbar. Der Check fuehrt
> dazu, das Leute das System bescheissen. Keiner wird sich von einem
> solchen Check der so einfach zu umgehen ist dazu zwingen lassen,
> wirklich redundante Nameserverstruktur herzustellen. "man" besorgt sich
> nen zweites Prefix (oder hat mehr als ein /24), die "total andere IP"
> liegt aber aufm gleichen Interface des gleichen Nameservers).
>
> Ausserdem blockt der Check Setups die hochredundant sind.
>
> > > Bleibt uebrig: "reduziert [...] bei uns die Supportanrufe"
> >
> > und das heisst impliziet, dass das ganze dann besser funktioniert,
> > weil nur dann die Leute nicht anrufen.
>
> Darueber (insb. ueber die statistische Basis dieses Schlusses) liesse
> sich laenger diskutieren... :-)
>
>
> Gruss,
> Daniel
>
>
--
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






Archive powered by MHonArc 2.6.19.

Top of Page