netcup DNS-Resolver von einem meiner VPS nicht erreichbar (Debian 12)

    Seit kurzem habe ich ein Problem auf einem (nicht produktiv) eingesetzten Piko.

    Auf diesem Server funktioniert die DNS-Auflösung plötzlich nicht mehr.

    Als Resolver sind standardmäßig seit Installation des Debian 12 Image von netcup folgendes eingestellt:

    Code
    #cat /etc/resolv.conf
nameserver 46.38.225.230
nameserver 46.38.252.230
nameserver 2a03:4000:0:1::e1e6

    Die Namensauflösung funktioniert nicht:

    Gibt man einen anderen Resolver an funktioniert's:

    Code
    #nslookup ard.de 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53


Non-authoritative answer:
Name:   ard.de
Address: 34.120.237.106

    Ich habe den VPS bzw. einzelne Dienste noch nicht neu gestartet.

    Der VPS befindet sich aktuell also noch im unveränderten Fehlerzustand.

    Auch jegliche Konfigruationen sind unverändert (habe noch nichts rumgespielt).

    Manche kleine Server (Piko und Nano) betreibe ich nur für unwichtige Dinge um gerade bei solchen Problemen (wie z.B. diesem hier) die Ursache ermitteln, eingrenzen und etwas lernen zu können.

    Der VPS läuft seit Monaten unverändert - abgesehen von apt update && apt upgrade (welche aber zeitlich nicht mit der fehlerhaften DNS-Auflösung zusammen fallen).

    Code
    #uptime
16:48:37 up 161 days,  2:53,  1 user,  load average: 0.13, 0.19, 0.18

    Per ping komme ich auf IPs.

    Der netcup Resolver ist per ping leider nicht erreichbar - das funktioniert aber auf keinem Rechner (seitens netcup scheinbar deaktiviert):

    Code
    #ping 46.38.225.230
PING 46.38.225.230 (46.38.225.230) 56(84) bytes of data.
(nix)

    Ich hatte fail2ban im Verdacht (wobei ich nicht wüsste welche Jail / welches Filter hier aktiv werden sollte), aber die netcup IPs sind sauber und befinden sich in keiner Jail:

    Code
    grep '46.38.2' /var/log/fail2ban.log
(nix)

grep '2a03' /var/log/fail2ban.log
(nix)

    Ein eigener Resolver läuft auf dem VPS auch nicht (ergibt sich aber auch schon aus den Angaben von oben):

    Code
    #sudo systemctl is-active systemd-resolved.service
inactive


    Fragen:

    Gibt es außer ping (was bei den netcup Resolvern nicht geht) auch noch andere Möglichkeiten mich dem Problem zu nähern?

    Kann ich auch ohne ping rausfinden ob es an der Verbindung zum 46.38.225.230 liegt oder ob irgendein Dienst auf dem VPS abgestürzt ist?

    Selbstverständlich kann ich einzelne Dienste oder den VPS neu starten und wenn danach alles wieder funktioniert ist das Problem vom Tisch. :rolleyes:

    Gerne hätte ich aber versucht das Problem einzugrenzen und vielleicht sogar eine Ursache zu finden um etwas zu Lernen. :)

    Einen Rechner neu zu starten um "Probleme zu lösen" ist zwar bei Windows üblich, aber unter Linux will ich lieber etwas lernen um solche Probleme (falls eingrenzbar) zukünftig vermeiden zu können. :saint:

    Beispielsweise wenn der VPS irgendwo einen Cache oder eine Logdatei hat (obwohl kein lokaler Resolver läuft) und das Ganze übergelaufen ist oder so. :/

    Wie bereits erwähnt läuft der VPS ja auch wegen des Lerneffekts. Jetzt gibt es erstmals einen Fehler, den ich (vermutlich) nicht während der Installation vor 1-2 Jahren selbst verursacht habe.


    Hinweis:

    Auf einem anderen VPS mit gleicher Konfiguration und gleichem Debian 12 Stand läuft alles problemlos.

    Die beiden VPS sind quasi Zwillinge.

    funktionierender Server zum Vergleich (selbe Konfig)

    Um zu sehen, was raus- und reingeht, bietet sich tcpdump an. Das lauscht auf dem Interface, zeigt also, was tatsächlich auf die Leitung geht (nach der Firewall) oder von dort kommt (vor der Firewall). Damit kannst du schnell ausschließen (oder bestätigen), dass es an deinem Server liegt. Beispielaufruf: tcpdump -i eth0 -n host 46.38.225.230 (Das -n schaltet die Namensauflösung ab, in der Situation wahrscheinlich sinnvoll. Ggf. weiter filtern, wenn du so zuviel Rauschen bekommst.)

    2 Mal editiert, zuletzt von NaN (22. November 2025 um 18:14)

    Probier den Tipp von NaN in jedem Fall aus. Aber denke jedenfalls nicht, dass es zwingend an deinem piko liegen muss, nur weil deine anderen Server das Problem nicht haben.

    Solche oder jedenfalls ähnliche Störungen bei den netcup Resolvern schon vor Jahren sind der Grund, warum seitdem keiner meiner Server mehr die netcup Resolver verwendet, sondern eigene - oder bei den größeren teils direkt auf dem Server installiertes Unbound.

    Bei mir waren die Störungen damals allerdings nur sporadisch. Sie traten teils stundenlang auf und waren dann irgendwann wie weggeblasen. Aber sie kamen immer wieder. Ich habe damals tagelang nach Ursachen für lästige Probleme gesucht (zeitweise laaaange Zeiten für einfache Seitenaufrufe im Serverpanel eines meiner Server) und bin irgendwann darauf gestossen, dass einer der netcup Resolver unzuverlässig war.

    Diese Ursache hatte ich damals zuerst gar nicht auf dem Radar, weil andere Server mit diesem Resolver zur gleichen Zeit nicht das geringste Problem hatten und auch zu anderen Zeiten nie dieses Problem zeigten. Also habe ich damals zunächst relativ schnell vermutet, dass es an dem betroffenen Server liegen muss. Aber nachdem ich absolut nichts finden konnte, habe ich letztlich testhalber die Resolver dann durch andere (damals Google) ersetzt und der Spuk war sofort vorbei. Keine Ahnung ob da nur irgendein bestimmtes Subnetz gelegentlich Verbindungsprobleme zu dem Resolver hatte (oder immer noch hat), ich habe es damals nicht weiter verfolgt.

    Vielen Dank für Eure Antworten!

    Zitat von NaN

    tcpdump -i eth0 -n host 46.38.225.230

    tcpdump hatte ich auf dem VPS nicht installiert und das apt install ging ohne DNS natürlich nicht. Da ich gestern Abend keine Lust/Zeit mehr hatte mich darum zu kümmern, habe ich es auf heute verschoben.

    Tja und heute geht die DNS-Auflösung wieder und die netcup Resolver antworten wie bisher.

    Ich habe mir gleich mal tcpdump installiert und warte nun, ob das Problem erneut auftritt.

    Dieses Thema setze ich erstmal (für mich) auf "erledigt" und öffne es mit einem fehlerhaften Paket-Dump falls es erneut auftritt.

    Code: tcpdump mit funktionierender Verbindung 23.11.2025
    # tcpdump -i eth0 -n host 46.38.225.230
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:43:26.797747 IP 1.2.3.4.33553 > 46.38.225.230.53: 53399+ A? netcupcup.de. (30)
12:43:26.797803 IP 1.2.3.4.33553 > 46.38.225.230.53: 40091+ AAAA? netcupcup.de. (30)
12:43:26.798060 IP 46.38.225.230.53 > 1.2.3.4.33553: 53399 1/0/0 A 202.61.232.190 (46)
12:43:26.798061 IP 46.38.225.230.53 > 1.2.3.4.33553: 40091 1/0/0 AAAA 2a03:4000:61:369a::18:1074 (58)

    Das Testen eines eigenen (lokalen) Resolvers steht auch schon auf der ToDo-Liste, muss aber aus zeitlichen Gründen noch warten.

    Zitat von tab

    ...seitdem keiner meiner Server mehr die netcup Resolver verwendet, sondern eigene - oder bei den größeren teils direkt auf dem Server installiertes Unbound...

    Warum unterscheidest Du in Deinem Satz zwischen "eigene Resolver" und "Unbound direkt auf größeren Servern"?

    Auf meiner ToDo-Liste steht das Testen von Bind9, PowerDNS und Unbound.

    Ist Unbound so ressourcenhungrig dass Du den nur auf größeren Servern verwendest und auf den anderen kleinere?

    Oder hast Du Dir auf einem VPS einen dicken DNS-Resolver installiert und bindest diesen mittels VLAN oder per VPN in deinem VPS-Verbund intern an? Was meinst Du mit "eigene Resolver".

    Zitat von Win98SE4ever

    Warum unterscheidest Du in Deinem Satz zwischen "eigene Resolver" und "Unbound direkt auf größeren Servern"?

    Auf meiner ToDo-Liste steht das Testen von Bind9, PowerDNS und Unbound.

    Ist Unbound so ressourcenhungrig dass Du den nur auf größeren Servern verwendest und auf den anderen kleinere?

    Oder hast Du Dir auf einem VPS einen dicken DNS-Resolver installiert und bindest diesen mittels VLAN oder per VPN in deinem VPS-Verbund intern an? Was meinst Du mit "eigene Resolver".

    Ich unterscheide es deshalb, weil die "eigenen Resolver" auf dafür dedizierten Serverchen laufen und nicht auf dem produktiven Server. Unbound ist aber an sich nicht besonders ressourcenhungrig, man kann das auch recht gut sparsam konfigurieren, wenn eben nicht mehrere andere Server mit dranhängen. Aber immerhin spart es nach meiner Einschätzung letztlich Zeit bei der Auflösung, wenn der Cache die Queries und Antworten mehrerer Server enthält. Es gibt da - zumindest bei mir - schon große Überschneidungen bei den Queries.

    Ist realistisch betrachtet aber auch mehr ein Fun-Projekt von mir, ursprünglich um mit dem Cloud VLAN Free etwas halbwegs sinnvolles anzustellen :). Und die Idee dazu kam damals hauptsächlich auch von den Problemen mit den netcup Resolvern und der Abneigung, Resolver von Google oder Cloudflare benutzen zu müssen.

    Ich benutze für die Resolver einen nano und einen piko. Der nano macht die Hauptarbeit, der piko ist nur zur Absicherung da. Die Resolver sind mit allen zu versogenden Servern über ein Cloud VLAN Free verbunden, über das die Queries und Antworten laufen. DNS-Queries "von außen" werden geblockt. Wenn ich mir die Auslastung des nano so anschaue, hätten es zwei pikos wohl auch getan. Solange beide nebenher noch fail2ban (nur für sshd) stemmen können ... ;) Das dürfte deutlich mehr Ressourcen beanspruchen. Aber der nano war halt gerade übrig und ich fahre meine Server auch ungern "auf Anschlag" bzw riskiere eine Überlastung, schon gar bei den Resolvern. Für alle Fälle könnte man auch noch z.B. Quad9 als dritten Resolver einbinden.

    Lokal installiertes Unbound haben derzeit nur mein Mailserver und mein amerikanischer "Gastserver". Beim Amerikaner würde es mit den VLAN in Nürnberg schwierig. :D