Externe Domain auf Webspace schalten (ohne Mailserver)

  • Hallo zusammen,


    kurz: Ist es möglich, eine externe Domain auf den Webspace von netcup zu schalten (vie DNS), ohne ebenfalls den Mailserver umzuziehen?


    Bei einem externen Webhosting-Anbieter liegt eine Domain mit angebundenem Webspace + Mailserver (beides in derselben Plesk-Instanz). Aus Performance-Gründen möchte ich nun den Webspace von netcup für diese Domain nutzen. Allerdings sind unter der Domain auch einige Mail-Adressen aktiv, die ich beim alten Webhosting-Anbieter belassen möchte.

    Die Aufschaltung von externen Domains ist via CCP von netcup und der Änderung bestimmter DNS-Einträge möglich, allerdings sind dort auch A- auch MX-Einträge für den Mailserver abzuändern, was ja zwangsläufig auch die den alten Mailserver "deaktivieren/umleiten" würde.


    Ist es z.B. möglich, die den Mailserver betreffenden Einträge unverändert zu lassen und nur die A- und CNAME-Einträge wie von netcup vorgegeben zu verändern oder ergeben sich dadurch Probleme - etwa auf dem alten Mailserver wie auf den neuen Webhosting-Anwendungen (Wordpress)?


    Eine alternative Überlegung wäre, die gesamte Domain zu netcup umziehen, sprich per Auth-Code zu transferieren. Dann müssten jedoch auch die eingerichteten Mailadressen / der Mailserver umgezogen werden. Ist das ohne große Ausfallzeit umsetzbar und vor allem: Wie sieht die Umsetzung aus? (Falls der alleinige Umzug des Webspace nicht funktioniert.)


    PS: Bin kein gelernter Informatiker, sondern Autodidakt - kenne mich also oft nur schemenhaft mit der ganzen Thematik (DNS/Server/...) aus, lese mich aber gerne ein und stolper doch immer zu einer Lösung. Also falls grobe Schnitzer in meiner Logik vorhanden sind, gerne darauf hinweisen oder ausführlicher erklären/auf Wissensquellen verweisen.


    Liebe Grüße
    Fabinski

  • Nach meinen Erfahrungen reicht es für die Aufschaltung einer externen Domain aus, die A und ggf AAAA Einträge zu ändern. Mit den CNAME Einträgen wäre ich vorsichtig, da sie zumindest teilweise Mail betreffen werden (autoconfig, Domainkeys usw).

  • Hallo,


    wenn der Webserver die Domain nicht kennt sollte es eigentlich immer Probleme geben.

    Die muss schon als Virtual Host oder ähnliches eingetragen sein.

    Das geht soweit ich weiss im Webhosting nicht per hand.


    Gruß Eckhard

  • Das passiert ja beim Aufschalten einer externen Domain.

  • Es gibt ja extra einen Menüpunkt im CCP/WCP, um externe Domains auf ein Webhosting aufzuschalten. Das ist der letzte Reiter beim entsprechenden Webhosting in der Produktliste, "Externe Domains". Hier muss die externe Domain eingebunden werden "Externe Domain hinzufügen". Das dauert dann ne Weile, ein A Record im DNS beim alten Anbieter, das auf die IPv4 des Webhostings verweist, sollte schon reichen. Falls IPv6 gewünscht ist noch ein AAAA-Record. Die entsprechenden IP-Adressen stehen ja auf der Übersichtsseite des Webhostings. Irgendwann habe ich es auch schon mal geschafft, die Domain aufzuschalten, obwohl rein gar nichts im DNS der Domain auf irgend etwas bei netcup verwiesen hätte. Hat dann noch etwas länger gedauert und ich war dann ganz überrascht, als dann völlig unerwartet doch die entsprechende E-Mail eingetroffen ist. Das ganze andere angezeigte Gedöns von DNS-Records braucht man nur, wenn man eben mehr nutzen will als nur den Webserver, also z.B. Mail, Webmail, Autoconfig usw.

  • Vielen Dank für die bisherigen Antworten.


    Ich habe mal mein geplantes Vorgehen visualisiert (siehe Bild im Anhang), um die externe Domain mit dem Webserver zu verbinden.


    1. Änderung der beiden A-Records beim alten Webhoster mit der IPv4 von netcup (sprich von meinem Webhosting-Paket) + IPv6 [rote Kästen]
    2. Sonst keine Änderungen vornehmen (MX/CNAME/TXT/...)
    3. Warten bis die Einträge aktualisiert wurden
    4. Im Menü des CCP die externe Domain aufschalten
    5. Der Domain ein Verzeichnis auf dem Webspace zuweisen + SSL-Verschlüsselung aktivieren
    6. fertig - DNS weist auf den Webserver von Netcup + der alte Mailserver vom alten Webhoster bleibt aktiv
  • Ich weiss nicht, was der AAAA-Eintrag für dyndnsv6 momentan genau bewirkt, aber ich denke mit den Websites selbst hat er nichts zu tun und wird eher auf irgendwas bei dir zuhause zeigen oder jedenfalls nicht auf netcup zeigen sollen. Also wenn AAAA-Record, dann für domain.tld und *.domain.tld, wo du ja auch die Änderungen in den A-Records machst. Ansonsten scheint mir das so ok zu sein, auch der Ablauf.


  • Habe es nun getestet.

    Umsetzung

    • Änderung der beiden A-Records
      1. domain.tld.
      2. *domain.tld
    • Keine Änderung bei AAAA/MX/...-Einträgen

    Ergebnis

    • Integration in netcup-Webhosting hat funktioniert
    • Mailserver des externen Hosters funktioniert weiterhin


    Vielen Dank für die Hilfe, sollte sich noch etwas ereignen werde ich hier berichten.

  • Noch ein Tipp: Auf dem Mailserver bei netcup wirst du vermutlich trotzdem die Domain finden. Dort besser einmal die Mail-Dienste für die Domain deaktivieren. Es kann nämlich sonst zu Problemen kommen, wenn der Mailserver versucht lokal Mails zuzustellen.

    VPS 500 G8 Plus | VPS Karneval 2020 | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Nachtrag

    Noch ein Tipp: Auf dem Mailserver bei netcup wirst du vermutlich trotzdem die Domain finden. Dort besser einmal die Mail-Dienste für die Domain deaktivieren. Es kann nämlich sonst zu Problemen kommen, wenn der Mailserver versucht lokal Mails zuzustellen.

    Habe sowohl auf netcup (in Plesk) den E-Mail-Service deaktiviert, als auch beim alten Hoster (in Plesk) das Webhosting deaktiviert.


    Problem: E-Mail Clients

    Ein Problem ist allerdings doch noch aufgetreten: Zwar funktioniert der Mailserver noch (via webmail.), doch in meinen E-Mail-Clients konnten keine Nachrichten mehr synchronisiert werden. Ich verwende als Mail-Clients Thunderbird (Desktop) und FairMail (Mobil). Die Fehlermeldung von FairMail habe ich angehängt.

    Beheben konnte ich das Problem durch Änderung des Host-Servers von domain.tld zu imap.domain.tld (in FairMail), bzw. durch Neu-Hinzufügen des E-Mail-Kontos bei Thunderbird.

  • domain.tld zu imap.domain.tld

    Ist diese Vorgehensweise nicht ohnehin problembehaftet? So müsste doch jedes mal ein Zertifikatsfehler geschmissen werden - daher werden ja i.d.R. auch diese generischen Hostnamen verwendet, bei Netcup beispielsweise mx2xxx.netcup.net. Dort kann der Anbieter dann auch seine eigenen Zertifikate hinterlegen.


    Und genau diese Mailserver werden auch, beispielsweise von Thunderbird, durch autoconfig genutzt.

    http://autoconfig.deinedomain.…dress=user@deinedomain.de

    Beispiel:

  • Ist diese Vorgehensweise nicht ohnehin problembehaftet? So müsste doch jedes mal ein Zertifikatsfehler geschmissen werden - daher werden ja i.d.R. auch diese generischen Hostnamen verwendet, bei Netcup beispielsweise mx2xxx.netcup.net. Dort kann der Anbieter dann auch seine eigenen Zertifikate hinterlegen.

    D.h. es sollte ohnehin der hostname imap.domain.tld verwendet werden und die vorherige Einstellung in den Mailclients war 'falsch'?

  • Nicht ganz. Ich kenne es von diversen Anbietern so, dass imap|mail|wasauchimmer.deinedomain.de zwar auch klappt, aber eben nur mit Zertifikatsfehlern, da auf den Mailservern des Anbieters eigene Zertifikate liegen.


    Beispiel bei Netcup: rufe ich das Zertifikat für mail.meinedomain.de ab, wird ein Zertifikat ausgeliefert das allerdings nur für *.netcup.net gültig ist. Und das würde jeder vernünftige Mailclient sofort bemängeln! (allerdings bieten auch die meisten Clients an das nach einer Bestätigung des Users zu ignorieren)

    Code
    $ openssl s_client -connect mail.meinedomain.de:143 -starttls imap
    CONNECTED(00000003)
    depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
    verify return:1
    depth=1 C = US, O = DigiCert Inc, CN = RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1
    verify return:1
    depth=0 CN = *.netcup.net
    verify return:1


    Wie sich das nun genau bei deinem unbekannten Anbieter B verhält, weiß ich nicht. Gibt natürlich auch Mittel und Wege beim Mailserver anders vorzugehen. Ich kenne es halt von mehreren Anbietern so. Einfach mal nachprüfen welcher Mailserver in der autoconfig bzw. in der Hilfe genannt wird - wenn das Zertifikat dort passt ist ja alles schick. :)

  • Ich habe beim Anbieter B in der Dokumentation nachgesehen und tatsächlich empfiehlt dieser als Posteingangs- und Ausgangsserver den Namen des Servers, auf welcher die jeweilige Plesk-Instanz liegt - gerade um Zertifikatsfehlermeldungen zu vermeiden.


    Wieder was gelernt, danke.