Einen Proxy und einen DNS-Server auf einem Docker-Host zu betreiben, verbindet ihre DNS-Pfade nicht. Drei getrennte Beziehungen sind relevant:

  • Netzwerkerreichbarkeit. Getrennte Compose-Projekte haben normalerweise getrennte Standardnetzwerke. Legen Sie die Dienste in ein geeignetes gemeinsames Netzwerk, entweder innerhalb eines Projekts oder über ein ausdrücklich gemeinsam genutztes Netzwerk zwischen Projekten.
  • Diensterkennung. Der eingebettete DNS eines benutzerdefinierten Docker-Netzwerks kann Containernamen auflösen. Damit kann eine Anwendung einen Nachbarn entdecken; es wählt diesen Nachbarn jedoch nicht automatisch als DNS-Resolver aus.
  • Resolver-Auswahl. Bestimmen Sie den Resolver, der im Proxy-Container verwendet wird. Das Feld dns von Compose nimmt DNS-Serveradressen an. Ein Name wie dns.local, der in einer Anwendung aufgelöst wird, ist deshalb noch kein gültiger Wert für dieses Feld.

Verfolgen Sie die Abfrage vom Proxy-Container bis zu seiner konfigurierten Resolver-Adresse. Bestätigen Sie eine Route und einen DNS-Listener an dieser Adresse. Host-Port 53 zu veröffentlichen schafft einen Zugangspfad auf der Host-Seite; es sagt Containern nicht, dass sie ihn nutzen sollen. Container in einem gemeinsamen Netzwerk können stattdessen direkt kommunizieren.

Wenn die Konfiguration die Adresse des DNS-Containers referenziert, halten Sie sie unter kompatibler IPAM-Konfiguration stabil. Eine dynamisch zugewiesene Adresse, die aus dem Container von gestern kopiert wurde, kann bei der Neuerstellung fehlschlagen. Prüfen Sie auch den Upstream-Pfad des Resolvers: unbeantwortete Abfragen an ihn selbst zurückzuleiten erzeugt einen anderen Fehler als ein nicht erreichbarer Resolver.

Schließlich ist zu klären, wer das Ziel auflöst. Ein HTTP-Proxy, der einen CONNECT-Namen auflöst, kann diesen Container-Pfad nutzen; ein SOCKS-Client, der lokal auflöst, möglicherweise nicht. Eine Host-Abfrage beweist die Route des Hosts, nicht die des Proxy-Prozesses.

Ähnliche Artikel