DNS – Grundlagen

Was ist DNS – und warum brauchen wir es?

Stell dir vor, du musst dir für jede Website, die du aufrufst, eine vierstellige Zahlenkombination merken – 172.217.16.4 für Google, 31.13.93.35 für Facebook, und so weiter. Das wäre schlicht nicht praktikabel. Genau deshalb gibt es das Domain Name System (DNS): Es ist das Telefonbuch des Internets.

DNS übersetzt lesbare Hostnamen wie google.com oder intranet.firma.ch in IP-Adressen, mit denen Netzwerkgeräte tatsächlich kommunizieren. Der Prozess nennt sich Namensauflösung (englisch: name resolution).

Als IT-Allrounder im KMU bist du mit DNS täglich konfrontiert – egal ob jemand nicht auf eine Website kommt, Mails gebounced werden, oder du eine neue Domain einrichtest. DNS verstehen ist keine Option, es ist Grundvoraussetzung.

Wie eine DNS-Abfrage abläuft

Wenn du im Browser www.firma.ch eingibst, passiert im Hintergrund folgendes:

1. Lokaler Cache: Dein Computer prüft zuerst seinen eigenen DNS-Cache. Ist der Eintrag dort, geht es direkt weiter.
2. Hosts-Datei: Windows schaut in C:\Windows\System32\drivers\etc\hosts – manuelle Einträge hier haben Vorrang.
3. Resolver (DNS-Client): Der PC fragt den konfigurierten DNS-Server (meist der Router oder ein AD-DC im Firmennetz).
4. Rekursive Auflösung: Kennt dieser Server die Antwort nicht, fragt er seinerseits andere Server:
   • Root-Nameserver (13 weltweit, z.B. a.root-servers.net) – kennen die Top-Level-Domain-Server
   • TLD-Nameserver (z.B. für .ch zuständig: Switch) – kennen den autoritativen Nameserver der Domain
   • Autoritativer Nameserver der Domain – hat die endgültige Antwort mit dem gewünschten Record
5. Der Resolver gibt die IP zurück und speichert sie für die Dauer der TTL im Cache.

DNS-Record-Typen im Überblick

Jede Domain hat eine Zone – eine Sammlung von DNS-Einträgen (Records). Die wichtigsten Typen:

A-Record: Der häufigste Record. Verknüpft einen Namen direkt mit einer IPv4-Adresse. Pro Hostname sind mehrere A-Records möglich (Load Balancing / Redundanz).

CNAME: Alias auf einen anderen Namen, nie direkt auf eine IP. Wichtig: Auf einem MX-Record darf kein CNAME stehen – das ist laut RFC nicht zulässig und führt zu Mailproblemen.

MX-Record mit Priorität: Mehrere MX-Records sind möglich. Niedrigere Prioritätszahl = bevorzugter Server. Fällt der primäre Mailserver aus, übernimmt der mit der nächsthöheren Zahl.

# Beispiel Zone firma.ch
firma.ch.    3600  IN  MX  10  mail1.firma.ch.
firma.ch.    3600  IN  MX  20  mail2.firma.ch.

TTL – Time to Live

Jeder DNS-Record hat eine TTL in Sekunden. Sie legt fest, wie lange ein Resolver (oder dein Browser-Cache) den Eintrag zwischenspeichern darf, bevor er ihn neu abfragen muss.

Mail-Security: SPF, DKIM und DMARC

Drei TXT-Records sind für die Mail-Zustellbarkeit entscheidend. Fehlen sie, landen Mails im Spam – oder werden gar nicht angenommen.

SPF – Sender Policy Framework

Legt fest, welche Server berechtigt sind, Mails für deine Domain zu versenden.

firma.ch.  TXT  "v=spf1 include:spf.protection.outlook.com ~all"

• include: – Welche externen Dienste dürfen Mails senden (Exchange Online, Mailchimp, usw.)
• ~all – Alle anderen Server: Softfail (wird als Spam markiert, aber angenommen)
• -all – Alle anderen Server: Hardfail (Mail wird abgelehnt) – strenger, empfohlen

DKIM – DomainKeys Identified Mail

Jede ausgehende Mail wird vom Mailserver mit einem privaten Schlüssel signiert. Im DNS liegt der öffentliche Schlüssel, den der empfangende Server zur Verifikation nutzt.

selector1._domainkey.firma.ch.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0..."

Der Selektor (hier selector1) erlaubt mehrere DKIM-Keys parallel – wichtig bei Diensten wie Mailchimp oder Exchange Online.

DMARC – Domain-based Message Authentication, Reporting & Conformance

Definiert, was passieren soll, wenn SPF oder DKIM fehlschlagen:

_dmarc.firma.ch.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@firma.ch"

• p=none – Nur monitoring, keine Aktion
• p=quarantine – In Spam verschieben
• p=reject – Ablehnen

DNSSEC: DNS-Antworten kryptografisch absichern

Normales DNS hat einen fundamentalen Schwachpunkt: Ein Client kann nicht prüfen, ob die Antwort wirklich vom autoritativen Server stammt oder unterwegs gefälscht wurde (siehe Cache Poisoning weiter unten). DNSSEC (Domain Name System Security Extensions) schliesst diese Lücke, indem es DNS-Antworten digital signiert.

Drei neue Record-Typen sind dafür zuständig:

Ein validierender Resolver läuft die Kette von unten nach oben durch: Er prüft die RRSIG gegen den DNSKEY, vergleicht den DS-Hash mit dem KSK, und so weiter bis zur Root-Zone. Passt irgendwo etwas nicht zusammen, liefert der Resolver SERVFAIL statt der (möglicherweise gefälschten) Antwort. Diese lückenlose Verkettung nennt man Chain of Trust.

DNSSEC auf einem Windows-DNS-Server aktivieren

# Signing Keys erzeugen (KSK + ZSK mit Standardparametern)
Add-DnsServerSigningKey -ZoneName "firma.ch" -Type KeySigningKey -CryptoAlgorithm RsaSha256
Add-DnsServerSigningKey -ZoneName "firma.ch" -Type ZoneSigningKey -CryptoAlgorithm RsaSha256

# Zone mit den Standardeinstellungen signieren
Invoke-DnsServerZoneSign -ZoneName "firma.ch" -SignWithDefault -Force

# Öffentlichen Schlüssel exportieren, um den DS-Record beim Registrar zu hinterlegen
Export-DnsServerDnsSecPublicKey -ZoneName "firma.ch" -Path "C:\dnssec\firma.ch.key"

Der letzte, oft vergessene Schritt: Den erzeugten DS-Record beim Domain-Registrar (z.B. bei Switch für .ch) eintragen. Ohne diesen Eintrag in der Elternzone bleibt die Kette unterbrochen und Resolver validieren nichts.

DNS im Windows-Netzwerk (Active Directory)

In einer AD-Umgebung läuft DNS immer auf dem Domain Controller. Die interne Domain (z.B. firma.local oder firma.ch) wird dort verwaltet. Clients sind so konfiguriert, dass sie den DC als primären DNS-Server nutzen.

Warum ist das wichtig? AD ist auf DNS angewiesen – ohne funktionierende Namensauflösung:

• Kein Domänen-Login möglich
• GPOs werden nicht angewendet
• Replikation zwischen DCs schlägt fehl

Wenn ein Domänen-PC plötzlich mit Problemen kämpft, prüf zuerst: Kommt er an seinen DNS-Server?

# DNS-Konfiguration des Clients anzeigen
Get-DnsClientServerAddress

# DNS-Cache des Clients leeren
Clear-DnsClientCache

# Aktuellen Cache anzeigen
Get-DnsClientCache

Windows-DNS-Server administrieren: Zonentypen und Forwarder

Auf dem DNS-Server selbst unterscheidest du mehrere Zonentypen:

Für die Auflösung fremder Domains stehen zwei Mechanismen zur Verfügung:

• Standard-Forwarder: Der DNS-Server leitet alle Anfragen, die er nicht selbst beantworten kann, an einen zentralen Forwarder weiter (z.B. den Provider-DNS oder 8.8.8.8).
• Konditionaler Forwarder: Nur Anfragen für eine bestimmte Domain werden an einen definierten Server weitergeleitet. Das ist der Standardfall bei Standortkopplungen, Firmenübernahmen oder AD-Trusts, wenn zwei Firmen-Domains sich gegenseitig auflösen müssen sollen, ohne dass die Zonen komplett dupliziert werden.

# Konditionalen Forwarder für die Partnerdomain anlegen, AD-weit repliziert
Add-DnsServerConditionalForwarderZone -Name "partnerfirma.ch" `
    -ReplicationScope "Forest" `
    -MasterServers 10.20.0.10,10.20.0.11

# Bestehenden Forwarder anpassen (z.B. Timeout, weiteren Master-Server ergänzen)
Set-DnsServerConditionalForwarderZone -Name "partnerfirma.ch" `
    -MasterServers 10.20.0.10,10.20.0.11,10.20.0.12

# Standard-Forwarder des Servers auslesen bzw. setzen
Get-DnsServerForwarder
Set-DnsServerForwarder -IPAddress 1.1.1.1,8.8.8.8

Scavenging und Aging: veraltete Records automatisch aufräumen

Clients, die per DHCP eine IP beziehen, tragen ihren A-Record oft per Dynamic DNS Update selbst in die Zone ein. Wird ein Notebook ausgemustert oder ein Rechnername geändert, bleibt der alte Eintrag sonst für immer stehen – sogenannte Karteileichen. Mit der Zeit sammeln sich Hunderte verwaiste Records an, die Fehlersuche erschweren und im schlimmsten Fall zu Namenskonflikten führen.

Aging versieht dynamische Records mit einem Zeitstempel. Scavenging löscht Records, die zwei Intervalle überschritten haben:

• No-Refresh-Intervall (Standard 7 Tage): In dieser Zeit wird ein Refresh-Update vom Server ignoriert (verhindert unnötigen Replikationsverkehr)
• Refresh-Intervall (Standard 7 Tage): Danach muss der Eintrag erneuert werden – geschieht das nicht, gilt er als stale

Scavenging muss auf zwei Ebenen aktiviert werden: am Server (erlaubt das Aufräumen grundsätzlich) und an der Zone (markiert diese Zone dafür).

# Scavenging auf Serverebene aktivieren, Intervall 7 Tage
Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 -ApplyOnAllZones

# Aging für eine konkrete Zone aktivieren
Set-DnsServerZoneAging -Name "firma.local" -Aging $true `
    -RefreshInterval 7.00:00:00 -NoRefreshInterval 7.00:00:00

# Aktuellen Stand prüfen
Get-DnsServerScavenging
Get-DnsServerZoneAging -Name "firma.local"

Zonentransfers absichern

Sekundäre DNS-Server holen sich den Zoneninhalt per Zonentransfer (AXFR für den vollständigen, IXFR für den inkrementellen Transfer) vom Primärserver. Ist ein Zonentransfer für jeden offen, kann ein Angreifer mit einer simplen Anfrage die komplette interne Namensstruktur auslesen – Hostnamen, IP-Schema, oft sogar Rückschlüsse auf Serverrollen. Das ist klassische Aufklärung (Reconnaissance) vor einem gezielten Angriff.

# Zonentransfer nur an Server erlauben, die als NS-Record der Zone eingetragen sind
Set-DnsServerPrimaryZone -Name "firma.ch" -SecureSecondaries "TransferToZoneNameServer"

# Alternativ: nur an explizit gelistete IP-Adressen
Set-DnsServerPrimaryZone -Name "firma.ch" -SecureSecondaries "TransferToSecureServers" `
    -SecondaryServers 10.0.0.20,10.0.0.21

Zum schnellen Testen von aussen, ob eine Zone offen ist (nur zu Diagnosezwecken auf eigenen Domains einsetzen):

nslookup
> server ns1.firma.ch
> set type=AXFR
> ls -d firma.ch

Antwortet der Server mit der vollständigen Zone, ist der Transfer offen – ein klassischer Fund in jedem externen Pentest-Report und meist mit wenigen Klicks zu schliessen.

Split-Horizon-DNS (Split-Brain-DNS)

Viele Firmen betreiben denselben Domainnamen sowohl intern als auch extern – z.B. soll owa.firma.ch von aussen auf die öffentliche IP der Firewall zeigen, von innen aber direkt auf die private IP des Exchange-Servers, um den Umweg über NAT und Firewall zu vermeiden (“Hairpin NAT”). Diese Technik heisst Split-Horizon-DNS (auch Split-Brain-DNS): derselbe Name liefert je nach Standort des Anfragenden eine andere Antwort.

Der klassische Ansatz unter Windows: Für die öffentliche Domain firma.ch existiert eine zweite, interne Kopie der Zone auf dem AD-DNS-Server. Diese enthält nur die Records, die intern abweichen (z.B. owa.firma.ch); alle anderen Records werden identisch gepflegt oder per Forwarder an den öffentlichen DNS weitergereicht.

Seit Windows Server 2016 geht das eleganter über DNS Policies und Zone Scopes – ohne zwei komplette Zonen parallel pflegen zu müssen:

# Zusätzlichen Scope für externe Anfragen in der Zone anlegen
Add-DnsServerZoneScope -ZoneName "firma.ch" -Name "extern"

# Record nur im externen Scope anlegen (öffentliche IP)
Add-DnsServerResourceRecord -ZoneName "firma.ch" -A -Name "owa" `
    -IPv4Address "203.0.113.10" -ZoneScope "extern"

# Record im Standard-Scope (intern) anlegen (private IP)
Add-DnsServerResourceRecord -ZoneName "firma.ch" -A -Name "owa" -IPv4Address "10.0.0.25"

# Policy: Anfragen vom externen Interface bekommen den "extern"-Scope
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainPolicy" -Action ALLOW `
    -ServerInterfaceIP "eq,203.0.113.1" -ZoneScope "extern,1" -ZoneName "firma.ch"

DNS als Angriffsvektor: Cache Poisoning und DNS-Tunneling

DNS geniesst oft blindes Vertrauen im Netzwerk – ein guter Grund, warum es auch als Angriffswerkzeug missbraucht wird.

Cache Poisoning (DNS Spoofing): Ein Angreifer schleust gefälschte Antworten in den Cache eines Resolvers ein, bevor die echte Antwort eintrifft. Nutzer, die danach den betroffenen Hostnamen abfragen, landen unbemerkt auf einer bösartigen IP (z.B. einer Phishing-Seite statt der echten Banking-Website). Gegenmassnahmen: DNSSEC-Validierung (siehe oben), zufällige Source-Ports und Transaction-IDs (moderne Resolver machen das automatisch), sowie DNS-Server, die nicht unnötig öffentlich rekursiv erreichbar sind.

DNS-Tunneling: DNS-Anfragen dürfen praktisch jede Firewall passieren – ein Umstand, den Malware ausnutzt, um Daten zu exfiltrieren oder Command-and-Control-Kommunikation zu tunneln. Dabei werden Nutzdaten in TXT- oder Sub-Domain-Labels codiert versteckt, z.B.:

YWRtaW5wYXNzd29yZDEyMw.data.exfil-domain.com

Typische Warnsignale in Logs: ungewöhnlich viele TXT-Abfragen, sehr lange Sub-Domain-Namen, hohe Abfragefrequenz zu einer einzelnen externen Domain, oder Traffic zu Domains mit sehr kurzer TTL und häufig wechselnden Zielen. Ein Monitoring-Setup mit Log-Auswertung (siehe unten und Monitoring – Grundlagen) und ein sauber konfiguriertes SIEM/SOC helfen, solche Muster zu erkennen. Grundlagen zu Netzwerk-Absicherung generell findest du unter IT-Security – Grundlagen für KMU.

DoH und DoT: verschlüsseltes DNS und die Monitoring-Falle

Klassisches DNS ist unverschlüsselt – jeder auf dem Übertragungsweg kann mitlesen oder manipulieren. Zwei Standards verschlüsseln die Anfrage:

Für Privatanwender ist das ein Gewinn an Privatsphäre. Für Unternehmen ist es ein Monitoring-Problem: Browser wie Firefox oder Chrome aktivieren DoH teils automatisch und leiten DNS-Anfragen an externe Resolver (z.B. Cloudflare oder Google), am firmeneigenen DNS-Server komplett vorbei. Das hebelt DNS-basierte Sicherheitsfunktionen aus – Content-Filter, Malware-Domain-Blocklisten und die forensische Auswertbarkeit über Logs greifen schlicht nicht mehr, weil die Anfrage den internen Server nie erreicht.

Praktische Gegenmassnahmen im Unternehmensumfeld:

• DoH in Browsern per GPO/Intune-Richtlinie deaktivieren bzw. auf den internen Resolver zwingen (z.B. DnsOverHttpsMode als Chrome-/Edge-Policy)
• Ausgehenden Traffic zu bekannten öffentlichen DoH-Endpunkten auf der Firewall blockieren, sofern kein expliziter Bedarf besteht
• DoT lässt sich einfacher als DoH kontrollieren – Blockieren von Port 853 nach aussen ist ein schneller erster Schritt
• Eigene interne DoT/DoH-Resolver anbieten, wenn Verschlüsselung gewünscht ist, aber Sichtbarkeit erhalten bleiben soll

DNS diagnostizieren: Die wichtigsten Befehle

nslookup (Windows, klassisch)

# Einfache A-Record-Abfrage
nslookup firma.ch

# Bestimmten Record-Typ abfragen
nslookup -type=MX firma.ch
nslookup -type=TXT firma.ch
nslookup -type=NS firma.ch
nslookup -type=AAAA firma.ch

# Einen bestimmten DNS-Server direkt befragen (Bypass lokaler Cache)
nslookup firma.ch 8.8.8.8

# Interaktiven Modus starten
nslookup
> set type=ANY
> firma.ch
> exit

Resolve-DnsName (PowerShell – moderner, empfohlen)

# Einfache Abfrage
Resolve-DnsName firma.ch

# MX-Records
Resolve-DnsName firma.ch -Type MX

# TXT-Records (SPF/DKIM/DMARC prüfen)
Resolve-DnsName firma.ch -Type TXT
Resolve-DnsName _dmarc.firma.ch -Type TXT
Resolve-DnsName selector1._domainkey.firma.ch -Type TXT

# Anderen DNS-Server direkt befragen
Resolve-DnsName firma.ch -Server 8.8.8.8

# Reverse Lookup (IP → Hostname)
Resolve-DnsName 185.1.2.3 -Type PTR

# DNSSEC-Antwort inkl. RRSIG anfordern
Resolve-DnsName firma.ch -DnssecOk

ipconfig (DNS-Cache)

# DNS-Cache anzeigen
ipconfig /displaydns

# DNS-Cache leeren (wichtig nach DNS-Änderungen)
ipconfig /flushdns

# IP + DNS neu beziehen (DHCP)
ipconfig /release
ipconfig /renew

DNS-Monitoring und Logging auf dem Windows-DNS-Server

Wenn nslookup und Resolve-DnsName nicht weiterhelfen, oder du einen Sicherheitsvorfall untersuchst, brauchst du einen Blick in die Logs des DNS-Servers selbst. Windows Server kennt dafür zwei unterschiedliche Mechanismen:

Debug-Logging – die klassische, textbasierte Variante. Protokolliert wahlweise ein- und ausgehende Pakete, Abfragen, Updates und Transfers in eine Log-Datei. Sehr detailliert, aber ressourcenintensiv und sollte nur befristet zur Fehlersuche aktiviert werden:

# Debug-Logging aktivieren: eingehende Queries protokollieren, max. 100 MB
Set-DnsServerDiagnostics -EnableLoggingToFile $true `
    -QueryLogging $true -Queries $true -Answers $true
Set-DnsServerDiagnostics -FilterIPAddressList 10.0.0.0/24

# Wieder deaktivieren, sobald die Analyse abgeschlossen ist
Set-DnsServerDiagnostics -EnableLoggingToFile $false

Die Logdatei liegt standardmässig unter %SystemRoot%\System32\Dns\dns.log.

Analytic- und Debug-Log im Ereignisprotokoll (ab Windows Server 2012 R2) – strukturierte ETW-Events statt Freitext, deutlich performanter und ideal für die Auswertung mit einem SIEM. Aktivierung über die Ereignisanzeige oder per Kommandozeile:

# Analytic-Log über wevtutil aktivieren
wevtutil set-log "Microsoft-Windows-DNSServer/Analytical" /e:true

# Events anschliessend wie gewohnt auswerten
Get-WinEvent -LogName "Microsoft-Windows-DNSServer/Analytical" -MaxEvents 50

In der Ereignisanzeige findest du die Logs unter Anwendungs- und Dienstprotokolle → Microsoft → Windows → DNS-Server (Analytic- und Debug-Logs sind standardmässig ausgeblendet – über Ansicht → Analytische und Debugprotokolle anzeigen einblenden). Mehr zur Ereignisanzeige generell findest du unter Windows-Ereignisanzeige.

Typische DNS-Probleme und Lösungsansätze

Problem: Hostname lässt sich nicht auflösen

# Schritt 1: Kann der PC den DNS-Server überhaupt erreichen?
Test-NetConnection -ComputerName 192.168.1.1 -Port 53

# Schritt 2: Direkt beim öffentlichen DNS fragen (Google)
Resolve-DnsName firma.ch -Server 8.8.8.8

# Schritt 3: Cache leeren
ipconfig /flushdns

# Schritt 4: DNS-Client-Dienst neu starten
Restart-Service -Name Dnscache

Problem: Mail landet im Spam

1. SPF prüfen: Resolve-DnsName firma.ch -Type TXT – ist v=spf1 vorhanden?
2. DKIM prüfen: Resolve-DnsName selector1._domainkey.firma.ch -Type TXT
3. DMARC prüfen: Resolve-DnsName _dmarc.firma.ch -Type TXT
4. Online-Tool: MXToolbox – zeigt alle Mail-Records auf einen Blick

Problem: DNS-Änderung ist noch nicht sichtbar

• TTL des alten Eintrags abwarten (z.B. bei 3600 kann es bis zu 1 Stunde dauern)
• Cache lokal leeren: ipconfig /flushdns
• Beim autoritativen Nameserver direkt nachfragen:

  # Zuerst den autoritativen NS herausfinden
  Resolve-DnsName firma.ch -Type NS
  # Dann diesen direkt befragen
  Resolve-DnsName firma.ch -Server ns1.provider.ch

Problem: Interne Hostnamen funktionieren nicht (AD-Umgebung)

# DNS-Server des Clients prüfen – muss der DC sein
Get-DnsClientServerAddress -AddressFamily IPv4

# Verbindung zum DC/DNS-Server testen
Test-NetConnection -ComputerName DC01 -Port 53

# Netzwerkkonfiguration prüfen
ipconfig /all

Problem: Namensauflösung schlägt nach DNSSEC-Aktivierung fehl

• Prüfen, ob der DS-Record beim Registrar wirklich publiziert wurde (ein häufig vergessener Schritt)
• Signaturen können ablaufen – Get-DnsServerSigningKey und die Zonen-Resign-Einstellungen kontrollieren
• Testweise Validierung umgehen, um die Ursache einzugrenzen: Resolve-DnsName firma.ch -DnssecCd

Öffentliche DNS-Server im Vergleich

Manchmal musst du für Tests oder als Fallback einen öffentlichen DNS-Server nutzen:

Weiterlernen

• Cloudflare: Was ist DNS? (deutsch) – umfassende Einführung von einem der grössten DNS-Betreiber weltweit
• RFC 1034 – Domain Names: Concepts and Facilities – das offizielle Originaldokument (englisch)
• Microsoft Learn: Sign DNS Zones with DNSSEC on Windows Server – offizielle Anleitung zur Zonensignierung
• Microsoft Learn: DNS Policies Overview – Split-Brain-Deployment – Split-Horizon-DNS mit Zone Scopes
• Microsoft Learn: DNS Aging and Scavenging – offizielle Referenz zu stale Records
• MXToolbox – DNS & Mail-Check – prüft SPF, DKIM, DMARC, Blacklists online
• Microsoft: Resolve-DnsName Dokumentation – offizielle Cmdlet-Referenz
• IANA: Root Servers – Liste der 13 Root-Nameserver weltweit
• Hostinger: Was ist DNS? – umfassender Leitfaden – gut geschriebener Überblick auf Deutsch

Verwandte Themen: DHCP – Grundlagen · TCP/IP Grundlagen · Active Directory – Grundlagen · VPN – Grundlagen · IT-Security – Grundlagen für KMU · Monitoring – Grundlagen · Troubleshooting-Methodik

Videos

YouTube

YouTube