it-swarm.com.de

Warum gibt es die 60-tägige "Änderung der Registrierungssperre", nachdem die Kontaktdaten einer Domain geändert wurden?

Es gibt nur wenige Umstände, die von ICANN unter https://www.icann.org/resources/pages/name-holder-faqs-2017-10-10-en in der Warum weigert sich mein Registrar, meinen Domainnamen zu übertragen? Abschnitt, in dem ein Registrar entweder oder muss die Übertragung einer Domain ablehnen. Einige davon betreffen 60-Tage-Fenster nach bestimmten Ereignissen.

Eine davon, die 60-Tage-Sperre, die Registrare implementieren dürfen, nachdem eine Domain von einem anderen Registrar übertragen wurde, wird bereits unter Warum müssen wir zwischen jedem Domain-Transfer 60 Tage warten? , besprochen. und eine Begründung: Indem die Rate gedrosselt wird, mit der eine Domain zwischen verschiedenen Registraren übertragen werden kann, wird die maximale Anzahl von verschiedenen Registraren, die an einem (schnell entdeckten) Domain-Hijacking beteiligt sind, niedrig gehalten, was den Aufwand für die Rekonstruktion der Domain minimiert Folge von Ereignissen nach einer Entführung und Rückgabe einer Domain an ihren rechtmäßigen Eigentümer.

Eine andere dieser 60-Tage-Regeln ist eine 60-Tage-Sperre für "Registrantenwechsel", die Registrare nach jedem Kontakt auferlegen müssen Angaben zum Registrantenwechsel. Dieses Schloss scheint durch die obige Erklärung nicht gerechtfertigt zu sein, daher gehe ich davon aus, dass es eine andere Begründung für seine Existenz gibt - aber ich sehe keine. Wofür ist es und warum ist es obligatorisch, wenn die Domain-Übertragungssperre im Ermessen des Registrars liegt?

2
Mark Amery

Wie in der Richtlinie zur Übertragung von Registrierungen zwischen Registrierstellen angegeben, müssen Registrierstellen vor der Durchführung einer Übertragung eine Genehmigung vom Inhaber der registrierten Bezeichnung einholen. Als solche dienen diese Kontaktdaten einem Sicherheitszweck: Sie sind die Daten, die ein Registrar verwendet, um die Autorisierung zu bestätigen, bevor ein Domaintransfer durchgeführt wird.

Daher dient die Sperre dazu, Domain-Hijacking zu vermeiden. Ohne die Sperre könnte jemand, der Ihre Anmeldedaten bei einem Registrar erfasst hat, die Kontakt-E-Mail Ihrer Domain in eine eigene ändern, eine Übertragung anfordern und dann die Bestätigungs-E-Mail selbst erhalten und die Übertragung damit autorisieren. Mit der Sperre können sie einen solchen Hijack nicht sofort ausführen; Wenn sie eine Übertragung anfordern, ohne die Kontaktdaten zu ändern, erhalten sie keine Bestätigungs-E-Mail. Wenn sie die Kontakt-E-Mail ändern, wird die Sperre aktiviert und Sie haben 60 Tage Zeit, um zu bemerken, dass etwas nicht stimmt, und es vor dem Hacker zu korrigieren bekommt Ihre Domain zu stehlen.

0
Mark Amery

Die Probleme sind aus den nachfolgend erläuterten Gründen miteinander verknüpft.

Aber lassen Sie uns bitte zuerst in die Geschichte zurückgehen, um die Dinge in einen Zusammenhang zu bringen. Ich werde mich hauptsächlich mit gTLDs und .COM/.NET befassen:

  • als die Registrierung/Registrar-Aufteilung gestartet wurde, war das zur Kommunikation verwendete Protokoll dann RRP (siehe RFC2832 ); Wie Sie in Abschnitt 4.3.10 sehen können, wurde der Übertragungsbefehl vom neuen Registrar verwendet ... ohne irgendetwas außer dem Domainnamen anzugeben
  • dies bedeutet natürlich, dass es zu Missbräuchen kommen kann. Daher hat ICANN eine Richtlinie ausgearbeitet, die die Registrierstellen dazu auffordert, die vorherige Zustimmung des aktuellen Registranten (oder des Verwaltungskontakts) einzuholen. Dies war in der Tat ein Albtraum für Registrare, da sie whois-Ausgaben analysieren mussten, um E-Mail-Adressen abzurufen und einen Registranten zu kontaktieren, bevor sie den Übertragungsbefehl starteten. Diese Richtlinie hat sich im Laufe der Zeit weiterentwickelt und in der neuesten Version sind bestimmte E-Mail-Nachrichten vorgeschrieben, die der potenzielle Registrar erneut an den Registranten oder Administratorkontakt senden muss. Er muss eine bestimmte positive Bestätigung zurückerhalten, bevor er mit der Übertragung fortfährt
  • trotz dieser Gefahr haben viele Registrare E-Mails an ihre Kunden gesendet, wenn sie über eine ausgehende Übertragung informiert wurden (sie erhalten die Informationen aus der Registrierung), da eine Übertragung standardmäßig 5 Tage dauert, in denen der aktuelle Registrar dies kann lehne es ab (wenn es nichts tut, wird die Übertragung genehmigt, kann aber auch explizit beschleunigt werden, wenn der aktuelle Registrar den entsprechenden Befehl an die Registrierung sendet, einige von ihnen haben diese Funktion ihren Kunden zur Verfügung gestellt); Transfers könnten also blockiert werden, aber nur während dieses Zeitraums von 5 Tagen
  • parallel dazu wurde RRP schrittweise durch EPP ersetzt (siehe STD69 ). In diesem Protokoll sieht die Übertragung etwas anders aus: Die Idee ist, dass jeder Domainname ein "Passwort" namens authInfo im Protokoll hat, das zum Erstellungszeitpunkt definiert (und später wie gewünscht aktualisiert) wird und normalerweise von der Registrant (was in der Tat nicht wirklich das war, was auf dem Feld passierte, Registrare kümmerten sich oft allein darum); Der Übertragungsbefehl erforderte, dass der potenzielle Registrar das authInfo zusammen mit dem Domainnamen sendet. Die Idee war, dass der potenzielle Registrar dieses "Passwort" erhalten hat, weil die Person, die die Übertragung startet, entweder der Registrant oder jemand war, der es erhalten hat das vom Registranten angegebene authInfo
  • selbst mit diesem neueren Schutz änderte sich die ICANN-Richtlinie nicht, und daher sind Registrare weiterhin vertraglich verpflichtet, positive Berechtigungen per E-Mail zu senden und zu erhalten, bevor sie die Übertragung versuchen, und selbst wenn sie die authInfo erhalten (dies wäre immer noch der Fall) verbindlich durch das Protokoll).

Trotz all dieser "Schutzmaßnahmen" kam es auf dem Feld vor, dass "viele" Domains aus verschiedenen Gründen gestohlen wurden. Dabei wechselten die Mitarbeiter von einem Registrar zum anderen, was sowohl die Ermittlungen als auch den eventuellen Abbruch der Operationen erschwerte Wenn eine Domain von X nach Y und dann von Z ging, konnte die Auflösung nicht von Z zurück nach X durchgeführt werden, es musste immer noch Y einbezogen werden, was die Dinge lang und kompliziert machte.

Daher die 60-tägige Sperrung nach jeder Erstellung oder Übertragung: Der Registrant glaubt, dass seine Domain gestohlen wurde, und erhält genügend Zeit, um den Registrar zu kontaktieren, damit die Domain bei der Untersuchung des Konflikts zumindest eingefroren wird, bevor der Domainname erneut verschoben wird.

Diese ICANN-Richtlinie wird hier detailliert beschrieben: https://www.icann.org/resources/pages/registrars/transfers-en (und als Konsensrichtlinie gilt sie sofort und ohne ausdrückliche Notwendigkeit Verweis auf einen von ICANN akkreditierten Registrar oder eine Registrierung, so dass dies nur gTLDs betrifft.

Erst vor kurzem (Dezember 2016) hat ICANN seine Richtlinien auch auf Registrierungsänderungen ausgeweitet, insbesondere auf E-Mails. Sie können die Redline hier anzeigen: https://www.icann.org/en/system/files/files/transfer-policy-redline-25may16-en.pdf

Beachten Sie, dass entgegen der Verzögerung nach der Übertragung/Erstellung die Verzögerung nach dem Registrantenwechsel ein Opt-out ist, sodass der Registrar darauf verzichten kann, wenn der Kunde dies verlangt.

Warum hat ICANN das hinzugefügt? Weil Sie sonst eine klare Lücke haben, hängt der gesamte oben beschriebene Vorgang davon ab, ob der aktuelle Registrant (oder der Administrator) auf eine E-Mail antwortet, um die Übertragung zu starten.

Stellen Sie sich vor, Sie möchten eine Domain wie diese stehlen: Sie benötigen sowohl den Code authInfo (um sie dem zukünftigen Registrar zu geben) als auch die Kontrolle über die E-Mail-Adresse, um auf die "FOA" (die zu sammelnde formatierte E-Mail) antworten zu können Genehmigung). Standardmäßig können Sie nicht. Wenn Sie jedoch eine Möglichkeit finden, mit der richtigen Autorisierung eine Verbindung zum Registrar-Panel herzustellen (durch jede andere Art von Angriff, wie z. B. einen Phishing-Angriff), können Sie den richtigen Registranten ändern, der Ihnen zwei Dinge bietet:

  • zuerst werden Sie leicht in der Lage sein, den authInfo Code zu erhalten, da alle Registrare ein System haben, um dies dem aktuellen Registranten zu geben
  • dann können Sie jede Art von E-Mail eingeben, die Sie möchten, damit Sie dort die FOA empfangen und darauf antworten können.

Wenn alle vorherigen erfolgreich waren, können Sie die Übertragung starten. Und dies ist schwierig zu beheben, wenn sich der frühere Registrant plötzlich beschwert, weil 5 Parteien beteiligt sind: die Registrierung (die Richtlinie ermöglicht der Registrierung, Streitigkeiten über Übertragungen zu behandeln), der frühere Registrar, der neue Registrar, der aktuelle Registrant und die vorherige.

Mit der neuesten ICANN-Richtlinie müssen Sie nun 60 Tage warten, um die Übertragung zu starten, auch wenn Sie die Registrierungsdaten ändern können. Auch dies gibt dem ehemaligen Registranten mehr Zeit, um ein Problem zu erkennen (der Registrar hat ihn möglicherweise darüber informiert, dass sich etwas in seinem Konto geändert hat, oder er kann für fortgeschrittene Benutzer die whois-Ausgabe überwachen und dort einen Unterschied feststellen ...). und es zu korrigieren. Oder zumindest, um die Übertragung einzufrieren und sicherzustellen, dass sich die Probleme nicht verschlimmern.

Beachten Sie abschließend, dass sich dies alles in naher Zukunft ändern kann und Sie wie zu Beginn zu einem gesünderen Setup zurückkehren können (das Übereinanderlegen von Richtlinien und Protokollen zur Behebung eines Problems führt nur zu mehr Problemen). Neuere europäische Vorschriften (DSGVO) wirken sich sowohl auf whois als auch auf Transfers aus. Kurz gesagt, die Konsequenz ist, dass es für einen potenziellen Registrar sehr schwierig ist, eine E-Mail an den aktuellen Inhaber zu senden und dessen Genehmigung zu erhalten. Der derzeitige Vorschlag von ICANN besteht darin, den RDAP-gestuften Zugriff dafür zu verwenden. Dies könnte funktionieren, wird aber sicherlich einige Zeit in Anspruch nehmen und ist in der Tat eher eine Umgehung eines defekten Systems als eine wirkliche Überarbeitung des Systems (und frühere Versuche von ICANN, das zu ändern) Das ganze System ging noch mehr in die falsche Richtung, wie zum Beispiel die Erstellung eines globalen whois-Inhalts-Repositorys. Eine andere Lösung wurde von einer Arbeitsgruppe innerhalb der ICANN auf den Tisch gelegt: https://www.icann.org/en/system/files/files/gdpr-comments-contract-party-techops-icann-proposed- Compliance-Modelle-08mar18-de.pdf

Kurz gesagt, es wird den aktuellen Registrar beauftragen, nicht den potenziellen um eine Bestätigung vom aktuellen Inhaber zu erhalten. Der potenzielle Registrar müsste lediglich die Übertragung erneut starten, und zwar immer noch mit dem vom Protokoll geforderten authInfo und abgerufen vom Kunden, der die Übertragung startet.

1
Patrick Mevzek

Wenn es jemandem gelingt, die Kontaktdaten des Registranten auf Ihrer Domain zu ändern, wären Sie froh, wenn er sie dann sofort weiterleitet? Oder bevorzugen Sie eine Art Bedenkzeit, damit böswillige Handlungen rückgängig gemacht werden können?

Dies ist der Punkt einer 60-Tage-Sperre nach der Änderung von (nur bestimmten) Registrierungsdaten.

0
Steve

Es gibt "Outs" für diese Regel, die ICANN zulässt. Viele Registrare haben eine Möglichkeit hinzugefügt, mit der Registranten diese Sperre aufheben können.

Warum gibt es diese Regel? Dies ist eine Methode, um Domain-Hijacking zu verhindern. Ich denke nicht, dass die meisten Registrare oder sogar Registranten nach dieser Art von Sperre gefragt haben, da es viele andere, effektivere Möglichkeiten gibt, die Domainentführung zu minimieren, wie das Hinzufügen einer Zwei-Faktor-Authentifizierung.

0
Dynadot