DNS-Probleme / keine bzw. nur teilweise Aktualisierung internes Netcup-Netz

  • Guten Abend in die Runde....

    Ich versuche seit Stunden, geänderte DNS-Einstellungen auf mehreren meiner gemieteten KVM-Rootservern aktualisiert zu sehen.
    Die externen internationaler DNS-Server haben die Änderungen bereits seit heut Vormittag übernommen, es ist eine TTL von 1800 eingestellt.
    Nur die Server von Netcup selbst betrieben übernehmen diese nicht, was natürlich dann zu massiven Problemen bei den umgezogenen Domains führt.
    Die Server haben fix eingetragen den DNS-Server 46.38.225.230 - der ist aber nirgendwo als Nameserver von Netcup eingetragen.
    Ein dig uauf die Nameserver von netcup (root-dns; second-dns; third-dns) macht es richtig, die IP wird richtig zugeordnet.
    Was ist hier los? Wieso sind falsche Nameserver in den Netzwerken der KVM-Server eingetragen?
    Da hängen ca. 30 Kunden aktuell dran, die umgezogen wurden und nicht richtig laufen, weil bswp. u.a. keine neuen Zertifikate per LE erzeugt werden können, weil die Domain von localhost der betroffenenn KVM-Sessions nicht aufgelöst werden kann.

    Bitte dringend um Hilfe - ich hab keine Möglichkeit hier einzugreifen und morgen (Ostersamstag) müssen die Domains wieder laufen...


    Ratlose Grüße ais dem Erzgebirge

    hempelr

  • Danke für die Info.

    Aber wo kann ich die DNS-Resolver eintragen? Wenn die /etc/resolv.conf manuell geändert wird, passt es, aber das ist ja logischerweise nicht rebootfest.
    Wo kann man die Konfiguration für resolvconf anpassen - ich such und probier schon den ganzen Abend und find nichts brauchbares...
    Das resolvconf muss doch irgendwo ne "grundkonfig" haben - woher holt er sich seine dynamischen Werte?

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

  • Für die Beantwortung der Frage wäre es hilfreich, zu wissen, welche Distribution in welcher Version über welchen Weg installiert wurde. Meine Vermutung wäre, dass sich die erforderlichen Einstellungen im Verzeichnis /etc/netplan/ (und dort ggf. in der Datei 50-cloud-init.yaml) finden. Wenn dort standardmäßig alles via dhcp(4/6) übernommen wird, lässt sich das ändern. Gegebenenfalls sieht die Datei ähnlich wie folgt aus?

    Code: /etc/netplan/50-cloud-init.yaml
    # This file is generated from information provided by the datasource.  Changes
    # to it will not persist across an instance reboot.  To disable cloud-init's
    # network configuration capabilities, write a file
    # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
    # network: {config: disabled}
    network:
        version: 2
        ethernets:
            eth0:
                dhcp4: true

    Wie man die Datei entsprechend anpasst, findet sich unter anderem hier oder ausführlicher hier.

    Fürs Protokoll: Es gibt aber eine andere Möglichkeit, die DNS-Auflösung temporär (lies: wirklich nur als Workaround gedacht!) blitzschnell "bootfest" zu korrigieren: Den Inhalt von /etc/resolv.conf ansehen (das ist meistens ein symbolischer Link, der auf eine andere Datei verweist), die Datei (also den Link) löschen, neu erstellen, und als Administrator vor Überschreibung schützen:

    Code
    #cat /etc/resolv.conf    #Ergebnis kopieren
    #rm -f /etc/resolv.conf
    #$EDITOR /etc/resolv.conf    #Texteditor der Wahl verwenden, falls $EDITOR nicht definiert ist
    ####An dieser Stelle den alten Inhalt einfügen und die Zeilen mit "nameserver" ersetzen durch "nameserver 1.1.1.1"
    ####(Statt 1.1.1.1 geht auch 8.8.8.8 oder 9.9.9.9; diese können theoretisch auch nebeneinander verwendet werden)
    #chattr +i /etc/resolv.conf    #"immutable"-Bit; kein Programm wird die Datei abändern können, bis es wieder gelöscht wird
    ####(Letzteres geht mit "chattr -i ...")

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Hallo und vielen Dank für Denkanstöße und Lösungsansätze - hat mich noch nicht wirklich weitergebracht...


    Distribution ist Debian 10, installiert aus dem Debian 10 minimal Image aus dem SCP


    Darauf ist dann KeyHelp als Webpanel installiert und die Domainverwaltung etc. läuft darüber - aber das hat ja nur am Rande was mit dem Problem zu tun...der Fehler tritt auch auf "nackten" gemieteten KVM-Instanzen auf....

    Als Beispiel sei eine domain abcdef.de und abc-def.de genannt. Beide wurden gestern abend im DNS auf den neuen Server umgestellt, A-Records entsprechend in beieden im CCP geändert.
    Jetzt per dig auf dem betreffenden Server wie folgt:

    auf abc-def.de

    Ein dig auf abcdef.de wie folgt:

    Demgegenüber steht ein dig auf einen belibigen der drei Netcup-DNS-Server, beispielhaft sei hier der second-dns.netcup.net genannt:

    What the hell shold that mean? (sorry...)


    Die Datei / den Ordner
    /etc/netplan/50-cloud-init.yaml

    gibt es auf dem Server nicht - eine Suche danach auf dem Server war erfolglos. (nur nochmal zur Info - es handelt sich um eine KVM-Instanz die von Netcup als KVM-Root benannt wird, es ist kein dedizierter Server der von mir hier verwaltet wird)
    Was da per find / -name '*cloud-init*' gefunden wird ist für mich nicht ganz klar - das ist ne ziemliche "Unmenge" auch in Dirs, die was mit dem Systemstart zu tun haben.

    Wenn es mit der festgeschriebenen resolv.conf neu gestartet wird, werden überhaupt keine Namen intern mehr aufgelöst - der Neustart dauert gefühlt Stunden (nee aber auf alle Fälle viel länger als wenn keine Änderungen vorgenommen wurden) - alle Fragen nach externen Domains werden dann mit Fehlermeldung quittiert (habs leider nicht dokumentiert, weil ein halbwegs funktionierender Server mit Kundendomains besser als ein nicht funktionierender ist möchte ich das auch nciht nochmal testen ;) )

    Wieso wird eine Domain hier auf dem Server aktualisiert die andere nicht, beide zur gleichen Zeit im DNS geändert, die aktiven Netcup-DNS-Server habens auch übernommen, DIGs auf internationale DNS-Server zeigen auch das richtige an (bspw. hier der von censurfridns.dk) :


    Irgendwas ist offenbar falsch konfiguriert bei Netcup, die gleichen Effekte treten auf alen anderen 5 von mir gemieteten KVM-Instanzen auf - vollkommen identisch fehlerhafte DNS-Auflösung.

    Was ist da los - ich kann es mir echt nicht erklären...

    Übrigens - die resolv.con sieht auf allen Instanzen wie folg aus:

    Code
    cat /etc/resolv.conf 
    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    nameserver 46.38.225.230
    nameserver 46.38.252.230
    nameserver 2a03:4000:0:1::e1e6

    Der Link der resolv.conf läuft auf /etc/resolvconf/run/resolv.conf
    Wenn die Datei /etc/resolvconf/resolv.conf.d/base wie folgt ausgeführt wird

    Code
    nameserver 46.38.225.225
     2 nameserver 37.221.199.199
     3 nameserver 188.68.63.68
     4 nameserver 2a03:4000:0:1::e1e1

    dann wird nach einem resolvconf -u die reslov.conf wie folgt generiert:

    (Die Zeile __hier ist es neu__ wurde in die /etc/resolvconf/resolv.conf.d/head von mir eingefügt, um zu checken, ob da tatsächlich was dynamisch gebaut wird - es wird)

    Mir ist vollkommen unklar, woher diese offensichtlich fehlerhaften doppelten Nameservereintragungen 46.38.225.230 in der resolv.conf kommen - und das auf allen 5 gemieteten Serverinstanzen...
    Wenn die dann in der resolv.conf manuell gelöscht werden, passt es, dig zeigt die richtigen Werte an. Also ist definitv dieser ominöse 46.38.225.230 fest irgendwo konfigurierte DNS-Server ursächlich - wo immer der auch da eingebaut wird...


    Weitere Gedankenanstöße gern erwünscht....


    Viele Grüße aus dem Erzgebirge

  • tab
    Wo kann der umgestellt werden - resolvconf macht nach jedem Neustart wieder den alten fehlerhaften rein... und das hat imho nix mit langsamerer Reaktion zu tun, da ist was grundlegend falsch bei netcup behaupte ich einfach mal :) *duckundweg*
    Das ganze Problem liegt da irgendwo tiefer...

  • ;; 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
    sudo echo nameserver 8.8.8.8 > /etc/resolv.conf
    sudo chattr +i /etc/resolv.conf

    Und schon verwendet dein Server Google DNs mit allen Vor- und Nachteilen.

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


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


    Weitere Bestätigungen dass Netcup nicht authoritive ist:


    Code
    ▸ 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.
     ∙ 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.
     ∙ NS:      shades08.rzone.de. expires in [min 1m 45s, max 3m 57s] (6) for domain name abc-def.de.
     ∙ NS:      docks13.rzone.de. expires in [min 1m 45s, max 3m 57s] (6) for domain name abc-def.de.
  • Distribution ist Debian 10, installiert aus dem Debian 10 minimal Image aus dem SCP

    […]

    Die Datei / den Ordner /etc/netplan/50-cloud-init.yaml gibt es auf dem Server nicht - eine Suche danach auf dem Server war erfolglos. […]
    Was da per find / -name '*cloud-init*' gefunden wird ist für mich nicht ganz klar - das ist ne ziemliche "Unmenge" auch in Dirs, die was mit dem Systemstart zu tun haben.
    Wenn es mit der festgeschriebenen resolv.conf neu gestartet wird, werden überhaupt keine Namen intern mehr aufgelöst […]

    Mir ist vollkommen unklar, woher diese offensichtlich fehlerhaften doppelten Nameservereintragungen 46.38.225.230 in der resolv.conf kommen - und das auf allen 5 gemieteten Serverinstanzen...
    Wenn die dann in der resolv.conf manuell gelöscht werden, passt es, dig zeigt die richtigen Werte an. Also ist definitv dieser ominöse 46.38.225.230 fest irgendwo konfigurierte DNS-Server ursächlich - wo immer der auch da eingebaut wird...

    […]

    Zunächst verwundert mich, dass eine explizit geschützte Datei resolv.conf mit einer einzigen Zeile ("nameserver 1.1.1.1" o. ä.) dazu führt, dass keine Auflösung mehr erfolgt. Das Ergebnis sollte identisch zu dem sein, was man mit dig bei expliziter Vorgabe des DNS-Servers erhält – kann es sein, dass bei dig +short abc-def.de @1.1.1.1 kein Ergebnis zurückgeliefert wird (und auch nicht mit 8.8.8.8, 9.9.9.9)? Letzteres würde in der Regel auf Probleme mit den DNS-Einträgen für die Domäne bei Netcup zeigen. (Man kann alternativ auch weltweit DNS-Server abfragen, siehe https://www.whatsmydns.net/ – hier kann es immer wieder zu wenigen Fehlern kommen, aber wenn gar nichts gefunden wird, liegt dies fast eindeutig daran, dass die DNS-Einträge der eigenen Domäne fehlerhaft sind.) Wird das erwartete Ergebnis gefunden, würde ich vermuten, dass beim ersten Test ggf. ein Schreibfehler in resolv.conf vorlag – denn das System sollte beim Booten zwar erfolglos versuchen, resolv.conf erneut zu schreiben, dies sollte bei korrektem Inhalt jedoch keine merkliche Verzögerung mit sich bringen und insbesondere nicht dazu führen, dass gar keine Auflösung von Domänennamen mehr funktioniert (letzteres Problem verlangsamt den Bootvorgang allerdings erheblich!)


    Es ist logisch, dass die vorgegebenen DNS-Serveradressen 46.38.225.230 bzw. 46.38.252.230 irgendwo herkommen müssen; entweder, sie finden sich explizit in einer Konfigurationsdatei (sollte sich finden mittels grep -r 46.38.252.230 /etc) oder – wahrscheinlicher – sie werden via DHCP erfragt. Informationen dazu sollten sich in der Datei /etc/network/interfaces finden.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • War die Domain vorher bei Strat0?

    Guter Punkt, aber bei abc-def.de handelt es sich um eine (unglücklich gewählte) Anonymisierung, somit sind die gezeigten Ausgaben "unzutreffend" – Der OP wollte hier sicherlich example.org verwenden.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

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

  • Guter Punkt, aber bei abc-def.de handelt es sich um eine (unglücklich gewählte) Anonymisierung, somit sind die gezeigten Ausgaben "unzutreffend" – Der OP wollte hier sicherlich example.org verwenden.

    Immerhin spannend, dass solche tollen Domainnamen wie abc-def.de tatsächlich registriert sind. Man sieht deutlich, dass Domains zu billig und die unzähligen Inklusivdomains kontraproduktiv sind.

  • :)

    Also es betrifft mehrere Domains die auf den Server connectiert sind.
    Dass der 46.38.225.230 eben nicht macht was er soll ist ja wohl offensichtlich:

    Ahh -

    (sollte sich finden mittels grep -r 46.38.252.230 /etc) oder

    da findet sich glatt was ... /etc/network/interfaces.d/50-cloud-init.cfg - danke für den Hinweis, manchmal kommt man nicht auf das naheliegendste (zumal mir da doch die echt effektiven Shell-Befehle halt noch nicht in Fleisch und Blut übergegangen sind ;))


    mhm - Anpassung vorgenommen, läuft aber jetzt noch nicht wie erwartet...


    die /etc/network/interfaces.d/50-cloud-init.cfg sieht jetzt so aus:



    mhm - ich gebs für heut erst mal auf...vielleicht bringt ja die Zeit doch noch was...
    Danke erst mal an alle, die versucht haben zu helfen.
    ...

  • 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
    address 185.163.116.167/22


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

  • [...] die /etc/network/interfaces.d/50-cloud-init.cfg sieht jetzt so aus:

    mhm - ich gebs für heut erst mal auf...vielleicht bringt ja die Zeit doch noch was...
    Danke erst mal an alle, die versucht haben zu helfen.

    Noch zwei kurze Anmerkungen:

    1. Die IPv6-Adresse in der Zeile "dns-nameservers" sollte als separater Eintrag unter die Zeile mit "address 2a03:4000:..."
    2. Auch die Namensgebung der Datei "50-cloud-init.cfg" sowie das Vorhandensein mehrerer Dateien mit dem Namen "*cloud-config*" lässt darauf schließen, dass Cloud-init den Dateiinhalt modifizieren könnte (was ich nicht direkt überprüfen kann, da ich das genannte Netcup-Debian-10-Abbild nicht verwende); im Zweifelsfall sollte man die vorgenannte Datei "50-cloud-init.cfg" umbenennen (um zu kennzeichnen, dass sie manuell erstellt wurde) und Cloud-init anweisen, die Netzwerkkonfiguration in Zukunft (=nach einem Reboot oder expliziten Anstoß der Neuerstellung von Konfigurationsdateien) nicht mehr anzufassen; siehe gelb markierte Anmerkung hier (manuell etwas nach oben scrollen).

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • So - vielen Dank für den Input...
    Offensichtlich alles eine Frage der Zeit und wahrscheinlich auch der manuellen Änderungen der DNS-Server in der /etc/network/interfaces.d/50-cloud-init.cfg hat erst mal eine Lösung gebracht.


    Die Infos des 46.38.225.230 sind jetzt aktuell - trotzdem erschließt sich mir nicht, wieso bei identischen TTL- u.a. Zeitwerten im DNS-Manager / CCP die Aktualisierungsraten so unterschiedlich sind - zumal der ja dies Caching-DNS im Netzwerk von Netcup direkt sind...aber egal, die restlichen Domains für den Umzug sind nur fast "tote" Hobbybetreiber, da ist so eine Verzögerung nicht ganz so stress vermittelnd ;)

    Hab wieder einiges gelernt - auch etwas Geduld zu üben - kann man ja schon fast nicht mehr in diesen Zeiten ;)


    Gute Ostern noch an alle, bist zum nächsten mal ;)


    Grüße aus dem sonnigen aber kühlen Erzgebirge


    Ruben