DNS einfach erklärt: Auflösung, Cache und Sicherheit

Stell dir vor, du gibst lernportal.example.org in den Browser ein. Dein Gerät kennt die passende IP-Adresse noch nicht. Es übergibt die Frage normalerweise an einen vorkonfigurierten rekursiven Resolver. Das ist ein DNS-Dienst, der im Auftrag deines Geräts eine abschließende Antwort beschafft.

Bei einer vollständig ungecachten Suche arbeiten mehrere Rollen zusammen:

1. Der Stub-Resolver auf deinem Gerät sendet die Frage an einen rekursiven Resolver.
2. Ein Root-Nameserver verweist den Resolver auf die zuständige Top-Level-Domain, hier .org.
3. Ein TLD-Nameserver für .org verweist auf die autoritativen Nameserver von example.org.
4. Ein autorativer Nameserver liefert den maßgeblichen Datensatz für die Zone, zum Beispiel einen A- oder AAAA-Record.
5. Der rekursive Resolver gibt die Antwort an dein Gerät zurück. Erst jetzt kann der Browser eine Verbindung zur Zieladresse aufbauen.

Ein Verweis enthält NS-Einträge und bei Bedarf zusätzliche A- oder AAAA-Adressen der genannten Nameserver. Diese zusätzlichen Adressen heißen Glue Records. Ohne sie müsste der Resolver unter Umständen erst den Namen des nächsten Nameservers auflösen.

Die Wörter rekursiv und iterativ beschreiben nicht zwei konkurrierende Wege für denselben Teilnehmer. Eine typische Auflösung verbindet beide Formen.

• Rekursive Anfrage: Dein Gerät verlangt vom rekursiven Resolver eine abschließende Antwort oder eine Fehlermeldung. Es verfolgt die DNS-Hierarchie nicht selbst.
• Iterative Anfrage: Der Resolver fragt andere Nameserver nacheinander. Ein Server antwortet mit den besten Informationen, die er hat: dem Datensatz, einem Fehler oder einem Verweis auf einen näher zuständigen Server.
• Nichtrekursive Anfrage: Ein Server kann sofort antworten, weil er selbst autoritativ ist oder einen noch gültigen Cacheeintrag besitzt.

Ein Verweis bedeutet nicht, dass der Root- oder TLD-Server die Anfrage heimlich weiterleitet. Er nennt dem Resolver die nächste zuständige Stelle. Der Resolver stellt dann selbst die nächste Anfrage.

Ein DNS-Cache speichert Datensätze vorübergehend. Das beschleunigt wiederholte Anfragen und entlastet Nameserver und Netzverbindungen. Die TTL (Time to Live) gibt in Sekunden an, wie lange ein Datensatz höchstens im Cache bleiben darf.

Auch negative Antworten können gespeichert werden. NXDOMAIN bedeutet, dass der angefragte Name nicht existiert. NODATA bedeutet, dass der Name existiert, aber keinen Datensatz des gefragten Typs besitzt. Die Dauer negativer Cacheeinträge wird mit Angaben aus dem SOA-Record der Zone begrenzt.

Die TTL erzeugt einen Zielkonflikt:

DNS liefert nicht einfach „die eine Adresse“. Eine Anfrage nennt einen Namen und einen Recordtyp. Der Typ legt fest, welche Art von Information gesucht wird.

Ein Forward Lookup fragt typischerweise von einem Namen zur Adresse. Ein Reverse Lookup fragt in einem besonderen DNS-Namensraum von einer Adresse zu einem PTR-Eintrag. Eine erfolgreiche Rückauflösung beweist allein noch nicht, dass ein Dienst vertrauenswürdig ist.

Wenn eine Website nicht erreichbar ist, ist nicht automatisch DNS schuld. Verfolge den Ablauf in der richtigen Reihenfolge:

1. Namensfrage: Ist der Name korrekt geschrieben und liefert DNS einen passenden Record?
2. Cache: Wird möglicherweise noch eine nicht abgelaufene alte Antwort verwendet?
3. Verbindung: Ist die ermittelte IP-Adresse erreichbar und kann eine Transportverbindung aufgebaut werden?
4. Anwendung: Antwortet der Webserver mit dem erwarteten Inhalt?

Auch unterschiedliche Antworten sind nicht automatisch ein Fehler. Ein Name kann mehrere A- oder AAAA-Records besitzen. Außerdem können interne und externe Resolver bei Split DNS absichtlich verschiedene Zonendaten verwenden.

Klassisches DNS wurde nicht dafür entworfen, jede Antwort kryptografisch zu prüfen oder jede Anfrage zu verschlüsseln. Manipulierte Antworten können deshalb Nutzer zu einer falschen Adresse lenken. Bei Cache Poisoning landet eine falsche Information in einem Resolvercache und kann dort weitere Anfragen beeinflussen.

Weitere Risiken betreffen die Verfügbarkeit. Bei einer DNS-Amplification sendet ein Angreifer kleine Anfragen mit gefälschter Absenderadresse. Größere Antworten treffen dann das Opfer. Öffentlich erreichbare Resolver sollten Rekursion deshalb nicht wahllos für beliebige Clients anbieten.

Drei Schutzideen lösen unterschiedliche Probleme:

• DNSSEC versieht DNS-Datensätze mit digitalen Signaturen. Ein validierender Resolver kann damit Herkunft und Unverändertheit signierter Daten prüfen und auch signierte Nichtexistenz nachweisen. DNSSEC verschlüsselt die Anfrage nicht und sagt nicht, ob der Inhalt einer Website harmlos ist.
• DNS over TLS (DoT) verschlüsselt DNS-Verkehr zwischen Client und gewähltem Resolver mit TLS.
• DNS over HTTPS (DoH) transportiert DNS-Anfragen und -Antworten über HTTPS und schützt auf diesem Abschnitt ebenfalls Vertraulichkeit und Integrität.

DoT und DoH verbergen die Anfrage vor Mitlesenden auf dem geschützten Weg, aber nicht vor dem gewählten Resolver. Sie signieren auch nicht automatisch die autoritativen DNS-Daten. DNSSEC und verschlüsselter Transport ergänzen sich deshalb, statt dass eines das andere vollständig ersetzt.