Hallo zusammen,
wir haben selbstverständlich umgehend nach Bekanntwerden dieser Sicherheitslücke geeignete Schutzmaßnahmen bei den durch uns verwalteten Systemen (wie Webhosting-Server und managed Server) vorgenommen. Es besteht somit keine Gefährdung für unsere Kunden durch diesen Sachverhalt (die Betriebssysteme von unmanaged Produkten wie Root-Server / VPS usw. sollten natürlich durch den jeweiligen Kunden aktualisiert werden, darauf haben wir keinen Einfluss).
Hallo chrisch80,
ich habe mir das zugehörige interne Ticket bei uns gerade nochmal angesehen.
Bereits seit einiger Zeit steht die Sieve-Erweiterung "duplicate" zur Verfügung.
Du kannst wie folgt vorgehen:
Die Verarbeitung dieser Filter erfolgt serverseitig, du musst dich also nicht regelmäßig im Webmailer einloggen oder Ähnliches, damit diese greifen.
So sollte sich das gewünschte Verhalten umsetzen lassen können.
Hallo zusammen,
wir haben soeben einen Fehler im Zusammenhang mit DNSSEC behoben.
Sollte eine Domain aufgrund der DNSSEC-Einschränkung nicht mehr korrekt auflösen, könnt ihr bei dieser den Haken für DNSSEC im CCP wieder setzen und abspeichern und es so neu initialisieren, was das Problem nach einigen Stunden (aufgrund des DNS-Cachings) lösen sollte.
Sollte bei eurer Domain DNSSEC im CCP aktiv sein und die Domain löst auch korrekt auf, jedoch ohne dass DNSSEC validiert wird (es ist kein DNSSEC-Schlüsselmaterial bei der Registry, z.B. der DENIC, hinterlegt, obwohl das so sein sollte), könnt ihr DNSSEC im CCP deaktivieren und es nach 48 Std. wieder aktivieren. Dies wird den Sachverhalt ebenfalls lösen.
In anderen, hier nicht beschriebenen Fällen, oder falls dies den Sachverhalt nicht löst, könnt ihr euch natürlich an unseren Support wenden, der dies prüft und euch gerne unterstützt.
Für die entstandenen Unannehmlichkeiten bitten wir um Entschuldigung.
Ich wünsche euch ein schönes Wochenende.
Hallo zusammen,
der Fehler, der verhinderte, externe Nameserver zu setzen, obwohl im DENIC NAST alles in Ordnung war, wurde behoben.
Für die Unannehmlichkeiten bitten wir um Entschuldigung.
Bei der Erstellung von Letsencrypt-Zertifikaten wird eine Email-Adresse verlangt. Wenn das Feld leer gelassen wird, wird es von Netcup abgelehnt. Wenn eine ungültige Email-Adresse eingegeben wird, lehnt Letsencrypt den Auftrag ab. Es ist aber tatsächlich nicht (mehr) notwendig, für Letsencrypt eine Email-Adresse anzugeben. Mit dem Ende der Expiration-Emails am 4. Juni 2025 (diesen Mittwoch) gibt es dafür auch keinen vernünftigen Grund mehr. Letsencrypt schreibt selbst dazu:
Ich möchte deshalb anregen, dass dieses Eingabefeld nicht mehr verpflichtend gemacht wird. Moderators zur Weiterleitung an die zuständige Stelle.
Hallo NaN ,
der Hersteller unseres Hostingpanels hat diesbezüglich nun ein Update veröffentlicht. Dieses rollt stetig über die nächsten Wochen auf unseren Webhosting-Servern aus, danach wird die E-Mail-Adresse für die Beantragung eines Let's-Encrypt-Zertifikats nicht mehr benötigt.
Hallo zusammen,
danke für eure Hinweise.
Das Problem der nicht erreichbaren IPv6-only-Server sollte gelöst sein. Falls ihr wider Erwarten weiterhin betroffen sein solltet, meldet euch bitte zur Prüfung bei unserem Support. Vielen Dank.
Hi everyone,
Thank you for your messages.
I have forwarded this to our developers and the issue has been resolved now.
We apologize for the inconvenience.
Hallo hjok,
vielen Dank für deine Frage.
Es gibt aktuell einen Fehler im Hostingpanel, der unter Umständen dafür sorgt, dass die PHP-Limits bei Domains initial inkorrekt sind. Der Fehler ist dem Hersteller bekannt und wir stehen mit diesem in Kontakt für eine zeitnahe Behebung.
Solltest du oder ein anderer Kunde von diesem Problem betroffen sein, wende dich bitte an unseren Support, wie auch in diesem Fall geschehen. Wir werden es dann korrigieren. Für bestehende Domains wird danach keine Änderung mehr erfolgen. Bei neuen Subdomains kann der Fehler jedoch bis zur abschließenden Behebung durch den Hersteller leider erneut auftreten. In diesem Fall unterstützt dich unser Support gerne.
Danke für dein Verständnis.
Hallo ff--xx,
danke für den Hinweis.
Ich habe das an unser Network Operation Center weitergeleitet.
Ich wünsche dir einen schönen Abend.
Hallo zusammen, hallo -Manu-, h725rk, tldev, kaospilot, Niklas434,
ich habe soeben Rückmeldung aus der Fachabteilung erhalten, dass der Fehler behoben sein sollte. Bitte setzt einmal eine Änderung in der Firewall um oder schaltet alternativ den Server einmal komplett aus und dann im SCP wieder ein, damit Ihr unmittelbar von der Fehlerbehebung profitiert.
Für die Unannehmlichkeiten bitten wir um Entschuldigung. Danke für euer Verständnis.
Hallo zusammen,
danke für euer zahlreiches Feedback.
Die von euch hier mitgeteilten vermutlichen Fehlfunktionen habe ich an die zuständige Abteilung zur Prüfung übermittelt. Danke, dass ihr uns hier so viel Rückmeldungen gebt 
Hallo Capt_iTweek,
vielen Dank für den Hinweis.
Wir haben den Fehler umgehend behoben, das sollte natürlich nicht so sein. Wir bitten um Entschuldigung.
Ich wünsche dir einen schönen Abend.
Hallo TobyC,
vielen Dank für deine Geduld.
Eine Fehlerbehebung wurde erstellt. Es kann bis zu zwei Stunden dauern, bis diese auf alle Hostingserver angewendet wurde. Bei dem Hostingserver, der mit deiner Kundennummer verknüpft ist, wurde es bereits behoben.
Ich wünsche dir ein schönes Wochenende.
Hallo TobyC,
danke für den Hinweis.
Wir arbeiten an einer Lösung und ich melde mich hier, sobald diese ausgerollt wurde.
Hallo engine,
beachte dazu bitte folgende Information aus unserem Help Center:
Die Firewall ist stateful. Das bedeutet, dass sie sich Verbindungen merkt, die von deinem Server ausgehen, und den Rückverkehr automatisch annimmt. Dies gilt jedoch nur für TCP-Traffic. Um UDP-Traffic auf die Whitelist zu setzen, musst du sowohl eine INGRESS- als auch eine EGRESS-Regel in deiner Policy anlegen.
Hallo Domvnxk,
wir hatten da heute einige betroffene Kunden, anscheinend stets im Zusammenhang mit NodeJS.
Ich vermute, es besteht hierzu ein Zusammenhang:
Vielleicht hilft dir das ja bereits.
Ich wünsche dir ein schönes Wochenende.
===== English version below =====
Hallo zusammen,
vielen Dank für euer zahlreiches Feedback, welches ihr uns hier im Thread kontinuierlich im Bezug auf die Performance unserer Server gebt.
Da wir immer daran arbeiten, unsere Produkte weiter zu entwickeln und zu verbessern und wir von einigen Nutzern auch Unzufriedenheit im Bezug auf die Performance ihrer Root-Server vernommen haben, ist es uns ein wichtiges Anliegen, diese Sachverhalte zu untersuchen. Wir überwachen unsere zahlreichen Hostsysteme gründlich, umso mehr bedauern wir es, dass einzelne Kunden mit der Performance ihrer Produkte nicht zufrieden sind. Wir prüfen, ob verschiedene Fälle gleiche Muster aufweisen. Root Server, welche die versprochene Leistung nicht einhalten, sind selbstverständlich etwas, was nicht erwünscht ist, und hier wollen wir gemeinsam mit euch eine gute Lösung finden. Unsere Analysen fokussieren sich hierbei aktuell auf unsere Root Server. Bei unseren VPS ist es erwartbar, dass es zu CPU-Steal und auch zeitweise schwankenden Benchmark-Ergebnissen kommen kann, wie bekannt, da diese keine dedizierten CPU-Ressourcen aufweisen.
Wie ihr euch aber sicher auch vorstellen könnt, ist es schwierig, über diesen Forenthread einen guten Überblick über diese Problematiken zu erhalten: So posten manche Nutzer hier Benchmarks, die völlig zufrieden sind, andere posten Benchmarks von Servern, die gar nicht zu ihrer im Kundenforum hinterlegten Kundennummer gehören, wieder andere haben zahlreiche Server und es ist aus dem Forenbeitrag unklar, um welches ihrer Produkte es geht. Außerdem geht es teilweise um verschiedene Sachverhalte, z.B. CPU-Steal, Benchmark-Ergebnisse und I/O-Performance.
Wir haben dafür gemeinsam mit der zuständigen Abteilung ein kleines "Formular" entwickelt, welches es uns erlaubt, die einzelnen Sachverhalte konsolidiert bestmöglich betrachten zu können und auf dieser Basis Analysen durchführen zu können.
Es ist nicht nötig, dass ihr diese Tests im Rettungssystem durchführt, in dem Fall bitten wir aber darum zu überprüfen, dass nicht gleichzeitig andere laufende Prozesse z.B. Benchmark-Ergebnisse erheblich verfälschen.
Falls ihr mit der Leistung eures Root Servers unzufrieden seid, bitten wir euch, dies mit Verweis auf meinen Beitrag hier an unseren Support über unser Kontaktformular im netcup Help Center zu übermitteln. Wir sammeln die Eingaben, werden nach Gemeinsamkeiten suchen und können so unsere Leistungen weiter optimieren
Anbei nun das Formular, wir freuen uns bereits auf euer Feedback:
Betroffene Kundennummer:
Betroffenes Produkt (Servername, z.B. v1234567890):
Betroffener Tarif (z.B. RS 1000 G12):
Genutztes Betriebssystem (Ausgabe z.B. von "lsb_release -a"):
Genutzter Kernel (Ausgabe z.B. von "uname -a"):
Beobachtetes Problem (Langsamer Benchmark / Hoher CPU-Steal / Niedrige I/O-Performance):
Beobachtung wie folgt validiert (z.B. Geekbench / Beobachtung von top / hdparm):
Problem tritt kontinuierlich auf (ja / nein, falls in dem Fall bekannt, zu welchen Zeiten gehäuft?):
Konkretes Messergebnis (z.B. Geekbench- / hdparm-Ausgabe, Beschreibung der beobachteten Steal-Werte, ggf. Monitoring-Graphen / -Messwerte):
Messergebnis wurde erhoben um (Datum und Uhrzeit):
Warum ich mit diesen Werten unzufrieden bin (kurze Beschreibung, welche Werte stattdessen erwartet würden):
Danke für eure Unterstützung, und dass ihr uns dabei helft, noch besser zu werden
===== English version =====
Hello everyone,
Thank you very much for your numerous feedback, which you continuously provide to us here in the thread regarding the performance of our servers.
Since we are always working on further developing and improving our products, and as we have also heard dissatisfaction from some users regarding the performance of their root servers, it is an important concern for us to investigate these issues. We monitor our numerous host systems thoroughly, and all the more we regret that individual customers are not satisfied with the performance of their products. We are checking whether different cases show similar patterns. Root servers that do not meet the promised performance are of course something that is not desirable, and here we want to find a good solution together with you. Our analyses are currently focused on our root servers. For our VPS it is to be expected, as is known, that CPU steal and also temporarily fluctuating benchmark results may occur, since these do not have dedicated CPU resources.
However, as you can surely imagine, it is difficult to obtain a good overview of these issues through this forum thread: some users post benchmarks here that are completely satisfactory, others post benchmarks from servers that do not belong to the customer number stored in the customer forum, others again have numerous servers and from the forum post it is unclear which of their products is affected. In addition, the posts sometimes refer to different matters, e.g. CPU steal, benchmark results, and I/O performance.
Together with the responsible department, we have developed a small “form” that allows us to view the individual matters in a consolidated and optimal way and to carry out analyses based on this.
It is not necessary for you to perform these tests in the rescue system, but in that case we kindly ask you to make sure that no other running processes significantly distort the benchmark results, for example.
If you are dissatisfied with the performance of your root server, we kindly ask you to submit this to our support via our contact form in the netcup Help Center, referring to my post here. We will collect the submissions, look for commonalities, and in this way further optimize our services
Below is the form; we are already looking forward to your feedback:
Affected customer number:
Affected product (server name, e.g. v1234567890):
Affected plan (e.g. RS 1000 G12):
Operating system used (output e.g. of “lsb_release -a”):
Kernel used (output e.g. of “uname -a”):
Observed issue (Slow benchmark / High CPU steal / Low I/O performance):
Observation validated as follows (e.g. Geekbench / observation from top / hdparm):
Issue occurs continuously (yes / no; if no, at which times does it occur more frequently, if known?):
Specific measurement result (e.g. Geekbench / hdparm output, description of observed steal values, if applicable monitoring graphs / measurement values):
Measurement was taken on (date and time):
Why I am dissatisfied with these values (short description of which values would be expected instead):
Thank you for your support and for helping us become even better
Hallo Finn,
bei den Auswahlfeldern, bei denen du auf einem managed Server zwischen verschiedenen Werten in den PHP-Einstellungen von Plesk wählen kannst, handelt es sich um kombinierte Auswahl- und Texteingabe-Felder. Das bedeutet, du kannst die zur Auswahl stehenden Werte einfach durch den von dir gewünschten Wert "übertippen".
Ich habe aktuell auch den Fall 6 externe Domains über den Support einpflegen zu lassen weil ich selber alles über eine Mailcow mache.
Das wäre echt toll wenn man die Aufschaltung mit dem TXT Record auch selber über das CCP anstoßen könnte.
Es freut mich, mitteilen zu können, dass dieses Feature nun ab sofort im Customer Control Panel zur Verfügung steht
Hallo zusammen,
die Passwortsicherheit wird mit Hilfe der Open-Source-Library "zxcvbn-ts" validiert. Die Bibliothek bewertet Passwörter nicht nach festen Regeln (z. B. "mindestens ein Großbuchstabe und eine Zahl"), sondern danach, wie leicht ein Angreifer das Passwort erraten könnte. Dazu analysiert sie das Passwort und erkennt typische Muster, zum Beispiel:
Aus diesen Mustern schätzt zxcvbn-ts, wie viele Versuche ein Computer bräuchte, um das Passwort zu erraten. Je mehr Versuche nötig wären, desto stärker das Passwort.
Weitere Informationen dazu finden sich z.B. auch hier:
https://zxcvbn-ts.github.io/zxcvbn/guide/
In folgendem Test (mit allen Haken aktiv) muss ein Score von "3" erreicht werden, damit wird die Richtlinie "stark" erfüllt:
