Warum eine private Route 53-Zone für öffentliche Namen NXDOMAIN liefert

Private Route 53-Zonen ersetzen die Antwort für einen Namen, statt sie mit dem öffentlichen Datensatz zusammenzuführen, und das überrascht Menschen im ungünstigsten Moment. Fügen Sie einen internen Datensatz für api.example.net in einer privaten Zone für example.net hinzu, verknüpfen Sie die Zone mit einer VPC, und jeder andere Name unter diesem Elternteil wird nun allein aus der privaten Zone beantwortet. Ein Client, der gestern www.example.net erreichen konnte, erhält heute eine negative Antwort. Der folgende Rundgang beginnt bei dieser fehlgeschlagenen Abfrage und arbeitet sich nach außen zur Zone vor, die sie beantwortet hat.

Beginnen Sie bei der Abfrage, nicht bei der Konsole

Reproduzieren Sie den Fehler auf dem Client, der ihn gemeldet hat, und notieren Sie den genauen Namen und Datensatztyp. Ein Name, der für A fehlschlägt, kann sich für AAAA weiterhin auflösen, und ein Browser, der einen zwischengespeicherten Namen erneut abfragt, verbirgt, welcher der beiden kaputt ist. Führen Sie die Abfrage zweimal aus: einmal über den Resolver, den der Client tatsächlich nutzt, und einmal mit einer Ablaufverfolgung, die ihn umgeht.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

Der zweite Befehl ist der wichtige. Seine Statuszeile und der Autoritätsabschnitt benennen die Zone, die die Antwort erzeugt hat, sodass Sie eine negative Antwort aus der privaten Zone von einer Zeitüberschreitung, einem blockierten Port oder einem Resolver unterscheiden können, der die Abfrage nie erhalten hat. resolvectl zeigt, welcher Upstream gefragt wurde, und das ist oft nicht der Resolver, von dem Sie annahmen, das VPN habe ihn übergeben.

Wenn die verfolgte Abfrage die öffentliche Adresse zurückgibt, die normale aber nicht, ist der öffentliche Datensatz intakt und die private Ansicht antwortet. Dieser eine Vergleich entscheidet, welche Hälfte des Rests dieser Seite für Sie gilt.

Lesen Sie, welche Zone geantwortet hat

Eine Antwort mit NXDOMAIN und der SOA der privaten Zone im Autoritätsabschnitt ist eine endgültige Antwort dieser Zone, kein fehlgeschlagener Lookup. Route 53 Resolver wählte die private gehostete Zone, weil ihr Name passte, fand dann keinen Datensatz des angeforderten Typs, und das dokumentierte Verhalten ist, die negative Antwort zurückzugeben, statt die Frage an öffentliches DNS weiterzuleiten.

Die Auswahl folgt der Spezifität. Bei mehreren überlappenden privaten Namespaces gewinnt die spezifischste passende Zone, und ein breiterer privater Elternteil bekommt keine zweite Chance für einen Namen, den die gewählte Unterzone nicht hat. Weiterleitungsregeln fügen eine weitere Ebene hinzu, denn eine domänenspezifische Resolver-Regel kann die Zuordnung der privaten gehosteten Zone überstimmen. Zählen Sie die Zuordnungen und Regeln auf, bevor Sie folgern, eine Zone sei leer.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Beide Befehle benötigen Anmeldedaten für das Konto, dem die Zone gehört, und der zweite benötigt die Zonen-ID aus dem ersten. Ersetzen Sie sie durch Ihre eigene ID; der Platzhalter oben ist bewusst keine echte.

Warum die private Zone gewinnt

Die Zuordnung ist es, die die Zone für eine VPC sichtbar macht, und der Resolver in dieser VPC wendet sie an. Eine private Zone, die nicht der VPC zugeordnet ist, aus der der Client-Datenverkehr kommt, hat überhaupt keine Wirkung, während eine Zuordnung zur falschen VPC eine private Antwort für die falsche Population erzeugt. Prüfen Sie die Zuordnungsliste, bevor Sie Datensätze bearbeiten, denn eine Zone kann korrekt und trotzdem unsichtbar sein.

Überlappende Namespaces sind die zweite Fehlerquelle. Eine private Zone für example.net und eine private Zone für api.example.net passen beide auf eine API-Abfrage, und die spezifischere antwortet. Das ist nützlich, wenn Sie einen engen internen Namespace wollen, und gefährlich, wenn der engen Zone ein Datensatz fehlt, den die breitere hat. Die Hinweise zu privaten gehosteten Zonen in der Route 53-Dokumentation beschreiben sowohl das Durchfallverhalten als auch den Regelvorrang, und sie lohnen die Lektüre, bevor Sie eine zweite überlappende Zone hinzufügen.

Nichts davon ändert die öffentliche Zone. Öffentliche Resolver beantworten die öffentlichen Datensätze weiterhin korrekt, und deshalb wirkt der Fehler für alle außerhalb der VPC wie ein Client-Problem.

Wählen Sie den Namespace, bevor Sie Datensätze hinzufügen

Wenn nur eine neue Familie interner Dienste private Namen braucht, geben Sie ihr eine eigene private Subdomain und lassen Sie den öffentlichen Elternteil in Ruhe. Ein Name wie internal.example.net kann www.example.net nicht überdecken, und der Wirkungsradius eines fehlenden Datensatzes bleibt auf Namen beschränkt, die Sie für diesen Zweck erfunden haben. Der Preis ist, dass vorhandene URLs und Zertifikate möglicherweise nicht zum neuen Namen passen.

Wenn öffentliche und private Nutzer denselben Hostnamen behalten müssen, ist Split-View-DNS das unterstützte Design, und es verlangt, dass Sie die Datensätze in jeder Ansicht ausdrücklich pflegen. Eine breite private Zone mit einem einzigen Datensatz darin bewahrt die öffentlichen Abhängigkeiten unter dieser Zone nicht; sie ersetzt sie durch eine Zone mit einem Datensatz.

Erfassen Sie die Namen, die eine Anwendung tatsächlich aufruft, bevor Sie eine Client-Population auf die private Ansicht richten. Login-Hosts, Hosts für statische Assets, Weiterleitungsziele und API-Endpunkte brechen zuerst, und sie sind meist über die Datensätze mehrerer Teams verteilt.

Verfolgen Sie den Resolver-Pfad, dann die Route

Ein Laptop sieht die private Ansicht nur, wenn seine Abfragen den Resolver erreichen, der die Zuordnung hat. Das Bearbeiten einer hosts-Datei auf dem VPN-Server veröffentlicht nichts an verbundene Clients, und ein Client mit öffentlichem Resolver erhält weiterhin öffentliche Antworten, solange der Tunnel steht. Bestätigen Sie die Resolver-Adresse, die der Client erhalten hat, und wiederholen Sie dann die Abfrage vom Client statt vom Server.

Sobald der Name auflöst, prüfen Sie den Pfad zur zurückgegebenen Adresse als eigenen Schritt, zum Beispiel mit ip route get gegen die Adresse, die die Abfrage zurückgegeben hat. Eine korrekte private Antwort ohne Route zur Adresse ist ein Routingproblem, und eine Antwort über einen fehlenden Datensatz ist ein DNS-Ansichtsproblem; beide als ein Problem zu behandeln führt zu Korrekturen, die nicht halten. Lassen Sie die Prüfungen von TLS-Hostname und Zertifikat des Dienstes unverändert, denn eine private Adresse ändert, wohin die Verbindung geht, und nichts daran, welches Zertifikat gültig ist.

Schließen Sie ab, indem Sie Zone, Zuordnung, Resolver und die geprüften Namen im Änderungsvermerk festhalten. Die nächste Person, die einen Datensatz hinzufügt, weiß dann, welcher Namespace für diese Client-Population maßgeblich ist.