Posts by michaeleifel

    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:


    Code
    1. address 185.163.116.167/22


    Bist du dir sicher dass das korrekt ist? Ich würde ja eher auf /32 tippen.

    War die Domain vorher bei Strat0? Der SOA Eintrag zeigt immer noch dort hin:


    Code
    1. ;; ANSWER SECTION:
    2. abc-def.de. 300 IN SOA docks13.rzone.de. hostmaster.strat0-rz.de. (
    3. 2020052404 ; serial
    4. 86400 ; refresh (1 day)
    5. 7200 ; retry (2 hours)
    6. 604800 ; expire (1 week)
    7. 300 ; minimum (5 minutes)
    8. )


    Weitere Bestätigungen dass Netcup nicht authoritive ist:


    Code
    1. ▸ Received 572 responses with 590 RR [6 A, 6 AAAA, 18 CNAME, 542 MX, 12 NS, 6 SOA], 4424 Nx, 9 Err [2 TO, 0 QR, 0 SF, 7 O] in (min 0, max 484) ms from 7 servers within 9161 ms of total run time.
    2. ∙ SOA: origin NS docks13.rzone.de., responsible party hostmaster.stratö-rz.de., serial 2020052404, refresh 1day, retry 2h, expire 7days, negative response TTL 5m expires in [min 2m 27s, max 4m 51s] (6) for domain name abc-def.de.
    3. ∙ NS: shades08.rzone.de. expires in [min 1m 45s, max 3m 57s] (6) for domain name abc-def.de.
    4. ∙ NS: docks13.rzone.de. expires in [min 1m 45s, max 3m 57s] (6) for domain name abc-def.de.

    ;; 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:


    Code
    1. sudo echo nameserver 8.8.8.8 > /etc/resolv.conf
    2. sudo chattr +i /etc/resolv.conf

    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 ;-)

    Bei mir war ebenfalls für ca. 10 Min alles lahmgelegt. Zusätzlich spinnt seit ein paar Tage einer der DNS Server sporadisch:


    Code
    1. Resolver 46.38.252.230 is unreachable


    kann das jemand auch bestätigen?

    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ß

    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?

    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

    Files

    • p1.png

      (310.52 kB, downloaded 30 times, last: )
    • p2.png

      (19.52 kB, downloaded 21 times, last: )
    • p3.png

      (41 kB, downloaded 24 times, last: )