Was ist DNS? Das Domain Name System einfach erklärt (2026)

Was ist DNS? DNS steht für Domain Name System. Es ist das Verzeichnis des Internets, das einen Namen wie getmind.io in die Adresse übersetzt, unter der der Rechner wirklich erreichbar ist, in unserem Fall 46.225.123.163. Dein Browser kann mit dem Namen allein nichts anfangen. Bevor er auch nur ein Byte dieser Seite laden konnte, hat er per DNS nachgefragt, wohin er sich verbinden soll.

Der übliche Vergleich ist das Telefonbuch: Du kennst den Namen, das Telefonbuch kennt die Nummer. Der Vergleich stimmt, unterschlägt aber das Interessante. Es gibt nicht ein Telefonbuch, sondern ein weltweit verteiltes Netz aus Millionen Servern, von denen keiner alles weiß. Jeder kennt nur ein Stück und verweist für den Rest weiter. Dass das trotzdem in wenigen Millisekunden klappt, liegt an einem zweiten Trick: Fast alle Antworten kommen aus einem Zwischenspeicher.

Wir betreiben mehrere Server und eine ganze Reihe Domains, und wir haben für diesen Artikel nicht nur nacherzählt, sondern am 2. Oktober 2026 auf unserem Produktionsserver (Hetzner, Ubuntu 24.04) gemessen. Drei Befunde vorweg:

1. Unser Server hat seit dem 13. September 308.739 DNS-Anfragen gestellt. 57,5 % davon wurden aus dem lokalen Cache beantwortet, ohne dass eine einzige Anfrage das Haus verlassen hat.

2. Die komplette Kette vom Root-Server bis zur Antwort dauerte bei uns 66 Millisekunden. Eine Antwort aus dem Cache: 0 Millisekunden.

3. In unserer eigenen DNS-Zone haben wir beim Nachsehen drei Dinge gefunden, die wir so nicht auf dem Schirm hatten. Dazu unten mehr, ehrlich und ohne Beschönigung.

Was ist DNS? Die Kurzfassung in fünf Sätzen

1. Rechner im Internet finden sich über IP-Adressen (zum Beispiel 46.225.123.163 oder 2a00:1450:4001:c0f::8a), Menschen merken sich lieber Namen.
2. DNS ist das System, das Namen in Adressen übersetzt (und ein paar andere Dinge nachschlägt, etwa welcher Server die E-Mails einer Domain annimmt).
3. Die Daten sind hierarchisch verteilt: Die Root-Server kennen die Endungen wie .de oder .io, die Endungs-Server kennen die zuständigen Nameserver jeder Domain, und erst diese kennen die eigentliche Adresse.
4. Ein Resolver (meist von deinem Internetanbieter, deinem Router oder einem Dienst wie Cloudflare oder Google) läuft diese Kette für dich ab und merkt sich das Ergebnis für eine festgelegte Zeit, die TTL.
5. Wenn „das Internet nicht geht”, aber die Verbindung steht, ist erstaunlich oft DNS schuld. Das ist unter Admins ein Running Gag mit wahrem Kern.

Wer nur die Kurzfassung wollte, kann hier aufhören. Ab hier wird es konkret.

Video: Patrick Boekhoven erklärt die Namensauflösung Schritt für Schritt. Guter Einstieg, wenn du es lieber einmal animiert siehst.

Wofür braucht man DNS überhaupt?

Theoretisch könnte man jede Website über ihre IP-Adresse aufrufen. Praktisch scheitert das an drei Dingen.

Erstens können sich Menschen keine Zahlen merken. Bei IPv4 sind es noch vier Blöcke, bei IPv6 werden daraus Zeichenketten wie 2a00:1450:4001:c0f::8a. Das tippt niemand freiwillig ab.

Zweitens ändern sich Adressen. Ziehen wir getmind.io morgen auf einen anderen Server um, ändern wir einen einzigen Eintrag. Alle Links, Lesezeichen und Suchergebnisse funktionieren weiter, weil sie auf den Namen zeigen und nicht auf die Nummer. Ohne DNS müssten wir allen Besuchern eine neue Zahl mitteilen.

Drittens teilen sich viele Namen eine Adresse. Auf unserem Hauptserver laufen Dutzende Websites hinter einem einzigen Reverse Proxy. Alle haben dieselbe IP. Welche Seite du bekommst, entscheidet der Server anhand des Namens, den dein Browser mitschickt. Die IP allein reicht dafür nicht einmal.

Dazu kommt alles, was keine Website ist: Wohin E-Mails für eine Domain zugestellt werden (MX-Einträge), wer im Namen der Domain Mails verschicken darf (SPF, DKIM, DMARC als TXT-Einträge), welche Zertifizierungsstelle Zertifikate ausstellen darf (CAA), und ob du eine Domain wirklich besitzt (die Verifizierungs-Codes von Google, Microsoft und Co. landen ebenfalls im DNS). DNS ist damit nicht nur ein Adressbuch, sondern das schwarze Brett jeder Domain.

Wie funktioniert DNS? Die Auflösung Schritt für Schritt

Angenommen, du tippst getmind.io in den Browser und nichts davon ist irgendwo zwischengespeichert. Dann passiert Folgendes.

Schritt 1: Dein Rechner fragt seinen Resolver. Das Betriebssystem schaut zuerst in die eigene Hosts-Datei und den eigenen Cache. Steht dort nichts, geht die Frage an den eingestellten DNS-Server. Zu Hause ist das meist der Router, der die Frage an den Resolver deines Internetanbieters weiterreicht. Auf unserem Server ist es systemd-resolved unter der Adresse 127.0.0.53, der an die Resolver von Hetzner weitergibt.

Schritt 2: Der Resolver fragt einen Root-Server. Es gibt 13 Root-Server-Namen (a.root-servers.net bis m.root-servers.net), hinter denen weltweit über tausend Maschinen per Anycast stehen. Der Root-Server kennt getmind.io nicht. Er weiß nur, wer für .io zuständig ist, und antwortet sinngemäß: „Frag a0.nic.io.”

Schritt 3: Der Resolver fragt den TLD-Server. Der .io-Server kennt die Adresse auch nicht, aber er weiß, welche Nameserver für getmind.io zuständig sind. Bei uns sind das zwei Cloudflare-Server: augustus.ns.cloudflare.com und laura.ns.cloudflare.com.

Schritt 4: Der Resolver fragt den autoritativen Nameserver. Erst dieser Server hat die Zone wirklich und antwortet verbindlich: getmind.io hat die Adresse 46.225.123.163, und diese Antwort darf 300 Sekunden lang zwischengespeichert werden.

Schritt 5: Antwort zurück, Cache füllen. Der Resolver gibt die Adresse an deinen Rechner und merkt sich alles, was er unterwegs gelernt hat. Die nächste Anfrage nach getmind.io geht nicht mehr um die Welt, und eine Anfrage nach irgendwas.io spart sich zumindest den Root-Server.

So sieht das bei uns gemessen aus. Das Werkzeug dig mit der Option +trace spielt die Kette selbst durch, statt den Resolver zu fragen:

dig +trace getmind.io

Die Ausgabe (gekürzt auf die Zeitangaben):

;; Received 622 bytes from 193.0.14.129#53(k.root-servers.net) in 40 ms
;; Received 584 bytes from 2a01:8840:a0::17#53(c0.nic.io) in 9 ms
;; Received 55 bytes from 2a06:98c1:50::ac40:20b7#53(laura.ns.cloudflare.com) in 17 ms

Drei Stationen, 40 + 9 + 17 = 66 Millisekunden. Der Root-Server war der langsamste Schritt, und genau den braucht ein Resolver fast nie, weil die Antwort „für .io ist a0.nic.io zuständig” zwei Tage lang (TTL 172.800 Sekunden) gültig bleibt.

Rekursiv und iterativ: zwei Arten zu fragen

Zwischen deinem Rechner und dem Resolver läuft eine rekursive Anfrage: „Besorg mir die Antwort, egal wie.” Der Resolver nimmt die Arbeit an. Zwischen dem Resolver und den Root-, TLD- und Nameservern laufen iterative Anfragen: Jeder antwortet nur mit dem, was er weiß, und verweist für den Rest weiter. Die autoritativen Server machen also keine Botengänge. Das ist ein wichtiger Grund, warum das System skaliert: Die Arbeit liegt bei den Resolvern, und die haben einen Cache.

Die Rollen im DNS: wer was weiß

Die Begriffe werden ständig durcheinandergeworfen, auch in Anleitungen. Darum einmal sauber getrennt.

Der häufigste Denkfehler: „Ich habe die Domain bei Anbieter X gekauft, also muss ich die Einträge bei X ändern.” Nicht unbedingt. Beim Registrar legst du nur fest, welche Nameserver zuständig sind. Zeigen die auf Cloudflare, dann sind Änderungen beim Registrar wirkungslos, und du musst die Einträge bei Cloudflare pflegen. Mit dig NS deinedomain.de +short siehst du in zwei Sekunden, wer gerade zuständig ist.

DNS-Server im Tempotest: fünf Resolver gemessen

Welcher DNS-Server ist der schnellste? Die ehrliche Antwort ist: der, der nah an dir steht und die Antwort schon im Cache hat. Wir haben fünf Resolver von unserem Server bei Hetzner aus je fünfmal gefragt, einmal nach einem bekannten Namen und einmal nach zufälligen, garantiert nicht gecachten Namen.

for i in 1 2 3 4 5; do dig @1.1.1.1 getmind.io +noall +stats | grep 'Query time'; done

Bekannter Name (getmind.io), fünf Durchläufe in Millisekunden:

Zufälliger, ungecachter Name, fünf Durchläufe in Millisekunden:

Was man daraus lesen kann und was nicht:

• Der Resolver im eigenen Rechenzentrum gewinnt, sobald er die Antwort hat. Hetzner lieferte dreimal in unter einer Millisekunde, weil die Antwort schon im Cache lag. Kein öffentlicher Resolver kann das schlagen, die Physik der Leitung lässt es nicht zu.
• Cloudflare war am gleichmäßigsten (16 bis 21 ms), Google bei ungecachten Namen am schnellsten.
• Quad9 war bei uns an diesem Morgen auffällig langsam, mit Ausreißern bis fast 900 ms. Das ist eine Momentaufnahme von einem Standort, kein Urteil über Quad9 insgesamt. Wir haben die Messung nicht über Tage wiederholt, und das Anycast-Routing von Quad9 kann vom Rechenzentrum aus anders aussehen als von deinem Heimanschluss.
• Für einen Server ist der Resolver des Hosters meist die beste Wahl. Am Heimanschluss sieht das anders aus, dort lohnt sich ein eigener Test.

Zum Vergleich haben wir dieselbe Frage auch über DNS over HTTPS (DoH) an Cloudflare gestellt, mit curl: 64 bis 81 Millisekunden pro Anfrage, also etwa dreimal so lange wie das klassische DNS über UDP. Das liegt vor allem am TLS-Handshake, den curl bei jedem Aufruf neu macht. Ein Browser hält die Verbindung offen und zahlt diesen Preis nur einmal. Der Vorteil von DoH ist nicht Tempo, sondern dass niemand unterwegs mitlesen oder manipulieren kann, welche Namen du nachschlägst.

Video: Luis Huber erklärt DNS und die wichtigsten Record-Typen in fünf Minuten. Hinweis: Der Kanal bewirbt einen eigenen Hacking-Kurs.

Der Cache: warum DNS so schnell ist

Ohne Cache würde jede einzelne Anfrage die ganze Kette ablaufen, und die Root-Server würden unter der Last zusammenbrechen. Mit Cache kommt die überwältigende Mehrheit der Antworten aus einem Speicher in der Nähe.

Unser Server zeigt das sehr deutlich. systemd-resolved führt eine Statistik, die du auf jedem aktuellen Ubuntu selbst abrufen kannst:

resolvectl statistics

Bei uns, seit dem letzten Neustart des Dienstes am 13. September:

Total Transactions: 308739
        Cache Hits: 177586
      Cache Misses: 131409
    Total Timeouts:     27
Total Failure Responses: 4

57,5 % Trefferquote im lokalen Cache, nur 27 Timeouts in knapp drei Wochen. Und das ist nur die erste Ebene: Jeder der 131.409 Fehlschläge ging an den Hetzner-Resolver, der selbst wieder einen großen Cache hat und viele davon ebenfalls ohne Weiterfrage beantworten konnte. Wie stark dieser Effekt ist, zeigt ein einfacher Versuch: Wir haben den lokalen Cache geleert und www.wikipedia.org zweimal nacheinander abgefragt. Erste Anfrage: 1 ms, zweite: 0 ms. Selbst die „kalte” Anfrage war praktisch sofort da, weil Hetzners Resolver Wikipedia natürlich längst kannte.

Interessant ist auch, dass sich negative Antworten cachen lassen. Fragt man nach einer Domain, die es nicht gibt, kommt NXDOMAIN zurück, zusammen mit einer Angabe, wie lange dieses „Gibt es nicht” gelten darf. Bei .de sind das laut SOA-Eintrag 7.200 Sekunden. In unserem Test dauerte die erste Anfrage nach einem frei erfundenen .de-Namen 14 ms, die zweite 3 ms.

Was die TTL wirklich bedeutet

Jeder DNS-Eintrag hat eine TTL (Time to Live) in Sekunden. Sie sagt jedem Resolver: „So lange darfst du dir diese Antwort merken, ohne nachzufragen.” Man kann ihr beim Ablaufen zusehen. Wir haben getmind.io dreimal im Abstand von vier Sekunden abgefragt:

265
261
257

Der Cache zählt die Zeit herunter. Bei 0 fliegt der Eintrag raus, und die nächste Anfrage holt ihn frisch beim Nameserver.

Daraus folgt die wichtigste praktische Regel für jeden, der einen Server umzieht: Die TTL muss vor dem Umzug sinken, nicht währenddessen. Steht ein Eintrag auf 86.400 Sekunden (ein Tag) und du änderst die IP, dann können Resolver, die die alte Antwort gerade gecacht haben, bis zu einen Tag lang die alte Adresse ausliefern. Senkst du die TTL einen Tag vorher auf 300, dann dauert der Übergang am Umzugstag höchstens fünf Minuten. Danach kannst du sie wieder hochsetzen.

Die wichtigsten DNS-Record-Typen

Eine DNS-Zone besteht aus Einträgen (Records). Die meisten Domains kommen mit einer Handvoll Typen aus.

Zwei Einschränkungen, über die fast jeder einmal stolpert:

• Ein CNAME darf nicht neben anderen Einträgen stehen. Auf der nackten Domain (beispiel.de ohne www) liegen immer NS- und SOA-Einträge, darum ist dort kein CNAME erlaubt. Anbieter wie Cloudflare umgehen das mit „CNAME Flattening”: Sie lösen den Alias selbst auf und liefern nach außen einen A-Eintrag.
• Ein MX darf nicht auf einen CNAME zeigen, sondern muss auf einen Namen mit A- oder AAAA-Eintrag verweisen. Viele Mailserver tolerieren es trotzdem, verlassen sollte man sich darauf nicht.

Was wir in unserer eigenen Zone gefunden haben

Ein Artikel über DNS, der nur erklärt, wäre billig. Wir haben deshalb unsere eigene Domain so abgefragt, wie es ein Außenstehender tun würde, und drei Dinge gefunden, die wir hier offen benennen. Geändert haben wir für diesen Artikel nichts. Es sind Entscheidungen, die man bewusst trifft, nicht nebenbei beim Schreiben.

Fund 1: Eine Wildcard fängt jeden Tippfehler

dig nichtda-123.getmind.io +short
# 46.225.123.163

Jeder beliebige Name unter getmind.io löst auf unseren Server auf, auch einer, den es nie gab. Der Grund ist ein Wildcard-Eintrag *.getmind.io, den wir beim autoritativen Nameserver direkt sehen konnten. Bei heynyx.dev ist es genauso, dort ist er Absicht, weil wir ständig neue Subdomains für Projekte anlegen und nicht jedes Mal das DNS anfassen wollen.

Was das in der Praxis heißt: Ein Tippfehler wie wwww.getmind.io landet nicht bei einem „Domain nicht gefunden”, sondern bei unserem Server. Über HTTP antwortet der mit einer Weiterleitung (Status 308), über HTTPS scheitert die Verbindung am Zertifikat, weil für den erfundenen Namen keins existiert. Für Besucher ist das verwirrender als eine saubere Fehlermeldung. Und jeder Scanner, der Subdomains durchprobiert, bekommt auf alles ein „Ja”. Wildcards sind bequem, aber man sollte wissen, dass man eine hat.

Fund 2: Der Rückwärts-Eintrag zeigt auf ein anderes Projekt

dig -x 46.225.123.163 +short

Die Rückwärtsauflösung (PTR) unserer Server-IP liefert nicht getmind.io, sondern einen Mail-Hostnamen eines älteren Projekts, das auf demselben Server lief. Für Websites ist das egal, PTR-Einträge spielen dort keine Rolle. Für E-Mail ist es wichtig: Viele Mailserver prüfen, ob die IP des Absenders einen PTR-Eintrag hat und ob der zum Namen passt, mit dem sich der Server meldet. Wer von einem eigenen Server Mails verschickt, sollte den PTR-Eintrag beim Hoster (nicht beim Domain-Anbieter, die IP gehört dem Hoster) passend setzen.

Fund 3: Kein DNSSEC

dig DS getmind.io +short
# (leer)

Für getmind.io existiert kein DS-Eintrag in der .io-Zone, die Domain ist also nicht mit DNSSEC signiert. Die Endung .io selbst ist signiert, das zeigte der +trace weiter oben mit einem DS-Eintrag für io.. Die Kette bricht also genau bei uns ab. Unser lokaler Resolver prüft DNSSEC übrigens auch nicht (DNSSEC=no/unsupported in resolvectl status, alle Zähler auf 0).

Was DNSSEC bringt: Antworten sind kryptografisch signiert, ein Resolver kann erkennen, ob jemand unterwegs eine gefälschte Adresse untergeschoben hat. Was es kostet: Ein Fehler bei der Schlüsselrotation macht die Domain für alle prüfenden Resolver unerreichbar, und das ist schon großen Betreibern passiert. Bei Cloudflare ist DNSSEC ein Klick plus ein Eintrag beim Registrar. Dass wir es nicht aktiviert haben, ist kein Statement, sondern schlicht nie angefasst worden. Genau solche Dinge findet man nur, wenn man selbst nachsieht.

DNS-Probleme erkennen: „It’s always DNS”

Wenn eine Website nicht lädt, lohnt sich ein schneller Blick, ob es am DNS liegt. Diese Befehle reichen für 90 % der Fälle.

Löst der Name überhaupt auf?

dig beispiel.de +short          # Linux/macOS
nslookup beispiel.de            # auch unter Windows

Kommt keine Adresse zurück, liegt es am DNS. Kommt eine zurück, aber die Seite lädt trotzdem nicht, liegt es eher am Server, an der Firewall oder am Zertifikat.

Liefert die Quelle etwas anderes als mein Resolver?

dig beispiel.de +short                              # über deinen Resolver (evtl. gecacht)
dig @$(dig NS beispiel.de +short | head -1) beispiel.de +short   # direkt beim zuständigen Nameserver

Unterscheiden sich die beiden Antworten, hast du gerade etwas geändert, und dein Resolver hat noch die alte Antwort im Cache. Dann hilft nur Warten (bis die TTL abläuft) oder den eigenen Cache leeren:

sudo resolvectl flush-caches     # Linux mit systemd-resolved
ipconfig /flushdns               # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS

Der Cache deines Internetanbieters lässt sich so natürlich nicht leeren. Für einen schnellen Gegencheck kannst du deshalb direkt einen anderen Resolver fragen, zum Beispiel dig @1.1.1.1 beispiel.de.

Was bedeuten die Statuscodes?

Eine Falle haben wir selbst schon erlebt: Eine Domain lieferte plötzlich NXDOMAIN direkt an der Registry, obwohl der Server einwandfrei lief und alle Einträge korrekt waren. Ursache war ein Registry-Hold wegen nicht verifizierter Inhaberdaten. Wenn sogar der TLD-Server die Domain nicht mehr kennt, liegt das Problem beim Registrar, nicht in deiner Zone. Mit dig +trace siehst du, an welcher Station die Kette abreißt.

Warum sich DNS-Änderungen „langsam verbreiten”

Oft liest man, DNS-Änderungen bräuchten „bis zu 48 Stunden, um sich zu verbreiten”. Das ist eine irreführende Formulierung. Nichts verbreitet sich. Dein autoritativer Nameserver kennt die neue Adresse in der Regel nach Sekunden. Was dauert, ist das Ablaufen der alten Caches überall auf der Welt, und wie lange das höchstens dauert, bestimmt die TTL, die der alte Eintrag hatte. Bei 300 Sekunden ist der Spuk nach fünf Minuten vorbei. Die 48 Stunden stammen von Änderungen an den Nameservern selbst, denn die stehen in der TLD-Zone mit langen TTLs (bei .io zwei Tage, wie der Trace oben zeigt).

DNS und Sicherheit

DNS wurde in den 1980ern entworfen, und dem klassischen Protokoll sieht man das an: Anfragen und Antworten gehen unverschlüsselt und unsigniert über UDP-Port 53. Daraus ergeben sich drei Themen.

Mitlesen. Jeder auf dem Weg, also WLAN-Betreiber, Internetanbieter oder jemand im selben Café-Netz, sieht, welche Namen du nachschlägst. Abhilfe schaffen DNS over HTTPS (DoH) und DNS over TLS (DoT), die die Anfrage verschlüsseln. Moderne Browser können DoH direkt, Android kann DoT als „Privates DNS”. Beachte: Der Resolver selbst sieht deine Anfragen trotzdem. Du verschiebst das Vertrauen nur vom Netz zum Resolver-Betreiber.

Fälschen. Wer Antworten fälschen kann, schickt dich auf einen falschen Server. DNSSEC schützt davor, indem es Antworten signiert. Wie oben beschrieben, ist die Verbreitung noch lückenhaft, auch bei uns.

Missbrauch der eigenen Zone. Vergessene Einträge sind ein echtes Risiko. Zeigt ein CNAME auf einen Cloud-Dienst, den du längst gekündigt hast, kann jemand anderes dort ein Konto mit demselben Namen anlegen und Inhalte unter deiner Subdomain ausliefern („Subdomain Takeover”). Gelegentlich alle Einträge durchgehen und Altlasten löschen ist billiger als jeder Vorfall.

Außerdem gilt: DNS ist öffentlich. Jeder Name, den du anlegst, und jedes Zertifikat, das du dafür ausstellst, landet früher oder später in Datenbanken, die Angreifer durchsuchen. In unserem Artikel zum Linux-Server einrichten haben wir gemessen, dass SSH-Angriffe auf unseren Server gezielt Benutzernamen verwenden, die aus unseren Domains stammen, während ein Server ohne Domain nur generische Namen abbekam. Eine Subdomain wie intern-test.beispiel.de ist nicht geheim, nur weil du sie nirgends verlinkst.

Brauche ich einen eigenen DNS-Server?

Die kurze Antwort für fast alle: nein. Es gibt zwei sehr verschiedene Dinge, die man „eigenen DNS-Server” nennt.

Eigener autoritativer Nameserver (die Zone selbst hosten, etwa mit BIND, Knot oder PowerDNS): Das lohnt sich nur, wenn DNS dein Kerngeschäft ist. Du brauchst mindestens zwei Server an verschiedenen Standorten, Überwachung, saubere Updates, und ein Ausfall macht alle deine Domains unerreichbar. Kostenlose Angebote wie Cloudflare, die DNS-Hosting der meisten Registrare oder Hetzner DNS sind schneller, weltweit verteilt und robuster, als ein Einzelner es nachbauen kann. Unsere Zonen liegen alle bei Cloudflare.

Eigener rekursiver Resolver oder Filter (zum Beispiel Pi-hole, AdGuard Home oder Unbound im Heimnetz): Das ist ein beliebtes und sinnvolles Projekt. Du blockst Werbung und Tracker für alle Geräte im Netz, siehst, welches Gerät welche Namen nachschlägt, und mit Unbound fragst du die Root-Server direkt, statt einem fremden Resolver zu vertrauen. Ein kleiner VPS oder ein Raspberry Pi reicht dafür völlig. Den Resolver aber nie offen ins Internet stellen: Ein offener Resolver wird innerhalb von Stunden für DDoS-Verstärkungsangriffe missbraucht. Port 53 gehört mit einer Firewall wie UFW auf das eigene Netz beschränkt.

DNS für die eigene Domain einrichten: der typische Ablauf

Wenn du eine Domain gekauft hast und eine Website darauf legen willst, sieht der Ablauf meistens so aus:

1. Entscheiden, wo die Zone liegt. Entweder beim Registrar lassen oder die Nameserver auf einen DNS-Anbieter wie Cloudflare umstellen. Die Umstellung der Nameserver ist die eine Änderung, die wirklich bis zu zwei Tage dauern kann.
2. A- und gegebenenfalls AAAA-Eintrag für die nackte Domain auf die IP deines Servers setzen.
3. www als CNAME auf die nackte Domain oder ebenfalls als A-Eintrag. Ob www oder ohne die Hauptadresse ist, entscheidet dann der Webserver per Weiterleitung.
4. Prüfen, ob es auflöst: dig deinedomain.de +short direkt beim Nameserver und über einen öffentlichen Resolver.
5. Erst dann das Zertifikat holen. Let’s Encrypt prüft per DNS, ob die Domain wirklich auf deinen Server zeigt. Ein Webserver wie Caddy macht das automatisch, mehr dazu in Caddy vs. Nginx.
6. Wenn du Mails verschickst: MX, SPF, DKIM und DMARC anlegen. Ohne diese Einträge landen deine Mails im Spam oder werden abgelehnt.
7. Optional: CAA-Eintrag, um festzulegen, welche Zertifizierungsstellen für deine Domain Zertifikate ausstellen dürfen, und DNSSEC.

Ein Tipp aus eigener Erfahrung: Bevor du irgendetwas an einer bestehenden Zone änderst, exportiere sie. Cloudflare und die meisten Anbieter bieten einen Zonen-Export als Textdatei an. Ein falsch gelöschter TXT-Eintrag kann die Mail-Zustellung tagelang stören, und dann ist man froh, wenn man den alten Wert noch hat.

Was wir nicht gemessen haben

Damit niemand mehr aus unseren Zahlen liest, als drinsteht:

• Die Resolver-Messung ist eine Momentaufnahme von einem Server in einem Rechenzentrum an einem Morgen, je fünf Durchläufe. Von deinem Heimanschluss können die Werte völlig anders aussehen.
• DoH haben wir nur mit einzelnen curl-Aufrufen gemessen, also mit TLS-Handshake pro Anfrage. Browser mit offener Verbindung sind deutlich schneller.
• DNS over TLS konnten wir mangels passendem Werkzeug auf dem Server nicht messen.
• Die Cache-Statistik zählt nur den lokalen Stub-Resolver. Wie viele der Fehlschläge Hetzners Resolver aus seinem eigenen Cache beantwortet hat, sehen wir von außen nicht.

Häufige Fragen

Was ist DNS einfach erklärt?

DNS (Domain Name System) ist das Adressbuch des Internets. Es übersetzt Namen wie getmind.io, die sich Menschen merken können, in IP-Adressen wie 46.225.123.163, mit denen Rechner sich verbinden. Jedes Mal, wenn du eine Website aufrufst oder eine E-Mail verschickst, findet im Hintergrund eine DNS-Abfrage statt.

Was ist ein DNS-Server?

„DNS-Server” ist ein Sammelbegriff. Gemeint ist entweder ein Resolver, der für dich Antworten sucht und zwischenspeichert (das ist der, den du im Router oder Betriebssystem einstellst), oder ein autoritativer Nameserver, der die Einträge einer Domain verbindlich verwaltet. Die Root- und TLD-Server sind spezielle autoritative Server für die oberen Ebenen.

Welchen DNS-Server soll ich nehmen?

Für die meisten ist der Resolver des eigenen Internetanbieters oder Hosters völlig in Ordnung und oft am schnellsten, weil er nah ist und einen großen Cache hat. Wer Wert auf Datenschutz oder Filter legt, nimmt einen Anbieter wie Cloudflare (1.1.1.1), Quad9 (9.9.9.9) oder Mullvad, idealerweise verschlüsselt per DoH oder DoT. In unserer Messung lagen Cloudflare, Google und Mullvad gleichauf bei 15 bis 20 ms, Quad9 war an diesem Morgen von unserem Standort aus deutlich langsamer.

Was bedeutet DNS im Router?

Im Router stehen die DNS-Server, die alle Geräte in deinem Netz zum Nachschlagen benutzen. Meist trägt der Internetanbieter sie automatisch ein, und der Router reicht die Anfragen nur weiter. Änderst du sie dort, gilt die Änderung für alle Geräte im Heimnetz auf einmal.

Was ist der Unterschied zwischen DNS und IP?

Die IP-Adresse ist die eigentliche Adresse eines Rechners im Netz, vergleichbar mit einer Telefonnummer. DNS ist das System, das zu einem Namen die passende IP-Adresse herausfindet, vergleichbar mit dem Telefonbuch. Ohne IP keine Verbindung, ohne DNS keine Namen.

Wie lange dauert eine DNS-Änderung?

Der autoritative Nameserver kennt die neue Antwort meist nach Sekunden. Bis alle Resolver weltweit sie ausliefern, vergeht höchstens die TTL des alten Eintrags. Bei 300 Sekunden sind das fünf Minuten, bei 86.400 Sekunden ein Tag. Die oft genannten 48 Stunden gelten für einen Wechsel der Nameserver selbst, nicht für normale Einträge.

Was ist ein DNS-Fehler und wie behebe ich ihn?

Ein DNS-Fehler heißt, dass der Name nicht in eine Adresse übersetzt werden konnte, im Browser oft als „DNS_PROBE_FINISHED_NXDOMAIN” oder „Server nicht gefunden”. Erste Schritte: Tippfehler prüfen, den lokalen DNS-Cache leeren, testweise einen anderen Resolver wie 1.1.1.1 nehmen und mit dig oder nslookup prüfen, ob der Name überhaupt auflöst. Liefert sogar der zuständige Nameserver nichts, liegt der Fehler in der Zone oder beim Registrar.

Was ist DNS over HTTPS?

DNS over HTTPS (DoH) verpackt DNS-Anfragen in verschlüsseltes HTTPS. Dadurch kann niemand auf dem Weg mitlesen oder manipulieren, welche Namen du nachschlägst. In unserem Test war DoH mit einzelnen Aufrufen etwa dreimal langsamer als klassisches DNS, im Browser mit dauerhaft offener Verbindung fällt das kaum ins Gewicht.

Was ist DNSSEC?

DNSSEC ergänzt DNS-Antworten um digitale Signaturen. Ein prüfender Resolver kann damit erkennen, ob eine Antwort unterwegs gefälscht wurde. Es schützt die Echtheit, aber nicht die Vertraulichkeit; dafür sind DoH und DoT da. Viele Domains, auch unsere, nutzen es noch nicht.

Was ist ein A-Record und was ein CNAME?

Ein A-Record verknüpft einen Namen direkt mit einer IPv4-Adresse. Ein CNAME sagt: Dieser Name ist nur ein anderer Name für einen anderen Eintrag, schau dort nach. A-Records verwendest du für die Hauptadresse, CNAMEs für Aliase wie www oder für Subdomains, die auf einen externen Dienst zeigen.

Kann ich DNS ohne Internetanbieter nutzen?

Ja. Du kannst in Betriebssystem oder Router jeden öffentlichen Resolver eintragen, oder mit Software wie Unbound einen eigenen Resolver betreiben, der direkt bei den Root-Servern anfängt. Dein Internetanbieter sieht dann zwar weiterhin, mit welchen IP-Adressen du dich verbindest, aber nicht mehr deine DNS-Anfragen, sofern sie verschlüsselt laufen.

Fazit: DNS ist unsichtbar, bis es kaputt ist

Was ist DNS? Ein verteiltes, hierarchisches Verzeichnis, das Namen in Adressen übersetzt, und eines der robustesten Systeme des Internets. Unser Server hat in drei Wochen über 300.000 Anfragen gestellt, mehr als die Hälfte davon kam aus dem Cache, und gerade einmal 27 liefen in einen Timeout. Die komplette Kette vom Root-Server bis zur Antwort dauerte 66 Millisekunden.

Die wichtigsten Dinge zum Mitnehmen sind wenige: Die TTL entscheidet, wie schnell Änderungen ankommen, also vor einem Umzug senken. Beim Registrar stehen nur die Nameserver, die Einträge pflegst du dort, wohin die zeigen. Und mit dig siehst du in Sekunden, ob ein Problem wirklich am DNS liegt oder nur so aussieht.

Und wenn du schon mal dabei bist: Frag deine eigene Domain ab, so wie wir es für diesen Artikel getan haben. Wir haben eine Wildcard gefunden, die wir halb vergessen hatten, einen Rückwärts-Eintrag aus einem alten Projekt und eine fehlende DNSSEC-Signatur. Nichts davon war dringend, aber alles davon hätte man irgendwann bei einem Fehler suchen müssen. Lieber jetzt.