Zum Hauptinhalt springen

← Zurück zur Kategorie

DNS-Namensauflösung bei getaddrinfo EAI_AGAIN prüfen

Zugriff & Authentifizierung Auth-Service Timeouts & Down-Status Konfiguration 3 Fragen
Kurzantwort

Prüfen Sie zuerst die Namensauflösung aus der betroffenen Laufzeitumgebung. getaddrinfo EAI_AGAIN weist meist auf einen temporären DNS-/Resolver-Fehler, eine fehlerhafte Resolver-Konfiguration oder einen blockierten DNS-Pfad hin. Wenn die Auflösung instabil bleibt, DNS-/Plattformteam einbinden.

Problem

Ein Portal- oder Backend-Dienst in der Kategorie connectivity-dns kann einen FQDN nicht auflösen und meldet dabei getaddrinfo EAI_AGAIN. Dadurch wirken API Management Developer Portal oder Open Data Portal im Produktivsystem nicht erreichbar oder als „Down“.

Symptome / Erkennungsmerkmale
  • Zugriff auf ein Portal oder einen Backend-Endpunkt schlägt fehl.
  • Die Anwendung meldet getaddrinfo EAI_AGAIN.
  • Ein FQDN wird zeitweise oder gar nicht aufgelöst.
  • Health-Checks oder Statusanzeigen zeigen den Dienst als „Down“.
  • Fehler tritt in der betroffenen Laufzeitumgebung, nicht nur auf dem eigenen Arbeitsplatz, auf.
Wahrscheinliche Ursachen
  • Temporärer DNS-Resolver-Timeout oder nicht erreichbarer Resolver (inferred): EAI_AGAIN ist typischerweise mit vorübergehenden Problemen bei der Namensauflösung verbunden, zum Beispiel wenn ein Resolver nicht antwortet oder zu langsam ist.
  • Fehlerhafte oder unvollständige Resolver-Konfiguration in der betroffenen Laufzeitumgebung (inferred): Wenn Nameserver, Suchdomänen oder Cluster-DNS falsch konfiguriert sind, kann die Auflösung von FQDNs sporadisch fehlschlagen.
  • Netzwerkpfad, Firewall oder NetworkPolicy blockiert DNS-Anfragen (inferred): DNS funktioniert nur, wenn die betroffene Umgebung den Resolver auch erreichen darf. Blockaden auf UDP/TCP 53 oder im internen Netzwerkpfad führen zu Lookup-Fehlern.
  • Fehlender, falscher oder nicht erreichbarer DNS-Record für den Ziel-FQDN (inferred): Wenn der A- oder AAAA-Record fehlt, geändert wurde oder nur in einem anderen DNS-Scope verfügbar ist, schlagen Lookups in bestimmten Umgebungen fehl.
  • Temporärer lokaler Cache- oder Zustandsfehler im Dienst, Container oder Resolver (inferred): Ein Neustart kann bei transienten Zuständen helfen, wenn DNS-Daten oder Resolver-Zustände im Prozess hängen geblieben sind.
Vorgehen / Lösungsschritte
  1. Fehler und Zielhostname bestätigen — Prüfen Sie, welcher Hostname betroffen ist und ob der Fehler aus der betroffenen Umgebung reproduzierbar ist. Notieren Sie, ob der Fehler dauerhaft oder nur sporadisch auftritt. Checks: Hostname und Fehlertext aus der Anwendung ablesen; Mehrfach testen, ob der Fehler stabil oder wechselnd auftritt
  2. Namensauflösung aus der betroffenen Umgebung testen — Führen Sie DNS-Tests direkt aus der Umgebung aus, in der der Fehler auftritt, nicht nur vom Arbeitsplatz oder aus einem anderen Netzsegment. Checks: nslookup <hostname>; dig <hostname>; getent hosts <hostname>
  3. Resolver-Konfiguration und Erreichbarkeit prüfen — Stellen Sie sicher, dass die Umgebung den richtigen DNS-Resolver verwendet und dieser erreichbar ist. Prüfen Sie zusätzlich, ob DNS-Verkehr durch Netzwerkregeln blockiert wird. Checks: Resolver-Konfiguration der Laufzeitumgebung prüfen; DNS-Server oder Cluster-DNS auf Erreichbarkeit prüfen; Firewall-, Proxy- oder NetworkPolicy-Regeln für DNS-Anfragen prüfen
  4. FQDN und DNS-Records verifizieren — Prüfen Sie, ob der Ziel-FQDN korrekt ist und ob der erwartete DNS-Record vorhanden ist. Achten Sie auf Änderungen, abgelaufene Einträge oder Split-DNS-Szenarien. Checks: Hostname auf Tippfehler oder veraltete Konfiguration prüfen; A- und AAAA-Records verifizieren; Split-DNS, Forwarder oder interne DNS-Zonen berücksichtigen
  5. Temporäre Zustände zurücksetzen — Wenn die Auflösung nur zeitweise fehlschlägt, setzen Sie den Zustand des betroffenen Dienstes zurück und testen Sie erneut. Das kann einen lokalen Cache oder einen hängenden Resolver-Zustand auflösen. Checks: Betroffenen Dienst, Container oder Pod neu starten; DNS-Cache oder Resolver-Zustand in der betroffenen Laufzeit zurücksetzen, sofern vorgesehen; Anschließend die Namensauflösung erneut testen
  6. Bei anhaltendem Fehler an DNS- oder Plattformteam eskalieren — Wenn die Namensauflösung weiterhin fehlschlägt, geben Sie die Ergebnisse der DNS-Tests, die Resolver-Konfiguration und die beobachtete Fehlerfrequenz an die zuständigen Teams weiter. Checks: Ergebnisse von nslookup, dig und getent bereitstellen; Resolver-Logs oder Plattform-Logs anfordern; Prüfen lassen, ob Forwarder, Split-DNS oder Proxy-Konfiguration angepasst werden müssen
Validierung
  • Der betroffene Hostname wird aus der betroffenen Umgebung konsistent aufgelöst.
  • nslookup, dig oder getent hosts liefern stabile Ergebnisse ohne EAI_AGAIN.
  • Der Portal- oder Backend-Dienst erreicht den Zielhost wieder ohne Down-Status.
  • Wiederholte Health-Checks laufen ohne DNS-Fehler durch.
Eskalation / Grenzen
  • Eskalieren Sie an das DNS- oder Plattformteam, wenn der Resolver nicht erreichbar ist oder interne DNS-Records geprüft werden müssen.
  • Eskalieren Sie, wenn der Fehler trotz korrekter Konfiguration und Neustart weiter auftritt.
  • Geben Sie bei der Eskalation die DNS-Testausgaben und den betroffenen Laufzeitkontext mit.
  • Diese Anleitung ist für DNS-/Resolver-Probleme gedacht und behebt keine reinen Anwendungs-, TLS- oder Authentifizierungsfehler.
  • EAI_AGAIN ist ein generischer Hinweis auf eine temporäre Namensauflösungsstörung; die konkrete Ursache muss über den Prüfungspfad eingegrenzt werden.
  • Die genauen Befehle und Prüfpfade können je nach Umgebung, Container-Setup oder Cluster-DNS variieren.
  • Ohne dokumentierte Root Cause bleibt die Lösung als Prüfanleitung und nicht als garantiertes Fix-Verfahren.

Fragen & Antworten​

Zugehörige Fragen (3)
Warum schlägt die Namensauflösung eines FQDN mit getaddrinfo EAI_AGAIN fehl?
Kurzantwort

Prüfen Sie zuerst die Namensauflösung aus der betroffenen Laufzeitumgebung. getaddrinfo EAI_AGAIN weist meist auf einen temporären DNS-/Resolver-Fehler, eine fehlerhafte Resolver-Konfiguration oder einen blockierten DNS-Pfad hin. Wenn die Auflösung instabil bleibt, DNS-/Plattformteam einbinden.

Vorgehen
  1. Fehler und Zielhostname bestätigen — Prüfen Sie, welcher Hostname betroffen ist und ob der Fehler aus der betroffenen Umgebung reproduzierbar ist. Notieren Sie, ob der Fehler dauerhaft oder nur sporadisch auftritt. Checks: Hostname und Fehlertext aus der Anwendung ablesen; Mehrfach testen, ob der Fehler stabil oder wechselnd auftritt
  2. Namensauflösung aus der betroffenen Umgebung testen — Führen Sie DNS-Tests direkt aus der Umgebung aus, in der der Fehler auftritt, nicht nur vom Arbeitsplatz oder aus einem anderen Netzsegment. Checks: nslookup <hostname>; dig <hostname>; getent hosts <hostname>
  3. Resolver-Konfiguration und Erreichbarkeit prüfen — Stellen Sie sicher, dass die Umgebung den richtigen DNS-Resolver verwendet und dieser erreichbar ist. Prüfen Sie zusätzlich, ob DNS-Verkehr durch Netzwerkregeln blockiert wird. Checks: Resolver-Konfiguration der Laufzeitumgebung prüfen; DNS-Server oder Cluster-DNS auf Erreichbarkeit prüfen; Firewall-, Proxy- oder NetworkPolicy-Regeln für DNS-Anfragen prüfen
  4. FQDN und DNS-Records verifizieren — Prüfen Sie, ob der Ziel-FQDN korrekt ist und ob der erwartete DNS-Record vorhanden ist. Achten Sie auf Änderungen, abgelaufene Einträge oder Split-DNS-Szenarien. Checks: Hostname auf Tippfehler oder veraltete Konfiguration prüfen; A- und AAAA-Records verifizieren; Split-DNS, Forwarder oder interne DNS-Zonen berücksichtigen
  5. Temporäre Zustände zurücksetzen — Wenn die Auflösung nur zeitweise fehlschlägt, setzen Sie den Zustand des betroffenen Dienstes zurück und testen Sie erneut. Das kann einen lokalen Cache oder einen hängenden Resolver-Zustand auflösen. Checks: Betroffenen Dienst, Container oder Pod neu starten; DNS-Cache oder Resolver-Zustand in der betroffenen Laufzeit zurücksetzen, sofern vorgesehen; Anschließend die Namensauflösung erneut testen
  6. Bei anhaltendem Fehler an DNS- oder Plattformteam eskalieren — Wenn die Namensauflösung weiterhin fehlschlägt, geben Sie die Ergebnisse der DNS-Tests, die Resolver-Konfiguration und die beobachtete Fehlerfrequenz an die zuständigen Teams weiter. Checks: Ergebnisse von nslookup, dig und getent bereitstellen; Resolver-Logs oder Plattform-Logs anfordern; Prüfen lassen, ob Forwarder, Split-DNS oder Proxy-Konfiguration angepasst werden müssen
Validierung
  • Der betroffene Hostname wird aus der betroffenen Umgebung konsistent aufgelöst.
  • nslookup, dig oder getent hosts liefern stabile Ergebnisse ohne EAI_AGAIN.
  • Der Portal- oder Backend-Dienst erreicht den Zielhost wieder ohne Down-Status.
  • Wiederholte Health-Checks laufen ohne DNS-Fehler durch.
Eskalation / Grenzen
  • Eskalieren Sie an das DNS- oder Plattformteam, wenn der Resolver nicht erreichbar ist oder interne DNS-Records geprüft werden müssen.
  • Eskalieren Sie, wenn der Fehler trotz korrekter Konfiguration und Neustart weiter auftritt.
  • Geben Sie bei der Eskalation die DNS-Testausgaben und den betroffenen Laufzeitkontext mit.
Wie prüfe ich DNS-Resolver und NetworkPolicy bei Namensauflösungsfehlern?
Kurzantwort

Prüfen Sie zuerst die Namensauflösung aus der betroffenen Laufzeitumgebung. getaddrinfo EAI_AGAIN weist meist auf einen temporären DNS-/Resolver-Fehler, eine fehlerhafte Resolver-Konfiguration oder einen blockierten DNS-Pfad hin. Wenn die Auflösung instabil bleibt, DNS-/Plattformteam einbinden.

Vorgehen
  1. Fehler und Zielhostname bestätigen — Prüfen Sie, welcher Hostname betroffen ist und ob der Fehler aus der betroffenen Umgebung reproduzierbar ist. Notieren Sie, ob der Fehler dauerhaft oder nur sporadisch auftritt. Checks: Hostname und Fehlertext aus der Anwendung ablesen; Mehrfach testen, ob der Fehler stabil oder wechselnd auftritt
  2. Namensauflösung aus der betroffenen Umgebung testen — Führen Sie DNS-Tests direkt aus der Umgebung aus, in der der Fehler auftritt, nicht nur vom Arbeitsplatz oder aus einem anderen Netzsegment. Checks: nslookup <hostname>; dig <hostname>; getent hosts <hostname>
  3. Resolver-Konfiguration und Erreichbarkeit prüfen — Stellen Sie sicher, dass die Umgebung den richtigen DNS-Resolver verwendet und dieser erreichbar ist. Prüfen Sie zusätzlich, ob DNS-Verkehr durch Netzwerkregeln blockiert wird. Checks: Resolver-Konfiguration der Laufzeitumgebung prüfen; DNS-Server oder Cluster-DNS auf Erreichbarkeit prüfen; Firewall-, Proxy- oder NetworkPolicy-Regeln für DNS-Anfragen prüfen
  4. FQDN und DNS-Records verifizieren — Prüfen Sie, ob der Ziel-FQDN korrekt ist und ob der erwartete DNS-Record vorhanden ist. Achten Sie auf Änderungen, abgelaufene Einträge oder Split-DNS-Szenarien. Checks: Hostname auf Tippfehler oder veraltete Konfiguration prüfen; A- und AAAA-Records verifizieren; Split-DNS, Forwarder oder interne DNS-Zonen berücksichtigen
  5. Temporäre Zustände zurücksetzen — Wenn die Auflösung nur zeitweise fehlschlägt, setzen Sie den Zustand des betroffenen Dienstes zurück und testen Sie erneut. Das kann einen lokalen Cache oder einen hängenden Resolver-Zustand auflösen. Checks: Betroffenen Dienst, Container oder Pod neu starten; DNS-Cache oder Resolver-Zustand in der betroffenen Laufzeit zurücksetzen, sofern vorgesehen; Anschließend die Namensauflösung erneut testen
  6. Bei anhaltendem Fehler an DNS- oder Plattformteam eskalieren — Wenn die Namensauflösung weiterhin fehlschlägt, geben Sie die Ergebnisse der DNS-Tests, die Resolver-Konfiguration und die beobachtete Fehlerfrequenz an die zuständigen Teams weiter. Checks: Ergebnisse von nslookup, dig und getent bereitstellen; Resolver-Logs oder Plattform-Logs anfordern; Prüfen lassen, ob Forwarder, Split-DNS oder Proxy-Konfiguration angepasst werden müssen
Validierung
  • Der betroffene Hostname wird aus der betroffenen Umgebung konsistent aufgelöst.
  • nslookup, dig oder getent hosts liefern stabile Ergebnisse ohne EAI_AGAIN.
  • Der Portal- oder Backend-Dienst erreicht den Zielhost wieder ohne Down-Status.
  • Wiederholte Health-Checks laufen ohne DNS-Fehler durch.
Eskalation / Grenzen
  • Eskalieren Sie an das DNS- oder Plattformteam, wenn der Resolver nicht erreichbar ist oder interne DNS-Records geprüft werden müssen.
  • Eskalieren Sie, wenn der Fehler trotz korrekter Konfiguration und Neustart weiter auftritt.
  • Geben Sie bei der Eskalation die DNS-Testausgaben und den betroffenen Laufzeitkontext mit.
Was tun, wenn ein Portal oder Backend wegen DNS-Problemen als Down erscheint?
Kurzantwort

Prüfen Sie zuerst die Namensauflösung aus der betroffenen Laufzeitumgebung. getaddrinfo EAI_AGAIN weist meist auf einen temporären DNS-/Resolver-Fehler, eine fehlerhafte Resolver-Konfiguration oder einen blockierten DNS-Pfad hin. Wenn die Auflösung instabil bleibt, DNS-/Plattformteam einbinden.

Vorgehen
  1. Fehler und Zielhostname bestätigen — Prüfen Sie, welcher Hostname betroffen ist und ob der Fehler aus der betroffenen Umgebung reproduzierbar ist. Notieren Sie, ob der Fehler dauerhaft oder nur sporadisch auftritt. Checks: Hostname und Fehlertext aus der Anwendung ablesen; Mehrfach testen, ob der Fehler stabil oder wechselnd auftritt
  2. Namensauflösung aus der betroffenen Umgebung testen — Führen Sie DNS-Tests direkt aus der Umgebung aus, in der der Fehler auftritt, nicht nur vom Arbeitsplatz oder aus einem anderen Netzsegment. Checks: nslookup <hostname>; dig <hostname>; getent hosts <hostname>
  3. Resolver-Konfiguration und Erreichbarkeit prüfen — Stellen Sie sicher, dass die Umgebung den richtigen DNS-Resolver verwendet und dieser erreichbar ist. Prüfen Sie zusätzlich, ob DNS-Verkehr durch Netzwerkregeln blockiert wird. Checks: Resolver-Konfiguration der Laufzeitumgebung prüfen; DNS-Server oder Cluster-DNS auf Erreichbarkeit prüfen; Firewall-, Proxy- oder NetworkPolicy-Regeln für DNS-Anfragen prüfen
  4. FQDN und DNS-Records verifizieren — Prüfen Sie, ob der Ziel-FQDN korrekt ist und ob der erwartete DNS-Record vorhanden ist. Achten Sie auf Änderungen, abgelaufene Einträge oder Split-DNS-Szenarien. Checks: Hostname auf Tippfehler oder veraltete Konfiguration prüfen; A- und AAAA-Records verifizieren; Split-DNS, Forwarder oder interne DNS-Zonen berücksichtigen
  5. Temporäre Zustände zurücksetzen — Wenn die Auflösung nur zeitweise fehlschlägt, setzen Sie den Zustand des betroffenen Dienstes zurück und testen Sie erneut. Das kann einen lokalen Cache oder einen hängenden Resolver-Zustand auflösen. Checks: Betroffenen Dienst, Container oder Pod neu starten; DNS-Cache oder Resolver-Zustand in der betroffenen Laufzeit zurücksetzen, sofern vorgesehen; Anschließend die Namensauflösung erneut testen
  6. Bei anhaltendem Fehler an DNS- oder Plattformteam eskalieren — Wenn die Namensauflösung weiterhin fehlschlägt, geben Sie die Ergebnisse der DNS-Tests, die Resolver-Konfiguration und die beobachtete Fehlerfrequenz an die zuständigen Teams weiter. Checks: Ergebnisse von nslookup, dig und getent bereitstellen; Resolver-Logs oder Plattform-Logs anfordern; Prüfen lassen, ob Forwarder, Split-DNS oder Proxy-Konfiguration angepasst werden müssen
Validierung
  • Der betroffene Hostname wird aus der betroffenen Umgebung konsistent aufgelöst.
  • nslookup, dig oder getent hosts liefern stabile Ergebnisse ohne EAI_AGAIN.
  • Der Portal- oder Backend-Dienst erreicht den Zielhost wieder ohne Down-Status.
  • Wiederholte Health-Checks laufen ohne DNS-Fehler durch.
Eskalation / Grenzen
  • Eskalieren Sie an das DNS- oder Plattformteam, wenn der Resolver nicht erreichbar ist oder interne DNS-Records geprüft werden müssen.
  • Eskalieren Sie, wenn der Fehler trotz korrekter Konfiguration und Neustart weiter auftritt.
  • Geben Sie bei der Eskalation die DNS-Testausgaben und den betroffenen Laufzeitkontext mit.