Welchen Port nutzt DNS? Port 53, und wann nicht

Welchen Port nutzt DNS für eine gewöhnliche Abfrage?

Eine normale Abfrage, wie Ihr Browser sie Dutzende Male pro Minute verschickt, geht als einzelnes UDP-Paket an Port 53 hinaus und kommt auf demselben Weg zurück. RFC 1035 nennt UDP „die empfohlene Methode für Standardabfragen im Internet", weil kein Handshake nötig ist: ein Paket hin, ein Paket zurück, fertig. Das ist auch, warum sich DNS sofort anfühlt, wenn es funktioniert, und warum ein einziges verlorenes Paket reicht, damit es sich kaputt anfühlt, denn UDP wiederholt nicht automatisch für Sie. Die Resolver-Software auf Ihrem Gerät oder Router übernimmt die Wiederholung, üblicherweise gegen einen zweiten konfigurierten Server, wenn der erste stumm bleibt.

Wann nutzt DNS stattdessen TCP?

Zwei Situationen drängen einen DNS-Austausch auf TCP-Port 53. Die erste ist ein Zonentransfer, bei dem ein sekundärer Nameserver eine vollständige Kopie einer Zone vom Primary abholt. RFC 1035 stellt ausdrücklich fest, dass „UDP für Zonentransfers nicht akzeptabel ist", weil der Vorgang einen zuverlässigen, geordneten Stream braucht, kein einzelnes Best-Effort-Paket. Die zweite ist eine Antwort, die nicht in die gerade genutzte UDP-Nachrichtengröße passt. In diesem Fall schickt der Server ein abgeschnittenes UDP-Paket mit gesetztem TC-Bit (truncated) zurück, und ein konformer Resolver bemerkt das Bit und schickt dieselbe Abfrage über TCP erneut, um die vollständige Antwort zu bekommen. Sie können dieses Verhalten selbst erzwingen und die vollständige Antwort direkt sehen:

dig +tcp example.com

Alltägliche Abfragen brauchen diesen Pfad selten, aber er existiert genau dafür, dass DNS weiterfunktioniert, wenn eine Antwort über das hinauswächst, was ein einzelnes UDP-Paket fassen kann, was häufiger vorkommt als früher.

Was war das 512-Byte-Limit, und was hat es geändert?

RFC 1035 legte die UDP-Nachrichtengröße auf 512 Byte fest, Header eingerechnet, ohne die IP- oder UDP-Header selbst zu zählen. Diese Zahl war 1987 großzügig, als eine DNS-Antwort eine Handvoll Adress-Einträge war. Großzügig blieb sie nicht mehr, als DNSSEC-Signaturen, längere Hostnamen und Einträge mit vielen IP-Adressen normal wurden, weil eine signierte Antwort mit einem RRSIG-Eintrag ganz von allein regelmäßig über 512 Byte hinausgeht.

RFC 6891, veröffentlicht 2013, hob die Obergrenze an, ohne das Drahtprotokoll anzufassen: EDNS0 fügt einen OPT-Pseudo-Eintrag hinzu, mit dem ein Resolver „die größte UDP-Payload, die im Netzwerkstack des Anfragenden zusammengesetzt und zugestellt werden kann" bekannt geben kann, und der RFC schlägt 4096 Byte als praktischen Ausgangswert vor. Ein Resolver und ein Server, die beide EDNS0 unterstützen, können Antworten austauschen, die ein Vielfaches der alten 512-Byte-Grenze über ein einziges UDP-Paket erreichen, und fallen erst auf TCP zurück, wenn selbst diese größere Erlaubnis nicht reicht. Fast jeder heute genutzte Resolver, einschließlich dem Ihres eigenen Betriebssystems, spricht EDNS0 standardmäßig, dieses Upgrade ist also schon passiert, ohne dass Sie etwas tun mussten.

Warum Firewalls, die nur UDP 53 erlauben, echte Probleme verursachen

Eine vor Jahren geschriebene und nie überprüfte Firewall-Regel lautet oft „UDP-Port 53 erlauben, alles andere DNS-Bezogene ablehnen". Diese Regel blockiert genau den TCP-Fallback, den das Protokoll braucht, und der dadurch entstehende Fehler ist schwer zu diagnostizieren, weil die meisten Abfragen weiterhin einwandfrei funktionieren. Nur die, die über das UDP-Limit hinauswachsen, schlagen fehl, und sie tun es zufällig wirkend: Eine Domain löst sich meist normal auf und läuft dann in ein Timeout, besonders sobald DNSSEC-Validierung im Spiel ist, denn ein validierender Resolver muss die RRSIG- und DNSKEY-Einträge zusätzlich zur angefragten Antwort abholen.

Das praktische Ergebnis ist, dass DNSSEC-signierte Zonen und jeder Recordset mit vielen Werten (eine Domain mit einem Dutzend Mailservern zum Beispiel) hinter einer nur-UDP-Firewall unzuverlässig werden, während alles andere gesund aussieht. TCP 53 ausgehend zu blockieren, oder es nur in eine Richtung zu blockieren, ist einer der häufigeren selbstverursachten DNS-Ausfälle, und er taucht selten in einer einfachen Konnektivitätsprüfung auf, weil diese Prüfung meist nur UDP versucht.

DNS over TLS und DNS over HTTPS: andere Ports, dieselben Abfragen

Zwei neuere Transportarten tragen dieselben DNS-Abfragen und -Antworten, verlegen sie aber ganz von Port 53 weg. DNS over TLS, definiert in RFC 7858, wickelt jede Abfrage in eine TLS-Sitzung auf TCP-Port 853 ein, gewählt, damit ein Netzwerkbetreiber weiterhin sehen kann, dass DoT stattfindet (und es blockieren kann), selbst ohne zu entschlüsseln, denn der Port selbst ist schon ein eindeutiges Signal.

DNS over HTTPS, definiert in RFC 8484, geht weiter. Es sendet DNS-Abfragen als gewöhnliche HTTPS-Anfragen über Port 443, denselben Port wie jede andere Website, die Sie besuchen, und der RFC nennt „die Möglichkeit, DoH-Traffic mit anderem HTTPS-Traffic auf derselben Verbindung zu mischen" als bewusste Eigenschaft. Genau das ist der Sinn von DoH: Ein Netzwerk, das nur nach Port prüft oder filtert, kann eine DNS-Abfrage nicht von jeder anderen HTTPS-Anfrage unterscheiden, weil beide dasselbe Protokoll auf demselben Port sind. Chrome, Firefox und Edge können heute alle standardmäßig DNS auf diesem Weg senden, weshalb das Blockieren von „Port 53" in einem Netzwerk nicht mehr garantiert, dass DNS blockiert ist. Es garantiert, dass der klassische Transport blockiert ist; ein Browser mit aktiviertem DoH löst Namen weiterhin über 443 auf.

Was ist mDNS auf Port 5353?

Multicast DNS ist ein anderes Protokoll mit einem ähnlichen Namen. RFC 6762 definiert es als Geräte, die „DNS-artige UDP-Abfrage- und Antwortnachrichten per IP-Multicast an UDP-Port 5353 senden", adressiert an die Multicast-Gruppe 224.0.0.251 (oder ihr IPv6-Äquivalent, FF02::FB) statt an einen bestimmten Server. Es gibt überhaupt keinen zentralen Nameserver: Jedes Gerät im lokalen Netzsegment hört auf Port 5353 und antwortet für den eigenen Namen. So wird ein Drucker oder ein smarter Lautsprecher als gerät.local erreichbar, ohne dass jemand einen DNS-Eintrag dafür einrichtet. mDNS ist per Design auf den lokalen Link beschränkt und hat nichts mit der Auflösung einer öffentlichen Domain zu tun, mDNS-Traffic muss also nie Ihren Router verlassen.

So testen Sie, ob Port 53 erreichbar ist

Beginnen Sie mit einer direkten Abfrage gegen einen bekannt funktionierenden Resolver, die zeigt, ob gewöhnliche UDP-Abfragen überhaupt funktionieren:

nslookup example.com 8.8.8.8
dig example.com @1.1.1.1

Funktioniert das, vermuten Sie aber, dass der TCP-Fallback-Pfad blockiert ist, erzwingen Sie TCP und vergleichen Sie:

dig +tcp example.com @1.1.1.1

Eine UDP-Abfrage, die erfolgreich ist, während die erzwungene TCP-Version in ein Timeout läuft, ist ein starkes Zeichen dafür, dass zwischen Ihnen und dem Resolver etwas gezielt TCP 53 verwirft, genau der oben beschriebene Fehlerfall. Um die rohe Erreichbarkeit eines Ports von außerhalb des eigenen Netzwerks zu testen, ist unser Port-Check-Tool nützlich: Richten Sie es auf Port 53 Ihres Resolvers oder Nameservers, und es öffnet eine echte TCP-Verbindung aus einem anderen Netzwerk und bestätigt, ob TCP 53 überhaupt erreichbar ist. Lesen Sie das Ergebnis mit einem Vorbehalt: Ein Port-Checker testet TCP, ein Bestehen bestätigt also nur, dass der Fallback-Pfad offen ist, und sagt nichts über UDP, das keinen Handshake hat, den man genauso testen könnte. Für die Abfrage selbst, einschließlich des Vergleichs von Antworten mehrerer öffentlicher Resolver und verschiedener Regionen auf einmal, nutzen Sie das DNS-Abfragewerkzeug.

Häufig gestellte Fragen

Muss ich neben UDP 53 auch TCP 53 öffnen?

Ja, für ausgehenden Resolver-Traffic. Eine Firewall, die nur UDP 53 erlaubt, bearbeitet die meisten Abfragen problemlos und schlägt dann unvorhersehbar bei größeren, meist DNSSEC-signierten Antworten fehl, die den TCP-Fallback brauchen.

Blockiert das Sperren von Port 53 den gesamten DNS-Traffic?

Nicht mehr. Es blockiert den klassischen UDP/TCP-Transport. DNS over HTTPS läuft über Port 443 und sieht wie jede andere HTTPS-Anfrage aus, und DNS over TLS läuft über den eigenen Port 853, ein Browser oder eine App mit einem der beiden aktiviert löst Namen also weiterhin auf.

Ist DNS over HTTPS dasselbe Protokoll wie normales DNS?

Die Abfragen und Antworten sind dieselben DNS-Einträge und Codes, definiert von RFC 1035. Nur der Transport ändert sich: statt eines rohen UDP- oder TCP-Pakets auf Port 53 ist dieselbe Anfrage in eine HTTPS-Anfrage auf Port 443 verpackt.

Warum nutzt dig manchmal TCP, ohne dass man es sagt?

Kommt eine UDP-Antwort abgeschnitten zurück, mit gesetztem TC-Bit, schickt ein standardkonformer Client die Abfrage automatisch über TCP erneut, um die vollständige Antwort zu bekommen. Das sehen Sie am häufigsten bei Domains mit aktiviertem DNSSEC oder vielen Einträgen desselben Typs.

Ist mDNS auf Port 5353 dasselbe wie das DNS meines Internetanbieters?

Nein. mDNS funktioniert nur im lokalen Netzsegment, hat keinen zentralen Server und löst Namen wie gerät.local für Geräte im selben Link auf. Es hat nichts mit der Auflösung einer öffentlichen Domain wie example.com zu tun.

Was ist eine normale EDNS0-Payload-Größe heute?

RFC 6891 schlägt 4096 Byte als praktische Vorgabe vor, und die meisten aktuellen Resolver geben etwas in diesem Bereich an, deutlich über der ursprünglichen 512-Byte-Grenze, bevor sie erst auf TCP zurückfallen, wenn selbst das nicht reicht.