DNS-Sicherheit unter Windows 11 und Windows Server 2025 – Von DNS-over-HTTPS bis Zero Trust DNS

DNS im Wandel – von Klartext zu Zero Trust

Die DNS-Sicherheit in Windows Server 2025 und Windows 11 ist ein zentraler Baustein moderner IT-Infrastrukturen. Ohne sie könnten weder Webbrowser zuverlässig Webseiten aufrufen noch E-Mail-Clients ihre Postfächer erreichen, und auch Dienste wie Active Directory wären nicht verfügbar. In Unternehmensnetzwerken spielt die sichere Namensauflösung eine Schlüsselrolle – besonders, wenn sie nach aktuellen Zero-Trust-DNS-Prinzipien gestaltet wird.

Kurz gesagt: DNS ist das Telefonbuch des Internets und der Unternehmensnetze. Ohne Verschlüsselung, Authentifizierung oder Manipulationsschutz ist es jedoch anfällig für Angriffe und Überwachung. Traditionell läuft DNS unverschlüsselt über UDP oder TCP Port 53 – schnell, ressourcenschonend, aber leicht auszunutzen.

Moderne Verfahren wie DNS-over-HTTPS (DoH) schließen diese Sicherheitslücke, indem sie Anfragen verschlüsselt übertragen. Dieser Beitrag zeigt, wie Administrator:innen DoH unter Windows Server 2025 und Windows 11 implementieren, welche Rolle Microsofts neue Zero-Trust-DNS-Strategie spielt und welche Best Practices in Active-Directory-Umgebungen sinnvoll sind.

Historische Einordnung

Das Domain Name System (DNS) ist ein Urgestein der Internetinfrastruktur – und gleichzeitig eine der am wenigsten abgesicherten Kerntechnologien. Seine Wurzeln reichen bis in die frühen 1980er Jahre zurück.

Damals löste es das statische hosts.txt-Verzeichnis ab, das auf jedem Rechner manuell gepflegt werden musste. Mit DNS entstand ein skalierbares, hierarchisches Namensauflösungssystem, das weltweit verteilte Informationen dynamisch bereitstellen konnte.

BIND – Der Ursprung des modernen DNS

Eine Schlüsselrolle bei der Verbreitung von DNS spielte BIND (Berkeley Internet Name Domain), das an der University of California im Rahmen des Berkeley Software Distribution (BSD)-Projekts entwickelt wurde.

BIND wurde erstmals 1984 als Teil von BSD 4.3 veröffentlicht und war der erste weitverbreitete, frei verfügbare DNS-Server. Seine Eigenschaften machten es schnell zum De-facto-Standard:

• Funktionsvielfalt – Unterstützung für Master- und Slave-Server, Caching und Zonentransfers
• Offener Quellcode – frei nutzbar, veränderbar und erweiterbar
• Portabilität – lauffähig auf einer Vielzahl von UNIX-Systemen

Bis heute ist BIND in zahlreichen Umgebungen im Einsatz und prägt viele Implementierungen – auch wenn moderne Betriebssysteme oft eigene DNS-Serverrollen (wie bei Windows Server) mitbringen, basieren viele Designprinzipien auf der BIND-Architektur.

Internet unter Freunden

Die Entstehung von DNS fällt in eine Zeit, in der das Internet – damals noch ARPANET – vor allem von Universitäten, Forschungseinrichtungen und staatlichen Stellen genutzt wurde.

Sicherheitsbedrohungen spielten nur eine untergeordnete Rolle, denn:

• Die Nutzer:innen kannten sich häufig persönlich oder waren Teil derselben Forschungsprojekte
• Die Zahl der beteiligten Akteure war überschaubar
• Vertrauen war der Standard – Misstrauen die Ausnahme

In dieser Kommunikation unter Freunden stand die Funktionalität im Vordergrund, nicht die Sicherheit. Weder Verschlüsselung noch Integritätsprüfungen waren vorgesehen. DNS-Anfragen und -Antworten konnten theoretisch von jedem mitgelesen oder manipuliert werden – ein Problem, das in der Praxis erst Jahre später relevant wurde.

Die ersten Erweiterungen

Mit dem Wachstum des Internets und der Öffnung für kommerzielle Anwendungen stieg auch die Attraktivität von Angriffen. Als erste Antwort auf Manipulationsrisiken wurde DNSSEC entwickelt, das DNS-Daten kryptografisch signiert. Es schützt vor verfälschten Antworten (Integrität), verschlüsselt aber nicht den Transport.

Weitere Ergänzungen wie TSIG und SIG(0) ermöglichten die Authentifizierung bei Zonentransfers zwischen DNS-Servern.

Verschlüsselung hält Einzug

Ab den 2010er Jahren setzte sich die Erkenntnis durch, dass DNS-Verkehr ein wertvolles Ziel für Überwachung und Angriffe ist. Die Standardisierung von DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH) brachte endlich eine Transportverschlüsselung in die Namensauflösung:

• DoT nutzt einen eigenen Port (853) und TLS
• DoH kapselt DNS in HTTPS über Port 443 und tarnt es damit im regulären Webverkehr

Vom offenen Dienst zum Sicherheitsbaustein

Heute ist DNS ein kritisches Element der Netzwerksicherheit. Was ursprünglich als effiziente Namensauflösung unter vertrauenswürdigen Partnern begann, ist längst zu einem Angriffsziel von Cyberkriminellen, staatlichen Akteuren und Wirtschaftsspionen geworden.

Die Integration von Verschlüsselung, Authentifizierung und Policy-gestützten Zugriffskontrollen ist daher kein Luxus mehr – sondern Grundvoraussetzung für eine sichere IT-Architektur.

Vergleich: DoH, DoT und DNSSEC

DNS-Sicherheit ist kein eindimensionales Thema. Verschiedene Standards adressieren unterschiedliche Bedrohungen – und nicht jeder Ansatz ist für jeden Einsatzzweck geeignet. Die drei derzeit wichtigsten Mechanismen sind:

• DNS-over-HTTPS (DoH)
• DNS-over-TLS (DoT)
• Domain Name System Security Extensions (DNSSEC)

Um sie sinnvoll einzusetzen, müssen wir verstehen, was sie leisten – und was nicht.

DNSSEC – Integrität ja, Vertraulichkeit nein

DNSSEC (Domain Name System Security Extensions) erweitert DNS um eine kryptografische Signaturinfrastruktur. Jede Zone, die DNSSEC nutzt, erzeugt zwei Schlüsselpaar-Typen:

• Zone Signing Key (ZSK) – signiert die Resource Records innerhalb der Zone
• Key Signing Key (KSK) – signiert den ZSK und wird zur Vertrauenskette hoch bis zur Root-Zone genutzt

Ablauf einer Anfrage mit DNSSEC:

1. Der Client (Resolver) fragt einen DNS-Record an
2. Der autoritative DNS-Server liefert die Antwort plus eine kryptografische Signatur (RRSIG)
3. Der Resolver prüft diese Signatur anhand des öffentlichen Schlüssels, der in einem DS-Record in der nächsthöheren Zone hinterlegt ist
4. Dieser Prozess setzt sich Kette für Kette fort, bis zur Root-Zone, deren Schlüssel als Vertrauensanker (Trust Anchor) fest im Resolver hinterlegt ist

Kerngedanke: DNSSEC garantiert die Integrität der Daten, nicht deren Vertraulichkeit – die Antworten sind weiterhin im Klartext sichtbar.

DNS-over-TLS (DoT) – Verschlüsselung auf eigenem Port

DoT transportiert DNS-Anfragen nicht im Klartext, sondern kapselt sie in einer TLS-Verbindung, ähnlich wie HTTPS – jedoch mit einem eigenen Standardport (853).

Ablauf einer DoT-Verbindung:

1. Der Client initiiert eine TCP-Verbindung zum Resolver auf Port 853
2. Ein TLS-Handshake wird durchgeführt, bei dem Zertifikate ausgetauscht und überprüft werden
3. Nach erfolgreicher Aushandlung werden DNS-Anfragen und -Antworten im verschlüsselten TLS-Datenstrom übertragen

Vorteile:

• Keine Klartext-DNS-Pakete mehr auf der Leitung
• Angriffe wie DNS-Spoofing oder -Manipulation durch Dritte werden verhindert

Einschränkungen:

• Der dedizierte Port macht DoT leicht erkennbar und ggf. blockierbar
• Erfordert oft zusätzliche Firewallfreigaben oder Anpassungen an Sicherheits-Gateways

DNS-over-HTTPS (DoH) – Verschlüsselung im Web-Traffic

DoH verpackt DNS-Anfragen in reguläre HTTPS-Anfragen und nutzt damit Port 443 – denselben Port wie jede verschlüsselte Website. Das macht DoH besonders schwer zu erkennen oder zu blockieren, ohne gleichzeitig Web-Traffic zu beeinträchtigen.

Ablauf einer DoH-Abfrage:

1. Der Client stellt eine HTTPS-Verbindung zu einem DoH-fähigen Resolver her (z.B. https://dns.google/dns-query)
2. Innerhalb dieser Verbindung wird die DNS-Anfrage im JSON- oder binären Wireformat übermittelt (definiert in RFC 8484)
3. Der Resolver beantwortet die Anfrage im gleichen HTTPS-Kanal, ebenfalls verschlüsselt

Vorteile:

• Kein dedizierter Port – daher unauffälliger als DoT
• Verschlüsselung und Tarnung im Webverkehr erschweren Überwachung und Zensur

Einschränkungen:

• Erfordert Unterstützung im Client-Betriebssystem oder in der Anwendung.
• Ohne zentrale Richtlinien kann DoH die internen DNS-Policies umgehen.

Windows-Status:

• Konfigurierbar per GUI, PowerShell oder Gruppenrichtlinien
• Native DoH-Clientunterstützung ab Windows 10 Build 19628 und Windows Server 2022

Vergleichstabelle

Praxisorientierte Einsatzempfehlungen

Die Wahl des passenden Mechanismus hängt stark vom Einsatzzweck und der vorhandenen Infrastruktur ab.

DNSSEC

DNSSEC ist vor allem dann unverzichtbar, wenn die Integrität der DNS-Daten entscheidend ist. Das gilt insbesondere für öffentlich erreichbare Domains, bei denen ein Manipulationsangriff nicht nur technische Probleme, sondern auch erheblichen Reputations- und Vertrauensverlust bedeuten würde.

In Unternehmensumgebungen kann DNSSEC sowohl intern (für kritische interne Zonen) als auch extern eingesetzt werden, erfordert jedoch eine saubere Schlüsselverwaltung und konsequente Implementierung auf allen beteiligten Servern.

In der Praxis wird DNSSEC häufig mit DoT oder DoH kombiniert, um sowohl Integrität als auch Vertraulichkeit zu gewährleisten.

DNS-over-TLS (DoT)

DoT eignet sich besonders für Szenarien, in denen feste, klar definierte Verbindungen zwischen DNS-Clients und Resolvern bestehen. Ein klassisches Beispiel ist die Verbindung zwischen Filialstandorten und einem zentralen Unternehmens-DNS-Server oder zwischen einem Unternehmensnetz und einem vertrauenswürdigen externen DNS-Anbieter.

Die klare Trennung über Port 853 macht DoT für Administrator:innen leicht steuerbar, gleichzeitig aber auch für Firewalls und Zensursysteme leichter blockierbar. Für öffentliche Hotspots oder mobile Geräte ist DoT daher oft weniger flexibel als DoH.

DNS-over-HTTPS (DoH)

DoH ist besonders dann interessant, wenn DNS-Anfragen unauffällig und sicher auch in restriktiven Netzwerken durchgeführt werden sollen – beispielsweise für Remote-Worker im Homeoffice oder unterwegs.

Der Einsatz sollte jedoch in Unternehmensumgebungen genau geplant werden, um nicht ungewollt interne DNS-Policies zu umgehen.
Hier bieten sich zentrale Richtlinien an, die festlegen, welche Resolver per DoH genutzt werden dürfen.

In BYOD-Umgebungen (Bring Your Own Device) kann DoH helfen, DNS-Sicherheit ohne komplizierte VPN-Setups zu realisieren, wenn interne Ressourcen nicht betroffen sind.

Fazit

Es gibt keinen universellen Ansatz, der alle Anforderungen an DNS-Sicherheit gleichermaßen abdeckt. Vielmehr geht es um eine kombinierte Strategie, die abhängig vom Einsatzszenario angepasst werden sollte:

• Für flexible und unauffällige Verschlüsselung: DoH ist besonders praktisch für mobile und heterogene Umgebungen, muss aber durch Richtlinien in Unternehmensnetzen kontrolliert werden, um keine internen Auflösungsmechanismen zu umgehen.
• Für Integrität: DNSSEC ist das Mittel der Wahl, um Manipulationen zu verhindern – jedoch nur wirksam, wenn alle beteiligten Zonen signiert sind und Resolver die Signaturen auch prüfen.
• Für Vertraulichkeit in kontrollierten Netzen: DoT bietet einen klaren, gut administrierbaren Kanal, eignet sich aber vor allem in festen Verbindungsbeziehungen.

In der Realität führt der Weg zu einer sicheren DNS-Infrastruktur selten über nur eine dieser Technologien. Oft besteht die optimale Lösung aus einer Mehrschicht-Architektur:

• DNSSEC auf den relevanten Zonen,
• Transportverschlüsselung via DoT oder DoH für den Client-Resolver-Weg,
• und ergänzende Sicherheitsmaßnahmen wie Monitoring, Policy Enforcement und Protokollanalyse im Rahmen einer Zero-Trust-Strategie.

Gerade unter Windows 11 und Windows Server 2025 sollten Administrator:innen die neuen Möglichkeiten von DoH gezielt evaluieren – idealerweise zunächst in Testumgebungen – und in bestehende Sicherheitsarchitekturen integrieren, anstatt sie isoliert zu betrachten.

DNS-over-HTTPS unter Windows 11

Mit Windows 11 hat Microsoft die Unterstützung für DNS-over-HTTPS (DoH) fest in den DNS-Client integriert.

Dadurch können Anfragen direkt auf Betriebssystemebene verschlüsselt werden – unabhängig davon, ob einzelne Anwendungen wie Browser eigene DoH-Implementierungen besitzen. Das vereinfacht die Administration und sorgt dafür, dass alle DNS-Abfragen des Systems, sofern möglich, über einen gesicherten Kanal laufen.

Die Aktivierung von DoH ist aber nicht per Knopfdruck ohne Vorbereitung sinnvoll. Bevor Administrator:innen die Funktion freischalten, sollten sie prüfen, ob die technischen Voraussetzungen erfüllt sind und ob die Konfiguration in die bestehende DNS-Architektur passt – insbesondere in Active-Directory-Umgebungen.

Voraussetzungen

Damit DoH unter Windows 11 reibungslos funktioniert, müssen folgende Bedingungen erfüllt sein:

• Windows-Version
  • Vollständige Unterstützung ab Windows 11 (alle Editionen)
  • Eingeschränkter Support ab Windows 10 Build 19628
• Netzwerkadapter
  • IPv4 oder IPv6 muss aktiv sein (DoH funktioniert mit beiden Protokollen)
• DoH-fähiger Resolver
  • Es muss ein DNS-Server hinterlegt werden, der DoH unterstützt und dessen HTTPS-Endpunkt bekannt ist.
  • Gängige Beispiele:
    • Cloudflare:1.1.1 → https://cloudflare-dns.com/dns-query
    • Google Public DNS:8.8.8 → https://dns.google/dns-query
    • Quad9:9.9.9 → https://dns.quad9.net/dns-query
  • Policy- und Netzwerkanpassung
    • In Unternehmensumgebungen müssen ggf. Gruppenrichtlinien gesetzt oder Firewallregeln angepasst werden, um DoH gezielt zuzulassen oder einzuschränken.

Praxis-Hinweis: Bevor DoH flächendeckend aktiviert wird, sollte ein Test mit ausgewählten Clients erfolgen, um Wechselwirkungen mit internen DNS-Zonen, Proxy-Servern und Sicherheitslösungen auszuschließen.

Konfiguration über die grafische Oberfläche (GUI)

1. Einstellungen öffnen → Netzwerk & Internet.
2. Entsprechenden Netzwerkadapter (LAN/WLAN) auswählen.
3. DNS-Server zuweisen auswählen → Manuell
4. Bevorzugten DNS-Server und alternativen DNS-Server eintragen (z.B. 1.1.1.1 und 1.0.0.1).
5. Unter „DNS über HTTPS“ den Modus „Nur verschlüsselt (DNS-over-HTTPS)“ auswählen.
6. Änderungen speichern – Windows nutzt nun DoH für alle Anfragen an diesen Resolver.

Hinweis: Wenn der Resolver kein DoH unterstützt, fällt Windows – sofern konfiguriert – automatisch auf klassisches DNS zurück.

Konfiguration per PowerShell

PowerShell bietet nicht nur mehr Kontrolle, sondern auch die Möglichkeit, DoH-Einstellungen skriptgesteuert auszurollen.

# Cloudflare DoH-Server hinzufügen
Add-DnsClientDohServerAddress `
  -ServerAddress "1.1.1.1" `
  -DohTemplate "https://cloudflare-dns.com/dns-query" `
  -AllowFallbackToUdp $false `
  -AutoUpgrade $true

# Google Public DNS DoH-Server hinzufügen
Add-DnsClientDohServerAddress `
  -ServerAddress "8.8.8.8" `
  -DohTemplate "https://dns.google/dns-query" `
  -AllowFallbackToUdp $false `
  -AutoUpgrade $true

# Aktuell konfigurierte DoH-Server anzeigen
Get-DnsClientDohServerAddress

Parametererklärung:

• -AllowFallbackToUdp $false → Verhindert unverschlüsselte DNS-Fallbacks.
• -AutoUpgrade $true → Stellt automatisch auf DoH um, wenn der Resolver es unterstützt.

Verwaltung über Gruppenrichtlinien (GPO)

In Unternehmensumgebungen kann DoH über Gruppenrichtlinien gesteuert werden. Dies ist besonders relevant, wenn Administrator:innen verhindern wollen, dass Benutzer:innen eigenständig andere Resolver konfigurieren.

GPO-Pfad:

Computerkonfiguration → Administrative Vorlagen → Netzwerk → DNS-Client

Wichtige Richtlinien:

• DNS über HTTPS aktivieren → Schaltet DoH systemweit ein oder aus.
• Liste der DoH-Resolver → Definiert die erlaubten Resolver-Adressen und zugehörigen HTTPS-Endpunkte.

Beispiel-Eintrag:

• Server: 1.1.1.1
• Template: https://cloudflare-dns.com/dns-query

Verhalten bei Mischbetrieb

Windows kann DoH auch dann nutzen, wenn nur ein Teil der Resolver in der Liste DoH unterstützt.
Die Reihenfolge ist wie folgt:

1. Prüfen, ob für den konfigurierten Resolver ein DoH-Endpunkt bekannt ist.
2. Falls ja → DoH-Verbindung aufbauen.
3. Falls nein → Fallback zu klassischem DNS (sofern nicht durch Richtlinie oder -AllowFallbackToUdp $false blockiert).

Gerade im Hybridbetrieb von internem DNS (AD) und externem DoH ist es wichtig, dass die Clients nicht versuchen, interne Domains über externe DoH-Resolver aufzulösen – hier helfen Conditional Forwarder und strikte GPOs.

DNS-over-HTTPS unter Windows Server 2025 – Aktueller Stand

Während die DoH-Clientunterstützung in Windows 11 mittlerweile weitgehend bekannt ist, wird oft übersehen, dass Windows Server bereits seit Windows Server 2022 in der Lage ist, als DNS-over-HTTPS-Client zu arbeiten – allerdings nicht als DoH-fähiger DNS-Server.

Für Administrator:innen bedeutet das:

• Ein Windows Server kann seine eigenen DNS-Anfragen (z.B. für Updates, Telemetrie oder als Forwarder) per DoH verschlüsseln
• Er kann jedoch keine DoH-Anfragen für andere Clients entgegennehmen oder selbst per HTTPS beantworten.

Windows Server als DNS-Client (Resolver)

Unterstützte Versionen:

• Windows Server 2022
• Windows Server 2025

Funktionsweise:

• DoH wird auf Systemebene im DNS-Clientdienst aktiviert, nicht in der DNS-Serverrolle
• Identisch zur Client-Implementierung in Windows 11
• Konfiguration über GUI, PowerShell oder Gruppenrichtlinien möglich

Praxisbeispiel:

Ein Windows Server 2025, der als Applikationsserver in einer DMZ steht, kann so konfiguriert werden, dass er externe Namensauflösungen ausschließlich über DoH-fähige Resolver durchführt, während interne Auflösungen weiterhin über einen internen DNS-Server laufen (Split-DNS-Ansatz).

Windows Server als DNS-Serverrolle

Auch wenn Windows Server 2022 und 2025 als DoH-Client arbeiten können, bleibt die DNS-Serverrolle aktuell auf das klassische DNS-Protokoll (UDP / TCP Port 53) beschränkt. Das bedeutet: Ein Windows-DNS-Server kann zwar selbst verschlüsselt zu einem Upstream-Resolver sprechen, nimmt aber keine DoH-Anfragen von Clients entgegen.

In einigen technischen Foren – unter anderem in Diskussionen auf der Microsoft Tech Community – wurde jedoch angedeutet, dass Microsoft perspektivisch einen DoH- oder DoT-fähigen DNS-Server bereitstellen könnte.

Ein solcher Schritt würde vor allem im Rahmen der Zero Trust DNS-Strategie Sinn ergeben, da so interne Clients direkt über verschlüsselte Kanäle mit einem Windows-DNS-Server kommunizieren könnten.

Ein offizielles Release-Datum oder verbindliche Roadmap gibt es derzeit jedoch nicht.

Aktueller Stand:

• Die DNS-Serverrolle in Windows Server 2022 und 2025 unterstützt kein DNS-over-HTTPS oder DNS-over-TLS für eingehende Anfragen
• Die Kommunikation zwischen Clients und dem Windows-DNS-Server erfolgt weiterhin über klassisches DNS (Port 53, UDP / TCP)
• Optional können DNSSEC-Signaturen für Zonen bereitgestellt werden – dies bietet Integritätsschutz, aber keine Verschlüsselung

Mögliche Konfiguration:

• Ein Windows-DNS-Server kann als Forwarder zu einem DoH-fähigen Upstream-Resolver agieren, wenn der Server selbst als Client konfiguriert ist
• Beispiel:
  1. Interner DNS-Server empfängt Client-Anfragen
  2. Für externe Domains leitet er die Anfrage an den DoH-Resolver weiter
  3. Der Transport zum Upstream-Resolver erfolgt verschlüsselt, die interne Client-Server-Kommunikation jedoch nicht

Implikationen für Unternehmensumgebungen

Die fehlende native DoH- / DoT-Serverunterstützung bedeutet:

• Interne Clients kommunizieren mit dem AD-DNS-Server weiterhin unverschlüsselt
• Externe Auflösung kann über DoH gesichert werden – entweder direkt am Client oder über den DNS-Server als Forwarder
• Für End-to-End-Verschlüsselung zwischen Client und Resolver sind aktuell Drittanbieter-Lösungen nötig (z.B. Technitium DNS Server, Unbound)

Zusammenfassung:

• DoH als Client: Seit Windows Server 2022 verfügbar, identisch zur Windows 11-Konfiguration
• DoH als Server: Aktuell nicht unterstützt – nur klassisches DNS oder DNSSEC möglich
• Empfehlung: DoH im Serverbetrieb gezielt für externe Namensauflösungen einsetzen, interne Kommunikation weiterhin über klassisches DNS abwickeln, bis Microsoft Zero Trust DNS als serverseitige Funktion verfügbar macht

Microsoft Zero Trust DNS – Blick in die Zukunft

Mit Zero Trust DNS verfolgt Microsoft das Ziel, die Namensauflösung zu einem identitäts- und richtliniengesteuerten Sicherheitsdienst zu machen. Der Ansatz erweitert klassische DoH- und DoT-Funktionalitäten deutlich und fügt sie nahtlos in die bestehende Zero Trust-Architektur von Microsoft ein.

Der Grundgedanke hinter Zero Trust DNS

Zero Trust DNS basiert auf den Prinzipien:

• Identitätsbasierte Namensauflösung – DNS-Abfragen werden im Kontext des authentifizierten Benutzers oder Geräts ausgewertet
• Integration in bestehende Sicherheitsdienste – Verknüpfung mit Microsoft Defender, Microsoft Entra ID (Azure AD), Microsoft Purview und Endpoint Manager
• Richtliniengesteuerte Kontrolle – Zugriff auf bestimmte Domains kann auf Basis von Benutzerrolle, Gerätezustand oder Standort erlaubt oder blockiert werden.

Das bedeutet: DNS wird nicht mehr als neutrales Transportprotokoll betrachtet, sondern als aktiver Bestandteil der Zugriffskontrolle – vergleichbar mit einer Firewallregel, nur auf Namensebene.

Aktueller Status (Preview)

Zero Trust DNS befindet sich derzeit noch in der Entwicklungs- und Testphase. Microsoft verfolgt hier einen schrittweisen Ansatz, um die Technologie zunächst im kontrollierten Umfeld zu erproben, bevor sie breiter ausgerollt wird.

Das hat den Vorteil, dass Feedback aus der Praxis direkt in die Weiterentwicklung einfließen kann – gleichzeitig bedeutet es aber, dass viele Funktionen derzeit nur in Cloud-basierten Testszenarien verfügbar sind.

• Private Preview: Angekündigt im Frühjahr 2024, zunächst mit ausgewählten Partnern und Unternehmenskunden getestet
• Public Preview: Seit 2025 für erweiterte Testgruppen verfügbar
• Zielumsetzung: Integration in Microsofts Cloud-Services mit Policy-Management über Microsoft 365 und Entra ID

Wichtiger Hinweis: Zero Trust DNS ist aktuell cloudzentriert. Das bedeutet, dass der Großteil der Funktionalität auf DNS-Resolvern in Microsofts Infrastruktur läuft – nicht lokal auf einem Windows Server. Eine spätere, hybride Variante, bei der ein lokaler Windows-Server als Zero Trust DNS-Endpoint agiert, ist denkbar, aber bisher nicht offiziell bestätigt.

Unterschiede zu reinem DoH oder DoT

Auf den ersten Blick mag Zero Trust DNS wie eine Weiterentwicklung von DoH oder DoT wirken – doch die Ziele und der Funktionsumfang sind deutlich umfassender.

Während DoH und DoT primär den Transportweg verschlüsseln, fügt Zero Trust DNS eine zusätzliche Sicherheitsebene hinzu, bei der Identität, Gerätezustand und Richtlinien eine zentrale Rolle spielen. Erst durch diesen Kontext wird DNS-Auflösung zu einem aktiven Bestandteil der Zugriffskontrolle.

• DoH / DoT: Sichern den Transportweg zwischen Client und Resolver – die Entscheidung, ob eine Domain aufgelöst wird, liegt rein beim Resolver
• Zero Trust DNS:
  • Ermöglicht Audit-Logging pro Benutzer / Gerät für Compliance-Zwecke
  • Führt zusätzliche Identitätsprüfung durch
  • Wendet feingranulare Richtlinien an, bevor die Anfrage beantwortet wird

Beispiel: Ein Benutzer mit einem nicht konformen Gerät versucht, devportal.example.com aufzulösen. DoH / DoT würden die Anfrage verschlüsselt weiterleiten – Zero Trust DNS würde die Anfrage blockieren, weil die Policy „Zugriff nur von compliant Devices“ verletzt ist.

Mögliche Auswirkungen auf die DNS-Architektur

Die Einführung von Zero Trust DNS wird nicht nur technische Konfigurationen verändern, sondern auch strategische Entscheidungen in Unternehmen beeinflussen. Die klassische Trennung zwischen internem und externem DNS könnte sich aufweichen, wenn Cloud-gestützte Resolver mit Policy-Integration Standard werden.

Gleichzeitig müssen bestehende Architekturen so angepasst werden, dass sie nahtlos mit Microsofts Sicherheits- und Compliance-Diensten zusammenarbeiten.

• Erweiterte Sichtbarkeit: DNS-Anfragen werden nicht nur als Netzwerkereignisse, sondern als sicherheitsrelevante Vorgänge im Microsoft 365 Security Center sichtbar
• Integration in Security-Stacks: DNS-Filterung wird Bestandteil von Conditional Access Policies
• Stärkere Cloud-Anbindung: Unternehmen, die Zero Trust DNS nutzen, werden DNS-Auflösung (teilweise) in Microsofts Resolver-Infrastruktur verlagern

Ausblick

Zero Trust DNS ist ein strategischer Schritt, der DNS-Sicherheit vom reinen Transport in die Identitäts- und Compliance-Ebene hebt. Gerade für Unternehmen mit Microsoft 365-Integration kann dies bedeuten:

• Bessere Transparenz über DNS-Aktivitäten
• Feinere Kontrolle auf Benutzerebene
• Konsistente Sicherheitsrichtlinien über Geräte, Standorte und Anwendungen hinweg

Für Administrator:innen heißt das aber auch:

• Die eigene DNS-Strategie muss Cloud-Integration berücksichtigen
• Lokale DNS-Server bleiben wichtig, benötigen aber klare Rollenverteilung in Hybrid-Szenarien

Zero Trust DNS – heute schon die Weichen stellen

Auch wenn Microsoft Zero Trust DNS aktuell noch in der Public Preview steckt, können Administrator:innen bereits jetzt technische und organisatorische Grundlagen schaffen, um später einen reibungslosen Umstieg zu ermöglichen.

1. Architektur und Rollenverteilung klären
   • Frühzeitig festlegen, welche Systeme künftig interne und welche externe Namensauflösung übernehmen
   • Lokale DNS-Server so konfigurieren, dass sie sich später flexibel als Forwarder zu Microsofts Resolvern anbinden lassen
2. DNS-Logging und Monitoring etablieren

• Bereits heute DNS-Abfragen zentral protokollieren (z.B. via Windows-DNS-Server, SIEM-Integration oder Defender for Endpoint)
• Logdaten nach Benutzer:innen oder Geräten differenzieren, um später die Zero-Trust-Policy-Zuordnung zu erleichtern

3. Policy-Framework vorbereiten

• Klare Regeln definieren, welche Domains aufgelöst werden dürfen, abhängig von Rolle, Standort oder Gerätezustand
• Testweise Conditional-Access-ähnliche Szenarien mit vorhandenen Tools umsetzen, um die Wirkung von Richtlinien zu verstehen

4. Identitätsintegration denken

• Prüfen, ob alle Endgeräte zuverlässig in Microsoft Entra ID (Azure AD) eingebunden sind
• Geräte-Compliance-Informationen in Intune pflegen, da Zero Trust DNS später darauf zurückgreifen wird

5. Testumgebungen schaffen

• Pilotgruppe aufbauen, die bereits heute mit einer Mischung aus klassischem DNS und Policy-basierten Filtern arbeitet
• Erfahrungen dokumentieren und Lessons Learned in das spätere Rollout einfließen lassen

Fazit:

Wer jetzt beginnt, Logging, Rollenverteilung und Policy-Strukturen sauber aufzubauen, kann Zero Trust DNS später fast nahtlos integrieren – und spart sich aufwendige Umbauten in der heißen Phase. Der Umstieg wird so eher ein „Policy-Upgrade“ als eine vollständige Neuarchitektur.

DoH in Active Directory-Umgebungen – Möglichkeiten und Grenzen

Active Directory ist in hohem Maße von einer korrekten und konsistenten DNS-Architektur abhängig. Jede Anmeldung, jede Gruppenrichtlinienverarbeitung und nahezu jede Domäneninteraktion beginnt mit einer DNS-Abfrage.

DNS-over-HTTPS kann hier zwar Sicherheit auf dem Transportweg schaffen – doch unüberlegte Implementierungen können schnell mehr Probleme verursachen als lösen.

Technische Hürden

Bevor DNS-over-HTTPS in einer Active-Directory-Umgebung eingeführt wird, müssen die grundlegenden technischen Abhängigkeiten verstanden werden. Active Directory verlässt sich vollständig auf eine funktionierende, interne Namensauflösung – jede Authentifizierung, Gruppenrichtlinienverarbeitung und Servicekommunikation hängt davon ab.

Bereits kleine Abweichungen von der vorgesehenen DNS-Architektur können gravierende Folgen haben, weshalb DoH hier nur mit klarer Strategie und präziser Umsetzung eingesetzt werden sollte.

• Interne Namensauflösung:
  AD-Clients benötigen Zugriff auf interne DNS-Zonen wie _ldap._tcp.domain.local oder _kerberos._tcp.domain.local; Diese Zonen werden ausschließlich von internen DNS-Servern (in der Regel Domänencontrollern) bereitgestellt
• Risiko der Umgehung:
  Wenn Clients externe DoH-Resolver nutzen, werden interne DNS-Namen nicht gefunden – was zu Anmeldefehlern, Gruppenrichtlinien-Problemen oder Dienstunterbrechungen führt
• Split-DNS-Komplexität:
  In Unternehmen, die interne und externe Zonen für denselben Namespace betreiben, kann die Verwendung externer DoH-Resolver zu inkonsistenten oder falschen Antworten führen

Beobachtungen aus der Praxis

In Projekten und Trainings zeigt sich immer wieder ein wiederkehrendes Muster: Administrator:innen haben in der Vergangenheit die DNS-Konfiguration von Clients bewusst so geändert, dass statt der internen Domänencontroller öffentliche Resolver wie 8.8.8.8 (Google) oder 1.1.1.1 (Cloudflare) verwendet wurden – meist mit der Absicht, die externe Namensauflösung zu beschleunigen.

Die Folgen waren regelmäßig gravierend:

• Gruppenrichtlinien wurden nicht oder nur teilweise angewendet
• Interne Dienste konnten nicht mehr oder nur unzuverlässig aufgelöst werden
• Kerberos-Authentifizierung schlug fehl
• Replikationsfehler zwischen Domänencontrollern traten auf

Mit der Einführung von DoH besteht die Gefahr, dass ein ähnliches Szenario ungewollt eintritt – etwa, wenn Benutzer:innen oder Anwendungen eigenständig einen DoH-Resolver konfigurieren, der interne DNS-Zonen nicht kennt.

Handlungsempfehlungen

Um DNS-over-HTTPS in Active Directory sicher einzusetzen, braucht es eine klare Governance und technische Kontrollen, damit die Vorteile der Verschlüsselung nicht durch Architekturbrüche zunichte gemacht werden.

Die folgenden Empfehlungen helfen, DoH so zu integrieren, dass interne Strukturen geschützt bleiben und externe Namensauflösung trotzdem sicher erfolgt.

• Aufklärung:
  Administrator:innen und Support-Teams sollten geschult werden, wie kritisch DNS für AD ist und warum unkontrollierte externe Resolver problematisch sind – unabhängig davon, ob DoH oder klassisches DNS genutzt wird
• Klarer Trennungsansatz:
  Interne Anfragen → ausschließlich über interne DNS-Server
  Externe Anfragen → ggf. über DoH-Forwarder oder direkt über externe Resolver, aber nur kontrolliert
• Überwachung:
  Einsatz von DNS-Logging und Netzwerkmonitoring, um unautorisierte DoH-Verbindungen zu erkennen
• Zentrale Steuerung:
  DoH-Resolver-Adressen sollten per GPO oder MDM festgelegt und nicht durch Endnutzer:innen änderbar sein

Merksatz:

In einer geschlossenen Active-Directory-Umgebung ist die Integrität der internen DNS-Struktur entscheidend. Extern konfigurierte Resolver – egal ob unverschlüsselt oder per DoH – untergraben diese Integrität und gefährden die Stabilität der gesamten Domäne.

Konfiguration per Gruppenrichtlinien (GPO)

In Unternehmensumgebungen ist es entscheidend, DNS-over-HTTPS (DoH) zentral zu steuern. Ohne klare Richtlinien riskieren Administrator:innen, dass Endgeräte eigenständig Resolver konfigurieren, die nicht in die Sicherheitsarchitektur passen – im schlimmsten Fall sogar interne DNS-Strukturen umgehen.

Die Gruppenrichtlinien von Windows bieten hier zwei große Vorteile:

1. Absicherung gegen Manipulation – Benutzer:innen können die Einstellungen nicht ohne Administratorrechte ändern.
2. Zentrale Verwaltung – Änderungen greifen auf allen verwalteten Clients automatisch.

Voraussetzungen für GPO-Verwaltung von DoH

• AD-Infrastruktur: Gruppenrichtlinienobjekte sollten in einer OU verlinkt werden, in der nur die Zielgeräte enthalten sind (Testphase empfohlen)
• Administrative Vorlagen: Aktuelle ADMX-Dateien für Windows 11 (mindestens Version 21H2) im zentralen Gruppenrichtlinienspeicher
• Betriebssystem: Windows 11 oder Windows Server 2022/2025 (als Client)
• Netzwerk: DoH-fähige Resolver müssen bekannt und erreichbar sein

GPO-Pfad für DoH-Einstellungen

Computerkonfiguration → Administrative Vorlagen → Netzwerk → DNS-Client

Hier stehen mehrere Richtlinien zur Verfügung, die direkt Einfluss auf das Verhalten von DoH nehmen.

Wichtige Richtlinien und ihre Funktion

1. DNS über HTTPS aktivieren

• • Schaltet DoH systemweit ein oder aus.
  • Optionen:
    • Nicht konfiguriert → Standardverhalten des Systems
    • Aktiviert → DoH für alle konfigurierten Resolver einschalten
    • Deaktiviert → DoH vollständig deaktivieren

Liste der DoH-Resolver

• Definiert die erlaubten Resolver-Adressen und die zugehörigen HTTPS-Endpunkte
• Syntax:
  Serveradresse, DoH-Template
  Beispiel:
  1.1.1.1, https://cloudflare-dns.com/dns-query
  8.8.8.8, https://dns.google/dns-query

3. Fallback zu unverschlüsseltem DNS zulassen

• • Steuerung, ob bei nicht erreichbarem DoH-Endpunkt automatisch auf klassisches DNS zurückgefallen wird
  • Empfehlung: Deaktivieren, um sicherzustellen, dass keine unverschlüsselten Abfragen stattfinden

Beispielkonfiguration für eine Unternehmensumgebung

Ziel:

• Interne Domains weiterhin über interne AD-DNS-Server
• Externe Domains über DoH-Resolver (Cloudflare / Google)
• Kein Fallback auf unverschlüsseltes DNS

Umsetzung:

1. GPO erstellen und mit Ziel-OU verknüpfen
2. Richtlinie „DNS über HTTPS aktivieren“ → Aktiviert
3. Richtlinie „Liste der DoH-Resolver“ →
   1.1.1, https://cloudflare-dns.com/dns-query
   8.8.8.8, https://dns.google/dns-query
4. Richtlinie „Fallback zu unverschlüsseltem DNS zulassen“ → Deaktiviert

Praxis-Tipp:

In gemischten Umgebungen mit internem und externem DNS kann zusätzlich mit Bedingten Weiterleitungen im internen DNS-Server gearbeitet werden, damit externe Abfragen gezielt an die konfigurierten DoH-Resolver weitergeleitet werden.

Microsoft Edge-spezifische DoH-Policies

Auch wenn DoH auf Betriebssystemebene über den Windows-DNS-Client gesteuert werden kann, bietet Microsoft Edge zusätzliche Richtlinien, um DoH nur im Browser zu erzwingen oder abweichend vom Systemverhalten zu konfigurieren.

Das ist besonders relevant in Szenarien wie BYOD, Gäste-WLAN oder Zero Trust Network Access, in denen der Browser eine separate Sicherheitsdomäne darstellt.

Warum Edge-Policies separat wichtig sind

Bevor wir uns den konkreten Edge-Policies widmen, lohnt sich ein Blick auf den Grund, warum browserseitige DoH-Einstellungen überhaupt separat von den Betriebssystemrichtlinien betrachtet werden sollten.

Gerade in heterogenen Umgebungen mit BYOD-Geräten oder geteilten Netzwerken
kann der Browser als isolierte Sicherheitsinstanz agieren und damit zusätzlichen Schutz bieten – unabhängig von der Konfiguration des Windows-DNS-Clients.

• Gezielte Steuerung von Web-Traffic:
  Unternehmen können DoH im Browser erzwingen, ohne andere Anwendungen auf dem Client zu beeinflussen
• Schnelle Umsetzung in kontrollierten Umgebungen:
  DoH im Browser lässt sich oft schneller testen und ausrollen als systemweite DNS-Änderungen
• Unabhängigkeit vom OS-Stack:
  Selbst wenn auf Betriebssystemebene DoH deaktiviert ist,
  kann Edge DNS-Anfragen verschlüsselt an einen konfigurierten Resolver senden

Relevante Edge-Policies für DoH

Microsoft Edge stellt eine Reihe von Gruppenrichtlinien- und MDM-Optionen bereit, mit denen sich das Verhalten von DoH im Browser granular steuern lässt.

Diese Einstellungen sind besonders interessant für Administrator:innen, die Web-Traffic gezielt absichern möchten, ohne gleich die DNS-Auflösung für das gesamte System umzustellen.

GPO-/MDM-Pfad:

Computerkonfiguration → Administrative Vorlagen → Microsoft Edge → DNS-over-HTTPS-Einstellungen

Wichtige Richtlinien:

1. DnsOverHttpsMode
   • Steuert, ob und wie DoH im Browser aktiviert wird.
   • Werte:
     • automatic – DoH aktiv, wenn der Resolver es unterstützt
     • off – DoH deaktiviert
     • secure – DoH erzwingen (nur verschlüsselte DNS-Anfragen zulassen)

2. DnsOverHttpsTemplates
   • Definiert die HTTPS-Endpunkte für DoH-fähige Resolver.
   • Syntax:
     https://resolver.example.com/dns-query
     Beispiele:
     Cloudflare: https://cloudflare-dns.com/dns-query
     Google: https://dns.google/dns-query

Beispielkonfiguration für Edge im Unternehmensumfeld

Um die Funktionsweise dieser Policies greifbarer zu machen, sehen wir uns eine praxisnahe Konfiguration an, wie sie in Unternehmen typischerweise umgesetzt wird.

Das Beispiel zeigt, wie DoH im Browser konsequent erzwungen und gleichzeitig auf einen einzigen, vertrauenswürdigen Resolver beschränkt wird.

Ziel:

• DoH im Browser erzwingen, unabhängig vom Betriebssystem
• Nur Cloudflare als Resolver zulassen

Umsetzung (GPO oder MDM):

1. DnsOverHttpsMode → Wert: secure
2. DnsOverHttpsTemplates → Wert:
   https://cloudflare-dns.com/dns-query

Ergebnis:

• Edge nutzt ausschließlich DoH über Cloudflare
• Wenn der Resolver nicht erreichbar ist, schlägt die DNS-Auflösung im Browser fehl (kein Fallback)

Praxis-Tipps

Die Umsetzung von DoH in Edge ist technisch schnell erledigt – der Erfolg hängt jedoch stark von der Koordination mit bestehenden Richtlinien und Prozessen ab.

Damit die Einführung reibungslos verläuft, sollten Administrator:innen sowohl technische als auch organisatorische Aspekte berücksichtigen und DoH in Edge nicht als isolierte Maßnahme betrachten, sondern als Teil einer Gesamtstrategie für DNS-Sicherheit.

• Koordination mit OS-DoH-Policies:
  Edge-DoH sollte nicht im Widerspruch zu systemweiten Richtlinien stehen –
  sonst kommt es zu inkonsistentem Verhalten bei der Auflösung
• Monitoring und Logging:
  Auch wenn Edge eigenständig DoH nutzt, sollten DNS-Abfragen zentral überwacht werden (z.B. über Cloudflare Gateway, Microsoft Defender for Endpoint)
• Pilotgruppen nutzen:
  Vor flächendeckender Aktivierung empfiehlt sich ein Test mit einer kleinen Benutzergruppe, um potenzielle Kompatibilitätsprobleme zu erkennen

Erweiterte Einsatzmöglichkeiten

DNS-over-HTTPS (DoH) und Zero Trust DNS bieten nicht nur Schutz vor Manipulationen auf dem Transportweg, sondern eröffnen auch neue Möglichkeiten, wie DNS in komplexen Unternehmens- und Hybridumgebungen eingesetzt werden kann.

Insbesondere in Szenarien mit flexiblen Arbeitsorten, BYOD-Geräten und Cloud-Diensten kann die DNS-Strategie entscheidend zur Gesamtsicherheit beitragen.

BYOD-Strategien (Bring Your Own Device)

In BYOD-Umgebungen haben Unternehmen oft nur eingeschränkte Kontrolle über das Betriebssystem der Endgeräte. DoH auf Browser-Ebene (z.B. über Microsoft Edge-Policies) bietet hier die Möglichkeit, DNS-Anfragen zu verschlüsseln und an vertrauenswürdige Resolver zu senden – selbst wenn die lokale DNS-Konfiguration des Geräts unsicher ist.

Vorteile:

• Absicherung von Web-Traffic auch ohne vollständige Geräteverwaltung
• Kombinierbar mit Cloud-basierten DNS-Filtern für Content- und Malware-Blockierung
• Vermeidung von DNS-Leaks in unsicheren Netzwerken

Zero Trust Access Integration

DoH kann in eine Zero Trust Network Access (ZTNA)-Architektur integriert werden,
indem DNS-Anfragen nur dann aufgelöst werden, wenn das Gerät und der Benutzer bestimmte Sicherheitskriterien erfüllen.

Beispiele:

• Blockierung von Hochrisiko-Domains basierend auf Threat-Intelligence-Feeds
• Durchsetzung von Zugriffsrichtlinien bereits auf Namensebene, bevor Verbindungen entstehen
• Zugriff auf interne Ressourcen nur bei compliantem Gerät (z.B. über Microsoft Intune validiert)

DNS-Filterung und Content-Kontrolle

DoH lässt sich mit DNS-Filterdiensten kombinieren, um Bedrohungen und unerwünschte Inhalte schon bei der Namensauflösung zu blockieren. Dabei können öffentliche Dienste wie Cloudflare Gateway, Quad9 oder Cisco Umbrella genutzt werden – oder in Zukunft Microsofts eigenes Zero Trust DNS.

Mögliche Filterkategorien:

• Command-and-Control-Server (C2)
• Glücksspiel-, Streaming- oder Social-Media-Seiten (Compliance-Anforderungen)
• Phishing- und Malware-Domains

VPN-Integration und Split-Tunneling

In Remote-Arbeitsumgebungen ist die Integration von DoH in VPN-Konzepte besonders interessant. Durch Split-Tunneling kann gesteuert werden, dass interne DNS-Anfragen über den VPN-Tunnel und interne Resolver laufen, während externe Anfragen verschlüsselt über DoH an vertrauenswürdige öffentliche Resolver gehen.

Vorteile:

• Beibehaltung der Sicherheit durch verschlüsselten Transport
• Entlastung des VPN-Gateways
• Schnellere externe Namensauflösung

Fazit:
Die erweiterten Einsatzmöglichkeiten von DoH und Zero Trust DNS zeigen, dass DNS längst nicht mehr nur eine grundlegende Netzwerkfunktion ist, sondern ein aktiver Bestandteil moderner Sicherheits- und Zugriffskontrollkonzepte sein kann.

Richtig integriert, lassen sich damit sowohl Sicherheitslücken schließen als auch Performance-Vorteile erzielen.

Sicherheitstechnische Bewertung und Best Practices

DNS ist seit Jahrzehnten ein zentrales Fundament des Internets – doch seine ursprüngliche Entwicklung fand in einer Zeit statt, in der Sicherheit kaum eine Rolle spielte.

Mit DNS-over-HTTPS (DoH) und modernen Konzepten wie Zero Trust DNS lassen sich viele dieser Altlasten kompensieren, indem Abfragen verschlüsselt, Manipulationen erschwert und zusätzliche Richtlinienkontrollen möglich werden.

Allerdings ist klar: DoH ist kein Allheilmittel – und die Umsetzung erfordert Planung.

Sicherheitstechnische Bewertung

Bevor konkrete Handlungsempfehlungen ausgesprochen werden, ist es wichtig, DoH und Zero Trust DNS aus sicherheitstechnischer Sicht nüchtern zu bewerten. Nur so lässt sich einschätzen, wo diese Technologien tatsächlich Mehrwert bieten – und an welchen Stellen sie möglicherweise Risiken oder neue Herausforderungen mit sich bringen.

Die folgende Gegenüberstellung beleuchtet Stärken und Schwächen im praktischen Einsatz.

Stärken von DoH und Zero Trust DNS:

• Integration in Sicherheits- und Compliance-Workflows
• Konsistenz durch zentrale Resolver-Konfiguration
• Reduzierte Angriffsfläche durch Blockierung bekannter Schad-Domains
• Verschlüsselung schützt vor Man-in-the-Middle- und Sniffing-Angriffen

Schwächen und Risiken:

• Abhängigkeit von externen Resolvern (Ausfallszenarien, Datenhoheit)
• Gefahr der Umgehung interner DNS-Strukturen in AD-Umgebungen
• Mögliche Performanceeinbußen bei schlecht angebundenen DoH-Servern
• Potenziell erschwerte Fehlersuche durch verschlüsselte Abfragen

Best Practices für den sicheren Einsatz

Aus den zuvor dargestellten Chancen und Risiken ergeben sich klare Handlungsleitlinien. Diese Best Practices sollen Administrator:innen dabei helfen, DoH und Zero Trust DNS so zu implementieren, dass sie den größtmöglichen Sicherheitsgewinn bringen und gleichzeitig reibungslos in die bestehende IT-Landschaft integriert werden.

Der Fokus liegt auf planvoller Einführung, technischer Konsistenz und kontinuierlicher Kontrolle.

1. Fallbacks bewusst konfigurieren
   • Fallback auf unverschlüsseltes DNS nur in definierten Ausnahmefällen zulassen
2. Klare Architekturentscheidungen treffen
   • Festlegen, welche Anfragen intern und welche extern aufgelöst werden
   • Interne DNS-Struktur in AD-Umgebungen unbedingt schützen
3. Monitoring etablieren
   • DoH-Verbindungen im Netzwerk überwachen
   • Threat-Intelligence-Feeds zur DNS-Filterung integrieren
4. Schrittweise Einführung
   • Zunächst in Test-OUs oder Pilotgruppen ausrollen
   • Enges Feedback mit Support-Teams und Fachabteilungen sicherstellen
5. Zentrale Verwaltung nutzen
   • GPOs oder MDM-Policies für Resolver-Adressen einsetzen
   • Browser-Policies (Edge) mit OS-Policies abstimmen

Ausblick

Mit der weiteren Verbreitung von Zero Trust DNS und der möglichen Einführung von DoH-fähigen Windows-DNS-Servern dürfte sich die Nutzung verschlüsselter Namensauflösung in Unternehmensnetzen deutlich erhöhen.

Für Administrator:innen bedeutet das:

• Integration statt Insellösung – DNS-Sicherheit muss eingebettet in das gesamte Sicherheitskonzept gedacht werden
• Planung vor Aktion – jede Implementierung muss die bestehende Infrastruktur berücksichtigen
• Schulung und Sensibilisierung – sowohl im IT-Team als auch bei Endanwender:innen

Fazit:

DoH und Zero Trust DNS sind mächtige Werkzeuge, um die Integrität und Vertraulichkeit von DNS-Anfragen zu sichern. Richtig eingesetzt, stärken sie nicht nur die technische Sicherheit, sondern auch die Resilienz einer Organisation gegenüber modernen Angriffsszenarien.

Ohne klare Architektur, Governance und kontinuierliche Überwachung kann der erhoffte Sicherheitsgewinn jedoch schnell verpuffen.

Zusammenfassung und Fazit

Die Namensauflösung ist seit den frühen Tagen des Internets ein zentrales Fundament der digitalen Kommunikation. Doch die ursprüngliche Architektur des Domain Name System (DNS) wurde zu einer Zeit entworfen, in der Sicherheitsbedrohungen überschaubar waren und die Netzwerke als vertrauenswürdig galten.

Heute ist klar: Ohne Schutzmechanismen ist DNS eine potenziell verwundbare Stelle in jeder IT-Infrastruktur.

Mit DNS-over-HTTPS (DoH) und dem Konzept des Zero Trust DNS stehen Unternehmen und Administrator:innen zwei Werkzeuge zur Verfügung, die sowohl Vertraulichkeit als auch Integrität der Namensauflösung verbessern können.

DoH verschlüsselt DNS-Anfragen und schützt so vor Abhören und Manipulationen auf dem Transportweg. Zero Trust DNS erweitert diesen Ansatz um eine kontextbasierte Zugriffskontrolle und Policy Enforcement.

Kernbotschaften des Beitrags:

• DNS ist ein kritischer Bestandteil moderner IT-Sicherheit und darf nicht isoliert betrachtet werden
• DoH bietet Schutz vor klassischen Angriffsvektoren wie Man-in-the-Middle, bringt aber in komplexen Umgebungen – insbesondere mit Active Directory – neue Herausforderungen mit sich
• Zero Trust DNS ist ein Baustein einer umfassenderen Sicherheitsstrategie, deren Fokus klar auf Cloud- und Hybrid-Szenarien liegt
• Die Einführung sollte schrittweise, kontrolliert und in enger Abstimmung mit bestehenden Prozessen erfolgen

Fazit

Die Zukunft der DNS-Sicherheit wird von Verschlüsselung, zentraler Steuerung und kontextabhängiger Zugriffskontrolle geprägt sein. Windows 11 und Windows Server 2025 bieten dafür bereits heute die technischen Grundlagen, sei es über systemweite DoH-Konfigurationen oder Edge-spezifische Policies.

Wer jetzt mit einer klaren Strategie beginnt, legt den Grundstein für eine widerstandsfähige Namensauflösung – und damit für ein stabileres, sichereres Netzwerk.

Quellenverzeichnis

(Abgerufen am 10.08.2025)

Offizielle Microsoft-Dokumentation

• DNS over HTTPS (DoH) client support in Windows
• Microsoft Edge – Richtlinie „DnsOverHttpsMode“
• Microsoft Edge – Richtlinie „DnsOverHttpsTemplates“

Microsoft Tech Community & Ankündigungen

• Announcing Public Preview of Zero Trust DNS
• Announcing Zero Trust DNS – Private Preview
• DNS, DoH and DoT – Windows Server 2025 Discussion

Weitere Quellen

• Cygnalabs: Why DNS security is the missing link in Zero Trust strategies
• Infoblox: The essential role of Zero Trust DNS in modern security
• Microsoft: What is Zero Trust Architecture?
• TechRadar: Microsoft just gave us a first look at the future of its DNS services

Weiterlesen hier im Blog

• Copilot in Microsoft 365 und Dynamics 365 – Von intelligenten Assistenten zu autonomen Agenten
• Intelligente Agenten mit Copilot Studio – KI-gestützte Automatisierung im Microsoft-Ökosystem
• Vertrauenswürdige KI in der Praxis – Regulierung, Sicherheit und Verantwortung im Zeitalter des AI Act
• Warum jedes Bit seinen Weg braucht – Der Weg zur intelligenten Kommunikation
• Windows Server 2025 – What’s New?