Ist das tatsächlich so einfach einen eigenen, lokalen DNS-Resolver zu installieren?
Ich kann jetzt nur für die Pakete in Debian und OpenWrt sprechen, aber prinzipiell: Ja!
Die sind normalerweise gut vorkonfiguriert, da kann man direkt loslegen. 
Den Upstreamserver kann man sich normalerweise sparen, das kann Unbound ja auch selbst, inklusive DNSSEC.
- Inhalt wieder gelöscht. -
Welchen Tarif hast Du denn? Also welches Control Panel verwendest Du?
Die erste Option scheint es laut Deiner Aussage ja nicht zu sein. Die dritte Option wurde bzw. wird mittlerweile eingestellt, das also wohl auch nicht.
Somit wären wir beim alten WCP, also die zweite Option?
Dort verwende ich folgendes in einer .htaccess Datei, das ist somit getestet:
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]Dort gibt es sowieso nur Apache und noch keinen Nginx, das sollte also ohne Konfigurationsänderung im WCP klappen.
Dagegen hilft das Setzen anderer DNS Server, z.B. Cloudflare oder Google.
Oder gleich ein eigener lokaler Resolver wie z.B. Unbound.
Kann ich definitiv nur empfehlen.
Das einzige wo ich hier die Finger von lassen würde ist DNS wenn man DNSSEC nutzen will
Auch wenn Du damit DNS im Sinne von über netcup registrierte Domains meinst, wo ich Dir leider ebenfalls zustimme…
Da sprichst Du etwas an, was für readyfornix vielleicht ganz interessant sein könnte: Installiere Dir lieber einen lokalen Resolver (z.B. Unbound) oder wenigstens lokalen Cache mit einem externen NS. Vertrau mir, da schläft man besser. 
Und stell Deine IPv4-Netzwerkkonfiguration unbedingt auf statisch, also nicht DHCP, und deaktiviere Router Advertisements bei IPv6. (Siehe: sysctl-Config im Wiki)
Bei mir wurden schon 3x Server aus irgendwelchen Gründen umgezogen. Auf allen waren Snapshots. Das geht, macht aber anscheinend mehr Arbeit ...
Natürlich geht es, aber afaik nicht "online" (live) sondern nur "offline", also heruntergefahren.
Bei einer Live-Migration wandert auch der RAM mit, Deine VM bemerkt es (bis auf einen kurzen Aussetzer) normalerweise gar nicht, da Deine Prozesse einfach weiterlaufen.
Werden Wartungsarbeiten rechtzeitig angekündigt?
Die meisten Hardware-Wartungsarbeiten wirst Du Dank Live-Migration wahrscheinlich gar nicht mitbekommen. Von Massenpatches wie z.B. bei Meltdown oder Spectre einmal abgesehen.
Falls man Snapshots hat, ist übrigens keine Live-Migration auf einen anderen Node möglich. In diesem Fall bekommt man normalerweise eine E-Mail, die ankündigt, dass ein Umzug inkl. Shutdown (ACPI) in nächster Zeit stattfinden wird.
Ist Euch schon mal die Hardware eines Server abgeraucht und mußte aus dem externen Backup wiederhergestellt werden? Oder ging dafür der Snapshot?
Bei den VPS/RS mir persönlich nicht, aber das ist eigentlich auch egal, welche Erfahrung andere Kunden damit gesammelt haben.
Fakt ist, dass ein Datenverlust jederzeit passieren könnte, man sollte also immer externe Backups haben. Es ist zwar unwahrscheinlich, aber genauso könnte sogar das ganze RZ abfackeln. (Siehe Ereignis bei der Konkurrenz.)
Die Snapshots liegen jedenfalls auf dem gleichen RAID-Verbund wie Deine virtuelle HDD/SSD. Wenn sich dort zu viel verabschiedet, sind die logischerweise weg. Snapshots ersetzen keinesfalls Backups!
Wie ist die Ausfallzeit wegen Netzwerkproblemen so übers Jahr?
Aus meiner 13+ jährigen Erfahrung als netcup-Kunde kann ich Dir jedenfalls berichten, dass sich das in Grenzen hält. Dass einmal das ganze Netzwerk weg ist, ist extrem selten. Das kann ich auf einer Hand abzählen.
Der letzte Ausfall, an den ich mich gut erinnern kann, war ein ca. zweistündiger Totalausfall der VLAN-Produkte Ende letzten Jahres. Das reguläre (öffentliche) Netzwerk funktionierte währenddessen aber einwandfrei.
Routing- bzw. Peering-Probleme zu einzelnen anderen ISP sind da schon ein anderes Thema, aber die liegen oftmals nicht (nur) im Einflussbereich von netcup bzw. Anexia.
Der v-server scheint gegenüber dem root-server gar nicht so hinterher zu sein. Was bevorzugt Ihr?
Viel Speicherplatz oder günstiger Preis: VPS
Hohe I/O oder CPU-Anforderungen: Ganz klar RS.
Wo soll ich da am besten fragen, einfach beim kundenservice anrufen oder irgendwo nh Ticket aufmachen
Falls Du die Sache mit dem Kündigen meinst: In meinem Beitrag waren (im Zitat) eigentlich alle Links zum Netcup-Wiki rund um das CCP bereits enthalten.
Oder worum geht's?
[…] kennt jemand einen anderen guten Anbieter bei dem ich einfach einen normalen windows server bekomme
Da wird Dir niemand ernsthafte Tipps geben können:
Folgende Verhaltensweisen sind, im Rahmen der Nutzung vom netcup GmbH Kundenforum, nicht erlaubt: […] Andere (Web) Hosting-Anbieter namentlich nennen […]
Max der kleine Normalerweise verwendet man dafür auch nicht die VNC-Konsole, außer man hat sich ausgesperrt. Das Stichwort heißt bei Linux SSH
Aber auch davon kann ich nur abraten, wenn Dir offenbar jegliches Grundwissen bezüglich Serveradministration fehlt. Wir meinen das alle nicht böse, ich zitiere mich einmal selbst…
Zitat von KB19Ein wirklich gut gemeinter Rat…
Zufriedenheitsgarantie nutzen bzw. Widerrufsrecht wahrnehmen
Bitte sei Dir bewusst: Du hantierst hier mit einem Server, der völlig ohne Schutz im Internet hängt und über eine ungefilterte Anbindung mit 2.500 Mbps verfügt! Du haftest für alles, was direkt oder indirekt damit passiert. Du bist alleinig für die Administration und Absicherung des Systems verantwortlich.
Wenn Du nicht über die notwendigen administrativen Kenntnisse verfügst, solltest Du den Server im SCP sofort ausschalten, den Autostart deaktivieren und das Produkt im CCP kündigen. Bei Nutzung der Zufriedenheitsgarantie bzw. des Widerrufsrechts sollten Dir keine Kosten entstehen. (Ohne Gewähr, bitte im Vertrag bzw. den AGB nachsehen.)
Bei ECONNREFUSED sind ja noch nicht einmal Zugangsdaten im Spiel, da wird bereits die TCP-Verbindung abgewiesen.
Ich kann Port 21 auf der IP-Adresse 188.68.47.217 jedenfalls einwandfrei erreichen. Deine Firewall (am PC bzw. Router) kannst Du als Fehlerquelle ausschließen?
Ist der Port bei Dir über telnet erreichbar?
Falls dort irgendwas von ProFTPD erscheint, klappt das schon einmal. Mit quit kommst Du wieder raus aus der telnet-Sitzung.
Wenn die Verbindung über Telnet auch nicht funktioniert, wende Dich einmal schriftlich an den Support. Vielleicht wurde Deine IP-Adresse wegen zu vielen Fehlversuchen temporär blockiert.
Ist da neben der index.php zufällig noch eine index.html im gleichen Ordner mit genau diesem Inhalt vorhanden?
Das ist einfach: Ein Euro für mich und -,69 für dich
Warte nur ab, bis das der Finanzminister sagt. 
mainziman Ob da jetzt 99/90 oder x9 steht, kommt aber aufs gleiche raus. Oder zeig mir mal, wie Du € 1,69 durch zwei teilst.
Also die allereinfachste Recheneinheit wären ja 100%, da könnte man die Umsatzsteuer immer absolut genau berechnen ohne runden zu müssen.
Du willst die ganzen 90er und 99er Preise in der Welt abschaffen? 
[…] und man muss sich halt kümmern. Muss man beim Hosting sicher auch, aber beim eigenen Server muss man sich eben so richtig kümmern […]
Treffend am Punkt gebracht.
Beim Webhosting muss man sich wenigstens "nur" um die installierten Anwendungen kümmern, und das kann bekanntlich schon enorm zeitraubend sein. 
Ich stimme dir zu, wenn du wirklich gar keine Kompromisse eingehen kannst. Ansonsten sind Shared Hostings durchaus sehr unterschiedlich, so dass man zwar überall Kompromisse machen muss, aber eben nicht überall die selben.
Mein persönliches Problem ist halt, dass ich es sehr genieße, meine eigenen Nginx/PHP/sonstwas Konfigurationen verwenden zu können und bei Bedarf root zu sein. Wenn ich dann zusätzlich nicht lange in einem Webinterface rumklicken muss, ist es natürlich noch besser.
Ich brauche meine Webserver aber sowieso für einige Dinge, die ich niemals auf einem Shared Server laufen lassen könnte. Der wirkliche Grund gegen Webhosting ist bei mir also eigentlich nicht zwangsläufig der Komfort: Wenn ich das sowieso schon selbst betreiben muss, kommt es auf einen vHost (oder vServer) mehr oder weniger auch nicht mehr an. 
Aber wir schweifen langsam ins Offtopic ab…
Um zur ursprünglichen Frage auch noch etwas Konstruktives beizutragen…
Nachdem ich selbst mit einer einfachen Spielwiese nicht in der Lage bin, mit der Webhosting-Oberfläche, Basis-Dienste einzurichten, und ich eigentlich keinen (v)Server brauche, bin ich verunsichert, ob ich den Umzug mit bestehenden Domains versuchen soll. Funktionieren die oben genannten Aktionen bei Euch, ohne das Ihr den Support jedesmal bemühen müsst? Habe ich einfach nur eine Montagsinstallation erwischt und nächste Woche ist alles gut?
Ich habe das Webhosting nur knapp zwei Jahre produktiv verwendet, meine Erfahrung damit: Wenn es mal läuft, dann läuft es auch. Klar, Pech kann man immer haben und irgendwelche Fehler könnten jederzeit auftreten. Aber es ist wohl im Interesse von netcup, dass Probleme nicht zum Standard werden.
Weil Du das Thema (v)Server ansprichst: Das ist schon eher der Knackpunkt. Wenn man das notwendige Wissen für einen selbst administrierten (v)Server hat, fühlt man sich bei einem Webhosting, egal bei welchem Anbieter, schnell eingeschränkt. Im Endeffekt ist Shared Webhosting immer ein Kompromiss, den man eingehen muss. Wenn man dazu nicht bereit ist, sollte man halt doch lieber einen (v)Server verwenden. Dort kann man alles einrichten, wie man es möchte, mit dem großen Nachteil, dass es mehr (Zeit-) Aufwand ist.
Für die von mir hochgeladenen Dateien und Verzeichnisse, muss den Zugriff aber auch für public freigeben.
Das sollte aber sowieso standardmäßig der Fall sein, also kein manueller Eingriff notwendig sein?
(Ordnerrechte: 0755; Dateirechte: 0644)
Prinzipiell braucht der Webserver aber sowieso nur Zugriff auf Dateien, die er selbst einlesen muss. D.h. für statische Dateien oder z.B. um die Existenz von PHP-Dateien zu verifizieren, bevor sie über FPM ausgeführt werden. Irgendwelche Includes-Ordner o.ä. müssen somit nicht für jeden lesbar sein. Die könnte man sogar als 0700 chmod'en bzw. die Dateien als 0600.
(Ich beziehe mich mangels Erfahrung jetzt rein auf PHP. Bei node.js könnte es Unterschiede geben.)
ich habe nicht nach Dateimanager geschaut sondern nach FTP. Und da habe ich nichts gefunden
Streng genommen hat der browserbasierende Dateimanager mit FTP (File Transfer Protocol) auch nichts zu tun.
Der verwendet weder intern FTP, und auch nicht nach außen, da dort HTTP(S) zum Einsatz kommt.
(SCNR)
Die A-Records müssen nur temporär auf das Webhosting geschaltet werden, damit Plesk sich zuständig fühlt. Die Einträge kannst du nach erfolgreicher Zuweisung der externen Domain dann wieder ändern und auf deinen VPS zeigen lassen.
Das Blöde daran ist nur, dass es dadurch bei einer bereits aktiv genutzten Domain zu einer Unterbrechung der Websiteerreichbarkeit kommen könnte.
Wenn man die TTL der Domain nicht rechtzeitig vorher (TTL × 2) drastisch reduziert, riskiert man im schlimmsten Fall gleich einmal 24-48h Downtime.
Aus dem Gedächtnis ist der Webserver-User in der Gruppe psaserv, alles was ich hochlade erhält aber psacln. Damit der Service das sieht (oder im schlimmsten Fall gar schreiben können soll), muss ich das für die Welt öffnen.
Der Webserver läuft eventuell mit psa*, aber die jeweiligen Scripts (z.B. PHP) sollten unter dem gleichen User wie auch die ganze SSH-Chroot-Umgebung laufen. Würde mich wundern, wenn das bei node.js & Co. anders ist. Somit reichen dort Schreibrechte für den Besitzer, die Gruppe oder gar die ganze Welt brauchen keine Schreibrechte.
Was Du versuchen könntest: Lade die Inhalte einmal über SFTP (nicht FTPS!) hoch. Treten dann die gleichen Probleme auf? Wem gehören die Ordner und Dateien dann wirklich? (SSH: ls -la o.ä.)
Dass man chown/chgrp nicht nutzen kann ist jedenfalls logisch. Unabhängig davon, dass das nur root darf, könnte man damit zu viel Schaden anrichten.
Was immer ich dort einstelle, nginx findet in dem Verzeichnis der Subdomain bestimmte Dateitypen nicht (z.B. .css, .js).
In welchem Ordner genau? Es gibt nämlich einige Forenthreads, dass man z.B. den /icons/ Ordner auf der obersten Ebene nicht nutzen kann, weil es sich dabei um ein globales Alias für die Autoindex-Icons des Apache-Webservers handelt.
Es könnte aber auch sein, dass es sich in Wirklichkeit gar nicht um statische Dateien handelt und diese durch eine RewriteRule von einem PHP-Script ausgeliefert werden. In diesem Fall sollte es helfen, wenn man auf Nginx ganz verzichtet und nur den Apache werkeln lässt. (Siehe z.B. mein Screenshot hier.)
