DNS-Konzepte & Record-Typen

Rekursiv vs. iterativ

DNS übersetzt Namen (www.example.com) in IP-Adressen. Der Client fragt seinen rekursiven Resolver (z. B. den DNS-Server im Router oder einen internen DNS). Dieser übernimmt die ganze Arbeit und liefert am Ende die fertige Antwort zurück, das ist die rekursive Abfrage.

Der Resolver selbst arbeitet iterativ: Er fragt sich von oben durch die Hierarchie:

1. Root-Server (·), kennt die zuständigen TLD-Server.
2. TLD-Server (.com), kennt die autoritativen Nameserver der Domain.
3. Autoritativer Nameserver (example.com), liefert den tatsächlichen Record.

Jede Ebene verweist auf die nächste, bis der autoritative Server die verbindliche Antwort gibt.

Caching & TTL

Damit nicht jede Anfrage die ganze Kette durchläuft, wird jede Antwort zwischengespeichert (Caching). Wie lange, bestimmt die TTL (Time To Live) in Sekunden, die im Record hinterlegt ist:

• Hohe TTL (z. B. 86400 = 24 h): weniger Anfragen, schnelle Auflösung, aber Änderungen brauchen lange, bis sie überall greifen.
• Niedrige TTL (z. B. 300 = 5 min): Änderungen wirken schnell, mehr Last. Vor einer geplanten Umstellung (Migration, IP-Wechsel) die TTL vorab senken.

Wichtig: Der Resolver und das Betriebssystem cachen unabhängig. Nach einer Änderung sieht man Altes oft noch aus dem lokalen Cache, daher beim Testen den Cache leeren (siehe Fehlersuche).

Häufige Stolperfallen

• CNAME am Apex: ein CNAME darf nicht auf der „nackten" Domain (example.com) stehen, weil dort schon SOA/NS liegen. Provider bieten dafür „ALIAS"/„ANAME"-Records an.
• PTR gehört dem IP-Inhaber: Reverse-Records verwaltet i. d. R. der Provider/Hoster des IP-Bereichs, nicht der Domain-Inhaber, relevant für die Mail-Zustellbarkeit.
• Trailing Dot: voll qualifizierte Namen enden in der Zonendatei mit einem Punkt (mail.example.com.), sonst wird die Zone angehängt.

Records erzeugen und Mail-Records prüfen: siehe die Tools DNS-Record-Generator und DNS-Lookup.

Split-Horizon (Split-DNS)

Beim Split-Horizon-DNS liefert der Server je nach Herkunft der Anfrage unterschiedliche Antworten. Beispiel: portal.firma.de löst intern auf die private LAN-IP (10.0.30.20) auf, extern auf die öffentliche IP der Firewall. So erreichen interne Clients den Dienst direkt, ohne den Umweg über das Internet („Hairpin/NAT-Loopback"), und die interne Struktur bleibt außen verborgen.

AD-integriertes DNS

In Windows-Domänen ist DNS die Grundlage von Active Directory: Domänencontroller registrieren ihre Dienste über SRV-Records (z. B. _ldap._tcp.dc._msdcs.firma.local), die Clients zur DC-Lokalisierung nutzen. Wichtig:

• Domänen-Clients müssen den internen AD-DNS als primären Resolver haben, niemals direkt öffentliche Resolver (8.8.8.8 etc.), sonst finden sie die Domäne nicht.
• Der interne DNS leitet unbekannte (externe) Namen per Forwarder an einen Upstream-Resolver weiter.
• AD-integrierte Zonen replizieren automatisch zwischen allen DCs und erlauben sichere dynamische Updates.

DNSSEC, Integrität der Antworten

DNSSEC signiert DNS-Einträge kryptografisch. Ein validierender Resolver kann so prüfen, dass eine Antwort wirklich vom zuständigen autoritativen Server stammt und unterwegs nicht manipuliert wurde (Schutz gegen Cache-Poisoning/Spoofing). DNSSEC verschlüsselt nicht, es garantiert nur Echtheit und Unversehrtheit. Die Vertrauenskette läuft über DS-Records vom Parent zur Zone (Chain of Trust bis zur Root).

DoH & DoT, Vertraulichkeit der Anfragen

• DoT (DNS over TLS, Port 853): verschlüsselt die DNS-Anfrage in einem eigenen TLS-Tunnel. Als DNS erkennbar, dadurch im Netz filterbar/blockierbar.
• DoH (DNS over HTTPS, Port 443): verpackt DNS in normalen HTTPS-Verkehr, kaum von Web-Traffic zu unterscheiden. Gut für Privatsphäre, aber im Unternehmen problematisch, weil es interne DNS-Richtlinien und -Filter umgehen kann.

Im Firmennetz DoH auf Clients meist gezielt deaktivieren, damit die Auflösung über den kontrollierten internen DNS läuft. DNSSEC dagegen kann man serverseitig aktivieren, ohne die Clients zu ändern.