Kaum ein anderes Element ist so essenziell für das Internet wie das Domain Name System. Ruckelts mal im DNS, reagieren Webseiten und überhaupt alle Internetanwendungen gleich langsamer oder gar nicht. Doch um Fehlerursachen zu ermitteln und zu beseitigen, brauchen Firmen- und Heim-Admins ein weitreichendes Verständnis der Zusammenhänge.

Was ist ein Domain-Name-System-Server und wofür braucht man ihn? Wahrscheinlich haben alle ITler sofort eine Antwort auf diese vermeintlich einfache Frage: Ein Gerät schickt eine DNS-Anfrage, also einen Domainnamen mit der Bitte um Auflösung an den DNS-Server und bekommt darauf eine Antwort in Form einer IP-Adresse.

Das ist nicht falsch, doch genau besehen ist das DNS ein Schwarm von unterschiedlichen DNS-Servern mit klar definierten Rollen. Ebenso gibt es viele Arten von DNS-Anfragen und -Antworten. Wir haben die wesentlichen Elemente, Funktionen und Datenflüsse in einer großen Infografik zusammengefasst, sodass Bezüge und auch Widersprüche ersichtlich werden. Daran orientiert, erläutern wir die wichtigsten DNS-Anfragen und -Antworten.

Zunächst zu den Hauptmerkmalen: Das DNS ist eine weltweit verteilte Datenbank auf Grundlage des Internetprotokolls (IP). Hierarchisch gesehen sind die verschiedenen Server dezentral in einer Baumstruktur gegliedert. Die Hauptaufgabe besteht darin, Beziehungen von Domainnamen (kurz Domains) zu IP-Adressen vorzuhalten und die IP-Adressen auf Anfrage von Inter- und Intranethosts (Clients) herauszugeben.

Denn Hosts wie PCs, Smartphones, Smart-TVs oder Router kommunizieren mit Servern und Clouddiensten zwar ausschließlich anhand von IP-Adressen, doch sie wären damit überlastet, sich die IP-Adressen sämtlicher Server der Welt zu merken und brauchen auch nur einen Bruchteil davon.

Weil sich Serveradressen immer mal ändern können, hat man mit dem DNS eine Abstraktionsebene zur Ermittlung der Adressen aufgesetzt: Hosts und Internetnutzer verwenden Domainnamen als Platzhalter für Server, die sie ansprechen wollen und holen sich vom DNS nur die aktuell erforderlichen IP-Adressen. Nur die Betreiber von DNS-Servern können Adresszuordnungen ändern, löschen oder ergänzen, und zwar nur auf dem Server, der für ihre Domain zuständig ist (autoritativ).

Domains bestehen aus verketteten Labeln, die durch Punkte getrennt und eigentlich auch mit einem Punkt abgeschlossen werden, zum Beispiel „www.ct.de.“. Der abschließende Punkt trennt das Label der ersten Hierarchieebene von der Wurzel (englisch root, leeres Label) und Domains gelten streng genommen nur dann als vollständig, wenn sie mit einem Punkt abschließen (Fully Qualified Domain Name, FQDN).

Bei Eingaben lässt man den abschließenden Punkt meist weg und Anwendungen, Server und Betriebssysteme gehen damit verschieden um: Viele ergänzen den abschließenden Punkt stillschweigend für ihre eigene Arbeit. Aber wer Server konfiguriert, muss peinlich genau auf die abschließenden Punkte achten, sonst kann das misslingen. Manche Anwendungen helfen, indem sie den abschließenden Punkt erzwingen, darunter der DNS-Server BIND9 und der DHCP-Server Kea. Doch es gibt auch Anwendungen, die keinen abschließenden Punkt akzeptieren. Als Faustregel gilt daher: Bei DNS-Software wie Servern und DNS-nahen Anwendungen wie DHCP-Servern muss man den Punkt angeben, in den meisten anderen Fällen kann man ihn weglassen.

Nach dem äußersten rechten Punkt folgen entgegengesetzt der Leserichtung und in der Hierarchie absteigend: die Top-Level-Domain (TLD wie de, com, net), die Second-Level-Domain (z. B. ct, nrw,…) und schließlich der Hostname (mail, www, chat oder eine andere Zeichenkette). Eine Domain kann man unterhalb der TLD mittels beliebig vielen Labels weiter unterteilen (zum Beispiel erste.ampel.ausfahrt.stadtumgehung.hannover.de), jedoch darf der Name inklusive aller Punkte höchstens 255 Bytes lang sein.

Zu Beginn der Internetära in den 70er Jahren haben Admins noch simple Textdateien als generische Datenbank für Netzwerkinformationen verwendet und darin neben Netzwerkadressen beispielsweise auch Betriebssystemnamen und Dienste ferner Hosts erfasst. Solche Dateien müssen aber auf jedem Host per Hand gepflegt werden. Anfang der 1980er hat die Internet Engineering Task Force das DNS dann ebenfalls als generische Datenbank konzipiert (RFC 882 und 883, inzwischen abgelöst durch RFC 1034 und 1035). Diese muss man nur noch auf allen Hosts einbinden (also den DNS-Resolver per DHCP-Anfrage erfragen und konfigurieren), was die Datenpflege sehr vereinfacht. Dabei sind Domains und IP-Adressen nur zwei von vielen Datentypen. Dennoch wurde das DNS zu Beginn meist nur für Adresseninformationen und Mailrouting verwendet.

Möchte ein Client die IP-Adressen zu einem Hostnamen herausfinden, sendet er eine rekursive Anfrage an den konfigurierten DNS-Server (Resolver). Dabei setzt er im DNS-Paket das RD-Bit (Recursion desired). Rekursiv bedeutet: Der Client wünscht nur die finale Antwort (positiv oder negativ) und keine Zwischenantworten von Servern in der Abfragekette sowie auch keine unvollständigen Antworten.

Auf Windows holt der Powershell-Befehl Resolve-DnsName -Name www.ct.de die IPv6- und IPv4-Adressen des ct-Webservers vom Resolver (vom fehlerhaften nslookup raten wir ab), auf Linux der Befehl host www.ct.de.

Im DNS sind die Informationen als Ressource Records gespeichert (RR). IPv6-Einträge heißen AAAA-Records (auch Quad-A gesprochen), IPv4-Einträge heißen A-Records.

Umgekehrt kann man das DNS auch nach den Domainnamen zu einer IP-Adresse befragen. Diese Art DNS-Eintrag nennt man Pointer Ressource Record (PTR RR). Anfragen nach PTRs senden beispielsweise Firewall-Log-Programme, aber auch Netzwerkanalyse-Tools wie Wireshark. Dabei liegen zunächst nur IP-Adressen vor und für weitergehende Untersuchungen sowie zur Verbesserung der Übersicht holt man sich die Domains.

Doch hier wartet ein Stolperstein: Manche Admins fragen die PTRs ab, um alle Domains zu ermitteln, auf die aus ihrem Netzwerk heraus zugegriffen wird, etwa bei Sicherheitsprüfungen. Doch da man mehrere Domains unter derselben IP-Adresse registrieren kann, aber nicht alle Hoster alle Adress-Domain-Bezüge eintragen, können PTR-Abfragen ein unvollständiges Bild liefern. Auch entnimmt manche Log-Software den DNS-Antworten nicht alle Namen, sondern nur den generischen des Webservers; die vielen Kundendomains von Webhostern fehlen dann trotzdem (siehe Infografik „Anfragen nach IP-Adressen und Pointern“). Für ein vollständiges Bild der angefragten Webseiten braucht man daher Werkzeuge, die in die Pakete hineinschauen (Deep Packet Inspection).

Neben AAAA, A und PTR sind viele weitere Ressource Records definiert. Darunter ist der HTTPS-Record derzeit der dritthäufigst angefragte (nach A/AAAA). Moderne Browser wie Firefox, Chrome, Edge sowie Vivaldi und fast alle HTTP/REST-basierten Clients auf macOS, iOS, iPadOS und watchOS verwenden diesen Record, um Webseiten und Diensteserver zu finden. Außerdem gebräuchlich sind MX-Records für Mailserver-Domains, TXT-Records für reinen Text (etwa zur Spam-Bekämpfung per Sender Policy Framework) und Canonical Name Records (CNAME), die auf andere Domains verweisen (Alias-Einträge).

Autoritative und rekursive DNS-Server

Eine Schlüsselrolle bei der Analyse von DNS-Verbindungen spielt die Einordnung von DNS-Servern und DNS-Nachrichten. Aus Clientsicht scheint es so, als gäbe es nur den einen DNS-Server, der Domainnamen zu IP-Adressen auflöst.

Doch genau besehen handelt es sich dabei um einen rekursiven DNS-Server, kurz Resolver (Farbe Lila in der Infografik auf dieser Seite). Er entlastet die Clients ganzer Netzwerke, indem er für sie die Namen zu IP-Adressen auflöst und für späteren Gebrauch im Cache sammelt. So muss ein Client nur eine Anfrage an den Resolver schicken (rekursiver DNS-Query, graue Pfeile) und bekommt von ihm darauf auch nur eine Antwort, egal, wie tief der Resolver im DNS graben musste.

Die Antwort holt der Resolver von jenem DNS-Server, der für die jeweilige Domain zuständig ist (autoritativ). Dort trägt der DNS-Admin die IP-Adresse in der DNS-Zone ein, die in einer Textdatei oder einer Datenbank steckt. Um Ausfällen vorzubeugen, sollten auf jede Domain mindestens zwei Nameserver verweisen (NS), die sich in verschiedenen Layer-3-Subnetzen befinden. Die Zone wird nur auf dem autoritativen Server, dem Primary, gepflegt. Diese enthält den Start of Authority (SOA) Record, der Auskunft über die Zone gibt.

Wird eine Zone geändert, erhalten die Secondaries die aktualisierte Fassung per Zone Transfer über das Transmission Control Protocol (grüne Pfeile). Dieser Zonentransfer besteht aus DNS-Paketen des Typs AXFR oder IXFR (AXFR: transfer of an entire zone, IXFR: incremental transfer).

DNS-Auflösung im Detail

So wie die Hosts keine vollständige Datenbank aller Server der Welt brauchen, so kommen auch Resolver ohne eine Liste aller Server aus, die für die Domains der Welt zuständig sind. Das geht, weil alle Domains des DNS eindeutig sind und weil man die jeweils zuständigen Server zweifelsfrei ermitteln kann, indem man die DNS-Hierarchie von oben nach unten beziehungsweise entgegen der Leserichtung abklappert.

Dabei startet der Resolver bei den Root-Servern, deren IP-Adressen er ab Werk an Bord hat und holt mittels iterativen DNS-Queries (türkise Pfeile) jeweils den Namen und die IP-Adresse der für die nächste Hierarchieebene zuständigen DNS-Server. Er bekommt den angefragten Record erst im letzten Schritt. Alle vorherigen enthalten nur Verweise auf NS-Records von übergeordneten autoritativen DNS-Servern.

Tippt der Benutzer in seinen Browser eine URL wie www.ct.de ein, startet die Namensauflösung. Der Browser fragt das Betriebssystem (1), das die Frage an den konfigurierten DNS-Resolver, beispielsweise einen Fritzbox-Router, schickt (2). Dieser enthält jedoch keinen vollständigen Resolver, sondern nur einen DNS-Proxy (DNS-Forwarder). Er reicht die Anfrage an den tatsächlichen Resolver weiter (3). Der Resolver klopft dann beim Root-Server an (4), um den Rest des DNS-Baums abzuklappern.

Der Root-Server antwortet mit dem Verweis auf die Nameserver von de (5). Einer davon liefert den Verweis auf die Nameserver von ct.de (6 & 7). Schließlich beantwortet der autoritative Server von heise.de den FQDN www.ct.de (8 & 9; die c’t-Redaktion gehört zum Verlag Heise Medien). Mit den Nachrichten 10, 11 und 12 landen die IP-Adressen im Browser, der nun die HTTP(S)-Verbindung zum Webserver aufbaut.

Im Übrigen laufen DNS-Anfragen sowohl per IPv6 als auch IPv4 und über beide Protokolle lassen sich sämtliche definierte DNS-Records abfragen. So kann man etwa einen Resolver per IPv6 nach der IPv4-Adresse (A-Record) einer Domain befragen. Doch Windows hält eine kleine Falle bereit: Das Betriebssystem sendet DNS-Anfragen in Dual-Stack-Umgebungen nur dann per IPv6, wenn man den Resolver per DHCPv6 bekannt gibt. Wenn man ihn hingegen per Router Advertisement (RDNSS Option) konfiguriert, sendet Windows seine DNS-Anfragen trotzdem über IPv4.

UDP, TCP und EDNS0

Es gibt aber viele weitere Fehler und die Ursachenforschung kann vertrackt sein. Die DNS-Auflösung läuft nämlich nur dann reibungslos ab, wenn alle an der Übertragung beteiligten Netzwerkelemente (Server, Firewalls, Loadbalancer, etc.) nicht nur das User Datagram Protocol auf Port 53 für DNS durchlassen, sondern auch TCP auf Port 53 (RFC-Spezifikation 7766) und erweiterte DNS-Pakete gemäß der Spezifikation EDNS0 (RFC 6891). Das klappt nicht immer, denn manche Hersteller implementieren die DNS-Protokolle fehlerhaft oder lassen Dinge weg. Die Internet Engineering Task Force hat im RFC-Dokument 8906 eine Vielzahl von Hindernissen zusammengetragen.

Beispielsweise fassen manche Hersteller die DNS-Kommunikation über TCP als Option auf und lassen sie weg. Deshalb kommt es vor, dass die Namensauflösung stillschweigend scheitert. Eine Ursache ist, dass DNS-Antworten nur dann ohne Weiteres ans Ziel kommen, wenn sie kleiner sind als 512 Bytes. Der Grund dafür ist, dass manche Firewall-Admins größere UDP-Pakete verwerfen lassen, weil sie die dafür erforderliche Fragmentierung fälschlich als Attacke auffassen.

Solche Fehlkonfigurationen fallen immer öfter auf, weil DNS-Antworten zunehmend über DNSSEC abgesichert werden, und durch die DNSSEC-Signaturen werden DNS-Pakete oft größer als 512 Bytes. Ein DNS-Server muss solche Pakete entweder per UDP gemäß EDNS0 senden (dann sind maximal 4096 Byte erlaubt) oder TCP verwenden. Für TCP ist zwar keine Obergrenze definiert, aber wegen des 3-Way-Handshakes ist es langsamer als UDP.

Beides kann wegen fehlkonfigurierter Firewalls, fehlerhafter Loadbalancer oder veralteter DNS-Server an beliebigen Stellen im Internet scheitern, sodass der Resolver keine DNS-Antwort bekommt und der Client die Webseite nicht ansteuern kann. Wohl dem, der in seiner Firewall für eingehendes DNS sowohl UDP als auch TCP freigegeben hat oder besser gleich eine Next-Generation Firewall hat, die die DNS-Applikation unabhängig vom Transportprotokoll erkennt und passieren lässt.

Tipp fürs Heimnetz: Setzen Sie wie in der Grafik „DNS-Pakete aller Couleur“ eingezeichnet, einen Pi-hole in Ihrem LAN ein. Mittels kostenfreier Listen blockiert er DNS-Anfragen für gängige Werbenetzwerke, Tracker und Malware-Sites.

Pro-Tipp: Richten Sie ihn gleich mit einem DNS-Resolver inklusive DNS-Anonymisierung und DNSSEC-Validierung ein, beispielsweise mit DNSCrypt-Proxy (türkise Pfeile vom Raspberry Pi ausgehend). Andernfalls servieren Sie Ihre Surfziele den Betreibern öffentlicher DNS-Resolver auf dem Silbertablett (graue Pfeile vom Raspi zum Public Resolver).

Caching: Es geht ums Timing

Eine sinnvolle, aber nicht unproblematische Technik ist das DNS-Caching: Um die teils langwierigen DNS-Anfragen abzukürzen, speichern viele Clients und auch Server die erhaltenen DNS-Antworten in Caches. Die Dauer hängt vom TTL-Wert ab (Time-To-Live, nicht zu verwechseln mit dem TTL des IPv4-Paketheaders). Den TTL-Wert für Domains trägt der DNS-Admin im autoritativen Server ein (Minuten, Stunden, Tage, …). Je kürzer der TTL-Wert, desto schneller verschwindet der Eintrag aus dem Cache, was bei Tests hilfreich ist. Je länger der TTL, desto seltener wird der autoritative DNS-Server von Resolvern belatschert.

DNS-Caches sind in Resolvern, DNS-Proxies, Betriebssystemen und Anwendungen wie Browsern implementiert. Für jeden Cacheeintrag zählen sie den TTL-Wert sekundenweise herunter und tilgen ihn, wenn er 0 erreicht hat. Falls ein Client nach dem Löschen dieselbe Domain wieder ansteuern will, läuft die komplette DNS-Auflösung von vorn ab.

Dass das Cachen besonders die Resolver entlastet, wird schnell klar, wenn man die Menge der für die Auflösung erforderlichen DNS-Pakete kennt: Um bloß die Domain www.netflix.net aufzulösen, muss ein Resolver satte 110 DNS-Pakete senden und empfangen.

Die Ursache ist, dass Netflix und viele andere Anbieter ihre Server weltweit in Rechenzentren aufstellen, und die Verkehrslast bedarfsgerecht verteilen (Content Delivery Networks, Load-Balancing). Das erfordert unter anderem eine Vielzahl von Weiterleitungen per CNAME, die alle einzeln aufgelöst werden. Doch wenn die Information im Cache liegt, liefert sie ein Resolver innerhalb von Millisekunden und spart dabei CPU-Zyklen und Übertragungsvolumen, weil der Rattenschwanz an DNS-Paketen wegfällt.

Herausfordernd wird ein DNS-Cache, wenn sich die Zone ändert, sodass Cacheeinträge überholt sind. Beispiel: Die Webseite Ihrer Firma muss wegen eines Webserverproblems kurzfristig umziehen. Dafür ändern Sie im autoritativen Server die AAAA- und A-Records, sodass sie zum Ersatzwebserver zeigen. Doch ungünstigerweise beträgt die TTL der Records des defekten Webservers sieben Tage. Die Folge: Alle Resolver, die innerhalb der letzten sieben Tage die Domain Ihrer Firma aufgelöst haben, füttern die Clients aus dem Cache mit veralteten IP-Adressen, bis die TTL abläuft. Folglich können die Browser die Webseite Ihrer Firma trotz aktueller DNS-Einträge nicht öffnen. Viel kann man in dieser Situation nicht tun: In Ihrer eigenen Umgebung können Sie die DNS-Caches leeren (flush). Aber auf alle anderen Resolver dieser Welt haben Sie keinen Einfluss. Um solchen Fällen vorzubeugen, empfiehlt es sich, die TTL vorausschauend zu kürzen, beispielsweise auf zehn Minuten.

Auch das negative Caching kann Kopfschmerzen verursachen: Mit negative Caching ist gemeint, dass Resolver auch die Resource Records für nicht vergebene Domains cachen (NXDomain-Antwort für beispielsweise katzenfrust.de oder riesenzwerg.org). Dafür ist auf dem autoritativen Server je Zone ein Default-TTL hinterlegt. Das RIPE empfiehlt eine Stunde beziehungsweise 3600 Sekunden.

Zu Problemen kann das führen, wenn Sie Ihr DNS-Team beauftragen, eine neue Domain anzulegen und vorher aber getestet haben, ob sie bereits vergeben ist. Damit landet die NXDomain-Info in jedem Resolver auf dem Weg zum autoritativen Server. Wenn Ihr DNS-Team dann die neue Domain registriert, erhalten Sie trotzdem erst mal NXDomain-Antworten, denn die TTL für den veralteten NXDomain-Eintrag muss ja erst ablaufen. Schon mehr als einmal hat dieses Szenario für unberechtigten Unmut und Support-Tickets gesorgt.

Fremde Resolver

In Firmenumgebungen sollte man öffentliche DNS-Resolver wie die von Google (8.8.8.8) oder Cloudflare (1.1.1.1) strikt meiden. Schließlich spiegelt die Liste der angefragten Hostnamen eins zu eins das Surfverhalten aller Mitarbeiter wider und gibt damit Aufschluss über Firmenaktivitäten. Auch Privatpersonen sollte das zu denken geben, aber eine Firma gibt so unter Umständen Geschäftsgeheimnisse preis. Daher sollten Firmen einen eigenen rekursiven Resolver betreiben. Ein weiterer Grund dafür ist, dass DNSSEC-signierte Antworten, die der Resolver geprüft und als vertrauenswürdig klassifiziert hat, möglichst kurz bis zu den Clients reisen sollten, um nachträgliche Manipulation möglichst auszuschließen.

Den autoritativen Server für die eigenen Domains können Firmen zwar ebenfalls selbst betreiben, aber oft weichen sie auf DNS-Provider aus, weil diese vielfach erprobte, hochverfügbare DNS-Server anbieten. Die Zonen solcher Server administriert man per Webportal oder API.

Bei der Variante „Hidden Primary“ betreibt die Firma den primären autoritativen DNS-Server (mit der beschreibbaren Zone) verborgen in ihrer DMZ, aber ohne den DNS-Port zum Internet zu öffnen. So ist er vor Angriffen aus dem Internet geschützt und intern hochverfügbar. Damit die Domain trotzdem auch aus dem Internet ansprechbar ist, lagert man die Secondaries beim DNS-Provider aus. Wird die Zone geändert, sendet der Hidden Primary die kompletten Daten per Zonentransfer an die Secondaries. In der großen Infografik steckt der autoritative Server in der DMZ und antwortet auf Anfragen für die beispielhaft genannte Domain firma.de.

In Firmenumgebungen ist es üblich, die rekursiven DNS-Server von den autoritativen Servern für die internen Domains zu trennen. Gründe hierfür sind besser überschaubare Zugriffsregeln und die Möglichkeit, die Serverleistung bedarfsgerecht zu dimensionieren.

Damit die Resolver bei Anfragen an interne Zonen mit den richtigen autoritativen DNS-Servern sprechen, bedarf es einer passenden Routing-Policy, Conditional Forwarding, siehe die roten Pfeile in der Infografik. Beispiele dafür sind interne Zonen oder auch über ein VPN erreichbare interne Zonen von Partnerfirmen.

Umsicht bei internen Zonen

Generell sollte man für interne Domains entweder eine Subdomain unter der für diesen Zweck reservierten Domain home.arpa verwenden (RFC 8375) oder eine Subdomain der Hauptdomain der Firma, die jedoch nicht im Internet delegiert wird, zum Beispiel lokal.firma.de.

Die naheliegende TLD .local sollte man unbedingt vermeiden, weil sie für mDNS reserviert ist, das inzwischen nicht nur iOS, macOS, Android und Linux, sondern auch Windows zur lokalen, serverlosen Namensauflösung verwenden. Auch von „Erfindungen“ wie .lokal oder .privat sollte man die Finger lassen, denn die IANA könnte solche Namen irgendwann als TLD definieren. Wenn das passiert, dann muss man die gesamte DNS-Infrastruktur der Firma umkrempeln, oft auch das Active Directory. Das ist sehr kostspielig.

Eine gern missverstandene DNS-Kommunikation geht auf das dynamische DNS-Update zurück, das vor allem im Active Directory von Windows eine Rolle spielt; nicht zu verwechseln mit dem DynDNS von Heimroutern, die ihre dynamisch zugewiesene WAN-IP-Adresse dem DynDNS-Provider per HTTPS melden. Das dynamische DNS-Update nutzt ein Client, nachdem er eine IP-Adresse per DHCP empfangen hat, um sie mitsamt seinem Hostnamen an den autoritativen DNS-Server der Domäne zu schicken (lila Pfeil).

Sind nun die DNS-Server im Firmennetz in rekursive und autoritative Server getrennt, kann es den Netzadmin irritieren, dass scheinbar alle möglichen Clients DNS-Anfragen nicht nur an den Resolver schicken, sondern auch an den autoritativen Server. Doch der Eindruck täuscht: Dabei handelt es sich mitnichten um DNS-Queries, sondern eben um dynamische DNS-Updates, was man im DNS-Header am zugehörigen Flag erkennt (OpCode 5).

DNS-Security

Übliche DNS-Pakete sind unverschlüsselt und meist über das zustandslose Transportprotokoll UDP unterwegs. Was bedeutet: Angreifer mit Zugriff auf den Netzwerkverkehr können nicht nur sämtliche DNS-Anfragen mitlesen, sondern auch nach Belieben verändern (Spoofing). Dagegen hilft DNSSEC (Domain Name System Security Extensions). Dafür signiert ein Admin auf seinen autoritativen Servern die Zonen und gibt ein Digest (Hash) seines Public Key an den Admin der Elternzone weiter. Der Admin der Elternzone signiert den Digest und legt ihn in der Elternzone ab.

Fortan liefert der autoritative DNS-Server überprüfbare signierte Antworten und ein Resolver kann damit sicherstellen (validieren), dass deren Inhalt unverfälscht ist und die Antwort von einer vertrauenswürdigen Quelle stammt. Daher gilt für alle Betreiber von DNS-Resolvern die klare Empfehlung: Validieren Sie per DNSSEC, wann immer möglich.

Doch auch signierte DNS-Pakete sind unverschlüsselt und somit von Dritten lesbar. Um auch noch unerwünschte Mitleser auszuschließen, empfiehlt es sich, den Verkehr zwischen Client und Resolver zu verschlüsseln. Dafür kann man verschiedene Methoden verwenden. Zu den jüngeren zählen DNS-over-HTTPS (DoH), DNS-over-TLS (DoT) und DNS-over-QUIC (DoQ). In der Grafik oben haben wir beispielhaft nur DoH aufgeführt (gestrichelte Linien), das den klassischen HTTPS-Kanal auf TCP Port 443 nutzt.

Eine Besonderheit bei verschlüsseltem DNS-Verkehr ist, dass einzelne Apps wie Browser den konfigurierten Resolver umgehen und ihre Anfragen direkt an einen Resolver im Internet senden (etwa Firefox und Chrome). Das hat vor allem in Firmenumgebungen unerwünschte Folgen: So konfigurierte Browser finden lokale Server nicht, weil externe Resolver keine internen Server kennen und sie umgehen DNS-Security-Mechanismen. Dann schützen DNS-Resolver und Firewalls, die DNS-Anfragen zu böswilligen Domains blockieren sollen, plötzlich nicht mehr.

Um beides zu verhindern, können Sie auf den PCs Ihrer Mitarbeiter DoH, DoT, DoQ und was auch immer mittels Gruppenrichtlinien verbieten. Noch besser: Aktivieren Sie DoH und DoT in Ihrem Firmen-Resolver und machen Sie ihn für Ihr gesamtes Netz verpflichtend, denn interne Netze sind nicht vertrauenswürdiger als das Internet (Zero-Trust-Ansatz).

Das weniger verbreitete DoT ist das verschlüsselnde Pendant zum üblichen DNS für rekursive Anfragen; es sichert den DNS-Verkehr zwischen dem Client oder dem Router und dem Resolver ab. Der Verkehr läuft über den dafür reservierten TCP-Port 853. Wie der Name schon sagt, verschlüsselt DoT per Transport Layer Security (TLS). Android bringt DoT ab Werk mit, Router auf Basis von OpenWrt und die von AVM gefertigte Fritzbox ebenfalls. Linux, macOS und Windows kann man mit Stubby nachrüsten.

Noch eins drauf setzen die ganz modernen Protokolle Oblivious-DNS (ODNS, siehe Grafik) und eine Variante des Protokolls DNSCrypt: Beide verschlüsseln den DNS-Verkehr nicht nur, sondern verschleiern auch noch die IP-Adresse des Clients. Oblivious-DNS wurde unter dem Dach der IETF standardisiert. Seit rund zwei Jahren setzen die Technik mehrere Firmen in kommerziellen Produkten ein: Apple in Private Relay für macOS und iOS, Google in One VPN für macOS, iOS und Android, Microsoft unter Zulieferung von Cloudflare in Windows und der ursprüngliche Erfinder Invisv in Pretty Good Phone Privacy für Android.

Ich weiß, dass ich nichts weiß

Zum Schluss noch der Hinweis, dass dieser Artikel nur die Spitze des Eisbergs sehen lässt. Viele Details rund um DNS haben wir der Übersicht halber nur angerissen oder gar nicht erläutert, beispielsweise TSIG, DNS-Cookies, die Sicherheitstechniken DANE, TLSA, SSHFP oder CAA.

Nicht zu vergessen die lokalen serverlosen DNS-Auflösungen auf Grundlage der Multicast-Technik mDNS, SSDP und LLMNR. Erst damit finden Smartphones im Heimnetz Drucker, Fernseher oder Lautsprecher automatisch. Aber das ist eine andere Geschichte. Sie möchten sich trotzdem einen Überblick über die DNS-Spezifikationen verschaffen? Keine triviale Aufgabe, gibt es doch knapp 300 (!) davon.

Ausblick

Die Phrase „It’s always DNS“ und daran angelehnte Memes in den sozialen Netzwerken sind berühmt-berüchtigt, denn wenn es mal knirscht, liegt der schwarze Peter sehr oft beim DNS. Um so wichtiger, dass man als IT-Admin die wichtigsten Abläufe in Grundzügen kennt. Mit etwas Übung und geeigneten Tools, die wir in einem der kommenden Hefte vorstellen, kommt man auch komplexen Problemen auf die Schliche.

Soli Deo Gloria!

Photo by Alexander Schimmeck on Unsplash.