Man sollte generell Exzesse nicht mit "nennt man Marktwirtschaft" rechtfertigen. In diesem Fall sowieso nicht: Es gibt keinen Markt für .de-Domains. Das ist genauso wie alle anderen Domains auf "Erzeugerseite" ein Monopol. Die Grenzkosten einer Domain sind Null. Wenn das Marktwirtschaft wäre, wüsstest du, was eine Domain kosten würde.
Beiträge von NaN
-
-
Man ist von NC schon sehr verwöhnt.
Nein, man ist von den Domainpreisen der kommerziellen Registries verdorben. Die Registry der .com TLD hat einen Gewinn von 200 Millionen Dollar bei einem Umsatz von 400 Millionen Dollar gemacht, und da weißt du, dass bei den "Kosten" auch schon gut hingelangt wird. Für diese Domains sind Preise von 1-2€/Monat normal, weil sich schon die Registry die Taschen voll macht, aber doch nicht für Domains, wo eine Genossenschaft ohne Gewinnerzielungsabsicht die Vorleistung erbringt, die nahezu das gesamte Produkt ist. Das ist eben die gleiche Branche, in der einige schwarze Schafe sündteure domain-validated TLS-Zertifikate alternativlos verkaufen, obwohl Letsencrypt existiert.
-
Du hast einen CNAME für die selbe Subdomain angelegt. Ein CNAME muss der einzige Resource Record sein, also sind alle weiteren Records für die selbe Subdomain ungültig. Mach den CNAME weg, dann funktionieren die NS-Records.
-
Es geht auch ohne hinzugucken: kill -9 -1 macht einfach alles platt. Da man nur seine eigenen Prozesse erledigen kann, kommt das vielleicht auch in Frage, wenn es eilt.
-
In einem meiner Webhostings heißt der Cronjob-Prozess php und lässt sich von einem Web-PHP-Script mit exec('killall php') beseitigen.
-
It's an automated process and takes a couple of minutes. If you've started it when you wrote the comment, you're already done.
-
I'm sending a verification request to Netcup, something has a problem above my instance.
Highly unlikely. The interface is configured and up, you're just throwing away all inbound packets. You send the pings but throw away the responses. This is a configuration problem on your end. Reinstall the server with a fresh OS image and take small steps when you configure your services. Reboot in-between steps and verify that everything still comes up again. When something doesn't, don't proceed. Fix the problem first.
-
Chain INPUT (policy DROP... with no accepting rules in the chain means that your server throws away everything inbound, so no communication is possible. It's a firewall issue. It may be a result of not finishing the network configuration. Look for hints why the network service fails.
-
Even though the network didn't start, eth0 appears to be configured correctly and is up. See if you have any firewall rules: nft list ruleset or iptables -L.
-
Es gibt nur die autoritativen Server, die rekursive Anfragen nicht bearbeiten, und die Resolver, die nur für Netcup-IP-Adressen arbeiten. Wenn du einen rekursiven Resolver für deinen Heim-Server brauchst, kannst du den von deinem Internetprovider nehmen, den von deinem Router, der den vom Provider verwendet, einen der vielen öffentlichen Resolver, oder einen eigenen Resolver betreiben, aber keinen von Netcup.
-
Der Server mit Traefik läuft doch bei dir zu Hause, nicht bei Netcup, oder? Dann kannst du die rekursiven Resolver von Netcup nicht verwenden. Die weigern sich, für Externe zu arbeiten. Wenn es mit den autoritativen Servern nicht funktioniert, nimm halt 9.9.9.9, 8.8.8.8 oder 1.1.1.1 (Quad9, Google, Cloudflare). Die TTL der TXT-Records ist hoffentlich kurz. Dann sollte das die Wartezeit nicht zu sehr verlängern.
-
Wenn der Record richtig gesetzt aber nicht gesehen wird, stimmt wohl mit der DNS-Auflösung etwas nicht. Du hast die drei autoritativen Netcup-Nameserver angegeben und eine weitere Adresse. Ist 46.38.243.234 wirklich ein Nameserver? Das ist eine Adresse bei Netcup, vielleicht deine? (Wenn es deine ist, solltest du dich darum kümmern.)
-
Angesichts von 45 Netzwerkdevices denke ich, dass du vielleicht etwas mehr als nur /etc/hosts and /etc/hostname geändert hast. Docker ist offenbar installiert. Das verwendet netfilter für seine Zwecke. Wenn dir nichts anderes einfällt, was du gemacht hast, hilft wahrscheinlich nur eine systematische Fehlersuche. Prüfe, ob eth0 die richtige(n) Adresse(n) hat: ip address show dev eth0. Du kannst mit tcpdump untersuchen, ob die SSH Pakete deinen Server erreichen (tcpdump -i eth0 port 22). Wenn die ufw Firewall installiert ist, lass dir die Konfiguration davon anzeigen: ufw status verbose. Logfiles anschauen ist auch nützlich.
-
Du kannst die VNC-Konsole benutzen, um den Server auch ohne Netzwerkzugriff zu bedienen. Eine andere Möglichkeit ist das Rettungssystem. Wenn es sich nur um ein Netzwerkproblem handelt, sollte der Server noch normal aus dem ServerControlPanel herunterzufahren sein, um ihn im Rettungssystem neuzustarten. Im Rettungssystem könntest du dann die Netzwerkkonfiguration (oder die Firewall, den SSH-Server, etc.) korrigieren.
-
Von Screenshot auf Snapshot wäre ich im Leben nicht gekommen.
Im "vServer / Server / KVM-Server" Forum? Doch, wärst du. Hast nur nicht hingeguckt, weil du es über die "letzten Beiträge" gelesen hast.
-
Hallo,
habe eine kurze Frage, wie lade ich herunter mein Screenshot was ich gerade erstellt habe.
LG
Du meinst Snapshot. Das ist im Wiki beschrieben.
-
Zu lange gewartet, Nonce abgelaufen. So eine lange Wartezeit kann aber nicht nötig sein, also wird sich das erledigen, wenn du mit einer zu erwarteten Wartezeit hinkommst. Du solltest jetzt aber wissen, ob der TXT-Record richtig eingetragen wurde.
-
Tools, die DNS-Konfigurationen überprüfen, sollten vernünftigerweise nicht oder nur sehr kurz cachen, genauso wie man selbst die eigenen DNS-Änderungen besser beim autoritativen Server abfragt als bei irgendeinem öffentlichen DNS-Resolver. Selbst wenn die lange TTL nicht bei einem DNS-Resolver angekommen ist, den du nach diesem Test abfragst, sagt das überhaupt nichts über andere Resolver aus. Die meisten DNS-Resolver kennst du gar nicht und fast alle darfst und kannst du gar nicht befragen. Wenn du einem Server gesagt hast, das gilt eine Woche lang, darf der dich beim Wort nehmen, und du hast keinen Grund zur Annahme, dass er das nicht tut.
-
Normalerweise müsste irgendwas über 10 Minuten schon reichen. So träge sind die Netcup-Server auch wieder nicht. Aber da du jetzt eine sehr lange Zeit eingestellt hast, kannst du in der Zeit mal nachsehen, ob wirklich der Record da gesetzt wird, wo er hingehört.
-
As you are portscanning systems operated by potentially unaware sysadmins and defended by automated abuse detection systems, you must expect Netcup to receive abuse reports about your activity in addition to Netcup's own abuse monitoring which is designed to catch malicious behavior to detect compromised systems. This is an additional workload that you would have to clear with Netcup.
I expect that this is not acceptable behavior because how could Netcup tell if you're actually authorized to perform these scans. Even if you can provide documentation in some cases, you could still run unauthorized scans and nobody would be the wiser.
My recommendation would be to use end-user networks for something like this. Nobody cares what DSL and mobile phone users do.
