Temporary failure resolving 'de.archive.ubuntu.com'

  • Die UBUNTU Installation scheitert wegen "Temporary failure resolving 'de.archive.ubuntu.com'". Ich hab im Forum auch die Empfehlung gefunden, mich dazu an den Support zu wenden.
    Hab ich gemacht, aber der kann mich auch nicht unterstützen, da die "Konfiguration Ihrer Dienste und Pfflege Ihrer Verantwortung unterliegt".

    Kann schon sein - aber ich komme halt nicht weiter.

    Kann mir jemand weiterhelfen ? Ich bin kein Superprofi und will eigentlich nur meinen V Server unter UBUNTU nutzen.Oder soll ich ein anderes Image verwenden ?

  • Die UBUNTU Installation scheitert wegen "Temporary failure resolving 'de.archive.ubuntu.com'". Ich hab im Forum auch die Empfehlung gefunden, mich dazu an den Support zu wenden.
    Hab ich gemacht, aber der kann mich auch nicht unterstützen, da die "Konfiguration Ihrer Dienste und Pfflege Ihrer Verantwortung unterliegt".

    Kann schon sein - aber ich komme halt nicht weiter.

    Kann mir jemand weiterhelfen ? Ich bin kein Superprofi und will eigentlich nur meinen V Server unter UBUNTU nutzen.Oder soll ich ein anderes Image verwenden ?

    Das *könnte* an den netcup Resolven liegen, die per Default in den Images konfiguriert sind. Versuch mal, da die Google oder Cloudflare Resolver zu benutzen.

  • Wenn du die Installation über ein DVD Image durchführst, kannst du deine eigenen Netzwerkeinstellungen tätigen, statt DHCP zu nutzen.

    Hierfür verwendest du die Daten aus dem Netzwerk-Tab des SCP.


    Wenn du nach DNS Servern gefragt wirst, gibst du entweder 8.8.8.8 für Google oder 1.1.1.1 für Cloudflare ein.

    Sofern du IPv6 konfigurieren möchtest, kannst du auch DNS Server für IPv6 hinterlegen 2001:4860:4860::8888 für Google.

  • Hier unser Ansible-Playbook für Ubuntu 20.04

  • Ich hab heute mit unbound in einem lxd Container herumgespielt, einfach um ein bisschen Erfahrung damit zu sammeln. Ich hab es u.a. auf dem Host Betriebssystem als Nameserver eingerichtet, also der RS fragt seinen Container nach der Namensauflösung.


    Und siehe da: Das Problem mit "Temporary failure resolving 'de.archive.ubuntu.com'" tritt dann ebenfalls auf. Deshalb hab ich mir gedacht, schaue ich mir das mal näher an.


    Folgendes hab ich dann herausgefunden: nutzt man "archive.ubuntu.com" anstatt "de.archive.ubuntu.com", dann funktioniert alles problemlos. Ebenso hilft es, einen anderen DNS Server zu verwenden, z.B. google oder cloudflare. Aber das wussten wir ja schon.


    Aber weiter:

    Rufe ich auf meinem RS "dig de.archive.ubuntu.com" auf, dann scheitert der Aufruf.

    Rufe ich "dig @10.42.42.208 de.archive.ubuntu.com", dann funktioniert es - obwohl der gleiche Nameserver gefragt wird. =O

    Dann hab ich systemd-resolved deaktiviert und den Nameserver direkt in die resolv.conf eingefügt. Ergebnis: Funktioniert.


    Es muss also was mit systemd-resolved zu tun haben. Da hab ich mir dann die Konfiguration näher angesehen und vor allem unser aller Lieblingsthema: DNSSEC. Ich hab DNSSEC von "allow-downgrade" auf "no" gestellt. Und siehe da: Es funktioniert sofort.

    Also ist es ein offenbar ein DNSSEC Problem. Nur bin ich jetzt mit meinem Latein am Ende. Wo suche ich weiter? Was kann ich noch testen?

  • Ich habe vor kurzem auch mit unbound ein wenig experimentiert.

    Ja, systemd-resolved sollte auf Ubuntu deaktiviert werden beim Einsatz von unbound. War bei mir auch nötig. Beide kommen sich sonst u.U. in die Quere

    Ich habe dann deshalb auch den symlink /etc/resolv.conf gelöscht und als echte Datei angelegt mit dem Inhalt nameserver 127.0.0.1

  • Also jedesmal hatte ich das nicht, auch nicht meistens, aber ab und an schon und auf jeden Fall öfter als mir lieb war.

    Da scheint doch diesbezüglich was im Argen zu liegen bei netcup, Bei den domains gibt es ja auch immer wieder ähnlich gelagerte Probleme.

    Wie wäre es netcup? Geht das doch mal intensiver an, findet raus, woran diese prinzipiellen Probleme liegen und löst sie mal grundlegend und nicht immer nur für den Einzelfall. (Wäre den Kunden sogar sicher lieber als die nächste neue Servergeneration ;))

  • Ich hab gerade mal einen Server neuinstalliert wo das schonmal aufgetreten ist und es ist genau so wieder passiert.


    Hab mal ein Support Ticket geschrieben und werde berichten!

    Ich habe auch den Eindruck, es hängt vom Server ab, oder vielleicht auch vom Subnetz ?(:/ . Ich habe zwei Server mit Debian 10, einen RS und einen VPS, installiert mit den entsprechenden netcup Debian 10 minimal Image und den Rest (Keyhelp) da draufgesetzt: Bei beiden bisher keinerlei Probleme mit den netcup Nameservern!

    Dann noch ein weiterer RS, genauso installiert. Der hatte massive Probleme mit den netcup MailDNS-Servern! Mit Google und Cloudflare war alles gut. Mittlerweile habe ich das Upgrade auf Debian 11 gemacht, weiterhin keine Probleme.

    Der letzte RS, installiert mit dem netcup Image Debian 11 minimal und Keyhelp da draufgesetzt. Das gab ebenfalls recht massive Probleme mit den netcup MailDNS-Servern, die trust anchor Telemetrie ist regelmäßig schiefgegangen und DNSSEC-Abfragen ebenso. Dann habe ich den Stub-Server rausgeschmissen und Google und Cloudflare als DNS-Server eingetragen. Das funktioniert danach seither auch problemlos.

  • tab  foto-andreas Nameserver sind keine Mailserver.

    Ja, ist mir bekannt, streiche 2x Mailserver und ersetze durch 2xNameserver. Oder noch besser, ersetze durch DNS-Server oder Resolver, leider ist der Sprachgebrauch da auch nicht immer eindeutig. Probleme mit DNSSEC machen bei netcup leider beide, sowohl die DNS-Server als auch die Nameserver. Was dann letztlich dazu geführt hat, dass ich für wichtige Mail- und Serverdomains nur noch Nameserver eines anderen Anbieters verwende und für die vom netcup DNS-Server Problem betroffenen Server eben externe, öffentliche DNS-Server (Google, Cloudflare, was mir eigentlich nicht besonders gefällt). Schade, dass es notwendig ist, aber der Aufwand dafür hält sich in Grenzen.

  • Ich kenne mich leider mit DNSSEC nicht genug aus. Was führt denn da zum Scheitern der Abfrage? Wenn die Anfrage auf de.archive.ubuntu.com scheitert, dann sehe ich das im Log bei mir lokal:

    Code
    Mar  5 10:39:17 serv0 systemd-resolved[2865966]: DNSSEC validation failed for question tudos.de IN DNSKEY: no-signature
    Mar  5 10:39:17 serv0 systemd-resolved[2865966]: DNSSEC validation failed for question ubuntu.mirror.tudos.de IN A: no-signature
    Mar  5 10:39:17 serv0 systemd-resolved[2865966]: DNSSEC validation failed for question ubuntu.mirror.tudos.de IN SOA: no-signature
    Mar  5 10:39:17 serv0 systemd-resolved[2865966]: DNSSEC validation failed for question ubuntu.mirror.tudos.de IN AAAA: no-signature

    Welcher Server auf dem Weg ist es denn? Mein lokaler Resolver? Oder der Nameserver von "tudos.de"? Oder irgendwas dazwischen?

  • Tja, der Support zeigt sich mal wieder von seiner besten Seite:

    Code
    vielen Dank für Ihre Anfrage.
    
    Sie besitzen bei uns einen virtuellen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung.


    Hab gesagt ich akzeptiere das nicht und das Ticket soll eskaliert werden da es sehrwohl die Laufzeitumgebung von netcup (DNS Server + Image) betrifft.


    Mal sehen…

  • Hab nun eine kompetente Antwort vom Support erhalten (vielen Dank!).

    Und zwar:

    Ich denke wenn das wirklich nicht in der Macht von netcup liegt das zu beheben (klar, man könnte das Image anpassen...) kann ich aber damit leben.


    Wir stellen also fest:

    IPv6: Schmerzen

    DNSSEC: Schmerzen


    So ist das halt in der IT ¯\_(ツ)_/¯