DNS / Namensauflösung

Du tippst bytearium.com, und noch bevor die Seite lädt, hat dein Rechner schon nachgefragt, wo die eigentlich liegt. Die Antwort kommt vom DNS, und wenn das hakt, „geht das Internet nicht“.

Kurz gesagt

Das Domain Name System übersetzt Namen wie bytearium.com in die Adressen, mit denen sich Rechner tatsächlich verbinden. Es ist keine große Liste, sondern ein Baum aus Zonen. Für jeden Teil antwortet der, dem er gehört.

So funktioniert’s

1. Dein Gerät fragt einen Resolver. Den betreibt meist dein Router, dein Internetanbieter oder ein öffentlicher DNS-Dienst.
2. Hat der Resolver die Antwort nicht im Zwischenspeicher, arbeitet er sich durch den Baum: von der Wurzel zu den Servern für .com und weiter zu den autoritativen Nameservern von bytearium.com. Autoritativ heißt: Dieser Server hält die Originaldaten der Zone.
3. Die Antwort ist ein Ressourceneintrag (Resource Record). Ein A-Eintrag enthält eine IPv4-Adresse, ein AAAA-Eintrag eine IPv6-Adresse. Ein CNAME verweist auf einen anderen Namen, ein MX-Eintrag nennt den Mailserver einer Domain.
4. Jeder Eintrag hat eine TTL (Time to Live) in Sekunden. Sie legt fest, wer die Zone verwaltet, und so lange dürfen Zwischenspeicher die Antwort behalten. TTL 0 heißt: nicht zwischenspeichern.
5. Deshalb brauchen Änderungen Zeit. Bis die TTL abläuft, verteilen Resolver womöglich noch die alte Antwort. Wer eine Änderung plant, senkt die TTL vorher.

In der Praxis

Unter Linux oder macOS zeigt dig die Antwort samt TTL:

dig bytearium.com A
dig bytearium.com AAAA

Unter Windows erledigt das die PowerShell mit Resolve-DnsName bytearium.com. In der Antwort von dig steht die verbleibende TTL in der zweiten Spalte. Schick den Befehl zweimal hintereinander ab und sieh zu, wie sie herunterzählt: Da arbeitet der Zwischenspeicher.

Drei Arten von „geht nicht“

Eine fehlgeschlagene Abfrage ist nicht gleich eine fehlgeschlagene Abfrage. Es lohnt sich, sie auseinanderzuhalten, denn jede zeigt woandershin:

• NXDOMAIN – den Namen gibt es nicht. Typische Ursachen: Tippfehler, ein nie angelegter Eintrag oder die falsche Zone antwortet wegen Split-DNS. Auch dieses „Nein“ merkt sich der Resolver. Das heißt Negative Caching und gehört fest zum DNS, es ist keine Option. Legst du also einen fehlenden Eintrag an, kann die alte Antwort „existiert nicht“ noch so lange im Umlauf sein, bis ihre eigene TTL abgelaufen ist.
• NODATA – den Namen gibt es, aber nicht mit dem Typ, nach dem du gefragt hast. Ein Host nur mit A-Eintrag liefert bei AAAA ein NODATA. Browser, die IPv6 bevorzugen, stecken das still weg; Skripte oft nicht.
• Timeout / SERVFAIL – es hat niemand geantwortet, oder der Resolver hat aufgegeben. Jetzt schaust du auf den Resolver selbst, den Weg dorthin oder kaputte autoritative Server, nicht auf den Eintrag.

dig schreibt den Status in die Kopfzeile (status: NXDOMAIN, status: NOERROR mit leerem Antwortteil bei NODATA, status: SERVFAIL). Lies diese Zeile, bevor du irgendetwas anderes liest.

Wer antwortet dir eigentlich?

In den meisten Heimnetzen hängt eine Kette dazwischen: Gerät → Router → Anbieter- oder öffentlicher Resolver. Jedes Glied darf zwischenspeichern, jedes kann anders antworten. dig @1.1.1.1 bytearium.com fragt gezielt einen Resolver und umgeht deinen Router; dig +trace bytearium.com läuft von der Wurzel bis zu den autoritativen Servern und zeigt dir jeden Schritt. Weichen die beiden voneinander ab, hast du einen veralteten Zwischenspeicher oder ein Split-DNS gefunden, keine kaputte Domain.

Verschlüsselte Abfragen: DoT und DoH

Klassisches DNS läuft unverschlüsselt. Wer auf dem Weg sitzt, kann deine Abfragen mitlesen und verändern. Zwei Standards beheben das zwischen deinem Gerät und dem Resolver: DNS over TLS (DoT, RFC 7858) packt DNS in eine TLS-Verbindung auf einem eigenen Port, DNS over HTTPS (DoH, RFC 8484) bildet jede Frage und Antwort auf einen HTTPS-Austausch ab, sodass es wie normaler Webverkehr aussieht. Beide schützen nur den ersten Abschnitt; der Resolver sieht deine Fragen weiterhin. Browser und manche Betriebssysteme schalten DoH von sich aus ein, und deshalb ignoriert ein Gerät plötzlich den Resolver, den dein Router verteilt. Wenn ein Homelab-Name auf einem Laptop nicht mehr auflöst, überall sonst aber schon: Prüfe, ob genau dieser Laptop verschlüsseltes DNS aktiviert hat und mit einem öffentlichen Resolver spricht, der deine interne Zone nie gesehen hat.

TTL-Werte, die sich bei uns bewährt haben

Es gibt keine amtlich richtige TTL, nur Abwägungen: Eine lange TTL (Stunden) spart Abfragen und übersteht einen Resolver-Ausfall, eine kurze (Minuten) lässt dich einen Dienst umziehen, ohne zu warten. Für interne Homelab-Einträge nehmen wir 300 Sekunden, solange etwas umgebaut wird, und 3.600, sobald es sich eingespielt hat; bei einer öffentlichen Domain senken wir die TTL einen Tag vor einer geplanten Änderung auf 300 und heben sie danach wieder an.

Im Homelab

Ein eigener Resolver (Technitium, Unbound, Pi-hole und Co.) bringt dir drei Dinge: interne Namen für deine Server, einen Zwischenspeicher, den du kontrollierst, und eine Stelle, an der du nachsiehst, wenn etwas klemmt. Halte die interne Zone von der öffentlichen getrennt, gib internen Einträgen eine kurze TTL, solange du Dienste noch hin- und herschiebst, und schreib auf, welchen Resolver jedes Gerät benutzen soll. Der häufigste DNS-Fehler im Homelab, den wir sehen, ist kein kaputter Server, sondern ein Gerät, das still einen anderen Resolver benutzt, als du denkst.

Prüfliste

• Prüfe, ob du eine autoritative Antwort oder eine aus dem Zwischenspeicher siehst.
• Frage A, AAAA und CNAME einzeln ab; funktioniert einer, heißt das nichts für die anderen.
• Sieh dir vor einer geplanten Änderung die TTL an und senke sie rechtzeitig.
• Denk daran, dass dein eigenes Netz anders antworten kann als das öffentliche Internet (Split-DNS).
• Lies zuerst die status:-Zeile: NXDOMAIN, NODATA und SERVFAIL zeigen auf drei verschiedene Probleme.
• Verhält sich ein Gerät anders als der Rest, prüfe DoH- oder DoT-Einstellungen, bevor du am Server drehst.