Beiträge von NaN

    Nach dem Transfer am 06.11.

    Transfersperre (clientTransferProhibited) weiterhin aktiv – trotz Entfernung beantragt am 27.11.

    Die Domain ist frühestens 60 Tage nach dem letzten Transfer wieder transferierbar, also frühestens am 5. Januar. Das ist eine Regel der .net TLD, die so auch für einige andere TLDs gilt. Netcup sind die Hände gebunden.

    Mit welchem Hostingprodukt nutzt du die Domain?

    Landen Aufrufe über Wildcard nicht ganz normal im eigenen Default DocRoot?

    Normalerweise ist das nicht der Fall. Die DNS-Auflösung zeigt per Wildcard auf den Webserver, aber der ist nicht für die konkrete Subdomain konfiguriert, also weiß der gar nicht, für welchen Kunden der Webseitenaufruf ist und zeigt die globale "Domain noch nicht zugewiesen" Platzhalterseite. Man kann in Plesk aber eine Wildcardsubdomain anlegen. Damit kann der Webserver die Domain zuordnen und so kann man seine eigene Default-Seite machen.

    Wegen der Update-Problematik mit Wildcard-Zertifikaten ist das aber kaum sinnvoll nutzbar. Besser löscht man die Wildcard A und AAAA Records und legt nur Records für die tatsächlich genutzten Subdomains an. Wer einen Server hat, kann die Default-Seite natürlich auch da handlen.

    Was genau wäre an dieser Vorgehensweise denn statisch?

    Ein normales CMS baut die Seite beim Abruf aus Datenbankinhalten und anderen Ressourcen zusammen. Statische Seiten liegen fertig als Dateien vor und können vom Webserver ausgeliefert werden, ohne dass Templates und Programmcode verarbeitet werden müssen. CMS, die statische Webseiten erzeugen, sind ein Mittelding dazwischen, weil die öffentlichen Seiten statisch sind, aber für die Änderungen aktive Inhalte nötig sind. Die Aufteilung ist aus Performance- und Sicherheitsgründen trotzdem oft sinnvoll, wenn der öffentliche Teil der Site keine Daten vom Besucher verarbeiten muss.

    Wofür ist DAS denn nun wieder ne Umschreibung?

    Seefahrer mit überwiegend schwarzer Flagge.

    Alles, was per VPN am Server ankommt, geht direkt an iptables vorbei.

    Nach dem VPN ist vor iptables (nftables). Das VPN geht nicht an der Firewall oder an Traffic Shapern vorbei. Es wird einmal als verschlüsseltes Paket bearbeitet und dann, wenn es aus dem VPN-Interface kommt, nochmal als entschlüsseltes Paket.

    Wenn ich mich per SSH einlogge, und den Server per iperf3 -c (-R) zu offenen Servern verbinden lasse, dann kommen da 2GBit/s raus.

    Server und Anbindung sind in Ordnung.

    Wenn ich das von meinem privaten Rechner aus mache, bekomme ich 500MBit/s (max) zu R3000 und leider nur 50MBit in meine Richtung raus...

    Du erwähntest, dass du einen Provider mit einer bekannt unzureichenden Transit-Anbindung verwendest. Wie sicher musst du sein, dass es das ist, bevor du aufhörst, woanders zu suchen?

    Domain und Domain mit Präfix "www" sind alles, was du brauchst. Das "Platzhalterzertifikat" (Wildcard-Zertifikat) brauchst du nur, wenn du alle möglichen Subdomains deiner Domain mit einem Zertifikat abdecken möchtest, also z.B. auch sowas wie blog.domain.de oder chat.domain.de. Wildcard-Zertifikate werden bei Netcup aber nicht automatisch erstellt und auch nicht automatisch erneuert, weil Letsencrypt dafür die DNS01-Challenge verlangt, die Netcup nicht automatisiert hat. Deshalb sind solche Zertifikate in einem Webhostingpaket bei Netcup nicht praktikabel, aber andererseits auch nicht nötig, weil du alle Subdomains, die du anlegst, auch separat mit einem Zertifikat für genau diese Subdomain (mit und ohne www davor) absichern kannst, was dann wiederum automatisch aktualisiert wird. Kurz: Vergiss "Platzhalterzertifikate". Das kann mal ein Thema für dich werden, wenn du einen Server hast, nicht nur ein Webhostingpaket.

    Ich verliere immer ein klein wenig Hoffnung, wenn sich Menschen entscheiden, weiter herumzukeifen anstatt sich auf einen konkreten Hinweis hin aus leicht verfügbaren Quellen abschließend zu informieren. Der Hinweis aus Kommentar #18 steht. Wer den ignoriert, tut das auf eigene Verantwortung.

    Sonst was? Hab ich dann nicht recht, weil ich dir nicht alles vorkaue? Die tatsächliche Rechtsgrundlage für die Impressumspflicht wirst du wohl noch selbst finden. Lange nach der Stelle suchen musst du nicht: Erster Absatz, viertes Wort.

    Man kann hunderte Seiten Chat-GPT-Output lesen, unzählige Impressumsgeneratorseiten ausprobieren, Anwälte befragen, sich seitenweise in Foren zoffen, oder man liest die Primärquelle - nicht so lustig aber erhellender.

    Erstens ist die Unterscheidung nicht "gewerblich oder nicht" bzw. "kommerziell oder nicht" sondern "geschäftsmäßig oder nicht", und wer das für das Gleiche hält, sollte mal genau nachlesen. Zweitens betrifft der MStV "journalistisch-redaktionelle" Inhalte. Das ist kein definierter Begriff, aber nur weil es schwierig zu entscheidende Grenzfälle gibt, heißt das nicht, dass man nie klar sagen kann, ob etwas "journalistisch-redaktionell" ist oder eben nicht. Wer sicher sein will, kann das auch mit einem Anwalt nicht erreichen, deswegen empfehle ich, sich nicht ins Hemd zu machen.

    Kann mir jemand sagen, ob ich die Domains auch intern transferieren kann, um vom neuen Preis zu profitieren?

    Ja, kann ich dir sagen: Nein, das geht nicht. Du kannst die Domains zu einem anderen Anbieter umziehen und dann im Rahmen einer Aktion hierhin zurücktransferieren. Beachte, dass einige TLDs zwischen solchen Wechseln eine Wartezeit verlangen.

    Die verlassen Frankreich, weil sie Ableger in den USA/Kanada haben?

    Sie verlassen einen französischen Provider, weil in Frankreich eine von Polizei und Regierung angestachelte Medienkampagne gegen GrapheneOS (als die angebliche Firmware-of-choice für Kriminelle) läuft und sie (weitere) Repressionen und Angriffe befürchten. Sie wollen auch Server dieses Providers meiden, die in anderen Ländern stehen. Die USA/Kanada sind nicht die Auslöser dieser Flucht. In diesem Fall ist es Frankreich als Heimatland des Providers.

    Um zu sehen, was raus- und reingeht, bietet sich tcpdump an. Das lauscht auf dem Interface, zeigt also, was tatsächlich auf die Leitung geht (nach der Firewall) oder von dort kommt (vor der Firewall). Damit kannst du schnell ausschließen (oder bestätigen), dass es an deinem Server liegt. Beispielaufruf: tcpdump -i eth0 -n host 46.38.225.230 (Das -n schaltet die Namensauflösung ab, in der Situation wahrscheinlich sinnvoll. Ggf. weiter filtern, wenn du so zuviel Rauschen bekommst.)