Beiträge von tab

Upps, da lag ich ganz schön daneben. Da war wahrscheinlich der Wunsch der Vater des Gedankens. Und wenn wir jetzt das Felix-Limit rausziehen, dann beginnt Massenmailing bei 2 Mails. Und leider sehen es große Mailhoster wie Microsoft ähnlich restriktiv. Das heißt, nicht die Menge ist das eigentliche Problem, sondern der überall (fast?) gleiche Inhalt und womöglich dann an mehrere hotmail.de, outlook.com, outlook.de innerhalb kurzer Zeit.

Kurze Antwort: Ja, das wird problematisch. Eventuell in mehreren Tranchen senden. Es gibt ein Limit von 100 Mails pro Stunde und ??? pro Tag. Das Limit pro Tag weiss ich nicht mehr auswendig, steht aber auch schon irgendwo im Forum. Es sind jedenfalls deutlich weniger als 24x100, eventuell 1200???

Naja, wenn du nicht grade ein vLAN in Nürnberg laufen hast, wo das Ding mit rein muss, dann ist es eigentlich fast egal.

Ja, wenn du den zusätzlichen SSD-Speicher nicht einrechnest schon. Mein RS 1000 G9.5 SE SS22 steht in Nürnberg und ist sogar noch ein klein wenig günstiger nach der Preiserhöhung nächstes Jahr. Im Moment sowieso.

appealing.monitoring.internet-measurement.com

civilized.monitoring.internet-measurement.com

ingenious.monitoring.internet-measurement.com

empathetic.monitoring.internet-measurement.com

radiant.monitoring.internet-measurement.com

upbeat.monitoring.internet-measurement.com

glamorous.monitoring.internet-measurement.com

...

Hahaha. Offenbar wird nicht nur hier fleissig monitoring betrieben

Ah ja, DDOS, deswegen so extrem lahm. Sieht so aus als hätte ich was verpasst. Zur Zeit ist allgemein viel los, die fail2ban-Liste meiner Server liest sich fast wie das who is who des Internets.

Apache mal neu gestartet? Oder zumindest die Konfiguration neu eingelesen.

Ich muss mir das nachher noch genauer anschauen, muss jetzt erst mal einkaufen. Auf den ersten Blick sieht es so aus, als ob da jede Menge Queries reinkommen für "105.184.in-addr.arpa. SOA". Muss ich nacher mal schauen auf den entsprechenden Maschinen was da los war, wenn ich die Anfrage an Cloudflare stelle kommt auch

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @1.1.1.1 105.184.in-addr.arpa SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37362
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 22 (No Reachable Authority): (at delegation 105.184.in-addr.arpa.)
; EDE: 23 (Network Error): ([2001:470:200::2]:53 rcode=REFUSED for 105.184.in-addr.arpa SOA)
;; QUESTION SECTION:
;105.184.in-addr.arpa.          IN      SOA

;; Query time: 348 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sat Dec 10 21:27:36 CET 2022
;; MSG SIZE  rcvd: 159

Zitat von frank_m

Ich habe ein ganz ähnliches Szenario, nur läuft der unbound bei mir in einem Container und versorgt meine anderen Container und VLAN Hosts.

Die Erfahrung habe ich auch gemacht. Ähnlich wie du hatte ich als Fallback öffentliche DNS Server konfiguriert. Dann habe ich festgestellt, dass je nach benutztem DNS Client das Verhalten komplett unterschiedlich ist. Einige wechseln im Fehlerfall, andere scheinen die Anfragen nach einem spezifischen Algorithmus auf alle konfigurierten DNS Server zu verteilen. Das Verhalten war nicht deterministisch, jedenfalls konnte ich kein Muster erkennen. Letztlich habe ich keine gute Lösung gefunden. Da muss man wahrscheinlich spezifisch für jeden Anwendungsfall und DNS Client draufschauen.

Ich werde jetzt erst mal die SERVFAIL Antworten von Unbound loggen und erklären lassen, da gibt es ja eine Einstellung dafür. Dann schaue ich mir an, was andere, öffentliche Resolver mit der selben Anfrage machen, ob da also auch ein SERVFAIL kommt oder vielleicht nur NXDOMAIN oder gar einfach die unsicheren Daten herausgegeben werden. Dann muss ich weitersehen, eventuell mal Stub-Resolver aus, um herauszufinden ob das mit den Forwardern der Stub-Resolver regelt oder ob das ein Ding von systemd-resolved ist. Den Stub-Resolver habe ich bisher laufen lassen, weil es erstens einfach ist, den eigenen Resolver da als ersten Forwarder einzubinden und zweitens, weil damit auch lokal gecacht wird und somit weniger Anfragen zu meinem Resolver kommen und außerdem der lokale Cache wahrscheinlich doch nochmal schneller ist als die Abfrage übers vLAN, auch wenn Unbound die Antwort aus seinem Cache nimmt.

In den letzten 2 Stunden scheint nichts passiert zu sein, alle DNS Queries gehen derzeit noch an meinen Resolver.

Ich habe mir einen kleinen Resolver (Ubuntu 22.0.4) für Server (Debian 11) im Cloud vLAN auf Basis von Unbound aufgesetzt. Auf zwei älteren Servern (S1, S2), die durch Upgrades auf Debian 11 gebracht wurden, ist sysmd-resolved nicht aktiv und die Nameserver (Resolver) werden direkt in der /etc/resolv.conf festgelegt. Ich trage da die vLAN-IP (v4 und v6) des eigenen Resolvers ein. Zusätzlich noch einen der Resolver von Google oder Cloudflare für den Fall, dass mein Resolver mal down ist. Das klappt prima, die benutzen seit mehreren Tagen ununterbrochen den ersten Nameserver aus der /etc/resolv.conf, die IPv4 meines Resolvers. Also wie geplant.

Jetzt zum Problem: Die beiden anderen Server benutzen systemd-resolved. Hier habe ich den Stub-Resolver erst mal aktiv gelassen und in der /etc/systemd/resolved.conf die selben Nameserver in der selben Reihenfolge eingetragen. Auch das funktioniert dann einige Stunden oder einen halben Tag lang einwandfrei. Auch diese Server schicken ihre DNS Queries per IPv4 über das Cloud vLAN an meinen Resolver. Irgendwann löst dann z.B. Postfix eine Query für den PTR eines Möchtegern-Spammers aus und Unbound stellt fest, dass die Daten nicht valide sind und gibt den Status SERVFAIL zurück. Passiert das öfter (und Spammer haben die unangenehme Eigenschaft, nicht so schnell aufzugeben. In diesem Fall vielleicht sogar gezielt, um den unangenehmen Resolver loszuwerden), dann wird der Resolver gewechselt, irgendwann lande ich dann unweigerlich bei Google/Cloudflare. Das möchte ich möglichst vermeiden, außer es geht eben wirklich nicht anders.

Würde es helfen, den Stub-Resolver abzuschalten in der /etc/systemd/resolved.conf und den Symlink /etc/resolv.conf entsprechend umzustellen oder deaktiviert man besser gleich den systemd-resolved komplett? Ich stelle immer mehr fest, dass ich noch zu wenig darüber weiss und das Internet auch nicht viel schlauer ist als ich. Zwei Quellen ergeben drei unterschiedliche empfohlene Vorgehensweisen. Oder ist es besser, den Unbound so einzustellen, dass er bei nicht validierenden RRs niemals SERVFAIL zurückgibt, die Bogusdaten an den Client schickt und nur da ad-Flag nicht setzt? Das ist natürlich ein Risiko, wenn der Client die invaliden Daten benutzt. Dass systemd-resolved da empfindlich reagiert und von eingeschränkten Fähigkeiten des Resolvers ausgeht, ist bekannt, es gibt diverse Issues dazu auf Github, manche davon nach vielen Jahren immer noch offen.

Das Messen überlasse ich euch. Nachdem verschiedentlich berichtet wurde, dass andere Anbieter teils von der Performance vergleichsweise miserabel sind, nehme ich die Server hier halt wie sie sind. Mein alter Rentier Server vom Advent 19 steht zwar auf der Abschussliste, weil ich ja extra als Ersatz vor gut 3 Monaten einen RS 1000 G9.5 SE SS22 geschossen habe. Gleicher Preis, 2 Cores mehr und AMD statt Intel, RAM gleich. Heute Morgen habe ich noch gemerkt, dass der Rentierserver sogar immer noch auf SCSI eingestellt ist während der neue Virtio eingestellt hat. In der Praxis merke ich bei deren Job als Mailserver und mit ein oder zwei Websites mit kaum Traffic keinen signifikanten Unterschied. Sind halt beide gnadenlos unterfordert.

Mir fehlt da noch ein wenig die Einschätzung was so ein Serverchen tatsächlich leisten kann. Sogar der VPS 200 G10s, den ich gerade als rekursiven Resolver (Ubuntu 22.04 + Unbound) einsetze, langweilt sich bloss mit den vier Servern die da zur Zeit über das Cloud vLAN Free dranhängen. Was da an DNS Queries und Antworten über das vLAN geht, liegt eher im Bereich von maximal 2-3 KB/s (gemäß der Anzeige im SCP, die ist ja wohl gemittelt, die realen Spitzenwerte werden schon deutlich höher liegen), da könnte man schon noch einige weitere Server dranhängen, sowohl vom vLAN her als auch vom Server. Und ich hätte nie nur den kleinen 200er genommen, wenn es nicht den 500er als Upgrade-Option gegeben hätte . Das wäre dann wohl vollends der Overkill.

Ja, das geht dort wirklich sehr schnell und einen Fehler im DNSSEC habe ich da noch nie gefunden. Ich habe mittlerweile für alle (für mich) wichtigen Domains bei netcup die Nameserver dorthin umgestellt. Für die weniger wichtigen aktiviere ich DNSSEC gar nicht erst.

Ist da eventuell DNSSEC aktiviert? Das ist leider bei den netcup DNS-Servern öfter mal "kaputt", so dass entsprechend scharf eingestellte Resolver die Einträge nicht validieren können und deswegen auch nicht an den Client ausliefern. Falls DNSSEC aktiv ist, kannst du überprüfen, ob da auch wirklich alles passt. Z.B. unter https://dnsviz.net/ oder https://dnssec-analyzer.verisignlabs.com/

Zitat von ltheinrich

Jetzt habe ich wieder eine Mindestvertragslaufzeit von 12 Monaten. Wie ich schon sagte, ist mir das bewusst. Mir geht es ja auch um eine mögliche weitere Vertragsverlängerung von weiteren 12 Monaten nach den ersten 12 Monaten.

Dezember 2022 - 1. Monat beginnt

Dezember 2023 - 12. Monat endet

- bis hier verständlich -

Nach Dezember 2023:

Möglichkeit 1: ohne Kündigung Verlängerung um 12 Monate bis Dezember 2024 (nicht monatlich kündbar)

Möglichkeit 2: ohne Kündigung Verlängerung um jeweils 1 Monat bis Januar 2024 (monatlich kündbar)

Den Support könnte ich zwar auch anschreiben, aber ich hatte dort zu einem anderen Thema schon eine Anfrage am 29. November. Bisher wurde diese Anfrage aber noch nicht bearbeitet und hatte gehofft, dass hier eventuell jemand etwas dazu weiß.

Alles anzeigen

Mehr als diesen offiziellen Beitrag auf eine Frage meinerseits kann ich dazu nicht anbieten. In diesem Beitrag wird auf die von dir verlinkte News verwiesen.

In dem Thread ging es eigentlich um die Sonderkündigungsmöglichkeit wegen der Preiserhöhung. Da aber davon die Möglichkeit einer normalen, fristgemäßen Kündigung nicht tangiert werden kann, habe ich eben gefragt wie das denn jetzt ist nach der Mindestlaufzeit.

Ich vermute einfach mal, dass du mit dem Upgrade aus Sicht von netcup einen neuen Server bestellt hast, der jetzt wieder 12 Monate Mindestlaufzeit hat. Allerdings habe ich bisher noch nie ein Upgrade gemacht, im Zweifelsfall den Support fragen bzw ein Ticket erstellen und fragen was Sache ist.

Edit: Habe gerade mal im CCP bei mir nachgeschaut. Unter dem Reiter "Kündigung"" kann ich gar keinen anderen Zeitpunkt wählen als bis zu dem Zeitpunkt, der sich ergeben würde, wenn es die neue Regelung nicht gäbe und sich der Vertrag wie früher um eine weitere Mindestlaufzeit verlängern würde, also nicht bis nächsten oder übernächsten Monat. Allerdings kann es auch sein, dass das einfach noch nicht angepasst wurde, weil das notgedrungen ältere Server sind (vor Änderung der Kündigungsregelung). Bei den neueren Servern ist die Mindestlaufzeit eben noch nicht erreicht, somit sehe ich dort natürlich auch keinen früheren Kündigungstermin. Die News ist aber eindeutig und das wurde hier im Forum auch schon so bestätigt.

Mehr hat composer nicht an Erklärung ausgegeben? Dass deine Abhängigkeiten das brauchen steht ja explizit in der composer.json drin, PHP in Version >=8.1 IST ja eine Abhängigkeit. deswegen wird das wohl auch ausgegeben. Aber normalerweise installiert er entweder oder spuckt irgendwelche für den Laien schwer interpretierbare Erklärungen aus, warum er die Abhängigkeiten in den geforderten Versionen nicht installieren kann. Gibt da glaube ich irgendeine Option (eventuell --verbose), mit der er dann etwas gesprächiger ist. Vielleicht verlangt ja irgendeine deiner Abhängigkeiten eine niedrigere PHP-Version als 8.1. Das ist durchaus relativ wahrscheinlich.

Zitat von prunelle

Ok, das klingt logisch. Ich dachte es wäre vielleicht alles automatisiert. Aber der Adventskalender ist ja wieder was Eigenes.

Es wird schon zumindest soweit automatisiert sein, dass der Betrag als Soll auf dein Kundenkonto gebucht wird, so dass es automatisch auf der nächsten Rechnung mit erscheint. Aber es wird bei Kleinbeträgen wahrscheinlich nicht sofort eine Rechnung erstellt, zumal du ja 10 Minuten später noch eine weitere Domain bestellen können. Ich bin mir nicht sicher, aber ich glaube, so eine Kleinstrechnung kam bei mir auch schon mal über eine Woche später. Also sie wird schon irgenwann rausgehen, auch wenn du in nächster Zeit nichts mehr bestellst, aber eben nicht unbedingt zeitnah. Bei Servern oder Webhostings kam sie immer innerhalb von maximal 1-2 Tagen nach der Bereitstellung. Und die 0 Euro Rechnung für mein vLAN free kam einen Tag später. Aber die muss ich auch nicht bezahlen.

Kann sein, dass sie wegen des geringen Betrags noch nicht gestellt ist und man vielleicht abwartet, ob du demnächst noch was bestellst oder sowieso turnusmäßig eine Rechnung bekommst. Gerade bei Domains hatte ich das schon öfter.

Zitat von DomDom

Danke dir für deine schnelle Antwort, ich probiere das gleich mal und melde mich dann mit Feedback

Und für die Synchronisation mit dem zweiten, externen Server sorgt Plesk?

Es gibt hier im Forum einige Threads zu node.js Anwendungen. Meine Einschätzung als "Außenstehender" beim Thema node.js: Eine Anwendung zum Laufen zu bringen ist nicht ganz trivial. Aber wird sich bestimmt noch der Eine oder Andere melden, der auch mit node.js hier arbeitet im Webhosting.