DNS-Rebinding-Schutz erfordert eine Auflösung zur Ausführungszeit

Eine Genehmigung für api.example.test ist keine Genehmigung für jede Adresse, auf die dieser Name später zeigt. Kann ein Agent eine authentifizierte HTTP-Anfrage stellen, verwandelt DNS-Rebinding eine veraltete Hostnamen-Entscheidung in einen Weg zu einem lokalen Dienst, einem Cloud-Metadatenendpunkt oder einer internen Steuerungsebene. Das Einfügen der Zugangsdaten kann dabei genau wie vorgesehen funktionieren. Die Entscheidung über das Ziel ist fehlgeschlagen.

Ich habe Teams erlebt, die sorgfältige Genehmigungsdialoge bauen und dann die HTTP-Bibliothek den Namen im letztmöglichen Moment auflösen lassen, ohne die Antwort zu prüfen. Diese Lücke übersieht man leicht, weil gewöhnliches DNS sich unauffällig verhält. Ein Angreifer braucht kein gewöhnliches DNS, das mitspielt. Er braucht einen Namen unter seiner Kontrolle, eine kurze Cache-Laufzeit und einen Client, der einen Hostnamen mit einem dauerhaften Ziel verwechselt.

Schutz vor DNS-Rebinding erfordert eine Auflösung zur Ausführungszeit. Lösen Sie den Namen unmittelbar vor dem Öffnen der Verbindung auf, prüfen Sie das vollständige Ergebnis, wählen Sie eine erlaubte Adresse und verbinden Sie sich genau mit dieser Adresse. Behalten Sie den ursprünglichen Hostnamen für HTTP und die TLS-Prüfung bei. Wiederholen Sie diesen Ablauf immer, wenn der Client eine weitere Verbindung öffnet, einer Weiterleitung folgt oder das Protokoll wechselt.

Die Genehmigung bezeichnet eine Zielklasse, nicht dauerhaft eine IP-Adresse

Ein Hostname ist eine Anweisung zur Auflösung, keine stabile Identität eines Netzwerkpartners. Das klingt kleinlich, bis ein Agent eine URL aus einem Issue, einem Build-Log, einer Tool-Antwort oder einem anderen Dienst erhält. Der Agent kann um Genehmigung bitten, reports.partner.test aufzurufen. Die genehmigende Person sieht ein plausibles öffentliches Ziel. Minuten später kann derselbe Name 127.0.0.1, eine IPv6-Loopback-Adresse oder eine Adresse liefern, die nur im Netzwerk des Rechners erreichbar ist.

Der übliche Rebinding-Ablauf hat zwei Phasen. In der ersten gibt der autoritative DNS-Server eine öffentliche Adresse zurück. Der Client oder Prüfer akzeptiert den Hostnamen, manchmal nach einer browserähnlichen Vorab-Anfrage. In der zweiten Phase ändert der Angreifer die Antwort und setzt darauf, dass Ablauf der Cache-Zeit, Neuverbindung, Weiterleitung, Wiederholung oder eine zweite Anfrage eine weitere Auflösung auslösen. Der Zieldienst sieht eine Anfrage von einem lokalen Rechner, dem Netzwerk-Firewalls oft mehr Zugriff gewähren als dem öffentlichen Internet.

Bei einem Agent-Gateway ist das Problem noch schärfer. Es kann ein Bearer-Token, Basic-Credentials oder einen eigenen Autorisierungsheader erst anhängen, nachdem eine Person die Aktion genehmigt hat. Prüft das Gateway den Agent-Prozess, aber nicht die Peer-Adresse, kann es echte Zugangsdaten an den falschen Ort schicken. Eine Anfrage an einen lokalen Verwaltungsdienst braucht die Zugangsdaten möglicherweise gar nicht. Der Angreifer kann die Anfrage allein dazu nutzen, dass der Rechner eine Antwort liest, die der Agent anschließend erhält.

Lösen Sie das nicht, indem Sie die zuerst aufgelöste IP-Adresse dauerhaft speichern. Öffentliche Dienste verwenden Lastverteilung, wechselnde Adressen und IPv6. Die sichere Aussage ist enger: Jede Verbindung muss eine Adresse verwenden, die zu Beginn dieser Verbindung die Prüfung bestanden hat. Eine frühere Genehmigung kann den Hostnamen und die Nutzung von Zugangsdaten erlauben. Sie rechtfertigt keine spätere Adresse aus einem gesperrten Netzwerk.

Unmittelbar vor dem Öffnen des Sockets auflösen

Die Reihenfolge der Schritte entscheidet, ob die Prüfung überhaupt etwas bedeutet. Lösen Sie den Hostnamen auf, validieren Sie die Resolver-Antwort, wählen Sie eine Adresse und übergeben Sie diese Adresse direkt an die Verbindungsroutine. Wenn Sie eine Adresse prüfen und anschließend eine bequeme API aufrufen, die den Hostnamen erneut auflöst, haben Sie ein Ziel geprüft und sich mit einem anderen verbunden.

Halten Sie während der gesamten Anfrage zwei Werte getrennt:

• origin_host ist der vom Nutzer genehmigte Hostname, den das Zertifikat abdecken muss.
• peer_ip ist die einzelne geprüfte Adresse, die für diesen Socket ausgewählt wurde.
• port ist der angeforderte Port, nachdem der Client seine Regeln für erlaubte Ports angewendet hat.
• scheme bestimmt, ob der Client TLS verlangt.

Bei HTTPS verbinden Sie den TCP-Socket mit peer_ip, senden aber origin_host als HTTP-Host-Header und verwenden origin_host für SNI und die Zertifikatsprüfung. Ein Zertifikat für die IP-Adresse ist kein Ersatz. Passt das Zertifikat nicht zum Hostnamen, muss die Anfrage fehlschlagen. Die Zertifikatsprüfung abzuschalten, um Adress-Pinning zu vereinfachen, ersetzt einen Routing-Fehler durch einen viel schlimmeren.

Eine minimale Verbindungsgrenze kann so aussehen:

origin_host = parse_url(request_url).host
answers = resolver.lookup_all(origin_host)
allowed = [ip for ip in answers if public_routable(ip)]
if allowed is empty:
    fail("DNS answer contains no permitted address")

peer_ip = choose_one(allowed)
socket = tcp_connect(peer_ip, request_port)
tls = tls_handshake(socket, server_name=origin_host, verify_name=origin_host)
send_http(tls, host_header=origin_host)

Die Skizze nennt absichtlich lookup_all. Eine Abfrage nach nur einer Adresse verdeckt einen häufigen Fehler: Der Resolver gibt sowohl eine erlaubte öffentliche IPv4-Adresse als auch eine IPv6-Loopback-Adresse zurück. Eine Bibliothek bevorzugt möglicherweise IPv6, obwohl die Anwendung nur IPv4 geprüft hat. Lehnen Sie den Hostnamen ab, sobald eine Antwort gesperrt ist, oder definieren Sie eine strenge Auswahlregel, die nur geprüfte Adressen an den Connector weitergibt. Gemischte Antworten abzulehnen ist leichter zu prüfen und gibt einem Angreifer weniger Spielraum, Verhalten beim parallelen Verbindungsaufbau auszunutzen.

Das Wort „unmittelbar“ ist wichtig. Lösen Sie vor dem Öffnen des Sockets auf, nicht wenn der Agent eine Anfrage entwirft, nicht wenn die Genehmigungskarte erscheint und nicht wenn der Nutzer Zugangsdaten speichert. Zwischen Auflösung und Verbindung bleibt ein kleiner Zeitraum, doch der Client hat die Adresse bereits ausgewählt und muss DNS für diesen Socket nicht erneut fragen.

Private IPv4-Filterung ist nur der erste Zaun

RFC 1918 reserviert IPv4-Bereiche für private Netzwerke. Dazu gehören die drei bekannten Blöcke 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16. Für einen internetfähigen Client müssen sie gesperrt sein. Diese Liste als vollständige Abwehr zu betrachten, ist jedoch ein häufiger und teurer Fehler.

Ein Zielfilter muss Adresskategorien ablehnen, die sich nicht sicher als öffentlich behandeln lassen. Sperren Sie mindestens Loopback-, nicht spezifizierte, Link-Local-, Multicast-, private und lokale IPv6-Adressen. Sperren Sie nach der Normalisierung auch IPv4-gemappte IPv6-Formen, denn ::ffff:127.0.0.1 wirkt praktisch weiterhin als Loopback. Behandeln Sie IPv6-Zonenkennungen für Remote-URLs als ungültig. Entscheiden Sie nicht anhand der Schreibweise über die Sicherheit. Parsen Sie die Adresse in ein binäres Format und klassifizieren Sie sie dort.

Für einige Bereiche braucht das Produkt eine ausdrückliche Entscheidung statt eines unbeabsichtigten Standards. Carrier-Grade-NAT-Adressen in 100.64.0.0/10 sind nicht global erreichbar. Dokumentations- und Benchmark-Bereiche sollten nicht als normale Produktionsziele erscheinen. Der IPv4-Link-Local-Bereich kann in einigen Cloud-Umgebungen Metadatendienste erreichen. IPv6-Link-Local-Adressen brauchen einen Interface-Bereich und sollten nie aus einer Anfrage für einen öffentlichen Hostnamen entstehen. Der sicherste Standard für ein externes Aktions-Gateway ist, nur gewöhnliche globale Unicast-Adressen zu erlauben, mit benannten Ausnahmen für einen separaten internen Bereitstellungsmodus.

Prüfen Sie keine Zeichenpräfixe. 127.1, 127.0.0.1, Ganzzahlformate, die ein großzügiger Parser akzeptiert, IPv6-Komprimierung und gemappte Formen machen das unzuverlässig. Parsen Sie den URL-Host entweder als DNS-Namen oder als IP-Literal. Ist er ein IP-Literal, klassifizieren Sie ihn direkt. Ist er ein DNS-Name, lösen Sie ihn auf und klassifizieren Sie jede zurückgegebene Adresse. Lehnen Sie fehlerhafte Namen vor der Auflösung ab.

Hier vermischen Teams auch öffentliches DNS mit öffentlicher Erreichbarkeit. Ein Resolver kann eine öffentliche Adresse liefern, die über einen Unternehmensproxy, ein VPN oder einen Split-Horizon-Netzwerkpfad geroutet wird. Die DNS-Antwort ist eine Eingabe, keine Zusage für die gesamte Route. Adressfilterung verhindert direkte Rebindings in offensichtliche lokale Bereiche. Netzwerkregeln für ausgehenden Verkehr müssen weiterhin Zugriffswege sperren, die der Host erreichen kann, die das Produkt aber nicht nutzen soll.

CNAMEs und gemischte Antworten brauchen eine Entscheidung

Ein CNAME macht einen Namen nicht sicher. Er delegiert die endgültige Antwort an einen anderen Namen, der sich ebenfalls ändern oder eine gemischte Menge von Antworten liefern kann. Der Resolver folgt dieser Kette normalerweise, bevor er der Anwendung A- und AAAA-Einträge gibt. Die Anwendung sollte daher die endgültigen Adressen beurteilen, die sie erhält. Stellt die Resolver-API die Kette bereit, protokollieren Sie sie zur Diagnose, aber machen Sie die Durchsetzung nicht davon abhängig, ob der erste Name vertraut aussah.

Ein starker Standard ist einfach: Liegt eine endgültige Antwort für einen angeforderten Hostnamen in einer gesperrten Kategorie, lehnen Sie die Anfrage ab. Das kann einen Dienst ablehnen, der neben einer öffentlichen Adresse eine unerreichbare private Adresse veröffentlicht. Diese Konfiguration erzeugt aber ohnehin unvorhersehbare Clients. Ein Gateway, das Zugangsdaten versendet, sollte den Dienstbetreiber bitten, den DNS-Eintrag zu korrigieren, statt stillschweigend eine passende Antwort auszuwählen.

Manche Teams bevorzugen die Regel „jede erlaubte Antwort verwenden“. Sie ist beliebt, weil damit mehr Integrationen funktionieren. Sie erzeugt aber schwer reproduzierbares Verhalten: Eine Resolver-Reihenfolge funktioniert, eine andere verbindet sich mit etwas Gesperrtem, und eine Happy-Eyeballs-Implementierung startet IPv6- und IPv4-Versuche zu unterschiedlichen Zeitpunkten. Wenn Sie diesen Weg wählen, darf die Verbindungsschicht nur die ausgewählten erlaubten Adressen erhalten und nie auf den ursprünglichen Hostnamen zurückfallen. Eine allgemeine HTTP-Bibliothek garantiert das oft nicht.

Protokollieren Sie genug Informationen, um eine Ablehnung erklären zu können. Das Anfrage-Log sollte ursprünglichen Hostnamen, Port, aufgelöste Adressmenge, gegebenenfalls ausgewählte Peer-Adresse, Richtlinienergebnis und eine Korrelationskennung der Anfrage enthalten. Protokollieren Sie keine Zugangsdaten oder Antwortinhalte, nur um die Fehlersuche bequemer zu machen. DNS-Sicherheitsfehler werden meist anhand der Adressliste allein verständlich.

Verbindungspools sind nur sicher, wenn sie den Peer bewahren

Eine wiederverwendete TLS-Verbindung führt keine neue DNS-Auflösung aus und braucht auch keine. Der Socket hat bereits beim Öffnen eine ausgewählte und geprüfte Peer-Adresse erhalten. Ein Client kann genau diese Verbindung für eine weitere Anfrage an dieselbe Origin wiederverwenden, sofern die normalen HTTP-Origin-Regeln und Zertifikatsprüfungen das erlauben.

Eine neue Verbindung ist etwas anderes. Pools verbergen oft Neuverbindungen nach einem Leerlauf-Timeout, einem Transportfehler, einem HTTP/2-Stream-Limit oder einer Änderung des Proxy-Zustands. Wenn der Pool das Betriebssystem erneut per Hostname verbinden lässt, öffnet er das Rebinding-Fenster. Platzieren Sie Resolver und Connector unterhalb des Pools, nicht neben der ersten Anfrage.

Beim Connection Coalescing ist Vorsicht nötig. HTTP/2 kann eine TLS-Verbindung für mehr als einen Hostnamen wiederverwenden, wenn das Zertifikat sie abdeckt und der Peer geeignet ist. Ein allgemeiner Browser kann diesen Kompromiss akzeptieren. Ein Aktions-Gateway sollte die Zielentscheidung für jede Origin ausdrücklich treffen. Nehmen Sie nicht an, dass ein für einen genehmigten Hostnamen geöffneter Socket eine Anfrage mit Zugangsdaten für einen anderen tragen darf, nur weil das Zertifikat beide Namen aufführt. Umfang der Genehmigung, HTTP-Autorität und Wiederverwendung der Verbindung sind getrennte Entscheidungen.

Wiederholungen haben dieselbe Form. Eine Wiederholung nach einem Verbindungsfehler ist ein neuer ausgehender Versuch. Lösen Sie erneut auf, klassifizieren Sie erneut, wählen Sie eine Adresse und öffnen Sie einen neuen Socket. Cachen Sie ein erlaubtes Ergebnis nie länger als die Verbindung, die es autorisiert hat. Gesperrte Ergebnisse dürfen Sie kurz cachen, um wiederholte Arbeit zu reduzieren, doch dieser Cache darf nicht zu einer ungeprüften Routing-Instanz werden.

Änderungen während eines Aufrufs lassen einen Angreifer keine bestehende TCP-Verbindung auf eine neue IP-Adresse verschieben. TCP hat seinen Peer bereits ausgewählt. Gefährlich ist der Codepfad, der eine Ersatzverbindung erzeugt, einer Weiterleitung folgt, ein Protokoll hochstuft oder nach der ersten Antwort eine weitere Anfrage stellt. Wer nur eine erfolgreiche Anfrage testet, übersieht die Pfade, die Produktions-Clients unter Last verwenden.

Weiterleitungen sind separate ausgehende Anfragen

Eine Weiterleitung ändert die Ziel-URI. Behandeln Sie sie als neue Aktion, auch wenn die HTTP-Bibliothek sie als Komfortfunktion bezeichnet. Parsen Sie den Wert von Location, lehnen Sie nicht unterstützte Schemas ab, lösen Sie den Hostnamen zur Ausführungszeit auf, prüfen Sie seine Antworten und kontrollieren Sie seinen Port vor dem Verbindungsaufbau. Das automatische Mitnehmen von Autorisierungsheadern über einen Origin-Wechsel hinweg ist ein eigener Fehler, der Zugangsdaten preisgeben kann. Entfernen Sie sie daher, sofern für die neue Origin keine eigene ausdrückliche Autorisierungsentscheidung vorliegt.

Begrenzen Sie Weiterleitungen auf eine kleine feste Anzahl. Ein Rebinding-Testserver kann Namen und Antworten bei jedem Sprung wechseln, und unbegrenzte Weiterleitungen machen aus einer einfachen ausgehenden Aktion eine undurchsichtige Kette. Protokollieren Sie jeden Sprung mit Quell-Origin, Ziel-Origin, Adressmenge, ausgewähltem Peer, Statuscode und dem Grund für eine mögliche Ablehnung.

DNS-Prüfungen gehören auch zu leicht zu übersehenden Protokollfunktionen. Ein HTTP-Proxy ändert, wer die erste TCP-Verbindung erhält. Prüfen Sie daher die Proxy-Adresse und legen Sie dann fest, was der Proxy auflösen darf. Ein CONNECT-Tunnel kann die Hostnamen-Auflösung sonst in eine Komponente verschieben, die nicht dieselben Prüfungen ausführt. Webhooks, Callback-URLs, Object-Storage-Endpunkte und Paketregistrys brauchen dieselbe Behandlung, wenn ein Agent ihr Ziel beeinflussen kann.

Eine Regel, die private DNS-Antworten sperrt, macht beliebige URLs nicht sicher. Sie hindert einen öffentlichen Server nicht daran, einen gefährlichen Befehl zu geben, eine riesige Antwort zurückzugeben oder zu einem genehmigten, aber bösartigen Dienst weiterzuleiten. Die Abwehr von DNS-Rebinding ist eine Grenze. Sie sollte präzise genug sein, damit niemand sie mit einer allgemeinen Richtliniensprache verwechselt.

Resolver und Connector als Einheit testen

Unit-Tests, die 127.0.0.1 an einen Adressklassifizierer übergeben, sind nötig, aber nicht ausreichend. Der Fehler entsteht, wenn der Client einen Hostnamen durch mehrere Schichten reicht und eine davon ungeschützt auflöst. Ihre Tests müssen das tatsächliche Socket-Ziel beobachten.

Richten Sie eine kontrollierte autoritative Testzone mit einem Namen wie flip.test ein. Bei der ersten Auflösung liefert sie einen öffentlichen Testendpunkt zurück, der eine harmlose Anfrage aufzeichnet. Bei der nächsten Auflösung liefert sie eine gesperrte Adresse. Erzwingen Sie dann eine zweite Verbindung, indem Sie den ersten Endpunkt nach seiner Antwort schließen. Das erwartete Ergebnis ist keine erfolgreiche zweite Anfrage mit einer Warnung im Log. Der Connector muss ablehnen, bevor er einen Socket zur gesperrten Adresse öffnet.

Verwenden Sie eine Testmatrix, die immer nur eine Bedingung ändert:

1. Geben Sie eine öffentliche IPv4-Antwort zurück, dann nach einer niedrigen TTL eine IPv4-Loopback-Antwort.
2. Geben Sie eine erlaubte IPv4-Adresse zusammen mit ::1 in derselben Antwortmenge zurück.
3. Geben Sie einen CNAME zurück, dessen endgültige Antwort von öffentlich auf IPv6 Unique Local wechselt.
4. Geben Sie eine Weiterleitung zu einem zweiten Hostnamen zurück, der zu einer gesperrten Adresse auflöst.
5. Schließen Sie eine gepoolte Verbindung und prüfen Sie, dass die Wiederholung eine neue Validierung erhält.

Fügen Sie an der Netzwerkgrenze eine Assertion hinzu. Ein Fake-Connector sollte die numerische IP und den Port aufzeichnen, die er erhält. Der Test muss fehlschlagen, wenn er einen Hostnamen erhält, denn dann kann nach der Validierung noch ein anderer Resolver laufen. Platzieren Sie bei Integrationstests einen Listener auf dem gesperrten Loopback-Port und stellen Sie sicher, dass er null Verbindungen aufzeichnet. Eine abgelehnte Anfrage, die den Listener erreicht, hat die Grenze bereits überschritten, die Sie schützen wollten.

Tests mit kurzen TTLs sind wichtig, weil sie Caches an unerwarteten Stellen sichtbar machen: im Anwendungs-Resolver, Betriebssystem, Proxy, Sprach-Laufzeitsystem oder in der HTTP-Bibliothek. Testen Sie sowohl einen Resolver, der die TTL berücksichtigt, als auch einen, der sofort eine geänderte Antwort liefert. Sicherheit darf nicht davon abhängen, dass ein bestimmter Cache langsam oder schnell ist.

Genehmigung und Adressvalidierung beantworten verschiedene Fragen

Eine Genehmigung pro Sitzung beantwortet die Frage „Welcher Agent-Prozess darf während dieses Laufs handeln?“. Eine Genehmigung pro Aufruf beantwortet „Verdient diese Nutzung von Zugangsdaten jetzt eine menschliche Entscheidung?“. Die DNS-Validierung beantwortet „Welcher Netzwerkpartner darf diese Verbindung erhalten?“. Wenn Sie das in einer Genehmigungsabfrage zusammenfassen, wirkt die Oberfläche einfacher, verschleiert aber eine wichtige Änderung dessen, was die Person genehmigt hat.

Zeigen Sie Hostnamen und Port bei einer Genehmigung an, behaupten Sie aber nicht, ein Hostname sei eine unveränderliche Peer-Adresse. Die Implementierung sollte die Adresse zur Ausführungszeit prüfen, unabhängig davon, ob die Person Sekunden zuvor eine Abfrage gesehen hat. Ist das Ergebnis gesperrt, verweigern Sie die Aktion und nennen Sie Hostnamen und klassifizierte Adresskategorie. Ein Nutzer kann einen fehlerhaften DNS-Eintrag korrigieren. Eine unsichtbare Rebinding-Race kann er nicht sinnvoll genehmigen.

Sallyports Tresortor, Sitzungsautorisierung und Genehmigungen für Zugangsdaten pro Aufruf steuern, wer eine Aktion auslösen darf und wann eine Person sie bestätigen muss. Sein HTTP-Aktionspfad braucht dennoch dieselbe Zielprüfung zur Ausführungszeit. Ein Tresor, der einem Agenten nie ein Geheimnis gibt, sollte dieses Geheimnis auch nicht an eine DNS-Antwort senden, der der Nutzer nicht vertrauen wollte.

Fügen Sie für dieses eng umrissene Problem keine frei formbare Regel-Engine hinzu. Das Kernverhalten kann deterministisch bleiben: Sperren Sie nicht öffentliche Antworten für externe HTTP-Aktionen, lösen Sie zum Zeitpunkt des Verbindungsaufbaus auf, binden Sie den Socket an die ausgewählte Adresse und prüfen Sie jede neue Verbindung erneut. Eine kleine Regel mit klar testbarer Grenze bleibt leichter korrekt als eine Seite voller Ausnahmen, die niemand erklären kann.

Logs müssen das tatsächlich verwendete Ziel zeigen

Ein Audit-Eintrag mit nur einem Hostnamen kann nach einem Vorfall die entscheidende Frage nicht beantworten: Wohin ging der Socket? Speichern Sie für jede erlaubte Verbindung sowohl die angeforderte Origin als auch die ausgewählte Peer-Adresse. Speichern Sie für abgelehnte Versuche die zurückgegebene Antwortmenge und die Klassifizierung, die zur Ablehnung führte. Halten Sie den Zeitstempel nah an der Verbindungserstellung, damit Ermittler ihn mit dem Verhalten des Resolvers korrelieren können.

Beanspruchen Sie keine Sicherheit, die das Log nicht belegen kann. Erhält die HTTP-Bibliothek nur einen Hostnamen, kann der Audit-Eintrag sagen, dass die Anwendung einen Hostnamen angefordert hat. Er kann die numerische Peer-Adresse nicht beweisen. Reparieren Sie den Connector, bevor Sie den Audit-Eintrag verbessern. Die Belege müssen aus der Schicht stammen, die den Socket kontrolliert.

Für eine manipulationssichere Audit-Spur nehmen Sie DNS-Entscheidungsdatensätze in dieselbe Reihenfolge wie Autorisierungs-, Verbindungs-, Weiterleitungs- und Antwortereignisse auf. Sallyport erstellt seine Sessions- und Activity-Journale aus einem schreibblinden, verschlüsselten und hashverketteten Audit-Log, und sp audit verify kann diese Kette offline über Geheimtext prüfen. Das hilft nur, wenn der Aktionsdatensatz das aufgelöste Ziel enthält und nicht bloß einen beruhigenden, aber unvollständigen Hostnamen.

Beginnen Sie bei der Connection Factory. Finden Sie jeden Pfad, der einen Hostnamen akzeptiert, lassen Sie ihn eine validierte numerische Peer-Adresse zurückgeben und sorgen Sie dafür, dass die Socket-API rohe Hostnamen ablehnt. Sobald diese Invariante gilt, werden kurze TTLs und wechselnde Antworten zu gewöhnlichen Testfällen statt zu einer Sicherheitsüberraschung beim nächsten Wiederverbinden.