April 21, 2022

STP018: DNS im Detail

1 hour 24 minutes

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?

ShownotesNicht die Desoxyribonukleinsäure, sondern das Domain Name System.

Rückbezüge

zu STP002 (Aufruf einer Webseite): Webserver haben Domain-Namen, die aufgelöst werden müssen

zu STP012 (Datenbanken): DNS ist eine globale, verteilte (aber nicht dezentrale!), hierarchische Datenbank

Grundaufgabe: Namensauflösung

menschenlesbare und stabile Server-Namen anstatt unlesbarer und möglicherweise wechselnder IP-Adressen

aber auch andere Abfragen möglich, siehe unten

historischer Vorgänger: /etc/hosts

Aufteilung des Internet in Domains (Domänen) und verschachtelte Subdomains (Unterdomänen)

Beispiel: Wurzeldomain "." enthält Domain "org" enthält Domain "wikipedia.org" enthält Domain "de.wikipedia.org" -> deswegen hierarchische Datenbank

wenn die Subdomain einer anderen Person oder Organisation gehört als die Domain darüber, hat man eine neue Zone

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

Wurzelzone ist unter der Kontrolle der ICANN -> deswegen nicht dezentrale Datenbank

Verteilung der Wurzelzone durch die Root-Nameserver

finanzieller Anreiz zum Erlauben von immer mehr Top-Level-Domains (TLD)

Einträge in einer DNS-Zone heißen Records (Datensätze), mehrere Record Types möglich:

A, AAAA: IP-Adresse zu einer Domain (A = IPv4, AAAA = IPv6)

CNAME: Domain-Alias (anstatt direkt eine IP zu erhalten, erhält man eine andere Domain, die man stattdessen nach der finalen IP fragen muss)

PTR: Rückwärtsabfrage, Domain zu einer IP-Adresse

MX: Mail-Server zu einer Domain

SRV: ähnlich wie MX, aber für beliebige Dienste (z.B. XMPP)

TXT: beliebige Textinformationen (wird zum Beispiel für Mail-Empfangsregeln verwendet)

NS: Zonendelegation, die entsprechende Domain ist der Ausgangspunkt einer Unterzone und der Record enthält den autoritativen Nameserver für diese Zone

Abfrage einer bestimmten Domain

Grundidee: zuerst Root-Nameserver fragen, der delegiert an den Nameserver der TLD, der delegiert an den Nameserver der Second-Level-Domain, etc.

Problem: absurd hohe Last auf die Root-Nameserver

Lösung 1: jeder Eintrag in einer Nameserver-Datenbank hat eine TTL ("Time to Live")

Lösung 2: Endnutzer reden nicht direkt mit den autoritativen Nameservern, sondern mit Vermittlern (Resolver), die sie sich mit anderen Endnutzern teilen

Komplexbeispiel: Abfrage von de.wikipedia.org über die Root-Nameserver mit dem Unix-Tool dig (Ausgaben stark gekürzt)

$ 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

zum Vergleich: Abfrage von de.wikipedia.org über einen öffentlichen Resolver (beachte die unterschiedlichen TTL-Werte)

$ 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

Beispiel: Rückwärtsabfrage der so erhaltenen IP mittels PTR-Record unter der Pseudo-Domain in-addr.arpa

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.

Woher kommt der Resolver?

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 /etc/resolv.conf

somit meist ein Resolver unter Kontrolle des ISP

alternative Resolver: z.B. 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.{9,10,11} (Quad9), 5.9.164.112 (Digitalcourage)

Resolverwahl: Implikationen für Privatsphäre und für Vertrauenswürdigkeit

DNS selbst ist unverschlüsselt -> neuere Entwicklung: DNS-over-TLS und DNS-over-HTTP

eigentlich würde DNS-over-TLS reichen, aber kann dann vom ISP geblockt werden; HTTP hingegen ist aus praktischen Gründen quasi unblockbar

Unterstützung in Betriebssystemen noch lückenhaft, aber Browser können DoT und DoH am Betriebssystem vorbei machen (Browsereinstellungen prüfen!)

alternative DNS-Roots: meist in privaten Netzen (z.B. Firmen-Intranet mit .corp-Domains), aber es gibt auch alternative Roots mit globalem Anspruch (z.B. Namecoin)

...more

View all episodes

By Xyrillian Noises

April 21, 2022

STP018: DNS im Detail

1 hour 24 minutes

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?

ShownotesNicht die Desoxyribonukleinsäure, sondern das Domain Name System.

Rückbezüge

zu STP002 (Aufruf einer Webseite): Webserver haben Domain-Namen, die aufgelöst werden müssen

zu STP012 (Datenbanken): DNS ist eine globale, verteilte (aber nicht dezentrale!), hierarchische Datenbank

Grundaufgabe: Namensauflösung

menschenlesbare und stabile Server-Namen anstatt unlesbarer und möglicherweise wechselnder IP-Adressen

aber auch andere Abfragen möglich, siehe unten

historischer Vorgänger: /etc/hosts

Aufteilung des Internet in Domains (Domänen) und verschachtelte Subdomains (Unterdomänen)

Beispiel: Wurzeldomain "." enthält Domain "org" enthält Domain "wikipedia.org" enthält Domain "de.wikipedia.org" -> deswegen hierarchische Datenbank

wenn die Subdomain einer anderen Person oder Organisation gehört als die Domain darüber, hat man eine neue Zone

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

Wurzelzone ist unter der Kontrolle der ICANN -> deswegen nicht dezentrale Datenbank

Verteilung der Wurzelzone durch die Root-Nameserver

finanzieller Anreiz zum Erlauben von immer mehr Top-Level-Domains (TLD)

Einträge in einer DNS-Zone heißen Records (Datensätze), mehrere Record Types möglich:

A, AAAA: IP-Adresse zu einer Domain (A = IPv4, AAAA = IPv6)

CNAME: Domain-Alias (anstatt direkt eine IP zu erhalten, erhält man eine andere Domain, die man stattdessen nach der finalen IP fragen muss)

PTR: Rückwärtsabfrage, Domain zu einer IP-Adresse

MX: Mail-Server zu einer Domain

SRV: ähnlich wie MX, aber für beliebige Dienste (z.B. XMPP)

TXT: beliebige Textinformationen (wird zum Beispiel für Mail-Empfangsregeln verwendet)

NS: Zonendelegation, die entsprechende Domain ist der Ausgangspunkt einer Unterzone und der Record enthält den autoritativen Nameserver für diese Zone

Abfrage einer bestimmten Domain

Grundidee: zuerst Root-Nameserver fragen, der delegiert an den Nameserver der TLD, der delegiert an den Nameserver der Second-Level-Domain, etc.

Problem: absurd hohe Last auf die Root-Nameserver

Lösung 1: jeder Eintrag in einer Nameserver-Datenbank hat eine TTL ("Time to Live")

Lösung 2: Endnutzer reden nicht direkt mit den autoritativen Nameservern, sondern mit Vermittlern (Resolver), die sie sich mit anderen Endnutzern teilen

Komplexbeispiel: Abfrage von de.wikipedia.org über die Root-Nameserver mit dem Unix-Tool dig (Ausgaben stark gekürzt)

$ 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

zum Vergleich: Abfrage von de.wikipedia.org über einen öffentlichen Resolver (beachte die unterschiedlichen TTL-Werte)

$ 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

Beispiel: Rückwärtsabfrage der so erhaltenen IP mittels PTR-Record unter der Pseudo-Domain in-addr.arpa

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.

Woher kommt der Resolver?

somit meist ein Resolver unter Kontrolle des ISP

alternative Resolver: z.B. 1.1.1.1 (Cloudflare), 8.8.8.8 (Google), 9.9.9.{9,10,11} (Quad9), 5.9.164.112 (Digitalcourage)

Resolverwahl: Implikationen für Privatsphäre und für Vertrauenswürdigkeit

DNS selbst ist unverschlüsselt -> neuere Entwicklung: DNS-over-TLS und DNS-over-HTTP

eigentlich würde DNS-over-TLS reichen, aber kann dann vom ISP geblockt werden; HTTP hingegen ist aus praktischen Gründen quasi unblockbar

Unterstützung in Betriebssystemen noch lückenhaft, aber Browser können DoT und DoH am Betriebssystem vorbei machen (Browsereinstellungen prüfen!)

alternative DNS-Roots: meist in privaten Netzen (z.B. Firmen-Intranet mit .corp-Domains), aber es gibt auch alternative Roots mit globalem Anspruch (z.B. Namecoin)

...more