Beiträge von tab

  • IP Location

    Zitat von User_unknow

    das gleich Problem habe ich jetzt auch. Ich streite mich derzeit mit dem Support, von Umschreibung ist bei mir aber keine Rede. Würde mich interessieren, was ihr über diesen IP-Range herausfindet, bzw. wo diese beheimatet sind:

    152.53.0.0-152.53.255.255

    Ich möchte da auch nicht vorgreifen, aber für mich ist die Sache eindeutig...

    Code
    % Information related to '152.53.128.0/20AS42473'

route:          152.53.128.0/20
descr:          Location: DE, Nuernberg
origin:         AS42473
mnt-by:         NETCUP-MNT
mnt-by:         ANEXIA-MNT
created:        2024-11-18T10:39:43Z
last-modified:  2024-11-29T11:18:31Z
source:         RIPE

  • Das längste Thema

    Bin gerade mal wieder an Unbound und meinem alten Absatz, das cloud VLAN free für die DNS-Queries an einen Unbound-Resolver und die Antwort zu nutzen. Habe also das Cloud VLAN free in bisher drei Server eingebunden. Den Resolver mit Unbound und zwei Server mit installiertem Keyhelp. Unbound habe ich so eingestellt, dass es auf 127.0.0.1 und meinem 192.168-er Subnetz lauscht und per access-control alle IPs aus dem 192.168.1.0/24 zulasse. Auf den Keyhep-Servern habe ich den Unbound-Resolver (192.168.1.101) als ersten Nameserver in die resolv.conf eingetragen. Localhost macht er ja implizit.

    Das scheint soweit auch zu klappen, alle drei Server bekommen per dig und auch sonst ihre DNS-Queries vom Resolver beantwortet. Jetzt bin ich aber eher versehentlich auf ein für mich nicht so einfach erklärbares Phänomen gestossen. Ich habe zuerst :rolleyes: versehentlich bei einem der beiden anderen Server (192.168.1.3) 192.168.1.2 als Resolver eingetragen, was die vLAN Adresse des anderen Servers ist, anstatt 192.168.1.101. Habe mit dig getestet, ob der richtige Resolver verwendet wird. Die Query wurde beantwortet, als Server war 192.168.1.2 angegeben. Hat mich etwas erstaunt, dass der 192.168.1.2 die Antwort geliefert hat, obwohl dort der 192.168.1.101 als Forwarder eingetragen ist. Das muss dann ja wohl letztlich von 192.168.1.101 beantwortet worden sein. Ebenso, dass er überhaupt rekursive Anfragen akzeptiert bzw überhaupt welche aus dem VLAN. Immerhin scheint da ein Cookie mitgeschickt worden zu sein, aber ist das im VLAN normal, dass alle Server darin sich gegenseitig rekursive DNS-Queries beantworten? Oder kann das an dem bind9 liegen, der ja mit Keyhelp installiert wird?

    Code
    ;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b9bc89fd566261e201000000675ef6b6889680ad0c0001f8 (good)
;; QUESTION SECTION:
;amazon.de.                     IN      A

  • Domain, E-Mail, Datenbank und Daten innerhalb eines Webhosting Pakes umziehen?

    Zitat von eyespeak

    Weitere Stolperfallen waren:

    - Datenbank Export und der Import im neuen Webhosting. Hier musste ich die erste Zeile per Editor löschen, die wollte er nicht:

    /*M!999999\- enable the sandbox mode */

    - Die Datenbank mit z.B. Notepad++ öffnen und den Hostnamen hostingxxxxxx.axxx.netcup.net durch Suchen und Ersetzen mit seinem neuen Pfad ändern. Dieser ist nämlich auf einem anderen Webhosting natürlich anders. In dem Fall war es eine WordPress Datenbank. Der Präfix des Namens der Datenbank blieb in meinem Fall gleich. Den Benutzernamen kann man auch gleich wählen.

    Den Schritt kann man sich ersparen oder zumindest vereinfachen, wenn man nicht die Datenbank exportiert sondern nur alle Tabellen. Also Datenbank anklicken im phpMyAdmin und dann erst exportieren. So kopiere ich seit Jahren problemlos Datenbanken von einem Webhosting zum anderen oder auch zwischen verschiedenen Hostern. Wenn man die ganze Datenbank komplett exportiert, sind eben auch Informatonen zur Datenbank selbst im Dump enthalten, wie z.B. der Name.

    Leider ist so ein Umzug recht kompliziert wie man sieht. Das eine oder andere nützliche Tool für solche Umzüge könnte das CCP/WCP sicher noch gut vertragen.

    Ich glaube, bei einem Upgrade eines regulären Webhostings im CCP ist es etwas einfacher. Aber sobald Quelle oder Ziel ein Aktionsprodukt ist, wird es eben so kompliziert wie beschrieben. Der Fairness halber räume ich aber gern ein, dass das alles bei anderen Hostern meist auch nicht besser aussieht.

  • netcup Nameserver ?

    Ja, dass speziell der Resolver hoffnungslos überlastet ist, leuchtet mir ein. Sind ja jetzt während der BW und am BF auch wieder Unmengen an Servern ausgeliefert worden, alle vorinstalliert so, dass sie diesen einen Server als ersten Nameserver eingetragen bekommen. Falls das auch bei Servern mit Standort Manassas so sein sollte, könnte das nicht obendrauf eventuell noch eine zusätzliche Belastung sein wegen längerer Paket-Laufzeiten? Und würden die Standard netcup Nameserver (mit Standort Nürnberg) für diesen Standort überhaupt einen Sinn machen? Vielleicht werden in dem Fall ja auch lokale Nameserver eingetragen. Ich weiss es nicht, weil ich dort noch keinen Server hatte.

  • Gibt es von netcup noch Support?

    Zitat von andreas.

    TheoN : Ja, als ich deinen Beitrag oben gelesen habe, habe ich mir schon gedacht: Oh, der wird mit Sicherheit auch einen Server bekommen haben, dessen IP-Adresse mit 152.53. anfangen wird. Von daher gehe ich mal davon aus, dass dann auch noch weitere Kunden - auch aus dem Ausland - dieses Problem haben und dem Support derzeit eventuell in einer sehr ungünstigen Zeit sogar rund um die Uhr die Bude einrennen werden.

    Unnötig zu sagen, einer meiner neuen Server mit Problemen mit den netcup-Resolvern gehört da auch dazu. Der andere ist ein 2.56.97.

  • netcup Nameserver ?

    Zitat von tab

    Ja, definitiv. Andererseits, besonders stabil waren sie zumindest vor einigen Jahren nicht. Ist jetzt sicher seit mehreren Jahren mein erster Server, der die wieder nutzt. Und auch das nur auf Bewährung :D .

    Leider bewähren sich die netcup Resolver irgendwie nur zum Teil?!? ?(:/;(

    Also auf dem oben erwähnten VPS 2000 ARM G11 habe ich keinen konkreten Grund zur Klage, auch auf meinem VPS 1000 G11 nicht. Aber auf den neuen Servern aus der BW24 (VPS 500 G11) und vom BF24 (RS 1000 G11), beide Standort Nürnberg (sagt man ;) ) habe ich jetzt genau die selben Probleme wie damals (tm) auf meinen ersten Servern mit Keyhelp. Eine Seite des Panels lädt mit einiger Verspätung. Ich weiss leider nicht, was genau da auf der Seite abgeht, ist halt kein Open Source :(. Damals habe ich lange gesucht nach einer Lösung und sie dann an zunächst nicht vermuteter Stelle gefunden, bei den netcup Resolvern. Da gab es in den Logs einige Meldungen von wegen "degraded". Hatte ich mir erst nicht viel dabei gedacht, immerhin liefen die anderen Server mit den selben Resolvern ganz normal und flüssig, nur zwei zickten rum. Obwohl das aus meiner Sicht eher dagegen sprach, dass die Resolver schuld waren, habe ich einfach mal testweise Google, Cloudflare & Co als Resolverein gesetzt. Und die Probleme waren sofort komplett weg.

    Damals war das mit systemd-resolved konfiguriert, mittlerweile kommen die Resolver im Debian 12 minimal Image m.E. per DHCP und stehen direkt in der /etc/resolv.conf, die auch eine (immutable) Datei ist und kein Symlink wie früher. Der Effekt ist aber eins zu eins der selbe. Die älteren Server haben kein Problem mit den netcup Resolvern, die neuen aber exakt die selben Probleme wie damals. Nur dass die Statusabfragen und -anzeigen für die von Keyhelp verwalteten Dienste (HTTP, HTTPS, FTP, SSH, SMTP, POP3, IMAP, MariaDB) mittlerweile direkt im Dashboard angesiedelt sind. Diesmal ist also das Dashboard extrem langsam und wird erst mit Verzögerung von mehreren Sekunden angezeigt. Allerdings nur auf den neuen Servern. Und auch diesmal behebt der Austausch der Resolver das Problem sofort und vollständig.

    Ansonsten wäre die Theorie aus meiner Sicht schnell fertig: Resolver haben eine Macke und sind eher langsam, gelegentlich auch bis zum Timeout der Verbindung. Für die Statusabfrage werden sie wahrscheinlich - aus welchen Gründen auch immer - häufiger gebraucht als auf den meisten anderen Seiten des Panels, deswegen die lange Verzögerung.

    Austauch gegen andere, schnellere Resolver behebt das Problem. Ja, sogar schon das Tauschen der Reihenfolge der beiden IPv4 Resolver in der /etc/resolv.conf hilft. Auch den Teil kann ich mir leicht erklären: Alle neu ausgelieferten Server, die aus irgendwelchem netcup Images aufgebaut wurden, haben die Resolver in der selben Reihenfolge in der /etc/resolv.conf. Somit hat der erste deutlich mehr Arbeit als der zweite und ist überlastet. Durch den Tausch der Reihenfolge benutze ich den weniger ausgelasteten zweiten Server - im Gegensatz zu den meisten anderen Kunden.

    Tja, aber ... Warum aber ist das nur bei den beiden neuen Servern ein Problem und nicht bei allen? Das ist so nicht zu erklären bzw es fehlt mir noch das entscheidende Puzzle-Teil. Eventuell das Subnetz der IP?

    Immerhin sehe ich beim neuen Server gelegentlich so etwas:

    Code
    ~# dig amazon.de A
;; communications error to 46.38.225.230#53: timed out

    Im zweiten Versuch klappt es dann wohl und das Ergebnis wird korrekt ausgegeben. Wenn das jetzt z.B. einmal von 10 Queries passiert und die Seite verursacht ziemlich viele Queries, dann wird es eben langsam.

    Leider hatte ich das jetzt auch bei einem neuen Server, sogar zweimal bei einer Query, also erst der dritte Versuch erfolgreich. Was bleibt noch als Erklärung? Liegt es an der abgefragten Domain? Dass es also bei manchen Domains länger braucht als bei anderen und beim einen Server grundsätzlich etwas länger? Keine Ahnung, irgendwie geht mir auch langsam die Lust aus. Da mache ich jetzt heute schon wieder mehrere Stunden dran rum. Andere Resolver nehmen (oder jedenfalls nicht den 46.38.225.230) , die Sache abhaken und zu den x-Files packen? Darauf wird es dann wohl hinauslaufen. Wird Zeit, meine eigenen Resolver vernünftig abzusichern, damit ich sie sicher benutzen kann. Mal sehen über Weihnachten.

  • Das längste Thema

    Ist da näheres bekannt?

    Ich habe mit meinen zwei letzten Neuanschaffungen Probleme. Online sind sie schon, aber manche Zugriffe sind langsam. Die Symptome sind so ähnlich wie vor Jahren mit den netcup Resolvern. Momentan habe ich in meinem hoffnungslosen Optimismus wieder die netcup-Resolver am Start. Auch die etwas älteren Server benutzen diese, haben aber komischerweise nicht die selben Symptome. Das war damals aber genauso, manche Server hatten Probleme, andere nicht, obwohl alle die selben Resolver benutzten. Umstellung auf Google/Cloudflare etc hat die Probleme damals behoben.

    Ich stelle jetzt mal einen der neuen auf andere Resolver um, dann werde ich ja sehen ob es das ist. Ich hatte gehofft, dass dieses alte Problem mittlerweile gefixt ist.

    Wenn es die Resolver sind, dann muss ich jetzt wohl meine eigenen Resolver in Betrieb nehmen. Installiert ist ja schon alles.

    Edit: Sieht leider ganz so aus, als ob es die Resolver sind. Mit Cloudflare ist alles wesentlich flotter. Oder vielleicht eher noch die Verbindung zu den Resolvern, weil von anderen Servern aus funktioniert es ja in normaler Geschwindigkeit, obwohl die selben Resolver (netcup) benutzt werden.

  • Email (Server & Accounts) zentralisieren.

    Bei zusätzlichen Domains Wegzug ohne die Domain selbst umzuziehen. Du kannst einfach im CCP einstellen, mit welchem Webhosting die Domain verbunden werden soll. Wenn du das willst, täglich mit einem anderen Webhosting aus deinem Kundenaccount. So eine Änderung der Zuordnung ist kostenlos und man braucht nicht den Support dazu.

    Eine Inklusivdomain ist fest mit einem Webhosting verbunden (und im Preis des Webhostings inklusive)

    (Zumindest) die Hauptdomain kann nicht in einem anderen Webhosting genutzt werden als dem, zu dem sie gehört.

    Wenn man sich ein weiteres Webhosting zulegt und die Inklusivdomain des alten Webhostings damit nutzen will, dann ist das kostenpflichtig und nur über den Support möglich. Bei Kündigung des Webhostings kannst du die Domain löschen lassen oder sie umziehen - aber nicht direkt zu netcup in ein anderes Webhosting, außer du beauftragst den Support damit, der kann das gegen eine Gebühr einrichten.

    Beide Typen sind bei netcup registriert, bei beiden kannst du das DNS frei einstellen. Du könntest per DNS MX und A/AAAA auf ein anderes Webhosting einstellen, sogar eigene oder andere Nameserver benutzen für die Domain. Aber der Mail- und Webserver des anderen Webhostings wird sich nicht für die Domain zuständig fühlen. Es ist im Webserver kein vHost für diese Domain vorhanden, du kannst auch keinen einrichten. Und der Mailserver legt auch keine Postfächer dafür an und empfängt oder sendet auch keine Mails für die Domain, damit ist die Domain also nicht wirklich nutzbar.

    Wenn du die Domain (auch oder ausschliesslich) für einen Root-Server nutzen willst, das geht mit beiden Arten von Domains. Hier kannst du ja in deinem Server einen Webserver und Mailserver nach deinem Belieben selbst installieren und passend konfigurieren.

  • Email (Server & Accounts) zentralisieren.

    Ja, wenn du nicht für zusätzliche externe Domains bezahlen willst, wirst du nicht umhin kommen,den Großteil der Maildomains bei netcup als zusätzliche Domains unterzubringen. Bis zur nächsten de-Domain Aktion dürfte es ja nicht mehr so lange dauern. :)

    Und prinzipiell wäre ein Webhosting in so einem Fall eh besser geeignet, sofern die Sende-Limits kein Problem darstellen. Mit der Zustellbarkeit soll es ja mittlerweile etwas besser aussehen. Edit: Gerade mal getestet zu meiner outlook.de Adresse. Angekommen ja, aber im Spamordner. Ist ja bei Microsoft schon ein Erfolg :rolleyes: .

    Nach verschieben in den Posteingang ging denn auch die nächste Mail direkt in den Posteingang.

  • Email (Server & Accounts) zentralisieren.

    Kommt halt auch drauf an, was der Server genau tun soll. Und wieviel Mailspace du brauchst. Wieviele Adressen wieviele sinds denn nunwirklich? Selbst 5 * (15+10) sind schon deutlich mehr als 50. ;) Wobei die Zahl der Mail-Adressen wohl eher sekundär ist.

    Für einen vollwertigen Mailserver würde ich nicht unter 8 GB RAM gehen wollen, unter ziemlichen Schmerzen vielleicht noch 4GB, wenn die Zuverlässigkeit nicht so hoch sein muss. Dann aber ohne Virenscan und eventuell Versand über ein Mailrelay. Also ich würde als separaten Server wohl einen VPS 1000 ARM G11 nehmen. Gelegentlich recht günstig, im Moment leider eher schwierig. Insofernlaufen solche Mailadressen bei mir momentan auf dem VPS 2000 ARM G11 nebenher mit. Der hat ansonsten einige kleine Websites, einige Website-Entwicklungen und bald eventuell noch eine kleine Cloud als Hauptaufgabe. Die paar Mails zusätzlich merkt der gar nicht. Und da er unter Keyhelp läuft, hat er Mail sowieso schon mit an Bord und auch Webmail.

  • E-Mails von neuer Pleskinstanz landen bei MS im Spam

    Das SPF enthält zwar drei Einträge, die alle auf die selbe IP (des Servers) verweisen, sollte aber ansonsten nicht hinderlich sein. Der Server selbst ist jedenfalls als Sender erlaubt. Solange ausschliesslich über den Server versendet wird, wird es also am SPF nicht scheitern.

    Das mit der Zustellung als Spam ist eine Marotte von Microsoft. Mit einem niegelnagelneuen Mailserver wird sich das schwer vermeiden lassen, auch wenn die IP blitzsauber ist. Regelmäßig Mail an Microsoft365 Accounts verschicken, dort immer die Mails explizit als kein Spam einstufen sollte helfen. Genügend Mailaufkommen von deinem Server bei Microsoft365 mit wenig bis keinem Spam kann das Problem dann halbwegs dauerhaft beseitigen. Ist aber nicht ganz einfach, ich denke bei 100 Mails pro Tag fangen die gerade mal an zu zählen ;) . Schon irgendwie lustig, dass die weltweit größten Spamversender die Mail von anderen Absendern als Spam zustellen. Sollten sie erst mal mit der ausgehenden Mail ihrer Kunden machen. Gleich ein Spam-Header rein beim Versand und ab dafür :D.

    Insofern schicke ich wirklich wichtige Mails nicht über meinen eigenen Server raus, sondern über externe Anbieter, die locker mehr als 100 (oder zig-tausend) Mails pro Tag an Microsoft zustellen und sich im Fall der Fälle auch um das Delisting ihrer SMTP-Server bei Microsoft kümmern. Kann man über SNDS auch selbst machen, braucht aber immer einige Mails, bis die Anfrage von einem Menschen bearbeitet und nicht von irgendeinem Bot mit allgemeinen Empfehlungen zu erforderlichen Einstellungen abgewimmelt wird.