Welchen Port verwendet DNS über TLS?

DNS über TLS verwendet standardmäßig den TCP-Port 853, wie in RFC 7858 definiert. Firewalls müssen diesen Port zwischen Clients und dem Resolver zulassen, damit verschlüsseltes DNS funktioniert.

Was ist der Unterschied zwischen DNS über TLS und DNS über HTTPS?

Bei DNS über TLS werden DNS-Nachrichten in einer TLS-Sitzung auf einem eigenen Port gesendet, während DNS über HTTPS sie als HTTP-Anfragen über TLS auf Port 443 überträgt. Ersteres lässt sich von Administratoren leichter überwachen und steuern, während letzteres schwerer vom Web-Datenverkehr zu unterscheiden ist.

Was ist DNS über TLS?

DNS-over-TLS ist eine Methode zur Verschlüsselung von DNS-Anfragen und -Antworten zwischen einem Client und einem Resolver mithilfe von TLS. Sie verhindert, dass Beobachter auf dem Übertragungsweg Anfragen lesen oder verändern können.

Verschlüsselt DNS über TLS den Datenverkehr zwischen Resolvern und autoritativen Servern?

DNS über TLS wird hauptsächlich zwischen Clients und rekursiven Resolvern eingesetzt. Die Unterstützung zwischen Resolvern und autoritativen Servern ist weniger verbreitet und hängt davon ab, dass beide Seiten entsprechend konfiguriert sind.

Ist TLS dasselbe wie SSL?

Nein, TLS ist der Nachfolger von SSL. SSL-Versionen sind veraltet und unsicher, obwohl der Begriff SSL immer noch häufig als Bezeichnung für TLS verwendet wird.

Glossar
Was ist TLS (Transport Layer Security)?

Sicherheitsglossar

Was ist TLS (Transport Layer Security)?

Transport Layer Security (TLS) ist ein kryptografisches Protokoll, das Vertraulichkeit, Integrität und Endpunkt-Authentifizierung für Daten gewährleistet, die über ein Netzwerk zwischen zwei Anwendungen übertragen werden. Es läuft auf einem zuverlässigen Transportprotokoll wie TCP, nutzt Zertifikate zur Authentifizierung von Servern und schützt den Datenverkehr für HTTPS, E-Mail und DNS über TLS.

Vereinfachen wir Ihr DDI

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button

Die wichtigsten Erkenntnisse

Transport Layer Security (TLS) is a cryptographic protocol that provides confidentiality, integrity, and endpoint authentication for data transmitted between applications over networks, with TLS 1.3 offering improved security by removing legacy algorithms and ensuring forward secrecy. DNS over TLS, defined in RFC 7858, encrypts DNS queries on TCP port 853 to prevent observers from reading or modifying queries, representing a critical advancement for protecting core network services alongside HTTPS, email, and APIs. Poor TLS management causes operational outages and security exposures through expired certificates, outdated protocol versions, weak cipher suites, and unmanaged private keys, requiring organizations to maintain comprehensive certificate inventories, automated renewal processes, and enforced minimum protocol version policies across all services.

DNS over TLS operates on dedicated TCP port 853 and differs from DNS over HTTPS by providing easier visibility and control for network operators compared to HTTPS traffic on port 443.
TLS 1.3 eliminates static RSA key exchange and legacy features to guarantee forward secrecy, ensuring that recorded sessions cannot be decrypted later even if the server’s private key is compromised.
Certificate management failures including expiration, incomplete chains, and name mismatches commonly affect multi-endpoint services such as load balancers and management interfaces, particularly when services are accessed by IP address or new aliases.

TLS auf einen Blick

Attribute	Value
Full name	Transport layer security
Category	Cryptographic network protocol
Defined in	RFC 8446 for TLS 1.3 and RFC 5246 for TLS 1.2
Protocol and port	Runs over TCP; DNS over TLS uses TCP port 853 as defined in RFC 7858
OSI layer	Commonly placed between the transport and application layers
Primary use	Encrypting and authenticating application traffic such as HTTPS, email and DNS over TLS
Related terms	DNS over TLS, DNS over HTTPS, DNSSEC, Public key infrastructure, Certificate authority

So funktioniert TLS

TLS beginnt mit einem Handshake, bei dem sich Client und Server auf Protokollparameter einigen, den Server authentifizieren und gemeinsame Sitzungsschlüssel ableiten. Nach dem Handshake werden Anwendungsdaten in verschlüsselten und integritätsgeschützten Datensätzen gesendet.

Client Hello: Der Client öffnet eine TCP-Verbindung und sendet die von ihm unterstützten TLS-Versionen, Verschlüsselungssuiten und Informationen zum Schlüsselaustausch.
Server-Hello und Zertifikat: Der Server wählt die Parameter aus und sendet sein Zertifikat, damit der Client seine Identität überprüfen kann.
Zertifikatsvalidierung: Der Client überprüft, ob das Zertifikat auf eine vertrauenswürdige Zertifizierungsstelle zurückgeführt werden kann, nicht abgelaufen ist und mit dem angeforderten Namen übereinstimmt.
Schlüsselaustausch: Beide Seiten nutzen einen kurzlebigen Schlüsselaustausch, um dieselben Sitzungsschlüssel abzuleiten, ohne diese über das Netzwerk zu senden.
Verschlüsselte Anwendungsdaten: Die Endpunkte wechseln zu der ausgehandelten Verschlüsselungsmethode und tauschen Anwendungsdaten in geschützten Datensätzen aus.

TLS 1.3, definiert in RFC 8446, verkürzt den Handshake und entfernt ältere, schwächere Algorithmen. Mutual TLS fügt ein Client-Zertifikat hinzu, damit der Server auch den Client authentifizieren kann. Die oben genannten Schritte zeigen den üblichen Fall der Server-Authentifizierung.

Warum TLS in Unternehmensnetzwerken wichtig ist

TLS schützt den Großteil des Datenverkehrs in Unternehmensnetzwerken, darunter Webanwendungen, APIs, E-Mail und Verwaltungsschnittstellen. Ohne TLS könnte jeder, der Zugriff auf die Übertragungsstrecke hat, die übertragenen Daten lesen oder verändern. TLS 1.3, veröffentlicht als RFC 8446, hat veraltete Funktionen wie den statischen RSA-Schlüsselaustausch entfernt, sodass jede Sitzung Forward Secrecy nutzt und eine aufgezeichnete Sitzung später nicht mit einem gestohlenen Serverschlüssel entschlüsselt werden kann.

TLS ist auch für zentrale Netzwerkdienste von Bedeutung. DNS über TLS, definiert in RFC 7858, verschlüsselt Abfragen zwischen einem Client und einem Resolver auf dem TCP-Port 853, wodurch verhindert wird, dass die von Benutzern abgefragten Namen auf dem Übertragungsweg gelesen werden können. Es unterscheidet sich von DNS über HTTPS, bei dem DNS innerhalb von HTTPS auf dem Standard-Webport übertragen wird. Die Verschlüsselung verändert auch die Überwachung, da Tools, die auf die Überprüfung von DNS-Klartext angewiesen waren, nun andere Wege benötigen, um den Datenverkehr einzusehen.

Mangelhaftes TLS-Management führt zu Ausfällen und Sicherheitslücken. Abgelaufene Zertifikate legen Dienste lahm, veraltete Protokollversionen und schwache Verschlüsselungssuiten laden zu Downgrade-Angriffen ein, und nicht verwaltete private Schlüssel ermöglichen es Angreifern, sich als Server auszugeben. Teams benötigen ein Zertifikatsinventar, eine automatisierte Erneuerung sowie eine Richtlinie, die Mindestprotokollversionen für alle Dienste festlegt.

Wie sich TLS von verwandten Begriffen unterscheidet

TLS vs. DNS über HTTPS

Bei DNS über TLS werden DNS-Nachrichten direkt innerhalb einer TLS-Sitzung auf einem dedizierten Port übertragen, während DNS über HTTPS diese in HTTP-Anfragen innerhalb einer TLS-Sitzung auf dem Standard-HTTPS-Port einbindet.

Attribute	TLS	DNS over HTTPS
Standard	RFC 7858	RFC 8484
Transport	TLS over TCP	HTTP over TLS
Default port	TCP 853	TCP 443
Visibility to network operators	Easy to identify and to block or monitor by port	Blends with other HTTPS traffic, so harder to separate
Typical implementation point	Operating system or resolver	Often the browser or application

Häufige TLS-Probleme

Ein Zertifikat, das ohne Verlängerung abläuft, führt zu Browserwarnungen und fehlgeschlagenen API-Aufrufen, oft zu unerwarteten Zeiten. Dienste mit vielen Endpunkten, wie beispielsweise Load Balancer und Verwaltungsschnittstellen, werden dabei am häufigsten übersehen.

Ein Server, der nur sein eigenes Zertifikat sendet und das Zwischenzertifikat weglässt, funktioniert in einigen Browsern, versagt jedoch bei Befehlszeilentools, Java-Clients und eingebetteten Geräten. Tests mit verschiedenen Client-Typen decken diese Lücke auf.

Clients lehnen ein Zertifikat ab, wenn der angeforderte Hostname nicht im Feld „Subject Alternative Name“ enthalten ist. Dies tritt häufig auf, wenn ein Dienst über eine IP-Adresse oder einen neuen Alias erreicht wird, den das Zertifikat nicht abdeckt.

Ältere Clients, die nur TLS 1.0 oder 1.1 unterstützen, oder Server, die die von einem Client angebotenen Verschlüsselungsalgorithmen deaktivieren, führen zu Handshake-Fehlern. In Paketaufzeichnungen wird in der Regel direkt nach dem „Client Hello“ eine Warnung angezeigt.

DNS-over-TLS-Clients schlagen fehl oder greifen auf unverschlüsseltes DNS zurück, wenn eine Firewall den TCP-Port 853 blockiert. Je nach Client-Einstellungen führt dies entweder zu einer fehlerhaften Auflösung oder zu einem unbemerkten Verlust der Verschlüsselung.

Erfahren Sie, wie ein einheitliches DDI den Netzwerkbetrieb vereinfacht

Verwalten Sie DNS, DHCP und IP-Adressen über eine einzige Plattform mit integrierter Automatisierung, Transparenz und Kontrolle.

Sprechen Sie mit uns

Das intelligente Netzwerk

Was ist TLS (Transport Layer Security)?

Sind Sie bereit, Ihre DDI zu vereinfachen?

TLS auf einen Blick

So funktioniert TLS

Warum TLS in Unternehmensnetzwerken wichtig ist

Wie sich TLS von verwandten Begriffen unterscheidet

TLS vs. DNS über HTTPS

Häufige TLS-Probleme

Erfahren Sie, wie ein einheitliches DDI den Netzwerkbetrieb vereinfacht

TLS-FAQ

Verwandte Begriffe

Einrichtung von geregelten, auditfähigen IPAM-Workflow- und Genehmigungsmodellen für Unternehmensnetzwerke

Das OSI-Modell verstehen: Wo DNS und IP-Adressierung in die 7 Schichten passen

Skalierung von DNS und IPAM für IPv6- und Dual-Stack-Unternehmensnetzwerke

Einbindung von DNS, DHCP und IPAM in Ansible- und Git-basierte Infrastructure-as-Code-Pipelines

Podcast: Wie KI die Entwicklung von Unternehmenssoftware verändert

Podcast: Why Open Platforms Matter in Network Operations

Erhalten Sie mit LiveAssist Antworten aus den LiveNX-Daten, über die Sie bereits verfügen

Erstellung einer Kostenanalyse für den Ersatz bestehender appliancebasierter DDI-Lösungen durch eine Overlay-Verwaltungsschicht

Verwandte Artikel