Transfer einer Domain (weg von df) und gleichzeitig als externe Domain einbinden

[Gast]

Ich (bzw. meine Frau) haben hier bei DomainFactory einige .eu-Domains registriert. Diese werden derzeit für Webhosting und Email hier bei DomainFactory genutzt.

1. Wir möchten nun diese .eu-Domains zu einem anderen Registrar transferieren.
   Das sollte noch kein Problem darstellen: Beim neuen Provider den Transfer veranlassen, die entsprechenden DNS-Records auf die Web- und Mailserver von df setzten und alles sollte wie gewohnt weiterlaufen...
2. ...solange die .eu-Domains bei DomainFactory noch nicht gekündigt sind, also dem df-System noch "bekannt" sind.

Problematik: Sobald die weggezogenen .eu-Domains bei df gekündigt sind, sollten sie nahtlos (unterbrechungsfrei) wiederum als externe Domains bei df eingebunden werden (Mail- und Webhosting soll ja weiterhin über df laufen).

Frage: Wie sollen wir hier am besten vorgehen, sodass die weg-transferierten Domains unterbrechungsfrei als externe Domains wieder eingebunden werden? (Ist das einen Kombination aus externem und internem Domain-Transfer?) Ich denke, im "alten" Forum war so ein Ablauf mal dokumentiert...

[Brasa]

Die Frage stellt sich bei mir momentan auch gerade. Wie hast du das gelöst?

[wecotec]

Ich habe zusammen mit dem Support (bzw. meine PVI (eigener Ansprechpartner)) gelöst indem ich vor dem Wegtransfer eine kurze Info gegeben habe.

ich kann allerdings nichts darüber sagen ob der Transfer ohne Ausfälle vonstatten ging, da uns nur die Erhaltung der Emailkonten wichtig gewesen ist.

[JensK_2]

Wir haben in den vergangenen 12 Monaten alle Domains zu einem anderen Registrar exportiert. Einen Teil der Domains haben wir bei DomainFactory wieder als externe Domain eingebunden. Das Vorgehen haben wir immer nach folgendem Schema vorgenommen:
1. Kündigung der Domain
2. KK-Auftrag beim neuen Provider. (Info: Bei Domainfactory sind gekündigte/umgezogene Domains auch nach dem Transfer immer noch für ein paar Tage im Kundenmenü sichtbar.)
3. Wenn beim neuen Provider der KK bestätigt wurde gewünschte DNS-Einträge auf Domainfactory zeigen lassen oder gar den Nameserver von Domainfactory angeben - je nach Bedarf.
4. One-Done-Ticket an die Vertragsabteilung mit dem Text: "wir haben soeben die Domain xxx (Domain Dxxxxxx) zu einem anderen Provider umgezogen. Da wir weiterhin die Webpräsenzen und E-Mail-Konten auf den DomainFactory-Server belassen möchten, bitten wir dies Domain kurzfristig von intern auf extern umzustellen, damit auch alle Mail- und Domainkonfigurationen erhalten bleiben. Für die externen Domains fallen Kosten gemäß Ihrer Preisliste an, dem wir ausdrücklich zustimmen."

Das hat in über 50 Fällen problemlos geklappt. Eine Unterbrechung fand nicht statt.

Jens

[Gast]

Das hat in über 50 Fällen problemlos geklappt. Eine Unterbrechung fand nicht statt.

Vielen Dank an Jens und Markus - so werden wir's versuchen!

[Gast]

Zwischenbericht:

Wir wollten nun gleich alle Domains (des Auftrags) zum Providerwechsel/Transfer kündigen:
Das geht so leider nicht, weil laut Hinweistext (im Kundenmenü) durch das Kündigen der letzten verbleibenden Domain auch der gesamte Auftrag selbst gekündigt wird!?

Wir haben daher probeweise mal eine Domain zum Providerwechsel/Transfer gekündigt und sofort die Kündigungsbestätigung und den AuthCode erhalten.
Als nächsten Schritt werden wir beim neuen Registrar den Transfer anstoßen, der sich aber bis zu 10 Tagen hinziehen kann.

@Jens: Wann genau ist der "richtige" Zeitpunkt (innerhalb des mehrtägigen Transferprozesses), das One-Done-Ticket an die Vertragsabteilung zu senden?
Schon präventiv im Vorfeld oder erst dann, wenn der Transfer tatsächlich (technisch) vollzogen ist?

2. KK-Auftrag beim neuen Provider. (Info: Bei Domainfactory sind gekündigte/umgezogene Domains auch nach dem Transfer immer noch für ein paar Tage im Kundenmenü sichtbar.)

Bedeutet das, dass df-seitig keine Eile besteht, nach dem erfolgreichen Transfer sofort von "interner" auf "externe" Domain umzustellen, weil die transferierte Domain dem (Mail-)System eh noch einige weitere Tage "bekannt" ist?

[Enigma]

Ich würde es im Vorfeld machen. Mit Garantien (z. B. bzgl. der Anzahl der Tage, die die Domain im System verbleibt) hat DF sich schon immer schwer getan, und mittlerweile kann man das komplett vergessen. Laut mehreren hier noch sehr aktiven Kollegen passiert zudem am Wochenende so ziemlich gar nichts mehr im Support; da fallen schon ein paar Tage Reaktionszeit weg. Die Domain kann zwar im Notfall nachträglich wieder angelegt werden, aber dann sind alle Einstellungen etc. weg.

Ich habe das daher direkt nach der Kündigung im DF-Kundenmenü beauftragt. Das betraf bei mir zwar nur sehr wenige Domains, hat da aber zuverlässig funktioniert.

Bzgl. der Kündigung der letzten Domain: Ggf. Kann DF Dir eine kostenlose Third-Level-Domain zuordnen (mal beim Support fragen). Oder Du wartest, bis die erste externe Domain aktiv ist - das sollte eigentlich auch genügen.

Gruß
Jan

[JensK_2]

Hallo Gast ,

wir hatten das One-Done-Ticket immer nach der Bestätigung durch den neuen Provider an Domaifactory geschickt. Aber wie Enigma schrieb, kann es auch nicht schaden, das Ticket vorher zu erstellen. Bei uns hat der Domaintransfer eigentlich immer nur einige Minuten gedauert.

Gerade diesen Monat haben wir die letzten beiden Domains abgezogen, so dass nun alle Domains weg sind. Wir haben allerdings auch keinen Tarif mit Inklusivdomains. Möglicherweise liegt es aber auch daran, dass Du alles auf einmal kündigst und dann wirklich nichts verbleibt - Von der Wiedereinbindung ist dem System ja noch nichts bekannt. Vermutlich klappt es, wenn Du die erste, einzelne Domain als externe Domain eingebunden hast und dann alle restlichen Domains kündigst.

Gruß, Jens

[Gast]

Mein abschließender Erfahrungsbericht:

Der Umzug/Transfer zweier .eu-Domains hat sich nun über eine Woche gezogen, weil

1. wir "kritische" Schritte nur werktags am Vormittag zu den Supportzeiten durchgeführt und
2. sicherheitshalber immer die Antworten der Support-Mitarbeiter abgewartet haben.

Domain A:

1. Domain A bei df zum Providerwechsel/Transfer gekündigt.
2. One-Done-Ticket an df geschrieben, indem wir unser Vorhaben (Domain-Transfer und danach Einbinden als externe Domain) angekündigt haben.
3. Antwort von df-Support abgewartet; dieser hat unser geplantes Vorgehen bestätigt.
4. Domain-Transfer beim Ziel-Regristrar mit Hilfe des AuthCodes eingeleitet.
5. System des Ziel-Regristrar meldet, dass AuthCode zur Domain A ungültig sei.
6. One-Done-Ticket an df geschrieben, mit der Bitte, einen neuen, gültigen AuthCode für die Domain A zu nennen.
7. Neuerlichen Domain-Transfer beim Ziel-Regristrar mit Hilfe des aktuellen AuthCodes eingeleitet.
8. Nach erfolgreichem Domain-Transfer One-Done-Ticket an df geschrieben, mit der Bitte, die Domain A nun endgültig von "intern" auf "extern" umzustellen.

Domain B:

1. Domain B bei df zum Providerwechsel/Transfer gekündigt.
2. One-Done-Ticket an df geschrieben, indem wir unser Vorhaben (Domain-Transfer und danach Einbinden als externe Domain) angekündigt haben.
3. Antwort von df-Support abgewartet; dieser hat unser geplantes Vorgehen bestätigt.
4. Domain-Transfer beim Ziel-Regristrar mit Hilfe des AuthCodes eingeleitet.
5. System des Ziel-Regristrar meldet, dass AuthCode zur Domain B ungültig sei.
6. One-Done-Ticket an df geschrieben, mit der Bitte, einen neuen, gültigen AuthCode für die Domain B zu nennen.
7. Neuerlichen Domain-Transfer beim Ziel-Regristrar mit Hilfe des aktuellen AuthCodes eingeleitet.
8. System des Ziel-Regristrar meldet, dass die Domain B nicht verfügbar bzw. transferierbar sei.
9. Wie sich später herausstellte, war just zu diesem Zeitpunkt eurid.eu ausgefallen bzw. eine Störung in deren Systemen.
10. Ticket an Ziel-Regristrar geschrieben, mit der Bitte, den "hängengebliebenen" Domain-Transfer nochmals manuell anzustoßen.
11. Nach erfolgreichem Domain-Transfer One-Done-Ticket an df geschrieben, mit der Bitte, die Domain B nun endgültig von "intern" auf "extern" umzustellen.

Die ganze Zeit über war (von unserer Seite) keine Dienste-Unterbrechung feststellbar.

Resüme:
+ df-Support hat jeweils zeitnah und korrekt reagiert,
- beide ursprünglichen df-AuthCodes waren ungültig.
o Transfer-Prozess des Ziel-Registrars war durch eurid-Störung in einem "undefinierten" Zustand.

Nochmals ein großes Danke an alle Mitwirkenden - auch (und gerade) hier im Forum!

[wecotec]

Ergänzend dazu noch eine Info meines PVIs: Pro Ticket sind nur 20 Domains von intern zu extern machbar

(... )Resüme: (...)

Hmmm....wenn ich mir jetzt überlege dass ich das mit 250 Domains vor der Brust habe....aber dafür hat man seinen PVI, der jetzt dank DF dieses Theater haben wird....

[fpielage]

Hmmm....wenn ich mir jetzt überlege dass ich das mit 250 Domains vor der Brust habe....aber dafür hat man seinen PVI, der jetzt dank DF dieses Theater haben wird....

Das hat df natürlich kommen sehen und fix die SSL-Preise "angepasst" (woran auch immer). Sofern die Reseller das durchrechnen, müssten sie eigentlich auch das Hosting umziehen. Und das wiederum führt zu einer niedrigeren Anzahl an Intern-Extern-Umwandlungen bei Domains. Das ist schon schlau gemacht!

Grüße
fp

[Nils Dornblut]

Ergänzend dazu noch eine Info meines PVIs: Pro Ticket sind nur 20 Domains von intern zu extern machbar

Der Mehraufwand für mehrere Tickets sollte sich doch aber in Grenzen halten oder? Ich würde mal vermuten, das liegt im Bereich von Sekunden und ablauftechnisch ist es sicher sinnvoll das zu stückeln für alle Seiten.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Resüme:
+ df-Support hat jeweils zeitnah und korrekt reagiert,
- beide ursprünglichen df-AuthCodes waren ungültig.
o Transfer-Prozess des Ziel-Registrars war durch eurid-Störung in einem "undefinierten" Zustand.

Nochmals ein großes Danke an alle Mitwirkenden - auch (und gerade) hier im Forum!

Danke für Ihren Bericht. Es tut uns leid, dass nicht alles direkt geklappt hat. Leider ist es aufgrund der umfangreicheren Zusammenhänge nicht so einfach mit den Auth-Codes und es kann an mehreren Stellen zu Problemen kommen, die eine Neugenerierung erforderlich machen. Bitte entschuldigen Sie die Unannehmlichkeiten.

Mit freundlichen Grüßen

Nils Dornblut

[Enigma]

- beide ursprünglichen df-AuthCodes waren ungültig.

Das ist eine unschöne Quote. Aber sicherlich auch nicht repräsentativ. Ich habe eine dreistellige Anzahl Domains weggezogen und dabei zwei oder drei ungültige AuthCodes gehabt. Andere hatten nicht ganz so viel Glück, aber die Quote war auch da im überschaubaren Rahmen. Nach einem Hinweis wurde jeweils schnell ein neuer AuthCode generiert; in meinem Fall passte der dann auch.

Gruß
Jan

[wecotec]

Der Mehraufwand für mehrere Tickets sollte sich doch aber in Grenzen halten oder? Ich würde mal vermuten, das liegt im Bereich von Sekunden und ablauftechnisch ist es sicher sinnvoll das zu stückeln für alle Seiten.

Ich habe es auch nur rein informativ hier dokumentiert