Nochmal etwas ausführlicher, falls die o.g. Fragen noch offen sind:
Ich gebe die URL (von netcup gehostet, wo kein content ist) ein "abc.com" so soll ich, ohne das ich es merke, auf die URL "123.squarespace.com" (die bei Squarespace liegt und auf dem der content, also der Shop ist) weitergeleitet werden.
(1) Niemand soll die Squarespace URL im Browserfenster sehen.
(2) Außerdem würde ich das SSL zertifikat, das bereits bei Squarespace aktiv ist nutzen.
(3) Ist dafür nicht diese Art von "Zusammenführung" mit DNS da? Ich hatte es in einigen Foren so verstanden.
Ich selbst nutze Squarespace nicht. Auf den ersten Blick widersprechen sich (1) und (2) bei der geplanten Verwendung. Squarespace verwendet ein Wildcard-Zertifikat "*.squarespace.com", welches alle Kundenunterdomänen abdeckt. Wenn aber nur die Domäne "example.com" (<-- Standard-Beispieldomänenname) auf der Client-Seite auftauchen soll, dann muss der verwendete Webserver, welcher direkt mit dem Client kommuniziert, auch ein Zertifikat für diese Domäne ausliefern.
Nehmen wir einmal an, dass es eine "DNS-Zusammenführung" (3) (also eine Weiterleitung von der Domäne "example.com" auf "123.squarespace.com") gäbe – wie oben ausgeführt nicht bei Netcup, aber bei anderen Anbietern möglich. (Bei Netcup wäre lediglich eine Weiterleitung einer Unterdomäne "123.example.com" machbar, mithilfe eines "CNAME"-Eintrags für die Unterdomäne im CCP.) Das hieße, dass der Client bei dem Versuch der Ermittlung einer IP-Adresse von "[123.]example.com" die Antwort erhält, er möge unter den (zugehörigen) DNS-Einträgen für "123.squarespace.com" nach einer IP-Adresse suchen. Die HTTP(S)-Anfrage geht dann zwar an die Serveradresse, die letztlich Squarespace hinterlegt hat, allerdings mit dem Ursprungs(unter)domänennamen "[123.]example.com". (Gewünschtes Verhalten wie oben beschrieben.) Diese Anfrage kann Squarespace aber nur korrekt bedienen, wenn es möglich ist, ein TLS-Zertifikat für die eigene (Unter-)Domäne bei Squarespace zu hinterlegen. Wichtig ist, dass diese DNS-Weiterleitung für *alle* Arten von Abfragen von DNS-Einträgen aktiv ist, welche ursprünglich an "[123.]example.com" gerichtet sind. Es findet client-seitig nur ein applikationsspezifischer Zugriff (hier: HTTP(S)) auf den Dienst (hier: Webserver) statt, die Weiterleitung "greift" schon bei Ermittlung der DNS-Inhalte.
Eine Weiterleitung ist allerdings auch (nur) bei Verwendung des HTTP(S)-Protokolls möglich:
(a) Der "einfachste" Fall ist derjenige, bei welchem der Host (welcher "[123.]example.com" bedient) dem Client mithilfe eines HTTP-3xx-Codes explizit mitteilt, er möge eine zweite Anfrage unter Verwendung der "Ersatzadresse" "123.squarespace.com" stellen. Das führt dann dazu, dass die Squarespace-Adresse auf der Clientseite bekannt wird, denn die zweite Anfrage erfolgt explizit unter dem "Ersatznamen". Nicht das ursprünglich genannte gewünschte Verhalten, allerdings benötigt Squarespace keine Kopie des TLS-Zertifikats für "[123.]example.com" und es gibt keinen doppelten Inhalt, wodurch die Webpräsenz nicht von Suchmaschinen abgestraft wird.
(b) Alternativ kann ggf. ein sogenannter "Reverse Proxy" eingesetzt werden, welcher die Anfragen an [123.]example.com[/xyz] dadurch bedient, dass er diese seinerseits in beide Richtungen umschreibt, intern also 123.squarespace.com[/xyz] kontaktiert und als "Mittelmann" fungiert. Dies führt jedoch zunächst zu redundanten Inhalten, denn dieselbe Anfrage sollte clientseitig ohne Gegenmaßnahmen auch direkt gegen 123.squarespace.com[/xyz] funktionieren. Eine Möglichkeit, gut erzogene Suchmaschinen davon abzuhalten, beide Adressen zu erfassen, ist die Sicherstellung, dass entweder unterschiedliche robots.txt-Dateien/-Einträge für beide (Unter-)Domänen ausgeliefert werden und/oder Kontaktanfragen bekannter Bots seitens Squarespace anderweitig verhindert werden.
Hat das etwas Licht ins Dunkel gebracht?