Linden Consulting.
Architecture

Route53 SERVFAIL: DNS-Delegierungs- und Konfigurationsfehler diagnostizieren

2026-05-27 · 9 Min. Lesezeit

Alles ist ausgefallen. Ihre Anwendung, Ihre API, Ihr CDN — alles unerreichbar. Die Health Checks schlagen an, der Bereitschaftsdienst wird alarmiert, und wenn Sie versuchen, Ihre Domain aufzulösen, erhalten Sie dies:

$ dig example.com

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43521
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

SERVFAIL. Keine Antwort, keine Authority, nichts. Der DNS-Resolver hat versucht, Ihre Records zu finden, und ist gescheitert. Ihre Domain existiert effektiv nicht mehr im Internet.

DNS-Ausfälle sind einzigartig schmerzhaft, weil sie alles gleichzeitig betreffen. Anders als der Ausfall eines einzelnen Services macht ein DNS-Ausfall Ihre gesamte Infrastruktur unerreichbar — jeden Service, jeden API-Endpoint, jedes statische Asset. Ich habe erlebt, wie SERVFAIL-Antworten bei Unternehmen mehrstündige Ausfälle verursachten, die redundante Infrastruktur über mehrere Regionen hatten — alles wegen einer einzigen DNS-Fehlkonfiguration, die die Namensauflösung zum Erliegen brachte.

Hier ist der systematische Ansatz, den ich zur Diagnose von Route53-SERVFAIL-Fehlern verwende.

Schritt 1: Ausfall bestätigen und Umfang ermitteln

Stellen Sie zunächst fest, ob der Ausfall global ist oder auf bestimmte Resolver beschränkt:

# Gegen Googles öffentlichen DNS testen
dig @8.8.8.8 example.com

# Gegen Cloudflares DNS testen
dig @1.1.1.1 example.com

# Gegen Route53s eigenen Resolver testen
dig @ns-1234.awsdns-12.org example.com

Wenn alle öffentlichen Resolver SERVFAIL zurückgeben, aber die direkte Abfrage des Route53-Nameservers die korrekte Antwort liefert, liegt das Problem in der Delegierungskette. Wenn selbst der Route53-Nameserver fehlschlägt, liegt das Problem in Ihrer Hosted-Zone-Konfiguration.

Prüfen Sie auch verschiedene Record-Typen:

dig example.com A
dig example.com AAAA
dig example.com MX
dig www.example.com CNAME

Wenn nur bestimmte Record-Typen fehlschlagen, haben Sie möglicherweise eine spezifische Record-Fehlkonfiguration statt eines Delegierungsproblems.

Schritt 2: Delegierungskette nachverfolgen

DNS-Auflösung ist eine Kette von Delegierungen von den Root-Servern bis zu Ihren Nameservern. Ein Bruch an irgendeiner Stelle dieser Kette verursacht SERVFAIL. Verfolgen Sie die Kette:

dig +trace example.com

Dies zeigt jeden Schritt der Delegierung. Suchen Sie den Punkt, an dem die Verfolgung abbricht:

.                       518400  IN  NS  a.root-servers.net.
com.                    172800  IN  NS  a.gtld-servers.net.
example.com.            172800  IN  NS  ns-1234.awsdns-12.org.
example.com.            172800  IN  NS  ns-567.awsdns-34.net.
example.com.            172800  IN  NS  ns-890.awsdns-56.co.uk.
example.com.            172800  IN  NS  ns-123.awsdns-78.com.

Wenn die in der Verfolgung angezeigten NS-Records nicht mit den Nameservern Ihrer Route53 Hosted Zone übereinstimmen, ist das Ihr Problem.

Ursache 1: NS-Record-Delegierungs-Mismatch

Dies ist die häufigste Ursache für Route53-SERVFAIL. Die NS-Records bei Ihrem Domain-Registrar müssen exakt mit den NS-Records in Ihrer Route53 Hosted Zone übereinstimmen.

Prüfen Sie, was Ihre Hosted Zone erwartet:

aws route53 get-hosted-zone \
  --id Z1234567890ABC \
  --query 'DelegationSet.NameServers'

[
    "ns-1234.awsdns-12.org",
    "ns-567.awsdns-34.net",
    "ns-890.awsdns-56.co.uk",
    "ns-123.awsdns-78.com"
]

Nun prüfen Sie, was der Registrar eingetragen hat:

dig example.com NS +short

Wenn diese nicht übereinstimmen, aktualisieren Sie die NS-Records beim Registrar entsprechend der Route53 Hosted Zone. Dieser Mismatch tritt häufig auf, wenn:

  • Sie eine Hosted Zone gelöscht und neu erstellt haben (neue Zone bekommt neue NS-Records)
  • Sie eine Domain zwischen AWS-Konten verschoben haben
  • Die NS-Records nach dem initialen Route53-Setup nie aktualisiert wurden

Verwenden Sie die Route53 test-dns-answer API zur Verifizierung:

aws route53 test-dns-answer \
  --hosted-zone-id Z1234567890ABC \
  --record-name example.com \
  --record-type A

{
    "Nameserver": "ns-1234.awsdns-12.org",
    "RecordName": "example.com",
    "RecordType": "A",
    "RecordData": ["203.0.113.42"],
    "ResponseCode": "NOERROR",
    "Protocol": "UDP"
}

Wenn dies die korrekte Antwort zurückgibt, öffentliche Resolver aber nicht, liegt das Problem definitiv in der Delegierung.

Ursache 2: Mehrere Hosted Zones für dieselbe Domain

AWS erlaubt das Erstellen mehrerer Hosted Zones für denselben Domain-Namen. Jede bekommt einen anderen Satz NS-Records. Wenn Sie Records in einer Hosted Zone bearbeiten, der Registrar aber auf eine andere zeigt, haben Ihre Änderungen keine Wirkung.

Listen Sie alle Hosted Zones für Ihre Domain auf:

aws route53 list-hosted-zones-by-name \
  --dns-name example.com \
  --query 'HostedZones[?Name==`example.com.`].{
    Id: Id,
    Name: Name,
    RecordCount: ResourceRecordSetCount,
    Private: Config.PrivateZone
  }'

Wenn Sie mehrere öffentliche Hosted Zones sehen, identifizieren Sie, auf welche die NS-Records des Registrars zeigen. Die anderen sind verwaist und sollten aufgeräumt werden, um Verwirrung zu vermeiden.

Prüfen Sie die Records in jeder Zone:

aws route53 list-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --query 'ResourceRecordSets[?Type==`A` || Type==`CNAME`]'

Ursache 3: DNSSEC-Validierungsfehler

Wenn Sie DNSSEC-Signierung für Ihre Hosted Zone aktiviert haben, verursacht ein Mismatch zwischen dem DS-Record beim Registrar und dem DNSKEY in Ihrer Zone SERVFAIL bei allen DNSSEC-validierenden Resolvern.

Prüfen Sie, ob DNSSEC aktiviert ist:

aws route53 get-dnssec \
  --hosted-zone-id Z1234567890ABC

Verifizieren Sie, dass der DS-Record beim Registrar übereinstimmt:

# Prüfen, welche DNSSEC-Records die übergeordnete Zone hat
dig example.com DS +short

# Prüfen, womit Ihre Zone signiert
dig example.com DNSKEY +short @ns-1234.awsdns-12.org

Häufige DNSSEC-Fehlerszenarien:

  • DS-Record wurde beim Registrar hinzugefügt, bevor DNSSEC in Route53 aktiviert wurde
  • DNSSEC wurde in Route53 deaktiviert, aber der DS-Record bleibt beim Registrar
  • KSK (Key Signing Key) wurde rotiert, aber der DS-Record nicht aktualisiert

Um DNSSEC zu deaktivieren, wenn es Probleme verursacht (Notfall-Fix):

# Zuerst den DS-Record beim Registrar entfernen
# Dann die Signierung in Route53 deaktivieren
aws route53 disable-hosted-zone-dnssec \
  --hosted-zone-id Z1234567890ABC

Entfernen Sie immer den DS-Record beim Registrar, bevor Sie DNSSEC in Route53 deaktivieren. In der falschen Reihenfolge verursacht dies SERVFAIL, weil Resolver den DS-Record sehen und gültige DNSSEC-Signaturen erwarten.

Ursache 4: Subdomain-Delegierung mit fehlenden NS-Records

Wenn Sie eine Subdomain (wie api.example.com) an eine andere Hosted Zone delegieren, muss die übergeordnete Zone NS-Records haben, die auf die Nameserver der untergeordneten Zone zeigen.

Prüfen Sie die übergeordnete Zone auf Delegierung:

aws route53 list-resource-record-sets \
  --hosted-zone-id Z_PARENT_ZONE \
  --query 'ResourceRecordSets[?Name==`api.example.com.` && Type==`NS`]'

Wenn es keine NS-Records für die Subdomain in der übergeordneten Zone gibt, wird die Subdomain nicht aufgelöst. Erstellen Sie sie:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z_PARENT_ZONE \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "NS",
        "TTL": 300,
        "ResourceRecords": [
          {"Value": "ns-111.awsdns-11.org"},
          {"Value": "ns-222.awsdns-22.net"},
          {"Value": "ns-333.awsdns-33.co.uk"},
          {"Value": "ns-444.awsdns-44.com"}
        ]
      }
    }]
  }'

Ursache 5: Private Hosted Zone nicht mit VPC verknüpft

Private Hosted Zones lösen nur innerhalb von VPCs auf, die explizit mit ihnen verknüpft sind. Wenn Ihre Anwendung in einer VPC läuft, die nicht verknüpft ist, geben DNS-Abfragen SERVFAIL zurück.

VPC-Verknüpfungen prüfen:

aws route53 get-hosted-zone \
  --id Z_PRIVATE_ZONE \
  --query 'VPCs'

[
    {
        "VPCRegion": "us-east-1",
        "VPCId": "vpc-abc123"
    }
]

Wenn die VPC Ihrer Anwendung nicht in dieser Liste steht, verknüpfen Sie sie:

aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z_PRIVATE_ZONE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-def456

Für Cross-Account-Zugriff auf private Hosted Zones benötigen Sie zuerst eine Autorisierung:

# Im Konto, das die Hosted Zone besitzt
aws route53 create-vpc-association-authorization \
  --hosted-zone-id Z_PRIVATE_ZONE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-def456

# Im Konto, das die VPC besitzt
aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z_PRIVATE_ZONE \
  --vpc VPCRegion=us-east-1,VPCId=vpc-def456

Ursache 6: Health-Check-basiertes Routing mit allen Zielen unhealthy

Wenn Sie Route53 Health Checks mit Failover- oder gewichtetem Routing verwenden und alle Ziele unhealthy sind, hängt das Route53-Verhalten von der Einstellung "Evaluate Target Health" ab.

Prüfen Sie Ihre Health Checks:

aws route53 list-health-checks \
  --query 'HealthChecks[*].{
    Id: Id,
    Type: HealthCheckConfig.Type,
    FQDN: HealthCheckConfig.FullyQualifiedDomainName,
    IPAddress: HealthCheckConfig.IPAddress
  }'

# Health-Check-Status abrufen
aws route53 get-health-check-status \
  --health-check-id abc-123-def \
  --query 'HealthCheckObservations[*].{
    Region: Region,
    StatusReport: StatusReport.Status
  }'

Wenn alle Health Checks fehlschlagen und Sie Failover-Routing haben:

  • Wenn sowohl Primary als auch Secondary unhealthy sind, gibt Route53 den Primary-Record zurück (Fail-Open-Verhalten)
  • Wenn Sie gewichtetes Routing mit allen Records unhealthy haben und EvaluateTargetHealth true ist, gibt Route53 möglicherweise NODATA zurück (kein SERVFAIL, aber trotzdem keine Antwort)

Überprüfen Sie Ihre Routing-Policy:

aws route53 list-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --query 'ResourceRecordSets[?Name==`example.com.` && Type==`A`]'

Ursache 7: Alias-Record zeigt auf gelöschte Ressource

Alias-Records, die auf gelöschte Ressourcen zeigen (wie einen terminierten ELB oder eine gelöschte CloudFront-Distribution), können Auflösungsfehler verursachen.

Alias-Records auflisten:

aws route53 list-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --query 'ResourceRecordSets[?AliasTarget!=`null`].{
    Name: Name,
    Type: Type,
    AliasTarget: AliasTarget.DNSName,
    HostedZoneId: AliasTarget.HostedZoneId
  }'

Für jedes Alias-Ziel überprüfen Sie, ob die Ressource noch existiert:

# Prüfen, ob ein ELB existiert
dig dualstack.my-elb-1234567890.us-east-1.elb.amazonaws.com

# Prüfen, ob eine CloudFront-Distribution aktiv ist
aws cloudfront get-distribution \
  --id E1234567890ABC \
  --query 'Distribution.Status'

Wenn ein Alias-Ziel gelöscht wurde, aktualisieren Sie entweder den Record auf die neue Ressource oder entfernen Sie ihn komplett.

Ursache 8: TTL-Propagierungsverzögerungen

Nach Behebung eines DNS-Problems sehen Sie möglicherweise immer noch SERVFAIL von einigen Resolvern aufgrund von negativem Caching. Resolver cachen SERVFAIL-Antworten (negative TTL ist typischerweise 300 Sekunden, variiert aber je nach Resolver).

Prüfen Sie den SOA-Record für die negative Cache-TTL:

dig example.com SOA

Die letzte Zahl im SOA-Record ist die Minimum-TTL, die das negative Caching beeinflusst:

example.com.  900  IN  SOA  ns-1234.awsdns-12.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Die 86400 am Ende bedeutet, dass negative Antworten von manchen Resolvern bis zu 24 Stunden gecacht werden können. Nach Behebung des zugrunde liegenden Problems müssen Sie möglicherweise warten, bis dieser Cache abläuft, oder Sie können bestimmte Resolver-Caches leeren:

# Google Public DNS Cache leeren
# Besuchen: https://developers.google.com/speed/public-dns/cache

# Cloudflare Cache leeren
# Besuchen: https://1.1.1.1/purge-cache/

Prävention und Best Practices

Löschen und erstellen Sie niemals eine Hosted Zone neu, ohne die NS-Records beim Registrar zu aktualisieren. Wenn Sie eine Zone neu erstellen müssen, aktualisieren Sie sofort den Registrar auf die neuen NS-Records.

Überwachen Sie die DNS-Auflösung extern. Route53 Health Checks können Endpoints überwachen, aber sie überwachen nicht Ihre eigene DNS-Auflösung. Verwenden Sie einen externen Monitoring-Service, der Ihre Domain von mehreren Standorten aus auflöst.

Halten Sie DNSSEC-Operationen geskriptet und getestet. DNSSEC-Schlüsselrotation ist fehleranfällig bei manueller Durchführung. Automatisieren Sie sie und testen Sie den Prozess zuerst mit einer Nicht-Produktions-Domain.

Dokumentieren Sie Ihre DNS-Architektur. Pflegen Sie ein Diagramm, das zeigt, welche Hosted Zones existieren, welche delegiert sind und welche VPCs mit privaten Zones verknüpft sind:

# Schnelles Audit: alle Hosted Zones auflisten
aws route53 list-hosted-zones \
  --query 'HostedZones[*].{
    Name: Name,
    Id: Id,
    Private: Config.PrivateZone,
    RecordCount: ResourceRecordSetCount
  }'

Setzen Sie TTLs angemessen. Niedrigere TTLs (60-300 Sekunden) für Records, die möglicherweise Notfall-Änderungen benötigen. Höhere TTLs (3600+) für stabile Records, um das Abfragevolumen zu reduzieren.

Verwenden Sie Route53 Health Checks mit Failover-Routing für kritische Records, damit unhealthy Endpoints automatisch umgangen werden.

Wann Sie Hilfe holen sollten

DNS-Probleme, die der obigen Diagnose widerstehen, beinhalten meist komplexe Delegierungsketten über mehrere Registrare und DNS-Anbieter, DNSSEC-Probleme bei Domain-Transfers oder Split-Horizon-DNS-Interaktionen zwischen privaten und öffentlichen Hosted Zones. Da DNS-Ausfälle alles gleichzeitig betreffen, ist schnelle Expertenhilfe entscheidend. Wir helfen Teams beim Design, Audit und der Fehlerbehebung von Route53-Konfigurationen. Wenn Ihre Domain Auflösungsfehler hat oder Sie diese mit einer ordentlichen DNS-Architekturüberprüfung verhindern möchten, kontaktieren Sie uns für eine kostenlose Beratung. Wir verfolgen Ihre gesamte Delegierungskette und identifizieren jede Schwachstelle.

Brauchen Sie Hilfe mit Ihrer AWS-Infrastruktur?

Buchen Sie ein kostenloses 30-Minuten-Gespräch.

Kostenloses Erstgespräch buchen