DNS-Port-Guide: Namensauflösung auf Port 53

Wenn ein Client eine Domäne erreichen muss, fragt er einen Resolver nach Datensätzen wie A, AAAA, CNAME, MX, TXT, NS oder SRV. Der Resolver antwortet möglicherweise aus dem Cache oder durchläuft die DNS-Hierarchie durch Root-, TLD- und autorisierende Server, bis er den Datensatz findet.

Die meisten Client-Anfragen verwenden UDP-Port 53, da die Anfrage und Antwort klein sind. DNS kann zu TCP wechseln, wenn die Antworten zu groß sind, wenn es zu Kürzungen kommt, wenn DNSSEC die Antwortgröße erhöht oder wenn Server Zonenübertragungen und andere Vorgänge durchführen, die einen zuverlässigen Stream erfordern.

UDP 53 ist der gängige Pfad für die alltägliche DNS-Auflösung. Durch das Blockieren werden normalerweise normale Suchvorgänge unterbrochen. TCP 53 ist für eine vollständige DNS-Bereitstellung nicht optional: Es unterstützt große Antworten, Fallback von verkürzten UDP-Antworten, DNSSEC-lastige Antworten und Zonenübertragungen zwischen autorisierten Servern.

Eine Firewall-Regel, die UDP 53 zulässt, aber TCP 53 blockiert, kann zu zeitweiligen Ausfällen führen, die schwer zu diagnostizieren sind. Kleine Einträge funktionieren möglicherweise, während größere DNSSEC-, TXT- oder E-Mail-bezogene Antworten fehlschlagen.

Ein autoritativer DNS-Server veröffentlicht Datensätze für von Ihnen kontrollierte Domänen. Es sollte über das Internet erreichbar sein, wenn es öffentliche Zonen bedient, aber es sollte nur für diese Zonen autorisierend antworten und keine offene Rekursion ermöglichen.

Ein rekursiver Resolver führt Suchvorgänge für Clients durch. Öffentliche rekursive Resolver müssen für diese Rolle entworfen und geschützt werden. Interne Resolver sollten normalerweise nur für vertrauenswürdige Netzwerke, VPN-Clients oder bestimmte Anwendungsumgebungen antworten.

Öffnen Sie Port 53 zum Internet für autorisierende DNS-Server, die öffentliche Zonen hosten. Sowohl UDP als auch TCP sollten berücksichtigt werden. Wenn der Server nur intern ist, beschränken Sie den Zugriff auf die Netzwerke, die eine Namensauflösung benötigen.

Setzen Sie einen rekursiven Resolver nicht dem gesamten Internet aus, es sei denn, Sie betreiben absichtlich einen öffentlichen Resolver mit Ratenbegrenzung, Missbrauchsüberwachung und Kapazitätsplanung. Offene Resolver werden häufig für Reflexions- und Verstärkungsangriffe missbraucht.

Bevor Sie Port 53 zulassen, entscheiden Sie, ob der Server autorisierend, rekursiv, weiterleitend, zwischenspeichernd oder Split-Horizon ist. Bestätigen Sie, welche Clients es verwenden sollen, welche Zonen es bedient, ob die Rekursion aktiviert ist und ob Zonenübertragungen auf autorisierte sekundäre Server beschränkt sind.

Ein Portprüfer kann bestätigen, dass Port 53 erreichbar ist, die DNS-Korrektheit erfordert jedoch Tests auf Protokollebene. Verwenden Sie Dig-, NSlookup-, Drill- oder Resolver-Protokolle, um Datensatzantworten, Rekursionsrichtlinien, TCP-Fallback, DNSSEC-Verhalten und Antwortzeiten zu überprüfen.

Auf Windows Server kann die DNS-Serverrolle Active Directory-integrierte Zonen, interne Datensätze und Weiterleitungsregeln bereitstellen. Beschränken Sie Rekursion und Zonenübertragungen sorgfältig, insbesondere wenn der Server über eine öffentliche Schnittstelle verfügt.

Unter Linux gehören zu den gängigen DNS-Servern BIND, Unbound, PowerDNS, Knot DNS, CoreDNS und dnsmasq. Konfigurieren Sie Überwachungsschnittstellen, Rekursionsrichtlinien, zulässige Clients, autorisierende Zonen, Protokollierung und Firewallregeln für UDP und TCP 53.

Auf Cloud-Plattformen ist verwaltetes DNS für öffentliche Autoritätszonen oft sicherer, da der Anbieter Anycast, Skalierung und grundlegende DDoS-Resilienz übernimmt. Selbstgehostetes DNS benötigt weiterhin redundante Instanzen, Überwachung und klare Netzwerkrichtlinien.

Beginnen Sie mit einer externen Portprüfung für UDP oder TCP 53, je nachdem, was Sie validieren müssen. Führen Sie dann dig @server example.com A, dig @server example.com AAAA oder nslookup für den Zielresolver aus, um echte DNS-Antworten zu bestätigen.

Testen Sie TCP explizit mit dig +tcp @server example.com TXT oder einer anderen großen Antwort. Fragen Sie bei autorisierenden Servern Datensätze von außerhalb Ihres Netzwerks ab und stellen Sie sicher, dass die Rekursion abgelehnt wird. Führen Sie bei rekursiven Resolvern Abfragen sowohl aus zulässigen als auch aus unzulässigen Quellnetzwerken durch.

Wenn Port 53 geschlossen ist, wird der DNS-Dienst möglicherweise gestoppt, lauscht auf der falschen Schnittstelle, wird von einer Host-Firewall blockiert oder durch eine Cloud-Sicherheitsgruppe eingeschränkt. Wenn UDP unzuverlässig erscheint, TCP jedoch funktioniert, überprüfen Sie MTU, Fragmentierung, Antwortgröße, EDNS-Einstellungen und DNSSEC-bezogenes Verhalten.

Wenn der Port geöffnet ist, aber Suchvorgänge fehlschlagen, überprüfen Sie Zonendaten, Delegation, Glue-Datensätze, SOA- und NS-Datensätze, Rekursionsrichtlinie, Weiterleitungen, DNSSEC-Validierung, Cache-Status und Protokolle. DNS-Fehler sind häufig auf die Richtlinien- oder Zonenkonfiguration und nicht auf die Erreichbarkeit des Rohports zurückzuführen.

Führen Sie nicht versehentlich einen offenen rekursiven Resolver aus. Begrenzen Sie die Rekursion auf vertrauenswürdige Clients, beschränken Sie Zonenübertragungen auf bekannte Sekundärserver, halten Sie die DNS-Software auf dem neuesten Stand und überwachen Sie Abfrageraten, NXDOMAIN-Spitzen, SERVFAIL-Spitzen und ungewöhnliche Quellnetzwerke.

Verwenden Sie für öffentliches autoritatives DNS redundante Server, ggf. DNSSEC, ausreichend kurze TTLs für betriebliche Flexibilität und eine klare Zuständigkeit für Zonenänderungen. Schützen Sie für internes DNS Split-Horizon-Einträge, da diese häufig Infrastrukturnamen und private Topologie offenlegen.