So sieht die Meldung aus
$ curl -I https://shop.example.com
curl: (6) Could not resolve host: shop.example.comHäufige Ursachen
- Der Hostname ist falsch geschrieben, oder der Eintrag existiert noch nicht, z. B. nach einer neuen Domain, einer neuen Subdomain oder einer DNS-Migration.
- Diese Maschine nutzt einen Resolver, der ausfällt oder veraltete Daten hat, während andere den Eintrag sehen.
- Der Eintrag existiert nur in einer anderen Zone oder im internen DNS, nicht im öffentlichen DNS.
/etc/hostsoder eine Suchdomain überschreibt oder verändert den Namen.- Der Server hat gar kein funktionierendes DNS (siehe „Temporary failure in name resolution“).
Prüfen
- Was sagt der System-Resolver? Den nutzt curl
getent hosts shop.example.com - Was sagt das öffentliche DNS?
- Haben die autoritativen Server den Eintrag?
dig shop.example.com +trace +short - Gibt es eine Überschreibung in hosts?
grep -n 'example' /etc/hosts
Lösung
- Die Schreibweise des Hostnamens im Befehl, in der Konfiguration oder in der URL prüfen.
- Zeigt das öffentliche DNS keinen Eintrag, ihn beim DNS-Anbieter anlegen und warten, bis die TTL einer negativen Antwort abgelaufen ist.
- Hat das öffentliche DNS den Eintrag, nur diese Maschine scheitert, den lokalen Resolver reparieren (
resolvectl status) oder seinen Cache leeren:sudo resolvectl flush-caches. - Klappt es mit einer IP, mit
curl --resolve shop.example.com:443:203.0.113.10 https://shop.example.comDNS vom Webserver trennen. - Falsche Zeilen aus
/etc/hostsentfernen und die Suchdomain inresolvectl statusprüfen.
Häufige Fragen
dig funktioniert, curl nicht. Warum?
dig fragt DNS direkt, curl nutzt den System-Resolver, der auch /etc/hosts liest und einen eigenen Cache hat. Vergleiche mit getent hosts.
Wie lange, bis ein neuer Eintrag überall funktioniert?
Das hängt von der TTL und von zwischengespeicherten negativen Antworten ab. Siehe das TTL-Tool und den Beitrag zur DNS-Propagation.