Wenn eine Website plötzlich nicht erreichbar ist, liegt der Fehler oft nicht beim Webserver, sondern bei der Namensauflösung. Ein IPv4-DNS-Server übersetzt Domainnamen wie metawebart.de in IP-Adressen und entscheidet damit mit, wie zuverlässig Anwendungen, APIs und Webseiten gefunden werden. Ich zeige, wie diese Server funktionieren, welche öffentlichen Resolver sich für Deutschland eignen und worauf man im Hosting- und DevOps-Betrieb achten sollte.
Die wichtigsten Entscheidungen rund um IPv4-DNS-Server auf einen Blick
-
IPv4-Adresse: Ein DNS-Server wie
1.1.1.1wird über das IPv4-Protokoll erreicht. - Geeignete Anbieter: Cloudflare, Google Public DNS und Quad9 verfolgen unterschiedliche Ziele bei Geschwindigkeit, Datenschutz und Filterung.
- Port 53: Klassisches DNS nutzt UDP oder TCP, während DoT Port 853 und DoH meist Port 443 verwendet.
- Hosting: Für eigene Domains sind autoritative Nameserver und korrekte DNS-Einträge wichtiger als ein beliebiger öffentlicher Resolver.
-
Fehlersuche: Mit
dig,nslookupundresolvectllassen sich DNS-Probleme meist schnell eingrenzen.
Was ein IPv4-DNS-Server tatsächlich macht
Das DNS ist das Telefonbuch des Internets. Der Rechner fragt nicht direkt nach einer Webseite, sondern nach einem Namen. Ein rekursiver Resolver ermittelt daraus die passende IP-Adresse und liefert sie an den Client zurück. Bei einer IPv4-Verbindung ist die Adresse des DNS-Servers selbst eine vierteilige Zahl wie 8.8.8.8.
Wichtig ist die Abgrenzung zwischen dem Transportweg und der Antwort. Ein DNS-Server, der über IPv4 erreichbar ist, kann durchaus einen A-Record für IPv4 und einen AAAA-Record für IPv6 zurückgeben. Die Bezeichnung sagt also zunächst nur, wie der Client den Resolver erreicht, nicht welche IP-Version die Zielwebsite unterstützt.
Rekursiv oder autoritativ
Ein rekursiver DNS-Resolver nimmt Anfragen von Geräten und Anwendungen entgegen. Er fragt bei Bedarf andere Nameserver ab und speichert Ergebnisse für die im DNS festgelegte TTL, also die Gültigkeitsdauer eines Eintrags. Öffentliche Resolver wie Cloudflare oder Google arbeiten überwiegend in dieser Rolle.
Ein autoritatives DNS-System ist dagegen für eine bestimmte DNS-Zone zuständig. Dort liegen die verbindlichen Einträge einer Domain, etwa für Webserver, Mailserver oder Verifizierungsdienste. Im Hosting wird dieser Unterschied oft übersehen: Ein öffentlicher Resolver löst Namen auf, er verwaltet nicht automatisch die DNS-Zone der eigenen Domain.
Welche öffentlichen IPv4-Resolver für Deutschland sinnvoll sind
Die Auswahl sollte nicht allein nach dem kürzesten Zahlencode erfolgen. Ich prüfe zuerst, ob ein Dienst Inhalte filtert, wie transparent er mit Protokolldaten umgeht und ob er zur jeweiligen Umgebung passt. Für einen privaten Anschluss gelten andere Prioritäten als für einen Produktionsserver.
| Anbieter | Primär und sekundär | Stärke | Zu beachten |
|---|---|---|---|
| Cloudflare |
1.1.1.11.0.0.1
|
Hohe Verfügbarkeit und einfache Konfiguration | Der Standarddienst ist nicht als Malware- oder Jugendschutz gedacht. |
| Google Public DNS |
8.8.8.88.8.4.4
|
Sehr große globale Infrastruktur und konsistente Antworten | Die Datenschutzbedingungen sollten vor dem produktiven Einsatz geprüft werden. |
| Quad9 |
9.9.9.9149.112.112.112
|
Blockiert bekannte schädliche Domains und unterstützt DNSSEC | Einige legitime Domains können durch Sicherheitsfilter beeinträchtigt werden. |
| AdGuard DNS |
94.140.14.1494.140.15.15
|
Werbe- und Trackerfilterung | Filter können Anwendungen, Analysewerkzeuge oder Login-Dienste stören. |
Für einen normalen deutschen Heimanschluss sind Cloudflare oder Google unkomplizierte Ausgangspunkte. Wenn der Resolver bekannte Schadsoftware-Domains blockieren soll, ist Quad9 interessanter. Ad- und Trackerfilter gehören eher auf Geräte, in Familiennetze oder in klar kontrollierte Umgebungen, nicht ungeprüft in jede CI/CD-Pipeline.
Eine öffentliche Adresse ist nicht automatisch schneller als der Resolver des Internetanbieters. Die Antwortzeit hängt von Peering, Routing, Cache-Zustand und dem Standort des Clients ab. Mein praktischer Rat lautet deshalb, zwei oder drei Kandidaten mit realen Domains zu messen und nicht von einem einzelnen Benchmark auf den Dauerbetrieb zu schließen.
[search_image] DNS resolver architecture recursive authoritative server IPv4 diagram
DNS im Hosting richtig einordnen
Beim Hosting gibt es zwei getrennte Aufgaben. Der autoritative Dienst beantwortet Fragen zu Ihrer Domain, während der Resolver des Servers Namen wie Paketquellen, Datenbanken oder externe APIs auflöst. Beide Komponenten können IPv4 verwenden, müssen aber nicht beim gleichen Anbieter liegen.
Die wichtigsten DNS-Einträge
- A-Record: verweist eine Domain auf eine IPv4-Adresse, zum Beispiel die öffentliche Adresse eines Webservers.
- AAAA-Record: verweist auf eine IPv6-Adresse und sollte nicht vergessen werden, wenn der Dienst IPv6 unterstützt.
- CNAME: legt einen Alias für einen anderen Hostnamen an, darf aber normalerweise nicht direkt an der Zone-Spitze verwendet werden.
- MX-Record: bestimmt, welche Mailserver Nachrichten für die Domain annehmen.
- TXT-Record: wird unter anderem für SPF, DKIM, DMARC und Domain-Verifizierungen verwendet.
- NS-Record: nennt die autoritativen Nameserver einer Zone.
Ein typischer Webeintrag sieht beispielsweise so aus:
example.de. 300 IN A 203.0.113.25
www.example.de. 300 IN CNAME example.de.Die TTL von 300 Sekunden kann bei einer geplanten Migration hilfreich sein, weil Clients den Eintrag kürzer zwischenspeichern. Sie macht einen Wechsel aber nicht augenblicklich. Resolver dürfen alte Antworten bis zum Ablauf der bisherigen TTL verwenden, und manche Anwendungen oder Betriebssysteme speichern zusätzlich eigene Daten.
Was bei Produktionssystemen zählt
Für eine produktive Domain sind mindestens zwei autoritative Nameserver sinnvoll, idealerweise in getrennten Netzen oder bei unterschiedlichen Anbietern. Ein einzelner DNS-Host kann zwar funktionieren, wird aber bei Wartung, Routingproblemen oder einem Serverausfall schnell zum Gesamtrisiko.
Auf einem Linux-Server sollte der lokale Resolver außerdem nicht ungeschützt aus dem Internet erreichbar sein. Ein offener rekursiver DNS-Server kann für DNS-Amplification-Angriffe missbraucht werden. Rekursion gehört ins interne Netz, während autoritative Antworten nur für die eigenen Zonen bereitgestellt werden sollten.
Unverschlüsseltes DNS, DoT und DoH im Vergleich
Klassische DNS-Anfragen laufen gewöhnlich über UDP-Port 53, bei größeren Antworten oder bestimmten Übertragungen auch über TCP-Port 53. Diese Verbindung ist normalerweise nicht verschlüsselt. Dritte im Netzwerk können daher erkennen, welche Domains abgefragt werden, auch wenn die spätere Website selbst HTTPS nutzt.
| Verfahren | Transport | Vorteil | Typischer Einsatz |
|---|---|---|---|
| DNS über UDP/TCP | Port 53 | Kompatibel und leicht zu betreiben | Lokale Netze, klassische Serverkonfiguration |
| DNS over TLS | TCP-Port 853 | Verschlüsselte Verbindung mit klar erkennbarem DNS-Dienst | Android Private DNS, Server und Router mit DoT-Unterstützung |
| DNS over HTTPS | HTTPS, meist Port 443 | DNS-Anfragen werden wie Webverkehr verschlüsselt | Browser, Betriebssysteme und moderne Netzwerkdienste |
DoT und DoH ersetzen DNSSEC nicht. Die Verschlüsselung schützt den Weg zwischen Client und Resolver. DNSSEC prüft dagegen, ob eine signierte DNS-Antwort tatsächlich aus der zuständigen Zone stammt. Für einen belastbaren Schutz ergänzen sich beide Verfahren.
Für Server bevorzuge ich eine zentral kontrollierte Konfiguration. Wenn ein Browser zusätzlich eigene DoH-Einstellungen verwendet, kann er die DNS-Vorgaben des Betriebssystems umgehen. Das erschwert Fehlersuche, Filterung und Monitoring. In Unternehmensnetzen sollte deshalb klar geregelt sein, welche Resolver erlaubt sind.
IPv4-DNS-Server testen und Fehler systematisch finden
Bei DNS-Problemen sollte man nicht sofort den Anbieter wechseln. Zuerst muss klar sein, ob die lokale Konfiguration, der Resolver, die autoritative Zone oder die Anwendung selbst fehlerhaft ist. Mit wenigen Befehlen lässt sich dieser Weg gut trennen.
Auf Linux und macOS
dig example.de A
dig @1.1.1.1 example.de A
dig @8.8.8.8 example.de A
resolvectl status
resolvectl query example.deDer erste Befehl fragt den aktuell konfigurierten Resolver ab. Mit @1.1.1.1 wird gezielt ein anderer Dienst getestet. Stimmen die Antworten nicht überein, sind Cache, DNSSEC, Geolokation oder eine Filterregel mögliche Ursachen.
Lesen Sie auch: IP-Netzwerke planen und absichern für Hosting und DevOps
Auf Windows
nslookup example.de
nslookup example.de 1.1.1.1
ipconfig /flushdnsipconfig /flushdns leert nur den lokalen Cache. Es repariert keinen falschen A-Record beim autoritativen Anbieter. Wenn eine Änderung nach dem Flush weiterhin nicht sichtbar ist, sollte man TTL, Nameserver-Delegation und die tatsächliche Zone mit dig +trace oder einem externen DNS-Test prüfen.
Besonders häufig sehe ich drei Fehler. Erstens wird ein A-Record geändert, obwohl die Domain durch einen CNAME auf einen anderen Namen zeigt. Zweitens wird nur IPv4 getestet, obwohl Clients wegen eines fehlerhaften AAAA-Records bevorzugt IPv6 verwenden. Drittens wird der DNS-Cache für einen Serverausfall verantwortlich gemacht, obwohl eigentlich Firewall, Load-Balancer oder TLS-Zertifikat fehlerhaft sind.
Typische Fehlentscheidungen bei der Auswahl
Der bekannteste Resolver ist nicht automatisch die beste Wahl für jede Umgebung. Wer ausschließlich auf Geschwindigkeit achtet, übersieht oft Filterverhalten und Datenschutz. Wer nur nach maximaler Privatsphäre sucht, sollte trotzdem prüfen, ob der Dienst für die eigenen Anwendungen zuverlässig erreichbar ist und ob regionale Antworten korrekt funktionieren.
- Primär und sekundär vom gleichen Anbieter: Das ist meist konsistenter als eine zufällige Mischung mehrerer Filterprofile.
- Öffentliche Resolver als autoritative Nameserver: Ein rekursiver Dienst ersetzt keine DNS-Verwaltung für die eigene Domain.
- Zu niedrige TTL: Werte von 30 oder 60 Sekunden erhöhen die Abfragelast und beschleunigen Änderungen nicht garantiert.
- DNS als Sicherheitslösung: Blockierung bekannter Domains hilft, ersetzt aber weder EDR, Firewall noch sichere Softwareentwicklung.
- Ungeprüfte Änderungen am Router: Vorher die bisherigen DNS-Werte dokumentieren und einen Rückweg vorbereiten.
Für Entwicklungsumgebungen kann ein interner Resolver mit Caching sinnvoll sein. In Kubernetes kommen zusätzlich CoreDNS, Service Discovery und Split-Horizon-DNS hinzu. Dann sollte die öffentliche Namensauflösung sauber vom internen Namensraum getrennt werden, damit interne Hostnamen nicht versehentlich nach außen gelangen.
Eine pragmatische Konfiguration für den Alltag
Für einen privaten oder kleinen geschäftlichen Anschluss würde ich zunächst zwei IPv4-Adressen eines Anbieters eintragen und anschließend die tatsächliche Auflösung messen. Für Quad9 spricht die Sicherheitsfilterung, für Cloudflare und Google die breite Infrastruktur. Der kostenlose Betrieb eines öffentlichen Resolvers kostet 0 Euro, aber die Nutzung bedeutet immer, dass ein externer Dienst DNS-Anfragen verarbeitet.
Für einen Webserver sollte der Resolver des Betriebssystems redundant erreichbar sein, zum Beispiel über zwei interne oder externe Adressen. Die autoritativen Nameserver der eigenen Domain sollten getrennt überwacht werden. Ein einfacher Healthcheck kann regelmäßig die A-, AAAA-, MX- und TXT-Einträge prüfen und bei unerwarteten Änderungen alarmieren.
Mein wichtigster Praxisgrundsatz lautet deshalb: DNS-Konfiguration versionieren und testen. Änderungen gehören in ein Review, kritische Zonen brauchen Monitoring und bei Migrationen sollten alte und neue Antworten eine Zeit lang parallel geprüft werden. So wird aus einer scheinbar kleinen IP-Änderung kein unbemerkter Produktionsausfall.
Die richtige DNS-Entscheidung hängt vom Einsatz ab
Ein IPv4-DNS-Server ist zunächst nur der über IPv4 erreichbare Vermittler zwischen Hostnamen und DNS-Antworten. Für den Alltag reichen meist zwei stabile öffentliche Resolver. Im Hosting zählen dagegen autoritative Redundanz, korrekte Records, DNSSEC und nachvollziehbare Änderungen deutlich mehr als ein vermeintlicher Geschwindigkeitsvorteil von wenigen Millisekunden.
Wer diese Rollen trennt und DNS mit dig, Monitoring und klaren Zuständigkeiten betreibt, löst die meisten Probleme schneller. Genau darin liegt der praktische Nutzen einer guten DNS-Strategie: Sie bleibt unsichtbar, solange sie funktioniert, und liefert im Fehlerfall genügend Informationen, um die Ursache nicht im Nebel suchen zu müssen.
