Was ist eigentlich DNS?

Was ist das DNS?

Das DNS ist ein verteiltes Adressbuch bei dem jeder seine eigene Adresseinträge selbst verwalten kann. Diese Adressbuch bildet primär Namen auf IP Adressen ab.

Geschichte des DNS

Das Domain Name System gab es nicht von Anfang an im ArpaNET. Im Jahr 1972 verwaltete und verteilte das Stanford Research Institute (SI) die HOSTS.TXT Datei (RFC 226). Das ist der Vorläufer von DNS und wurde als Datei auf alle vernetzten Rechner verteilt.

Die Entwicklung zum heutigen DNS System begann 1981 mit RFC 799 geschrieben von Dr. David Mills, über RFC 819/881 von Jon Postel und Zaw-Sing Su 1982, hin zu den beiden Grundsteinen für das DNS von Dr. Paul Mokapetris im Jahre 1983 mit RFC 882 und RFC 883, geschrieben im Jahr 1983.

Request for Comments sind eine Sammlung eindeutig nummerierter Dokumente, die von der (Internet Engineering Task Force) herausgegeben werden. Inhalt dieser Dokumente ist die Beschreibung von Protokollen, Methoden, Programmen und Konzepte für die Zusammenarbeit vernetzter Systeme.

• In RFC 799 (Internet name domains) wird beschrieben, wie ein Host eindeutig über eine oder mehrere 32-bit Internet Adressen identifiziert werden kann.
• In RFC 819 (The Domain Naming Convention for Internet User Applications) wird erstmals eine Domain Hierachie definiert.
• In RFC 882/883 werden die Konzepte von DNS, das Format und auch die konzeptionelle Verwendung beschrieben.
• In RFC 920 wurden Anforderungen an eine Domain definiert, dass das Management der Namensräume entsprechend aufgeteilt wird und autonom verwaltet werden kann sowie die „temporäre“ TLD .arpa und .gov, .edu, .com, .mil und .org.
• Die Länder TLDs wurden in der ISO-3166-1 definiert.

Wie funktioniert das DNS?

Ein wichtiges Merkmal von DNS ist die verteilte Verwaltung der Zuordnungstabellen (Forward Mapping / Reverse Mapping). Die Namensauflösung auf dem Client passiert nach folgendem Schema:

Programm -> Betriebssystem -> resolving /caching Nameserver -> authoritative Nameserver

Die Antwort durchläuft die Kette rückwärts.
Der Unterschied zwischen einem resolving/caching Nameserver und einen authoritativen Nameserver ist, das ein autoritativer Namenserver nur Antworten liefert für bei ihm konkret konfigurierte Domains.

Der resolving/caching Nameserver wird bei einer Anfrage seinerseits die Anfrage entsprechend an den aus seiner Sicht zuständigen Nameserver stellen und die Rückmeldung für eine bestimmte Zeit speichern. Damit kann der resolving/caching bei der gleichen Anfrage die Antwort direkt zurückliefern.

Das Forward Mapping ist die Zuordnung eines Namens auf ein Objekt. Das Objekt kann ein Name oder eine IP Adresse sein.

Es existieren verschiedene Ressource Records (RR) nach denen explizit gefragt werden muss. Ein Resource Record bezeichnet einen bestimmten Typ eines Eintrags im  DNS. Diese Resource Records haben verschiedene Bedeutungen je nach Anwendungsfall.

Beispiele für häufig genutzte RR: A, AAAA, MX, CNAME und NS.

• Ein A Resource Record bildet einen Namen auf eine IP Adresse ab
• Ein MX Resource Record verweist auf den für den Domainnamen zuständigen Mailserver (mit einstellbarer Priorität).
• Ein CNAME Resource Record ist ein Alias der auf einen beliebigen anderen vollqualifizierten Domainname zeigen kann.

Beispiele:

www.to.com löst auf die IP Adresse 134.119.224.166
Die MX Einträge für die Domain to.com sehen so aus:

20  mx-002.to.com

10  mx-001.to.com

Wie aber funktioniert überhaupt das Auflösen eines Namens zu einer IP Adresse?

Ein resolving Nameserver, so er den Eintrag noch nicht kennt und nicht im Zwischenspeicher hat, muss zuerst einen der 13 Root Nameserver befragen, die er schon per Konfiguration kennt um die für eine Top Level Domain (TLD) zuständigen Nameserver in Erfahrung zu bringen. Mit dieser Information kann der resolving  Nameserver dann die für die TLD zuständigen Nameserver befragen welche Nameserver für die gesuchte Domain zuständig ist. Diese Nameserver sind dann die autoritativen Nameserver für diese Domain.

Beispiel: Von dem Root Namserver die Namserver von der TLD .com in Erfahrung bringen

$ dig +noadditional @198.41.0.4 com. NS 

; <<>> DiG 9.11.2-P1 <<>> +noadditional @198.41.0.4 NS com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41471
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 27
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;com.                   IN      NS

;; AUTHORITY SECTION:
com.                172800  IN      NS      a.gtld-servers.net.
com.                172800  IN      NS      b.gtld-servers.net.
com.                172800  IN      NS      c.gtld-servers.net.
com.                172800  IN      NS      d.gtld-servers.net.
com.                172800  IN      NS      e.gtld-servers.net.
com.                172800  IN      NS      f.gtld-servers.net.
com.                172800  IN      NS      g.gtld-servers.net.
com.                172800  IN      NS      h.gtld-servers.net.
com.                172800  IN      NS      i.gtld-servers.net.
com.                172800  IN      NS      j.gtld-servers.net.
com.                172800  IN      NS      k.gtld-servers.net.
com.                172800  IN      NS      l.gtld-servers.net.
com.                172800  IN      NS      m.gtld-servers.net.

;; Query time: 21 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Nov 26 17:31:13 CET 2018
;; MSG SIZE  rcvd: 828

Mit den nun gewonnenen Informationen kann über die Namserver der TLD .com die zuständigen Namserver für to.com ermittelt werden.

$ dig +noadditional @a.gtld-servers.net to.com NS

; <<>> DiG 9.11.2-P1 <<>> +noadditional @a.gtld-servers.net to.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36634
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 10
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;to.com.                                IN      NS

;; AUTHORITY SECTION:
to.com.                 172800  IN      NS      a.ns14.net.
to.com.                 172800  IN      NS      b.ns14.net.
to.com.                 172800  IN      NS      c.ns14.net.
to.com.                 172800  IN      NS      d.ns14.net.

;; Query time: 96 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Nov 26 17:33:22 CET 2018
;; MSG SIZE  rcvd: 299

Diese Nameserver sind autoritativ für die Domain to.com und können daher für die Subdomain www eine Antwort liefern.

Beispiel:

$ dig @d.ns14.net www.to.com A

; <<>> DiG 9.11.2-P1 <<>> @d.ns14.net www.to.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45121
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;www.to.com.                    IN      A

;; ANSWER SECTION:
www.to.com.             360     IN      A       134.119.224.166

;; Query time: 132 msec
;; SERVER: 74.208.254.254#53(74.208.254.254)
;; WHEN: Mon Nov 26 17:33:41 CET 2018
;; MSG SIZE  rcvd: 55

Das DNS ist dezentral und ein sehr wichtiger Baustein für das Funktionieren der verschiedensten Dienste im Internet.