Vielen Dank für die Antworten. Der Tip von Jimi hat mich zum Ziel gebracht:
Einfach im SCP auf dem Server ein Netcup Standard Image installieren (unter Images) und dabei auswählen "Zugangsdaten per Email senden".
Dann bekommt man nach der automatischen Installation des Images praktisch die gleiche Mail wie bei einem neuen Server. Also mit den ganzen Daten wie root Passwort usw. und eben auch mit dem entsprechenden (originalen) rDNS Eintrag.
Ich weiß nicht ob jemand es schon mal gefragt hat, hab nichts zu gefunden:
Gibt es einen Weg wie ich meinem Netcup Server seinen ursprünglichen rDNS Eintrag wieder verpassen kann?
Gruß
Domain löst sauber auf, ich tippe weiterhin auf TTL / SOA Ärger bei der Umstellung.
Dass der 46.38.225.230 eben nicht macht was er soll ist ja wohl offensichtlich:
Was wäre denn deine Erwartung bzw was soll er tun? Dann können wir die ja mal testen.
Ich würde übrigens den 37.221.199.199 aus der dns-nameservers rausnehmen. Versuch mal gegen den eine Domain aufzulösen die nicht bei Netcup liegt und achte dabei auf den StatusCode. Der wird natürlich REFUSED sein
Noch eine Sache:
Bist du dir sicher dass das korrekt ist? Ich würde ja eher auf /32 tippen.
Dann sollte er vielleicht mal mit paar Sachen rausrücken, ansonsten können wir ihm nicht wirklich helfen fürchte ich. Aber prinzipiell tut der 46.38.252.230 was ich von ihm erwarte: Er cached DNS Einträge und ich muss nicht jedes Mal zu google laufen 
War die Domain vorher bei Strat0? Der SOA Eintrag zeigt immer noch dort hin:
Weitere Bestätigungen dass Netcup nicht authoritive ist:
;; ANSWER SECTION:
abc-def.de. 17582 IN A xxx.xxx.204.57
Kann es sein dass die TTL erst seit kurzem auf den 1800 steht und vorher auf einen anderen Wert stand?
Das würde nämlich das erklären. DNS Einträge werden ja nicht bei jeder Anfrage neu aktualisiert. Selbst bei dem großen Konzern mit A am Anfang musst du warten bis deine TTL abgelaufen ist bevor da die Einträge refreshed werden.( https://de.wikipedia.org/wiki/DNS-Caching )
Mit der Information Debian 10 ist dein Problem doch in 5 Sekunden gelöst:
Und schon verwendet dein Server Google DNs mit allen Vor- und Nachteilen.
Es würde helfen zu wissen mit welchem OS wir es zu tun haben und inwiefern das System konfiguriert /provisioniert ist. /etc/resolv.conf verhält sich in Ubuntu 20.04 anders als bspw in Debian Buster. Von Haus aus wird das System vermutlch auf DHCP stehen und kriegt daher auch die Info welche DNS Resolver. Das lässt sich im dhclient auch "superseeden" sofern man weiter DHCP für die IP Adressen selber nutzen möchte.
Alternativ kann man das ganze auch ( ich mache es per Ansible) statisch konfigurieren. Hau doch mal paar Infos raus
Was ist hier los? Wieso sind falsche Nameserver in den Netzwerken der KVM-Server eingetragen?
Das sind interne Caching DNS-Server von Netcup, sie sind nicht "falsch" im eigentlichen Sinne. Notfalls kannst du ja andere public DNS Resolver eintragen.
Nutze sowohl Icinga2 High Availibilty mit eigenem Dockercontainer als auch Prometheus.
Sofern Debian:
- prüfen was in /etc/network/interfaces definiert ist, dort steht bei dir "source /etc/network/interfaces.d/*" mit drin
- checken was in source /etc/network/interfaces.d/* so rumliegt.
Normalerweise haben die Dateien dort das Muster XX-yyyy.cfg == XX sind Zahlen von 0-9 und yyy ist normalerweise der Inferface name. Bei cloud-init ist es typischerwise 50-cloud.cfg
Um ganz sicher zu gehen würde ich auch im Zweifel die Maschine rebooten nach Änderung falls möglich.
Hallo,
hast du evtl was mehr Informationen dass wir der Suche evtl auf die Spur kommen?
- finden sich denn irgendwelche Logs die auf Verbindungsprobleme oder sonstiges hinweisen bspw die CNI Pods?
- Starten bestimmte Pods weil bspw Healtchecks fehlschlagen?
- sofern Monitoring vorhanden: wieviele IOPS finden statt? gibt's spikes bei cpu / ssd?
Gruß
Stand von vor 1Jahr nach Kontakt mit dem Support:
- Ist die Trafficgrenze erreicht, dann kann der Speicher den Rest des Monats nicht mehr verwendet / angesprochen werden
Da es zudem keine Anzeige / Warnung gibt wann dies der Fall ist, hab ich damals den wieder gekündigt.
Gute Frage.
"Interessant" ist auf jeden Fall dass ein Netcup VLAN Abhängigkeiten nach sich zieht wie bspw auch eine Floating Ip sofern diese einem Server zugewiesen ist der eine NIC mit dem gleichen VLAN hat wie der zu übertragene Server.
Kontakt mit dem Support. Kündigung des anderen Produktes wurde temporär rausgenommen, danach ging der Inhaberwechsel.
Abend,
im Wiki finde ich keinen Abschnitt zu folgendem Problem. Die Kündigung eines Produktes bei Netcup blockiert sämtliche Inhaberwechselaktionen? Kann das jemand bestätigen?
Gruß,
Michael
Moin,
bin derzeit in Recherche für hidden primary / secondary dns.
Ich habe mich durch das CCP geklickt, allerdings nicht fündig geworden:
- Wie kann ich den Zonentransfer von Netcup auf eine Ziel IP erlauben?
Hatte paar Threads gefunden (https://forum.netcup.de/admini…ghlight=primary#post99407) bspw, aber keine Antwort.
He.net habe ich schon als Slave im Einsatz, finde bei denen aber auch nicht wie ich AXFR bei einer Master Zone erlauben kann. Jemand Tipps für mich?
wir haben Schon ein paar Methoden gemacht Und es Zu 52.7% geschaft
Moin,
ist das ein Benchmark den man ausführen kann? Dann würde ich den mal bei mir ausprobieren und kann schauen. Ich hatte eine Zeit lang mal DDoS Regeln in Verbinding mit Sysctl hardening aktiv, die haben allerdings an anderen Stellen Probleme verursacht.
Gruß
Mahlzeit,
das letzte Mal mit CheckMK vor ca. 2 Jahren gearbeitet. Was monitorst du denn so alles?
Icinga2 ist ja "nur" ein Monitoring Framework, von Haus aus ist da checkmk besser. Allerdings war ich in checkmk oft an dem Punkt angelangt wo ich dann doch wieder selber Pakete "backen" muss und die GUI fand ich sehr unübersichtlich. Die Appliance ist ein netter Ansatz, allerdings mag ich es zu wissen was so alles darin läuft und konfiguriert ist. Und zudem entspricht sie nicht meinem "Ansible" Ansatz für Verwaltung.
Ich habe was Zeit in Icinga2 und Automatisierung gesteckt, Hosts werden per Ansible / Kubernetes Daemonset ohne zutun registirert. Dies beinhaltet den Austaisch der Zertifikate, feststellen was die Maschine so ist (OS, Memory, Disk, Loadwerte werden automattisch ermittelt etc.) (inkl. Autoscaling in AWS), die Master laufen im HA Modus und koordinieren sich selber. Das heßt Konfig gegen master1 testen, der 2. monitort weiterhin und erst wenn auf dem 1. alles OK ist wird die Konfig automatisch zum anderen übertragen und der 1. monitort in der Zeit. Das fehlt mit bspw an Prometheus sehr.
integriert ist das ganze dann mit Matrix / Email als Alarmierung. Im Anhang mal ein Beispiel von paar Hostschecks. Die restlichen checks werden von icinga2 containern gemacht, da wird so ziemlich alles gecheckt was man möchte, webseiten status, zertifikate die ablaufen, ob die Netcup SOAP erreichbar ist und Status 200 meldet etc.
Auch die Master checken sich gegenseitig. Prometheus spielt an der Stelle den Wächter und sammelt die sonstigen Metriken im Cluster so ein.
Von extern wird das ganze noch von einem Monitoring Dienst gegengeprüft, roundabout sind es ca. 1000 Checks gegen 10 Nodes.
Gruß,
Michael
