Public DENIC mailinglist

[ambos AT ambos-is.net]

Hallo Kollegen, Mitstreiter und Leidensgenossen,


zunächst muss ich schon sagen, dass ich es beschämend finde, mit welchen 
Argumentationen das DENIC hier abblockt und sich Provider mit 
Fronterfahrungen hier abrackern, um den direkten Kunden der DENIC ein 
sorgenfreieres Leben zu bescheren.


Schaue ich mir die Unterschiede zwischen ..de und CNO an, muss ich sagen, 
dass ich mir bei ..de-Domains jeden Kunden-Wunsch schriftlich bestätigen 
lasse - für ..de-Domains wohlgemerkt.
Dies liegt nicht primär daran, dass die WIPO weiter weg ist, als das 
entfernteste deutsche Gericht.
Im CNO-Bereich sehe ich den Kundenwunsch mit den elektronischen Mechanismen 
besser umgesetzt, auch wenn ich diese eMail-Kiste (FOA) oftmals als leidiges 
Übel ansehe, stimmt der Whois mal wieder nicht.

Zurück zum AuthInfo:
Ich vermag noch nicht erkennen, wie ich mit dem AuthInfo auf Schriftstücke 
verzichten kann. Dies, weil ich in so mancher Situation mit Sicherheit nicht 
beweisen kann, wem ich welchen AuthInfo gab und wem keinesfalls nicht. Wer 
hat mitgelesen? Wer hat sich bei der Anforderung des AuthInfo für wen 
ausgegeben?
Die Welt besteht nicht nur aus 1&1, wo der Endkunde direkt per Frontend seine 
Daten beeinflusst.
Ich bewege mich im Reselling-Bereich und nachgelagerten gewerblichen 
Endkunden, die mit ihrem Provider auch mal einen Kaffee trinken gehen.

Seit google und co sind wir uns schon lange einig, dass Mechanismen 
eingeführt werden müssen, die die Arbeit von Gerichten minimiert.


Welche Probleme sollen abgesichert werden?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 a) ungerechtfertigter Providerwechsel und damit verbundene
    Domainkaperung

 b) ungewollte Löschung
    sei es durch Member, Reseller oder Wohnzimmerprovider-
    Fehler?
    Warum tun wir nichts, um uns selbst zu schützen?
    Nicht nur ein Endkunde kann sich irren, weil er ggfls.
    nicht weiss was CLOSE bedeutet.

 c) Provider möchte rechtlich einwandfrei eine Domain loswerden.



Die Lösungen:
~~~~~~~~~~~~~

c) ist gelöst - der Transsit - einwandfreie Realisierung

b) Lösche ich durch Programmierfehler ungewollt 1000 Domains
   auf Schlag und soll für eine Redemption-Period-Lösung
   100 Euro pro Domain ausgeben, nehme ich mir besser gleich
   einen Strick.

   Wie wäre es mit einem 2-stufigen CLOSE?
   CLOSE-1 : DENIC dekonnektiert die Domain, hält sie aber noch
             registriert. So ein Zustand wie beim Transit.
             Vielleicht sogar mit einer ähnlichen Infoseite
   CLOSE-2 : CLOSE wie jetzt üblich

   Eine Domain wird von CLOSE-1 nach CLOSE-2 automatisch
   zeitgesteuert überführt. U.U. schon nach 3-7 Tagen.

   Fehler bei einer wichtigen Produktivdomain fallen binnen
   Stunden auf. Da bedarf es keiner 6-wöchigen Redemption-Period
   Machen wir das von allen geforderte Feature der Redemption-
   Period doch einfach mal praxistauglicher.
   Eine CLOSE-1-Zeitspanne von 3 Tagen ist mit Sicherheit
   ausreichend. Fehl-Löschungen können dann unentgeltlich per
   UPDATE rückgängig gemacht werden.
   Für wichtige Löschungen kann man immer noch CLOSE-2 direkt
   anstossen.
   Programmiere ich in meinem Robot nur CLOSE-1, kann mich ein
   Dusseligkeitsfehler nicht ruinieren.

a) Die 60-Tage-Frist bei CNO-Domains für einen erneuten Provider-
   wechsel finde ich persönlich problematisch.
   Ich würde sogar hergehen, dass ein Providerwechsel binnen
   7 Tage ohne Angabe von Gründen rückgängig gemacht werden kann.
   Optionale Idee - möglicherweise überflüssig:
   Erfolgt ein Providerwechsel in Zusammenhang mit einem Domain-
   verkauf und Inhaberwechsel, muss man das beim Providerwechsel
   mit einem Flag explizit angeben können, dass ein rückgängig
   machen des Providerwechsels unterbunden werden kann.



Ich sehe mein Problem der Notwendigkeit der Schriftstücke bzgl. der 
Dokumentation des Kundenwunsches nicht gelöst.
Der AuthInfo in der jetzigen Realisierung hat für den Provider nur den 
Vorteil, dass er zu seinem neuen Kunden nur sagen braucht "besorg mir mal den 
AuthInfo". Der anstehende Providerwechsel geht dann glatt durch und keiner 
muss sich mehr mit unwilligen Exprovidern rumquälen.
Kann ein ungerechtfertigter Providerwechsel unkompliziert wieder rückgängig 
gemacht werden, reduziert dies die Zahl der Rechtsstreite.
Das DENIC glaube bitte nicht, dass IT-ler grundsätzlich Ahnung von IPs, 
Routing, DNS und Domains haben.

Und wenn ich dann schon diesen Spruch höre: "Dann hätte sich der Endkunde ja 
einen seriösen Provider aussuchen sollen ...." Da kann ich nur sagen: "Warum 
nimmt das DENIC denn unseriöse Provider als Mitglied auf?"
Das ist nicht der Ansatz, mit dem wir das Problem auf verbalem Wege lösen 
können.

Die Bankenkrise hat gezeigt, dass sich die Menschheit vor sich selber 
schützen muss.


Wenn mir nun jemand gründsätzlich widersprechen möchte, eine kurze Frage: 
"Str-Z". Die Tastenkombination hat sich als praxistauglich und 
programmübergreifend durchgesetzt. Schon mal benutzt?


Mit freundlichen Grüßen
Heiko Ambos
 
Ambos InterNet-Solutions
Inh. Heiko Ambos
 
Hausanschrift: Am Biberbach 23, D-24145 Kiel
Postanschrift: Postfach 1233,   D-24011 Kiel
 
Tel.: 0700 - AmbosFon (14 Cent/min)
             26267366
Fax.: 0700 - AmbosFax (14 Cent/min)
             26267329
http://www.ambos-is.net
http://www.dynaccess.de 
 
USt-ID-Nr.: DE223257916
 
 
 

-------- Original Message --------
Subject: [DENICpublic-l] Pressemitteilung: Providerwechsel mit AuthInfo 
Schnell, sicher, zuverlässig (14-Nov-2008 14:19)
From:    DENICpresse <presse AT denic.de>
To:      public-l AT denic.de

> 
> Pressemitteilung
> 
> Frankfurt, den 14. November 2008
> 
> Providerwechsel mit AuthInfo – Schnell, sicher, zuverlässig
> 
> Ab Dezember 2008 bieten die DENIC und ihre Mitglieder den Domaininhabern, 
> die ihren Provider wechseln wollen, ein neues Verfahren an. Es basiert auf 
> der Übermittlung eines Passworts, das in Anlehnung an internationale 
> Gepflogenheiten AuthInfo genannt wird. Diese AuthInfo ist nur für diesen 
> speziellen Vorgang des Providerwechsels vorgesehen und bezieht sich immer 
> auf eine bestimmte Domain.
> 
> Das derzeitige Providerwechselverfahren (im Folgenden auch als asynchrones 
> Verfahren bezeichnet) schreibt für den aktuellen und den zukünftigen 
> Provider Prüfungspflichten vor, um sicherzustellen, dass der 
> Providerwechselauftrag für die Domain nur von einer dazu berechtigten 
> Person angestoßen wird. Die Kommunikation zwischen den beteiligten 
> DENIC-Mitgliedern und der DENIC erfolgt dabei über das 
> DENIC-Registrierungssystem. Da jeweils mehrere Tage als Reaktionszeiten 
> vorgesehen sind, kann ein Providerwechsel bis zu seinem Abschluss bis zu 
> fünf Werktage benötigen. Beim neuen Verfahren wird dagegen nach dem Start 
> des Providerwechsels nur noch die Übereinstimmung der im Auftrag 
> übermittelten AuthInfo mit der bei der DENIC hinterlegten AuthInfo 
> überprüft. Im positiven Fall wird der Providerwechsel sofort ohne weitere 
> Wartezeit durchgeführt. Das eröffnet die Möglichkeit, den exakten 
> Zeitpunkt eines Providerwechsels im Voraus festzulegen und die mit der 
> Domain verbundenen Services durch den Provider entsprechend einzurichten.
> 
> Das neue Providerwechselverfahren mittels AuthInfo und das bisherige, 
> asynchrone Verfahren stehen zunächst parallel zur Verfügung. Der 
> Domaininhaber hat also die Wahl, welches Verfahren er nutzen möchte, muss 
> sich allerdings definitiv für eines der beiden entscheiden. Das 
> AuthInfo-Verfahren hat den Vorteil, die Kommunikationswege zu minimieren 
> und damit einfacher, schneller und noch ein wenig sicherer zu sein als das 
> asynchrone Verfahren.
> 
> Um das neue Verfahren zu nutzen, muss der Domaininhaber zwei Mal aktiv 
> werden: Zunächst beauftragt er bei seinem derzeitigen Provider eine 
> AuthInfo und lässt diese bei der DENIC hinterlegen. Im zweiten Schritt 
> startet er bei seinem neuen Provider den Providerwechselprozess, wobei er 
> diesem die AuthInfo mitteilt. Im Folgenden werden diese beiden Vorgänge 
> ausführlicher dargestellt. 
> 
> Erzeugung und Hinterlegung der AuthInfo
> 
> Wenn ein Domaininhaber mit seiner Domain zu einem anderen Provider 
> wechseln möchte, beauftragt er über seinen derzeitigen Provider eine 
> AuthInfo. Es gibt keine Vorgaben der DENIC, ob der Domaininhaber selbst 
> ein Passwort (AuthInfo) auswählt oder ob der Provider dies tut und es dem 
> Domaininhaber mitteilt. Der Provider erzeugt von der AuthInfo eine 
> „verschlüsselte“ Version (einen sog. Hash) und übergibt sie über das 
> verwaltende Mitglied an die DENIC. Die Übergabe als Hash ist ein 
> zusätzliches Sicherheitsmerkmal bei der Übertragung. Bei der DENIC wird 
> die AuthInfo in verschlüsselter Form in der Datenbank hinterlegt. Damit 
> ist der DENIC das Klartextpasswort nicht bekannt. 
> 
> Ebenfalls aus Sicherheitsgründen ist eine AuthInfo nicht unbegrenzt 
> gültig, sondern verfällt nach spätestens 30 Tagen. Ein Providerwechsel 
> kann dann mit dieser AuthInfo nicht mehr durchgeführt werden. Soll der 
> Providerwechsel weiterhin stattfinden, muss entweder wieder eine AuthInfo 
> hinterlegt oder das asynchrone Verfahren angestoßen werden. 
> 
> Sollte es dem Domaininhaber nicht möglich sein, bei seinem derzeitigen 
> Provider eine AuthInfo zu beauftragen (etwa weil der Provider nicht mehr 
> existiert, der Domaininhaber ihn nicht erreicht oder der Provider nicht 
> reagiert), so kann er auch ein Providerwechselpasswort direkt von der 
> DENIC erhalten. Der Domaininhaber wendet sich in diesem Fall an das 
> DENIC-Mitglied, das die Domain zukünftig verwalten soll. Dieses veranlasst 
> die Generierung der AuthInfo direkt bei der DENIC. Die DENIC sendet 
> daraufhin dem Domaininhaber per Einschreiben die erzeugte AuthInfo an 
> seine in den Domaindaten hinterlegte Adresse zu. Bei ausländischen 
> Domaininhabern wird das Schreiben an den in Deutschland ansässigen Admin-C 
> geschickt, um lange Brieflaufzeiten und hohe Portokosten zu vermeiden und 
> eine sichere Zustellung zu garantieren. Gleichzeitig hinterlegt die DENIC 
> die generierte AuthInfo als Hash in der Domaindatenbank. Der Domaininhaber 
> kann nun seinem neuen Provider die AuthInfo mitteilen und dieser startet 
> den Providerwechselauftrag, bei dem er diese AuthInfo an die DENIC 
> übergibt. 
> 
> Durchführung eines Providerwechsels mit AuthInfo
> 
> Um den tatsächlichen Providerwechsel zu starten, teilt der Domaininhaber 
> die AuthInfo seinem neuen Provider mit. Dieser, oder genauer: das die 
> Domain verwaltende DENIC-Mitglied, kann bei der DENIC nachsehen, ob eine 
> AuthInfo hinterlegt ist (natürlich ohne die Angabe, wie die AuthInfo 
> lautet) und, sofern das geschehen ist, den Providerwechselauftrag unter 
> Angabe der AuthInfo an die DENIC übermitteln. 
> 
> Wenn der Providerwechselauftrag bei der DENIC eingegangen ist, prüft diese 
> zunächst, ob für die betreffende Domain eine gültige AuthInfo hinterlegt 
> ist. Ist dies der Fall, vergleicht die DENIC den Hash der übermittelten 
> AuthInfo mit dem hinterlegten Wert. Stimmt er überein, wird der 
> Providerwechsel sofort durchgeführt und die dafür verwendete AuthInfo 
> gelöscht. Ist das Passwort nicht korrekt, wird der Providerwechsel 
> abgelehnt und der neue Provider darüber informiert. Liegt für die Domain 
> keine AuthInfo vor, muss sich der Domaininhaber mit dem bisherigen 
> Provider in Verbindung setzen, um zu klären, warum die AuthInfo nicht 
> hinterlegt wurde.
> 
> Mit einer AuthInfo kann übrigens zeitgleich mit dem Providerwechsel auch 
> ein Inhaberwechsel für die Domain erfolgen, sofern dem nicht andere 
> Vorschriften, wie ein DISPUTE-Eintrag auf der Domain, entgegenstehen. Dies 
> unterscheidet das neue Verfahren vom asynchronen Verfahren, bei dem der 
> Inhaberwechsel getrennt durchgeführt werden muss. Andere 
> Domainverwaltungsprozesse wie beispielsweise Updates der Domaindaten oder 
> Löschungen können mit einer AuthInfo nicht abgewickelt werden.
> 
> AuthInfo beim Service DENICdirect
> 
> Domaininhaber, die mit ihrer Domain zum Service DENICdirect der DENIC 
> umziehen wollen, können dazu ebenfalls eine AuthInfo nutzen, die sie bei 
> ihrem aktuellen Provider beauftragt haben. Ist keine AuthInfo des 
> Providers hinterlegt, kann während des Providerwechsels zu DENICdirect 
> alternativ eine AuthInfo bei der DENIC beauftragt werden. Danach erhält 
> der Domaininhaber die AuthInfo zugesandt und kann den Providerwechsel hin 
> zu DENICdirect abschließen. 
> 
> Regelungen für Domains im TRANSIT
> 
> Gelangt eine Domain in den TRANSIT, so wird eine AuthInfo, die von dem die 
> Domain bislang verwaltenden Mitglied hinterlegt wurde, gelöscht. Eine 
> AuthInfo, welche durch die DENIC generiert und dem Domaininhaber zugesandt 
> wurde, bleibt dagegen bis zum Ende ihrer Gültigkeitsdauer bestehen. Ein 
> Grund für diese unterschiedliche Behandlung liegt darin, dass im zweiten 
> Fall nur der Domaininhaber die AuthInfo kennt. Im ersten Fall könnte das 
> Providerwechselpasswort hingegen auch dem bisher verwaltenden 
> DENIC-Mitglied und eventuellen Resellern bekannt sein. Da dieses Mitglied 
> aber die Verwaltung der Domain aufgegeben und diese in den TRANSIT 
> geschickt hat, ist es sinnvoll, dass es auch keine 
> Verwaltungsinformationen zu dieser Domain mehr besitzt. 
> 
> Soll eine Domain, die sich im TRANSIT befindet, wieder in die Verwaltung 
> eines DENIC-Mitglieds übergehen, so kann dafür ein Providerwechsel mit 
> AuthInfo gestartet werden, sofern bereits eine AuthInfo von der DENIC, die 
> per Brief zugeschickt wurde, existiert. Alternativ kann der Domaininhaber 
> mit dem Passwort, das ihm im TRANSIT-Schreiben mitgeteilt wurde, auf der 
> DENIC-Webseite sein zukünftiges verwaltendes Mitglied auswählen und im 
> Rahmen des TRANSIT-Verfahrens die Domain zu diesem umziehen.
> 
> -- 
> 
> DENIC eG
> Kaiserstraße 75-77
> 60329 Frankfurt am Main
> GERMANY
> 
> E-Mail: presse AT denic.de
> Fon: +49 69 27235-274 
> Fax: +49 69 27235-235
> http://www.denic.de
> 
> Angaben nach § 25a Absatz 1 GenG:
> DENIC Domain Verwaltungs- und Betriebsgesellschaft eG (Sitz: Frankfurt am 
> Main)
> Vorstand: Sabine Dolderer, Marcus Schäfer, Carsten Schiefner, Dr. Jörg 
> Schweiger 
> Vorsitzender des Aufsichtsrats: Elmar Knipp
> Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht 
> Frankfurt am Main
>