STP018: DNS im Detail

Nachdem wir das Thema in STP002 schon einmal gestreift haben, wollen wir in dieser Episode genauer darauf eingehen.
Woher weiß unser Computer eigentlich, welche IP-Adresse er aufrufen muss, um uns all die schönen Katzenvideos zu zeigen?<h2>Shownotes</h2>Nicht die Desoxyribonukleinsäure, sondern das <a href="de.wikipedia.org/wiki/Domain_Name_System"… Name System</a>.
<ul>
<li>
Rückbezüge
<ul>
<li>zu STP002 (Aufruf einer Webseite): Webserver haben Domain-Namen, die aufgelöst werden müssen</li>
<li>zu STP012 (Datenbanken): DNS ist eine globale, verteilte (aber nicht dezentrale!), hierarchische Datenbank</li>
</ul>
</li>
<li>
Grundaufgabe: Namensauflösung
<ul>
<li>menschenlesbare und stabile Server-Namen anstatt unlesbarer und möglicherweise wechselnder IP-Adressen</li>
<li>aber auch andere Abfragen möglich, siehe unten</li>
<li>historischer Vorgänger: <code>/etc/hosts</code></li>
</ul>
</li>
<li>
Aufteilung des Internet in Domains (Domänen) und verschachtelte Subdomains (Unterdomänen)
<ul>
<li><a href="commons.wikimedia.org/wiki/File:Dns-raum.svg&q…; Wurzeldomain "." enthält Domain "org" enthält Domain "wikipedia.org" enthält Domain "de.wikipedia.org" -> deswegen hierarchische Datenbank</li>
<li>wenn die Subdomain einer anderen Person oder Organisation gehört als die Domain darüber, hat man eine neue Zone</li>
<li>jeder Inhaber einer Zone hält auf einem (oder mehreren) Webserver(n) die Inhalte seiner Zone (also Domain-Daten und Zonenreferenzen) in einem Nameserver -> deswegen verteilte Datenbank</li>
</ul>
</li>
<li>
Wurzelzone ist unter der Kontrolle der <a href="de.wikipedia.org/wiki/Internet_Corporation_for…; -> deswegen nicht dezentrale Datenbank
<ul>
<li>Verteilung der Wurzelzone durch die <a href="de.wikipedia.org/wiki/Root-Nameserver">…;
<li>finanzieller Anreiz zum Erlauben von immer mehr Top-Level-Domains (TLD)</li>
</ul>
</li>
<li>
Einträge in einer DNS-Zone heißen Records (Datensätze), mehrere Record Types möglich:
<ul>
<li>A, AAAA: IP-Adresse zu einer Domain (A = IPv4, AAAA = IPv6)</li>
<li>CNAME: Domain-Alias (anstatt direkt eine IP zu erhalten, erhält man eine andere Domain, die man stattdessen nach der finalen IP fragen muss)</li>
<li>PTR: Rückwärtsabfrage, Domain zu einer IP-Adresse</li>
<li>MX: Mail-Server zu einer Domain</li>
<li>SRV: ähnlich wie MX, aber für beliebige Dienste (z.B. XMPP)</li>
<li>TXT: beliebige Textinformationen (wird zum Beispiel für Mail-Empfangsregeln verwendet)</li>
<li>NS: Zonendelegation, die entsprechende Domain ist der Ausgangspunkt einer Unterzone und der Record enthält den autoritativen Nameserver für diese Zone</li>
</ul>
</li>
<li>
Abfrage einer bestimmten Domain
<ul>
<li>Grundidee: zuerst Root-Nameserver fragen, der delegiert an den Nameserver der TLD, der delegiert an den Nameserver der Second-Level-Domain, etc.</li>
<li>Problem: absurd hohe Last auf die Root-Nameserver</li>
<li>Lösung 1: jeder Eintrag in einer Nameserver-Datenbank hat eine TTL ("Time to Live")</li>
<li>Lösung 2: Endnutzer reden nicht direkt mit den autoritativen Nameservern, sondern mit Vermittlern (Resolver), die sie sich mit anderen Endnutzern teilen</li>
</ul>
</li>
<li>
Komplexbeispiel: Abfrage von <code>de.wikipedia.org</code> über die Root-Nameserver mit dem Unix-Tool <code>dig</code> (Ausgaben stark gekürzt)
</li>
</ul>
<pre><code>$ dig A de.wikipedia.org @m.root-servers.net

;; QUESTION SECTION:
;de.wikipedia.org. IN A
;; AUTHORITY SECTION:
org. 172800 IN NS a0.org.afilias-nst.info.
...
;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 172800 IN A 199.19.56.1
...

$ dig A de.wikipedia.org @199.19.56.1

;; QUESTION SECTION:
;de.wikipedia.org. IN A
;; AUTHORITY SECTION:
wikipedia.org. 86400 IN NS ns0.wikimedia.org.
...
;; ADDITIONAL SECTION:
ns0.wikimedia.org. 86400 IN A 208.80.154.238
...

$ dig A de.wikipedia.org @208.80.154.238

;; QUESTION SECTION:
;de.wikipedia.org. IN A
;; ANSWER SECTION:
de.wikipedia.org. 86400 IN CNAME dyna.wikimedia.org.

$ dig A dyna.wikimedia.org @199.19.56.1

;; QUESTION SECTION:
;dyna.wikimedia.org. IN A
;; AUTHORITY SECTION:
wikimedia.org. 86400 IN NS ns0.wikimedia.org.
...
;; ADDITIONAL SECTION:
ns0.wikimedia.org. 86400 IN A 208.80.154.238
...

$ dig A dyna.wikimedia.org @208.80.154.238

;; QUESTION SECTION:
;dyna.wikimedia.org. IN A
;; ANSWER SECTION:
dyna.wikimedia.org. 600 IN A 91.198.174.192
</code></pre>
<ul>
<li>zum Vergleich: Abfrage von <code>de.wikipedia.org</code> über einen öffentlichen Resolver (beachte die unterschiedlichen TTL-Werte)</li>
</ul>
<pre><code>$ dig A de.wikipedia.org @9.9.9.9

;; QUESTION SECTION:
;de.wikipedia.org. IN A
;; ANSWER SECTION:
de.wikipedia.org. 32533 IN CNAME dyna.wikimedia.org.
dyna.wikimedia.org. 227 IN A 91.198.174.192
</code></pre>
<ul>
<li>Beispiel: Rückwärtsabfrage der so erhaltenen IP mittels PTR-Record unter der Pseudo-Domain <code>in-addr.arpa</code></li>
</ul>
<pre><code>dig PTR 192.174.198.91.in-addr.arpa
;; QUESTION SECTION:
;192.174.198.91.in-addr.arpa. IN PTR

;; ANSWER SECTION:
192.174.198.91.in-addr.arpa. 1104 IN PTR text-lb.esams.wikimedia.org.
</code></pre>
<ul>
<li>
Woher kommt der Resolver?
<ul>
<li>normalerweise über DHCP (auf demselben Wege, über den das eigene Gerät eine IP-Adresse vom Router bekommt; oder über den der Router eine IP-Adresse vom ISP bekommt), unter Unix siehe <code>/etc/resolv.conf</code></li>
<li>somit meist ein Resolver unter Kontrolle des ISP</li>
<li>alternative Resolver: z.B. <code>1.1.1.1</code> (Cloudflare), <code>8.8.8.8</code> (Google), <code>9.9.9.{9,10,11}</code> (<a href="de.wikipedia.org/wiki/Quad9">Quad9<…;), <code>5.9.164.112</code> (<a href="digitalcourage.de/support/zensurfreier-dns-ser…;)</li>
<li>Resolverwahl: Implikationen für Privatsphäre und für Vertrauenswürdigkeit</li>
</ul>
</li>
<li>
DNS selbst ist unverschlüsselt -> neuere Entwicklung: DNS-over-TLS und DNS-over-HTTP
<ul>
<li>eigentlich würde DNS-over-TLS reichen, aber kann dann vom ISP geblockt werden; HTTP hingegen ist aus praktischen Gründen quasi unblockbar</li>
<li>Unterstützung in Betriebssystemen noch lückenhaft, aber Browser können DoT und DoH am Betriebssystem vorbei machen (Browsereinstellungen prüfen!)</li>
</ul>
</li>
<li>
alternative DNS-Roots: meist in privaten Netzen (z.B. Firmen-Intranet mit <code>.corp</code>-Domains), aber es gibt auch alternative Roots mit globalem Anspruch (z.B. <a href="en.wikipedia.org/wiki/Namecoin">Nameco…;)
</li>
</ul>

Kapitelklicken springt direkt hin

Shownotes