DNS-Grundlagen, die jeder Entwickler kennen sollte

Jan 26, 2026 · 4 min read

DNS-Grundlagen, die jeder Entwickler kennen sollte

Sie haben Ihre Anwendung deployed, aber Benutzer melden, dass sie nicht erreichbar ist. Ihr erster Instinkt könnte sein, den Server zu überprüfen, aber der eigentliche Übeltäter ist oft DNS. Das Verständnis von DNS-Grundlagen ist nicht optional – es ist essenziell für das Debugging von Produktionsproblemen und das Verständnis, wie Ihre Webanwendungen tatsächlich die Benutzer erreichen.

Dieser Artikel behandelt den DNS-Auflösungsablauf, gängige Record-Typen, Caching-Verhalten und moderne DNS-Entwicklungen, die Performance und Sicherheit beeinflussen.

Wichtigste Erkenntnisse

Die DNS-Auflösung umfasst drei Ebenen: Stub-Resolver, rekursive Resolver und autoritative Nameserver – Fehler können an jedem Punkt auftreten
TTL-Werte bestimmen die Propagationszeit; senken Sie diese vor Migrationen, nicht währenddessen
HTTPS-Records (SVCB) liefern Verbindungshinweise für schnellere, sicherere Browser-Verbindungen
DNSSEC authentifiziert Records, während DoH/DoT/DoQ Anfragen verschlüsselt – sie lösen unterschiedliche Probleme
Verwenden Sie dig oder nslookup, um DNS-Probleme durch Abfragen verschiedener Resolver zu debuggen

Wie DNS-Auflösung funktioniert

Wenn ein Browser sich mit api.example.com verbinden muss, kennt er die IP-Adresse nicht auf magische Weise. Der Auflösungsprozess umfasst drei Ebenen:

Stub-Resolver: Der in Ihr Betriebssystem integrierte DNS-Client. Er löst Namen nicht selbst auf – er leitet Anfragen an einen konfigurierten rekursiven Resolver weiter und cached Antworten lokal.

Rekursiver Resolver: Wird typischerweise von Ihrem ISP oder einem öffentlichen Dienst wie Cloudflare (1.1.1.1) oder Google (8.8.8.8) betrieben. Dieser Server übernimmt die eigentliche Arbeit und fragt andere Server in Ihrem Auftrag ab.

Autoritative Nameserver: Die Quelle der Wahrheit für die DNS-Records einer Domain. Der rekursive Resolver durchläuft die DNS-Hierarchie – Root-Server, dann TLD-Server (.com, .io), dann die autoritativen Server der Domain – um die Antwort zu finden.

Für Entwickler ist die zentrale Erkenntnis, dass DNS-Fehler auf jeder Ebene auftreten können. Ein falsch konfigurierter Stub-Resolver, ein nicht erreichbarer rekursiver Resolver oder veraltete autoritative Records können alle Ihre Anwendung lahmlegen.

Gängige DNS-Record-Typen

Diese Records werden Ihnen regelmäßig begegnen:

A / AAAA: Ordnen einen Hostnamen einer IPv4- oder IPv6-Adresse zu
CNAME: Aliasiert einen Hostnamen zu einem anderen (kann nicht am Zone-Apex verwendet werden – example.com selbst benötigt einen A- oder AAAA-Record)
MX: Spezifiziert Mailserver für die Domain
TXT: Speichert beliebigen Text, wird häufig für Domain-Verifizierung und E-Mail-Authentifizierung verwendet (SPF, DKIM)
NS: Delegiert eine Zone an bestimmte Nameserver

Das Verständnis dieser Records hilft bei der Konfiguration von CDNs, E-Mail-Diensten oder beim Debugging, warum eine Subdomain nicht aufgelöst wird.

DNS-Caching und TTL

DNS-Caching und TTL (Time To Live) wirken sich direkt auf Ihre Deployment-Strategie aus. Jeder DNS-Record enthält einen TTL-Wert in Sekunden. Sobald ein Resolver einen Record gecacht hat, fragt er erst wieder ab, wenn die TTL abgelaufen ist.

Praktische Auswirkungen:

Eine TTL von 3600 Sekunden (1 Stunde) bedeutet, dass DNS-Änderungen bis zu einer Stunde zur Propagation benötigen
Senken Sie TTLs vor Migrationen im Voraus – nicht während der Änderung
Browser und Betriebssysteme unterhalten ihre eigenen Caches, was eine weitere Ebene hinzufügt

Der Mythos, dass „DNS-Propagation 24-48 Stunden dauert”, ist irreführend. Die Propagationszeit hängt vom vorherigen TTL-Wert ab. Wenn Ihre alte TTL 86400 Sekunden (24 Stunden) betrug, ist das Ihre Worst-Case-Wartezeit.

Modernes DNS: HTTPS-Records und verschlüsselter Transport

DNS hat sich in den letzten Jahren erheblich weiterentwickelt. Zwei Entwicklungen sind für Webentwickler am wichtigsten.

Der HTTPS-DNS-Record (SVCB)

Der HTTPS-Record (ein spezifischer Typ von SVCB-Record) liefert Verbindungshinweise, bevor der Browser überhaupt Ihren Server kontaktiert. Er kann Folgendes ankündigen:

HTTP/3- und QUIC-Unterstützung
Alternative Ports
Encrypted Client Hello (ECH) Keys

Dies ermöglicht Browsern, schnellere, sicherere Verbindungen aufzubauen. Allerdings ist die Unterstützung für HTTPS-Records noch nicht universell – nicht alle DNS-Provider unterstützen sie, und einige Resolver fragen sie nicht ab.

Hinweis: HTTPS-Records bieten begrenzte Apex-Aliasing-Fähigkeiten, sind aber keine vollständige CNAME-at-Apex-Lösung.

DNS over HTTPS (DoH) und verschlüsseltes DNS

Traditionelle DNS-Anfragen werden im Klartext über UDP-Port 53 übertragen. DNS over HTTPS (DoH), DNS over TLS (DoT) und DNS over QUIC (DoQ) verschlüsseln diese Anfragen und verhindern so Abhören und Manipulation.

Verschlüsseltes DNS ist mittlerweile weit verbreitet – Firefox und Chrome verwenden DoH standardmäßig in vielen Konfigurationen –, aber es ist nicht universell. Unternehmensnetzwerke und einige ISPs fangen verschlüsseltes DNS immer noch ab oder blockieren es.

DNSSEC vs. Verschlüsselung: Den Unterschied kennen

Eine häufige Verwechslung: DNSSEC ist keine Verschlüsselung.

DNSSEC bietet Authentifizierung. Es signiert DNS-Records kryptografisch, sodass Resolver verifizieren können, dass Antworten nicht manipuliert wurden. Es verbirgt Ihre Anfragen nicht.

Verschlüsseltes DNS (DoH/DoT/DoQ) bietet Privatsphäre. Es verschlüsselt die Transportschicht, sodass Beobachter nicht sehen können, welche Domains Sie abfragen.

Sie lösen unterschiedliche Probleme und können zusammen verwendet werden.

Wie DNS-Fehler in Ihren Anwendungen auftreten

Wenn DNS fehlschlägt, sehen Sie typischerweise:

NXDOMAIN-Fehler (Domain existiert nicht)
Connection-Timeouts (Resolver nicht erreichbar)
SERVFAIL-Antworten (Upstream-Server-Probleme)

In Browsern erscheinen diese als „DNS_PROBE_FINISHED_NXDOMAIN” oder ähnliche Fehler. In Node.js oder anderen Runtimes erhalten Sie ENOTFOUND oder äquivalente Exceptions.

Verwenden Sie dig oder nslookup zum Debuggen. Fragen Sie verschiedene Resolver ab, um zu isolieren, ob das Problem lokales Caching, Ihr Resolver oder die autoritativen Server sind.

Fazit

DNS sitzt zwischen Ihren Benutzern und Ihren Servern. Das Verständnis des Auflösungsablaufs, des TTL-Verhaltens und moderner Protokolle wie HTTPS-Records und DoH hilft Ihnen, zuverlässiger zu deployen und schneller zu debuggen. Wenn etwas kaputt geht, sollte DNS einer Ihrer ersten Verdächtigen sein – nicht Ihr letzter.

FAQs

Verwenden Sie den dig-Befehl in Ihrem Terminal, z. B. dig example.com A, um A-Records zu prüfen, oder dig example.com ANY, um alle Records zu sehen. Sie können auch einen Resolver angeben wie dig @8.8.8.8 example.com, um Googles DNS direkt abzufragen. Unter Windows verwenden Sie stattdessen nslookup example.com.

DNS-Änderungen erscheinen verzögert, weil Resolver Records basierend auf ihrem TTL-Wert cachen. Wenn Ihre vorherige TTL 3600 Sekunden betrug, prüfen Resolver erst nach Ablauf dieser Stunde auf Updates. Um zukünftige Änderungen zu beschleunigen, senken Sie Ihre TTL rechtzeitig vor den Updates und stellen Sie sie danach wieder her.

Ein A-Record ordnet einen Hostnamen direkt einer IP-Adresse zu. Ein CNAME erstellt einen Alias, der einen Hostnamen auf einen anderen verweist, der dann zu einer IP aufgelöst wird. CNAMEs sind nützlich für Subdomains, die auf externe Dienste verweisen, können aber nicht am Zone-Apex verwendet werden, wo Ihre Root-Domain einen A- oder AAAA-Record benötigt.

DoH verschlüsselt DNS-Anfragen und verhindert, dass Netzwerkbeobachter sehen, welche Domains Sie auflösen. Für die Privatsphäre der Endbenutzer ist es vorteilhaft. Für Serveranwendungen ist jedoch traditionelles DNS oft ausreichend, da Ihre Infrastruktur bereits bekannt ist. Erwägen Sie DoH, wenn Privatsphäre vor Netzwerk-Intermediären für Ihren Anwendungsfall wichtig ist.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.