Was ist das DNS (Domain Name System)?

Das DNS wird oft als „Telefonbuch für das Internet“ bezeichnet. Übertragen auf eine modernere Analogie funktioniert das DNS auf eine ähnliche Weise wie die Kontakte-App auf einem Smartphone: Es verknüpft Domainnamen mit IP-Adressen, wie Smartphones es mit Kontakten und Telefonnummern tun. Dort ist es überflüssig, sich einzelne Telefonnummern zu merken, weil sie in leicht durchsuchbaren Kontaktlisten gespeichert werden.

Vergleichbar damit ermöglicht das DNS den Nutzern, Websites über Domainnamen anstelle von IP-Adressen aufzurufen. Anstatt sich beispielsweise merken zu müssen, dass sich der Webserver einer bestimmten Seite unter „198.51.100.3“ befindet, können die Benutzer einfach die Webseite „www.example.com“ aufrufen, um die gewünschten Ergebnisse zu erhalten.

In Zeiten vor dem DNS war das Internet ein wachsendes Netzwerk von Computern, das hauptsächlich von akademischen Organisationen und Forschungseinrichtungen genutzt wurde. Entwickler ordneten Hostnamen manuell IP-Adressen zu, indem sie eine einfache Textdatei namens HOSTS.TXT verwendeten. SRI International pflegte diese Textdateien und stellte sie allen Computern im Internet zur Verfügung. Mit der Ausweitung des Netzwerks wurde dieser Ansatz jedoch zunehmend untragbar.

Um eine Lösung für die Einschränkungen von HOSTS.TXT zu finden und ein besser skalierbares System zu schaffen, erfand der Informatiker Paul Mockapetris von der University of Southern California 1983 das Domain Name System. Eine Gruppe von Internetpionieren war an der Schaffung des DNS beteiligt und verfasste die ersten Request for Comments (RFCs). Dabei handelt es sich um ein Dokument, das zentrale Spezifikationen eines Internetsystems erläutert und somit seine Funktionsweise definiert. Die ursprünglich von der Gruppe geschaffenen RFCs nannten sich RFC 882 und RFC 883. Später wurden die früheren RFCs durch RFC 1034 und RFC 1035 abgelöst.

Nachdem das DNS konstant zu expandieren begonnen hatte, wurde die Verwaltung des DNS schließlich von der Internet Assigned Numbers Authority (IANA) übernommen, bevor 1998 die gemeinnützige Internet Corporation for Assigned Names and Numbers (ICANN) die Verantwortung für das DNS erhielt.

Bereits von Anfang an konzipierten die Entwickler das DNS mit einer hierarchischen, verteilten Datenbankstruktur, um einen dynamischeren Ansatz zur Auflösung von Domainnamen zu ermöglichen, der mit einem schnell wachsenden Computernetzwerk Schritt halten kann. Die Hierarchie beginnt mit der Root-Ebene, die mit einem Punkt (.) gekennzeichnet ist, und unterteilt sich in Top-Level-Domains (TLDs) – wie „.com“, „.org“, „.net“ oder länderspezifische TLDs (auch Country Code TLDs oder ccTLDs) wie „.uk“ und „.jp“ – und Second-Level-Domains (SLDs). Bei Letzteren handelt es sich um den Teil vor der TLD, den wir häufig als den Namen einer Website wahrnehmen. Im Falle von „example.com“ wäre dies beispielsweise „example“, bei „ibm.com“ hingegen „ibm“. Vor der SLD kann sich wiederum eine Third-Level-Domain befinden, beispielsweise „mail“ vor „mail.example.com“.

Die DNS-Architektur besteht aus zwei Typen von DNS-Servern: rekursiven Servern und autoritativen Servern. Rekursive DNS-Server sind diejenigen, die die „Anfrage“ stellen und nach den Informationen suchen, die einen Benutzer mit einer Website verbinden, während autoritative Server auf diese Anfragen „antworten“. Im Folgenden werden beide Typen genauer beschrieben.

Rekursive Server – auch bekannt als rekursive Resolver oder DNS-Resolver – werden in der Regel von Internetdienstanbietern (Internet Service Providers, ISPs), großen Unternehmen oder anderen DNS-Service-Anbietern verwaltet. Sie handeln im Auftrag des Endnutzers, um den Domainnamen in eine IP-Adresse aufzulösen. Rekursive Resolver speichern die Antworten auf eine Anfrage für einen bestimmten Zeitraum (definiert durch den Time-to-Live- oder TTL-Wert) zwischen, um die Effizienz des Systems für zukünftige Abfragen an dieselbe Domain zu verbessern.

Wenn ein Benutzer eine Webadresse in die Suchleiste eines Browsers eingibt, stellt der Browser eine Verbindung zu einem rekursiven DNS-Server her, um die Anfrage aufzulösen. Wenn der rekursive Server die Antwort zwischengespeichert hat, kann er den Benutzer verbinden und die Anfrage abschließen. Andernfalls schickt der rekursive Resolver eine Reihe von Abfragen an autoritative DNS-Server, um die IP-Adresse zu finden und den Benutzer mit der gewünschten Website zu verbinden.

Autoritative Server liefern die „Antworten“ auf diese Anfragen. Autoritative Nameserver enthalten die definitiven Datensätze für eine Domain und antworten auf Anfragen zu Domainnamen, die in ihren jeweiligen Zonen gespeichert sind (normalerweise mit vom Domaininhaber konfigurierten Antworten). Es gibt verschiedene Arten autoritativer Nameserver, die jeweils eine bestimmte Funktion innerhalb der DNS-Hierarchie erfüllen.

Zu den autoritativen DNS-Nameservern gehören:

Root-Nameserver stehen an der Spitze der DNS-Hierarchie und sind für die Verwaltung der Root-Zone (der zentralen Datenbank für das DNS) verantwortlich. Sie beantworten Abfragen zu Datensätzen, die in der Root-Zone gespeichert sind, und leiten Anfragen an die entsprechenden TLD-Nameserver weiter.

Es gibt 13 IP-Adressen, die für die Abfrage von 13 verschiedenen Root-Server-Netzwerken verwendet werden – gekennzeichnet durch die Buchstaben A bis M. Sie bearbeiten die Abfragen für die TLDs und leiten die Anfragen an die entsprechenden TLD-Nameserver weiter. Diese Root-Server-Netzwerke werden von der Internet Corporation for Assigned Names and Numbers (ICANN) betrieben.

TLD-Server sind für die Verwaltung der nächsten Hierarchieebene verantwortlich, einschließlich generischer Top-Level-Domains (gTLDs). TLD-Nameserver leiten Abfragen an die autoritativen Nameserver für die spezifischen Domains innerhalb ihrer TLD weiter. Der TLD-Nameserver für „.com“ leitet also Domains weiter, die auf „.com“ enden, der TLD-Nameserver für „.gov“ leitet Domains weiter, die auf „.gov“ enden, und so weiter. Indem einem bestimmten Nameserver die Verantwortung über eine TLD zugeordnet wird, entsteht eine Struktur, die die Internetkommunikation trotz der stets wachsenden Menge an Websites organisieren und somit deutlich erleichtern kann.

Der Domain Name Server (manchmal auch als Second-Level Domain Name Server oder Domain Name Server der zweiten Ebene bezeichnet) enthält die Zonendatei mit der IP-Adresse für den vollständigen Domainnamen, beispielsweise „ibm.com“. Über diese IP-Adresse kann die Website schließlich aufgerufen werden. Interessant ist, dass vor dem Domainnamen noch weitere sogenannte Subdomains hinzugefügt werden, die je nach Tiefe als Third-Level Domain, Fourth-Level Domain usw. bezeichnet werden – eine Hierarchie, die sich praktisch beliebig weit vertiefen lässt. Hier können Hosts ihre eigenen DNS-Einstellungen festlegen und so bestimmen, ob Subdomains auf denselben oder einen anderen Server verweisen sollen.

Jede DNS-Abfrage (manchmal auch DNS-Anfrage genannt) folgt derselben Logik zum Auflösen von IP-Adressen. Wenn ein Benutzer eine URL eingibt, fragt sein Computer nach und nach DNS-Server ab, um die entsprechenden Informationen und Ressourceneinträge zu finden, die der Anfrage des Benutzers oder der Benutzerin entsprechen. Dieser Prozess wird so lange fortgesetzt, bis das DNS die richtige Antwort von dem autoritativen DNS-Server findet, der mit dieser Domain verbunden ist. Dieser Vorgang lässt sich als ein Bote visualisieren, der nach und nach einer Reihe von Wegweisern folgt, bis er am finalen Ziel letztendlich die gesuchte Information findet und sie dem Anfragesteller übergibt.

Diese Beschreibung ist allerdings eher generell gehalten. Im Detail umfasst die Abfrageauflösung im DNS mehrere Schlüsselprozesse und -komponenten, die hier näher betrachtet werden sollen.

Ein Benutzer gibt einen Domainnamen, wie z. B. „ibm.com“, in einen Browser oder eine App ein und die Anfrage wird an einen rekursiven DNS-Resolver gesendet. Normalerweise verfügt das Gerät des Benutzers über vordefinierte DNS-Einstellungen, die vom Internetdienstanbieter (Internet Service Provider, ISP) bereitgestellt werden und bestimmen, welchen rekursiven Resolver ein Client abfragt. An vielen Geräten verfügen technisch versierte Nutzer zudem auch über die Möglichkeit, manuell einen rekursiven Resolver zu wählen, der möglicherweise bestimmte Ansprüche erfüllt.

Der rekursive Resolver überprüft seinen Cache – den Zwischenspeicher eines Webbrowsers oder Betriebssystems (wie macOS, Windows oder Linux), in dem frühere DNS-Abfragen gespeichert sind – auf die entsprechende IP-Adresse der Domain. Wenn der rekursive Resolver die DNS-Lookup-Daten nicht in seinem Cache hat, beginnt er damit, sie von den autoritativen DNS-Servern abzurufen, angefangen beim Root-Server. Der rekursive Resolver fragt die DNS-Hierarchie ab, bis er die endgültige IP-Adresse findet.

Der rekursive Resolver fragt einen Root-Nameserver ab, der mit einem Verweis auf den entsprechenden TLD-Server für die betreffende Domain antwortet. In diesem Beispiel wählt er den TLD-Nameserver, der für „.com“-Domains zuständig ist.

Der Resolver fragt den TLD-Nameserver „.com“ ab, der mit der Adresse des autoritativen Nameservers für „ibm.com“ antwortet, der manchmal auch als Domain Name Server der zweiten Ebene oder Second Level Domain Name Server bezeichnet wird.

Der Resolver fragt den Nameserver der Domain ab, der die DNS-Zonendatei durchsucht und mit dem richtigen Datensatz für den angegebenen Domainnamen antwortet.

Der rekursive Resolver speichert den DNS-Datensatz für eine durch die TTL des Datensatzes festgelegte Zeit im Cache und gibt die IP-Adresse an das Gerät des Nutzers zurück. Der Browser oder die App kann dann eine Verbindung mit dem Hostserver unter dieser IP-Adresse herstellen, um auf die angeforderte Website oder den Service zuzugreifen. Der Browser selbst musste also nur eine einzelne Abfrage stellen, während der rekursive Resolver seinem Namen gemäß mehrere aufeinanderfolgende Abfragen stellen musste, um sich Schritt für Schritt durch die unterschiedlichen Level und Server zu arbeiten.

Zusätzlich zu den wichtigsten Servertypen verwendet das DNS Zonendateien und verschiedene Eintragstypen, um den Auflösungsprozess zu unterstützen. Diese werden in diesem Abschnitt näher betrachtet.

Jede Zeile einer Zonendatei gibt einen DNS-Ressourceneintrag an (einen einzelnen Teil der Informationen über die Art eines bestimmten Typs oder einer bestimmten Art von Daten handelt). Die Ressourceneinträge stellen sicher, dass das DNS Domainnamen schnell in nutzbare Informationen umwandeln kann, die einen Benutzer zum richtigen Server weiterleitet, wenn er eine Abfrage sendet.

DNS-Zonendateien beginnen mit zwei obligatorischen Einträgen: der globalen Time to Live (TTL), die angibt, wie die Einträge im lokalen DNS-Cache gespeichert werden sollen, und dem Start of Authority (SOA-Eintrag), der den primären autoritativen Nameserver für die DNS-Zone angibt.

Neben den beiden primären Einträgen kann eine Zonendatei mehrere andere optionale Eintragsarten enthalten, darunter:

Sowohl A-Einträge als auch AAAA-Einträge (auch Quad-A-Eintrag genannt) verweisen auf IP-Adressen und unterscheiden sich nur in Hinblick auf das genutzte Protokoll. Dabei beziehen sich Erstere auf IPv4-Adressen, Letztere hingegen auf IPv6-Adressen.

MX-Einträge geben einen SMTP-E-Mail-Server für eine Domain an.

CNAME-Einträge leiten Hostnamen von einem Alias auf eine andere Domain um (die „kanonische Domain“).

NS-Einträge geben den autoritativen Nameserver für eine Domain an. Häufig werden hier neben dem primären Nameserver noch weitere, sekundäre Nameserver konfiguriert, um die Ausfallsicherheit zu erhöhen. Fehlerhafte NS-Einträge führen dazu, dass die Website für Nutzer nicht länger erreichbar ist.

PTR-Einträge ermöglichen eine umgekehrte DNS-Suche, bei der IP-Adressen Domainnamen zugeordnet werden. Sie lassen sich quasi als das genaue Gegenteil eines A- bzw. AAAA-Eintrags verstehen. Wird beispielsweise eine IP-Adresse direkt über einen Browser angesteuert, gibt der PTR-Eintrag an, welche Domain damit verbunden ist.

TXT-Einträge lassen sich prinzipiell verwenden, um einen beliebigen Text als Zusatzinformation zu einer Domain hinzuzufügen. In der Praxis geben TXT-Einträge heute meist das Absenderrichtlinien-Framework für die E-Mail-Authentifizierung an. Darüber lässt sich die E-Mail-Sicherheit verbessern und Spam reduzieren.

DNS-Lookups beinhalten in der Regel drei Arten von Abfragen:

Rekursive Abfragen, die den rekursiven Server und den DNS-Client verbinden, lösen entweder den Domainnamen vollständig auf oder geben eine Fehlermeldung an den Benutzer zurück, die ihn darüber informiert, dass die Domain nicht gefunden werden kann.

Iterative Abfragen verbinden rekursive Resolver (einen lokalen DNS-Server) und nicht-lokale DNS-Server (wie Root-, TLD- oder Domainnameserver) und erfordern keine Domain-Auflösung. Stattdessen können die Server mit einem Verweis antworten, bei dem der Root-Server den rekursiven Resolver an die TLD verweist, die den Resolver wiederum an einen autoritativen Server verweist, welcher – falls möglich – die Antwort bereitstellt. Daher werden iterative Abfragen entweder mit einer Antwort oder einem Verweis aufgelöst.

Bei nicht-rekursiven Abfragen weiß der rekursive Resolver bereits, wo die Antwort auf die Abfrage zu finden ist, sodass diese Abfragen immer mit einer Antwort aufgelöst werden. Der Resolver spart Zeit, indem er entweder die Antwort im Cache des rekursiven Servers findet oder die DNS-Root- und TLD-Nameserver überspringt und direkt zum entsprechenden autoritativen Server geht. Wenn der rekursive Resolver beispielsweise eine IP-Adresse angibt, die in einer früheren Sitzung zwischengespeichert wurde, gilt die Anfrage als nicht-rekursive Anfrage.

Unternehmen haben verschiedene Möglichkeiten, das DNS zu nutzen, darunter öffentliches und privates DNS oder eine Kombination aus beidem. Ein öffentliches und privates DNS sind zwei völlig unterschiedliche Dinge. Um zu verstehen, wie man das DNS am besten für die Bedürfnisse des Unternehmens nutzt, ist es wichtig zu wissen, wie beide Arten funktionieren.

Verwaltete DNS-Lösungen lagern die Server-Verwaltung und den Orchestrierungsprozess praktisch aus. Bei einem verwalteten System kümmert sich der DNS-Anbieter alle Konfigurations-, Wartungs- und Sicherheitsprotokolle für die DNS-Server einer Organisation, während der Kunde die Infrastruktur des Anbieters verwendet, um Domainnamen zu verwalten. Wenn ein Benutzer in diesem Fall die URL eines Unternehmens eingibt, wird er vom Domain Name Server des Unternehmens auf die Server des Anbieters umgeleitet, die alle Ressourcen abrufen und dem Benutzer antworten.

Außerdem bietet ein verwaltetes DNS weitere Services und Vorteile wie ein dediziertes DNS, globalen Server- Lastausgleich, garantierte Betriebszeit, API-first-Architektur, DNSSEC-Unterstützung, globale Anycast-Netzwerke, beschleunigte Weiterleitungszeiten, Monitoring- und Health-Check-Tools, DDoS-Schutz und mehr.

Die meisten modernen DNS-Server sind recht sicher, selbst bei der Verwendung eines öffentlichen DNS. Dennoch können selbst die besten DNS-Systeme anfällig für Cybersicherheitsprobleme sein. Bestimmte Arten von Angriffen zielen auf die autoritative Seite des DNS ab, während andere auf die rekursive Seite ins Visier nehmen. Zu diesen Angriffen gehören:

DNS-Spoofing, auch Cache Poisoning genannt, liegt vor, wenn ein Angreifer falsche Adressdatensätze in den Cache eines DNS-Resolvers einfügt, sodass der Resolver eine falsche IP-Adresse zurückgibt und Nutzer auf bösartige Websites umleitet. Spoofing kann sensible Daten gefährden und zu Phishing-Angriffen und der Verbreitung von Malware führen. Dies ist besonders perfide, da Internetnutzer in diesem Fall keine Möglichkeit haben, die Echtheit einer Website zu überprüfen. Wenn sicherheitsbewussten Nutzern eine Website verdächtig vorkommt, überprüfen sie häufig die URL in der Adresszeile des Browsers, um zu bestimmen, ob sie wirklich mit der offiziellen URL übereinstimmt. Da der Browser bei einem DNS-Spoofing-Angriff allerdings weiterhin den angeforderten – und somit echten – Domainnamen anzeigt, wird die Website fälschlicherweise als sicher wahrgenommen.

DNS-Amplification ist eine Art Distributed Denial-of-Service (DDoS)-Angriff, bei dem ein Angreifer Abfragen an einen DNS-Server sendet und die Rücksendeadresse so fälscht, dass die Antwort nicht an seine eigene IP-Adresse, sondern an die des Opfers geschickt wird. Diese Angriffe nutzen den zustandslosen Charakter von DNS-Protokollen aus und setzen Techniken ein, mit denen sie nur eine kleine Anfrage stellen, die jedoch eine sehr große Antwort erzeugen kann.

So antwortet der DNS-Server bei einem Amplification-Angriff mit wesentlich längeren Antworten, wodurch sich die an den Benutzer gerichtete Datenverkehrsmenge erhöht und dessen Ressourcen überlastet werden. Dies kann dazu führen, dass das DNS nicht funktioniert und die Anwendung abstürzt.

DNS-Tunneling ist eine Technik, mit der Sicherheitsmaßnahmen umgangen werden, indem Nicht-DNS-Datenverkehr wie HTTP in DNS-Abfragen und -Antworten eingeschlossen wird. Angreifer können DNS-Tunneling nutzen, um Malware-Befehle weiterzuleiten oder Daten aus einem kompromittierten Netzwerk zu exfiltrieren. Dabei verschlüsseln sie die Nutzlast häufig in DNS-Abfragen und -Antworten, um eine Erkennung zu vermeiden.

Beim Domain-Hijacking verschafft sich ein Angreifer unbefugten Zugang zu einem Domain-Registrar-Konto und ändert die Registrierungsdaten einer Domain. Durch Hijacking können böswillige Akteure den Datenverkehr auf bösartige Server umleiten, E-Mails abfangen und auf andere Weise die Kontrolle über die Online-Identität des Benutzers übernehmen. Während sich die Angriffsmethode deutlich vom DNS-Spoofing unterscheidet, bietet Domain-Hijacking Angreifern ähnliche Möglichkeiten. Da böswillige Akteure im übernommenen Konto allerdings auch weitere Domain-Einstellungen ändern können, können sie mit dieser Methode potenziell noch größeren Schaden anrichten.

Vernachlässigte DNS-Einträge für Subdomains, die auf stillgelegte Services verweisen, sind ein ideales Ziel für Angreifer. Wenn ein Dienst (wie etwa ein Cloud-Host) außer Betrieb genommen wurde, der DNS-Eintrag jedoch erhalten bleibt, kann ein Angreifer möglicherweise Anspruch auf die Subdomain erheben und an ihrer Stelle eine schädliche Website oder einen schädlichen Dienst einrichten.

Unabhängig davon, für welchen DNS Service sich ein Unternehmen entscheidet, ist es ratsam, Sicherheitsprotokolle zu implementieren, um DNS-Angriffsflächen zu minimieren, potenzielle Sicherheitsprobleme zu entschärfen und DNS in Netzwerkprozessen zu optimieren. Einige nützliche Praktiken zur Verbesserung der DNS-Sicherheit sind:

• Einsatz von DNS-Sicherheitserweiterungen (DNSSEC) und virtuellen privaten Netzwerken (VPNs): DNSSEC fügt eine zusätzliche Sicherheitsebene für DNS-Abfragen hinzu, indem vorausgesetzt wird, dass DNS-Antworten digital signiert werden. DNSSEC kann insbesondere vor DNS-Spoofing-Angriffen schützen, indem es den Ursprung von Anfragen authentifiziert und die Integrität von DNS-Daten überprüft.
  
  VPNs unterstützen die Geheimhaltung der Nutzerdaten, indem sie IP-Adressen verschlüsseln, sodass u.a. Standort- und Browserverlaufsdaten nicht zurückverfolgt werden können. Anstatt dass Internetnutzer eine direkte Verbindung zu einer Website aufzubauen, wird ein VPN-Server als Vermittler zwischengeschaltet, der auch in unsicheren Netzwerken Daten verschlüsseln und zudem Identität und Standort des Nutzers verschleiern kann.
  
  
• Einsatz von Ratenbegrenzungsmethoden: Die Ratenbegrenzung auf DNS-Servern kann DDoS-Angriffe eindämmen, indem sie die Anzahl der Antworten – oder die Rate, mit der die Server Antworten an einen einzelnen Anfragesteller in einem bestimmten Zeitraum senden können – begrenzt.
  
  
• Verpflichtende Zwei-Faktor-Authentifizierung (2FA) für Domain-Registrars: Die Einrichtung von 2FA für Domain-Registrar-Konten kann es Angreifern erschweren, unbefugten Zugriff auf Server zu erhalten, und das Risiko von Domain-Hijacking verringern.
  
  
• Verwendung von Redundanzen: Die Bereitstellung von DNS in einer redundanten Konfiguration auf mehreren geografisch verteilten Servern kann dazu beitragen, die Verfügbarkeit des Netzwerks im Falle eines Angriffs oder Ausfalls sicherzustellen. Wenn der primäre Server ausfällt, können sekundäre Server die DNS-Auflösung übernehmen.
  
  
• Implementierung von DNS-Flushing: Durch regelmäßiges Leeren des DNS-Caches werden alle Einträge aus dem lokalen System entfernt. Dies kann nützlich sein, um ungültige oder kompromittierte DNS-Einträge zu löschen, die Benutzer zu bösartigen Websites führen könnten.
  
  
• Bleiben Sie über DNS-Bedrohungen informiert: Taktiken von Angreifern und Sicherheitsbedrohungen entwickeln sich genauso weiter wie die Systeme, die sie kompromittieren. Wenn Sie über die neuesten DNS-Schwachstellen und Bedrohungen auf dem Laufenden bleiben, können Ihre Teams den böswilligen Akteuren einen Schritt voraus sein und Sicherheitslücken schließen, bevor Angreifer diese nutzen können.