In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

DNS ist eines der Grundelemente des Internets - obwohl es "nur" ein Dienst (also Layer 5 und höher) ist, ohne DNS wäre TCP/IP eigentlich in der Praxis unbrauchbar.

Wir kennen TCP/IP inzwischen. Und auch, wie zwei Rechner mittels IP-Routing miteinander kommunizieren können. Aber nicht mal wir ITler haben Freude daran, im Browser IP-Adressen einzugeben. Nicht nur, dass man sich die nicht merken kann, wir haben auch zu wenig davon: Ein Server hat meist nur wenige IP-Adressen, aber betreibt vielleicht tausende Websiten und braucht den aufgerufenen Domainnamen, um zu erkennen, welche da aufgerufen werden soll. Dafür braucht man Domain-Namen und DNS- das Domain Name System DNS ist quasi das "Telefonbuch" des Internets, dort kann man zu jedem Namen (Domain/Hostname) die entsprechende Nummer (IP-Adresse) nachschlagen.

Wenn man eine Webseite wie z.B. www.vollzeitnerd.de aufruft, dann sorgt das Domain Name System DNS dafür, dass daraus die IP 80.237.226.3 draus wird, denn die kann man dank IP-Routing erreichen. 

Wie läuft das genau ab?

• Der PC weiß es nicht. Aber er hat, z.B. per DHCP, einen DNS-Server mitgeteilt bekommen. Den fragt er (Standard-Typ ist "IN A", dazu später mehr)
• Meistens hat man seinen eigenen z.B. DSL-Router als DNS-Server eingetragen/mitgeteilt bekommen. Der ist aber in der Regel gar kein Server, sondern nur ein Relay, d.h. er leitet die Anfrage weiter. Und zwar an den Server, den er ebenfalls automatisch bei der Einwahl vom DSL-Provider empfohlen bekommen hat.
• Beim DSL-Provider läuft nun ein richtiger DNS-Server. Der kennt die Antwort aber auch nicht. Aber er hat eine Liste von sog. root-Nameservern (also die Wurzel des DNS) gespeichert, und davon fragt er bei einem nach, wer für die Zone "de" zuständig ist.
• Da bekommt er eine Liste von Nameservern der DENIC, die ja operativ für die Domainendung ".de" zuständig ist, also sowohl die Registrierung der Domains als auch den DNS-Zonenbetrieb.
• Die DENIC wiederum antwortet mit den bei der Domainregistrierung hinterlegten "Nameserver"-Einträgen mit den autoritativen Nameservern für die Domain "vollzeitnerd.de"
• Also fragt der DSL-Provider jetzt (immer noch per DNS-Protokoll) einen der dort hinterlegten autoritativen Nameserver meines Providers. Und der antwortet mit der IP-Adresse.
• Nachdem der DSL-Provider die Antwort kennt, beantwortet er die Anfrage meines DSL-Routers (wo ja nur ein DNS-Relay-Server lief) und der wiederum beantwortet die Anfrage an meinen PC
• Damit die ganze Kette nicht bei jedem Seitenau wiederholt werden muss, dürfen die einzelnen Zwischenstationen die Ergebnisse zwischenspeichern.

Im o.g. Beispiel ging es nur um die Zuordnung Domainname-zu-IP-Adresse, der sog. "A"-Record. Nun gibt es ja verschiedene Aufgaben rund um meine Domain, sie kann Mails empfangen (das macht ein anderer Server als 80.237.226.3), man könnte sie für IP-Telefonie nehmen, man kann aber auch zig andere Sachen machen.

Der Default-Wert ist immer der A-Record. Aber wenn man jetzt z.B. wissen will, welche Mailserver für Mails @vollzeitnerd.de zuständig sind, würde man den speziellen Record, in dem Fall MX abfragen.

Die wichtigsten Typen:

• A = Zuordnung IPv4-Adresse 
• AAAA = Zuordnung zu IPv6-Adresse
• MX = Mailserver, der Mails @diese-Domain annimmt
• NS = Nameserver, der für diese Zone zuständig ist (darüber erfolgt z.B. das o.g. Weiterrechen von den root-Servern zur DENIC und von der DENIC zu meinem Provider)
• SRV = besondere Serverdienste. Mail ist so alt, das hat einen eigenen Typ (MX) bekommen, aber alles, was danach kam, bekommt keine eigenen Typen mehr, sondern läuft allgemein unter SRV
• TXT = Freitext-Einträge für verschiedene Anwendungen und Informationen

An der Stelle ein Hinweis: Als das Internet bekannt wurde, spielte Microsoft gar keine Rolle. Nahezu alle Server liefen unter Unix/Linux/BSD/... (alles sehr ähnliche Betriebssysteme), und der beliebteste Nameserver war "Bind". Aus der Zeit stammen auch diese Texte hier, d.h. wir arbeiten nah an der Bind-Syntax.

Im Umgang mit Microsoft-Nameservern ist das ein oder andere Detail anders. Das liegt aber nicht daran, dass diese Anleitung falsch ist, sondern dass der falsche Nameserver installiert wurde :-)

Auf dem Nameserver, der für unsere fiktive Domain "beispieldomain.de" zuständig ist, gibt es ein Zonenfile. Das beginnt mit Angaben zu Gültigkeit usw., die lassen wir an der Stelle weg. Wichtig ist der Inhalt:

beispieldomain.de. IN NS dns01.coolerprovider3000.de.
beispieldomain.de. IN NS dns02.coolerprovider3000.de.

beispieldomain.de. IN MX 10 1.mailrelay.coolerprovider3000.de.
beispieldomain.de. IN MX 10 2.mailrelay.coolerprovider3000.de.
beispieldomain.de. IN MX 20 backuprelay.coolerprovider3000.de.
 
beispieldomain.de. IN A 89.90.91.92
www.beispieldomain.de. IN A 89.90.91.92
www2.beispieldomain.de. IN CNAME www.beispieldomain.de.
 
intranet.beispieldomain.de. IN NS intranet-dns
intranet-dns IN A 192.168.0.1
 
*.beispieldomain.de. IN MX 10 mailrelay.coolerprovider3000.de.
*.beispieldomain.de. IN A 89.90.91.92

beispieldomain.de. IN SRV 0 5 5060 sip.coolerprovider3000.de.
_sip._udp.beispieldomain.de. IN SRV 0 5 5060 sip.coolerprovider3000.de. 

Zerpflücken wir das mal:

NS-Delegation

beispieldomain.de. IN NS dns01.coolerprovider3000.de.
beispieldomain.de. IN NS dns02.coolerprovider3000.de.

Hier steht im Zonenfile drin, dass für die Domain "beispieldomain.de" die beiden Nameserver "dns01/dns02" des coolen Providers zuständig sind. Diese Angabe sollte mit dem übereinstimmen, was auch die DENIC bei sich in den "nameserver"-Einträgen hinterlegt hat. Ist an der Stelle nicht weiter spektakulär.

Was uns hier aber bereits auffällt: Die Angaben enden mit einem Punkt. Damit sind sie absolut und zuende. Würde man den Punkt weglassen (z.B. hinter "dns02.coolerprovider3000.de"), dann würde Bind das für einen relativen Domainnamen halten, also für eine Subdomain unterhalb der Zone, in der wir gerade sind. Das heißt, er würde glauben, dass der Server "dns02.coolerprovider3000.de.beispieldomain.de" mit ganzen Namen heißt, was natürlich Blödsinn ist. Darum der abschließende Punkt. Das ist ein großer Unterschied zu z.B. Microsoft-Nameservern (die kennen diese Denkweise m.W. nicht) und z.B. auch den meisten Kundenmenüs der Provider (wo man den vollständigen Namen einträgt ohne Punkt dahinter).

Gleiches gilt auch vorne für den Teil, da schreibt man entweder (wie hier) "beispieldomain.de." als absoluten Namen rein. Oder man könnte die Angabe auch weglassen (und einfach eingerückt mit "IN NS" anfangen).

MX-Records

beispieldomain.de. IN MX 10 1.mailrelay.coolerprovider3000.de.
beispieldomain.de. IN MX 10 2.mailrelay.coolerprovider3000.de.
beispieldomain.de. IN MX 20 backuprelay.coolerprovider3000.de.

Die nächsten drei Zeilen definieren einen MX-(Mail-Exchange-)Eintrag für die Domain "beispieldomain.de" (d.h. ohne irgendwelche Subdomains), d.h. sie legen fest, welche Mailserver für Mails @beispieldomain.de zuständig sind - hier mit Priorität 10 die Server "1.mailrelay..." und "2.mailrelay..." (Lastverteilung auf beide Server) und mit Priorität 20 (d.h. erst, wenn die ersten Server z.B. gerade ausgelastet ist und vorübergehend keine Mails entgegennehmen kann) der Server "backuprelay....".

Beim MX-Ziel ist ausschließlich ein Hostname erlaubt, es darf keine IP-Adresse angegeben werden. Ebenfalls darf kein Alias (siehe CNAME) angegeben werden, das ist für MX-Ziele ausdrücklich verboten (RFC 2181 10.3)

A-Records für IPv4

beispieldomain.de. IN A 89.90.91.92
www.beispieldomain.de. IN A 89.90.91.92

Hatten wir schon ganz zu Anfang erläutert. An der Stelle nur zur Klarstellung: "beispieldomain.de" und "www.beispieldomain.de" sind technisch zwei getrennte Hostnamen, die sollten, aber die müssen nicht auf die gleiche IP-Adresse zeigen. 

CNAME, DNAME und ALIAS

www2.beispieldomain.de. IN CNAME www.beispieldomain.de.

Hier wird die Subdomain "www2" als CNAME für www definiert. Ein CNAME-Eintrag leitet alle Arten von Anfragen um, d.h. er ersetzt alle Einträge wie A, MX und NS - aus diesen Grunde darf ein CNAME-Eintrag nur für Subdomains gesetzt werden, für die kein anderer (z.B. MX-)Eintrag existiert und aus diesem Grund auch nicht ohne eine Subdomain, denn auch dort existiert schon ein anderer Eintrag, nämlich die beiden NS-Einträge der zuständigen Nameserver.
Wichtig ist an der Stelle, dass wirklich "nur" www2 dann umgeleitet wird. Irgendwas unterhalb von www2 (also test.www2.beispieldomain.de - so unsinnig derartige Subdomains auch erscheinen mögen) gilt weiterhin als nicht definiert.

Vergleichbar, aber nicht ganz so streng ist der ALIAS-Record. Den darf man auch nicht-exklusiv verwenden (was aber u.U. dann auch wieder unübersichtlicher werden kann). Der ALIAS-Record ist nie offiziell standardisiert worden (er findet sich in keinem RFC), er wird vom Bind-Nameserver auch gar nicht unterstützt.

Was Bind dafür aber kann (weil in RFC 2672 nachträglich eingeführt) ist der Typ "DNAME". DNAME wird offiziell als rekursive Variante zu CNAME betitelt, verhält sich aber eher wie ein rekursives ALIAS. Das heißt einerseits, ich kann neben einem IN DNAME-Eintrag parallel noch eigene Einträge (MX, SRV, ...) setzen, zu denen ich ja teilweise noch komme. Und andererseits wäre bei einer DNAME-Delegation auch test.www2.beispieldomain.de dann als Alias zu test.beispieldomain.de definiert usw.

Subdomain-Delegation

intranet.beispieldomain.de. IN NS intranet-dns
intranet-dns IN A 192.168.0.1

Jetzt haben wir noch ein Intranet, und das hat einen eigenen Nameserver, der für diese (Unter-)Zone verantwortlich ist.

Also alles, was intranet.beispieldomain.de betrifft, machen nicht mehr wir, das macht der "intranet-dns.beispieldomain.de" (durch den nicht gesetzten abschließenden Punkt ist das "intranet-dns" ja nur relativ zu verstehen). Und in der nächsten Zeile haben wir mit einem klassischen A-Record dessen IP definiert.

Wildcard

*.beispieldomain.de. IN MX 10 mailrelay.coolerprovider3000.de.
*.beispieldomain.de. IN A 89.90.91.92

Für alles übrige (also auch shop.beispieldomain.de), was wir nicht explizit definiert haben, haben wir hier noch für MX und A je einen Wildcard-Eintrag gesetzt.

Wichtig: Fragen wir jetzt den MX-Eintrag zu shop.beispieldomain.de ab, dann lautet er: mailrelay.coolerprovider3000.de (da greift unser Wildcard-Eintrag).

Fragen wir den MX-Eintrag zu www.beispieldomain.de ab, dann lautet er: Not found. Denn die Subdomain "www.beispieldomain.de" hatten wir zu Beginn konfiguriert (mit einem IN A-Eintrag), damit existiert sie und damit greift der Wildcard-Eintrag nicht (auch nicht für die Typen wie z.B. MX, die wir zuvor nicht gesetzt hatten).

SRV-Records

Mit SRV-Records kann man für bestimmte Dienste (benannt werden die durch ihre Ports) festlegen, wer zuständig ist. Also genau so, wie es bei MX für Mail macht, nur dass SRV eben neutral für alles nutzbar ist:

beispieldomain.de. IN SRV 0 5 5060 sip.coolerprovider3000.de.
_sip._udp.beispieldomain.de. IN SRV 0 5 5060 sip.coolerprovider3000.de. 

Im oberen Beispiel wird für die beispieldomain.de festgelegt, dass für Serverdienste auf Port 5060 (in diesem Beispiel ist das ein Voice-over-IP-Port) der zuständige Server "sip.coolerprovider3000.de" heißt (wie immer mit abschließendem Punkt, weil es ein absoluter Name ist. Die 0 (Priorität) und die 5 (Gewichtung innerhalb einer Priorität) sind Pflichtangaben und dienen bei mehreren gleichen Einträgen zur Steuerung der Reihenfolge.

Im unteren Beispiel wird dieser Eintrag nochmal explizit für SIP-Verbindungen (Voice-over-IP) über UDP (Transportprotokoll) gesetzt. In diesem Fall werden die Schlüsselwörter _sip und _udp mit einem Punkt getrennt einfach vorne als Subdomain eingefügt (womit das Subdomain-Feld quasi zweckentfremdet werden).

TXT-Records

TXT-Records hingegen haben gar nichts mehr mit Serverdiensten zu tun, sondern sie dienen ganz allgemein dazu, Textdaten in Ihrem Zonenfile zu hinterlegen. 

Erster Anwendungzweck ist der Nachweis, dass diese Domain mir gehört, z.B. wenn ich diese mit Office365 oder irgend einem Google-Produkt nutzen möchte. In dem Fall fordert man mich auf, einen TXT-Eintrag anzulegen, der z.B. so aussieht:

 IN TXT MS=ms123456

Der Eintrag hat technisch keinerlei Bedeutung. Aber Microsoft kann nach ein paar Minuten erkennen, dass ich ihn gesetzt habe (und damit offensichtlich Zugriff auf das Zonenfile und damit die Domain haben darf).

Der zweite Anwendungszweck von TXT-Records sind sog. SPF-Angaben. Dazu später mehr.

Dritter Anwendungszweck ist das veröffentlichen von Schlüsseln für Signaturen (DNSSec, DKIM, ...) - das ist ein Thema für sich.

Doppelte Einträge sind ausdrücklich erlaubt.

Hat man z.B. mehrere Webserver, dann kann man mit

www.beispieldomain.de.    IN  A   123.45.67.89
www.beispieldomain.de.    IN  A   123.45.67.90

eine einfache Lastverteilung erreichen. Bei der DNS-Abfrage kommen immer beide Antworten zurück, aber in wechselnder Reihenfolge (nennt sich dann "round robin"), und üblicherweise nutzt das abfragende System einfach die erste Antwort.

Aber: Bei Ausfall eines Servers würde z.B. ein Browser nicht auf die Idee kommen, eine erneute DNS-Anfrage zu stellen (um die andere IP zu probieren). Für Redundanz ist DNS-RoundRobin daher nicht zu gebrauchen.

DNS-Zonenfiles haben eine Lebensdauer (TTL - Time to live).

Solange dürfen sie von den verschiedenen abfragendenden Zwischenservern gecached werden, also in einem eigenen Speicher vorgehalten, um bei Wiederholungsfragen nicht nochmal eine Anfrage starten zu müssen.

Die TTL beträgt üblicherweise mehrere Stunden, denn DNS-Änderungen sind relativ selten, DNS-Abfragen aber relativ häufig, darum ist ein langes Caching sehr sinnvoll.

Das kann aber natürlich bei Änderungen dazu führen, dass aus manchen Richtungen die Änderung sofort greift (weil der abfragende Nameserver nichts dazu im Cache hatte und eine frische Anfrage gestellt hat), während man von anderen PCs aus auch Stunden später noch auf der alten IP landet.

Nachdem wir die Serverseite (hoffentlich) verstanden haben, gucken wir uns das aus Client-Seite einmal an. Unter Windows nutzt man dafür das Programm "nslookup":

C:\Users\Nerd>nslookup
Standardserver:  fritz.box
Address:  fd00::eadf:70ff:ef98:ae70

> www.vollzeitnerd.de.
Server:  fritz.box
Address:  fd00::eadf:70ff:ef98:ae70

Nicht autorisierende Antwort:
Name:    www.vollzeitnerd.de
Address:  80.237.226.3

Nach dem Start von "nslookup" sehe ich zuerst, mit welchem Nameserver ich verbunden bin (einer FritzBox über IPv6). Ich habe einfach meine Abfrage ("www.vollzeitnerd.de." wieder mit dem abschließenden Punkt am Ende, den wir schon kennen. Es funktioniert meist auch ohne, aber er ist sauberer, mit Punkt abzufragen) eingegeben und bekomme wieder von der Fritzbox eine nicht autorisierende Antwort mit der IP-Adresse. "Nicht autorisierend" heißt, dass der mir antwortenden Nameserver (meine FritzBox) diese Zone nicht verwaltet, also sozusagen keine verbindliche Antwort liefert.

Wir können aber auch die komplette Antwort-Kette mal durchgehen:

> set query=NS
> .
Server:  fritz.box
Address:  fd00::eadf:70ff:ef98:ae70

Nicht autorisierende Antwort:
(root)  nameserver = g.root-servers.net
(root)  nameserver = c.root-servers.net
(...)

a.root-servers.net      internet address = 198.41.0.4
b.root-servers.net      internet address = 199.9.14.201
(..)
a.root-servers.net      AAAA IPv6 address = 2001:503:ba3e::2:30
b.root-servers.net      AAAA IPv6 address = 2001:500:200::b

Zuerst haben wir den Abfrage-Typ geändert. Standard war "A", mit "set query=NS" habe ich gesagt, ich möchte jetzt NS-Einträge abfragen. Danach habe ich die root-Zone abgefragt, wieder mit einem abschließenden Punkt - und weil die root-Zone quasi der Nullpunkt des DNS ist, habe ich also nur einen Punkt abgefragt.

Die Antwort sind dann die root-DNS-Server in zufälliger Reihenfolge (ich habe nur zwei aufgeführt, das Ergebnis enthielt noch ein paar mehr) und netterweise bekomme ich auch die IPv4 und IPv6-Adressen schon direkt mit genannt.

Fragen wir deren mal einen ab:

> server a.root-servers.net.
Standardserver:  a.root-servers.net
Addresses:  2001:503:ba3e::2:30
          198.41.0.4

> vollzeitnerd.de.
Server:  a.root-servers.net
Addresses:  2001:503:ba3e::2:30
          198.41.0.4

de      nameserver = s.de.net
de      nameserver = a.nic.de
(..)

s.de.net        internet address = 195.243.137.26
s.de.net        AAAA IPv6 address = 2003:8:14::53
(..)

Mit "server a.root-servers-net." habe ich den Server gewechselt (sieht man später auch bei der Antwort: Ab sofort antwortet nicht mehr die FritzBox"). Dann habe ich wieder "vollzeitnerd.de." abgefragt und bekomme dieses mal eine autorisierende Antwort (denn das folgende weiss der root-Server selbst, weil er diese Zone verwaltet): Zuständig für weitere Anfragen sind die DENIC-Nameserver, wieder in zufälliger Reihenfolge und wieder von mir nach zwei Ergebnissen abgeschnitten.

Was hier auffällt sind die unterschiedlichen Domainnamen (der erste heißt irgendwas unterhalb "de.net", der zweite unterhalb "nic.de") - reine Redundanz. Würden alle DENIC-Nameserver unter "nic.de" laufen, und in diesem Zonenfile wäre irgend ein Syntaxfehler, dann wären am Ende alle .de-Domains offline. Wenn man das aber auf mehrere Domains aufteilt, dann würden im Störungsfall auch nur die eine Hälfte der Nameserver ausfallen (und der Client würde den nächsten probieren).

Zurück zu unserer Abfrage, wir hangeln und weiter im Text:

> server s.de.net.
Standardserver:  s.de.net
Addresses:  2003:8:14::53
          195.243.137.26

> vollzeitnerd.de.
Server:  s.de.net
Addresses:  2003:8:14::53
          195.243.137.26

vollzeitnerd.de nameserver = dns01.dt-internet.de
vollzeitnerd.de nameserver = dns05.d-t-internet.de
dns01.dt-internet.de    internet address = 80.237.197.14
dns05.d-t-internet.de   internet address = 185.102.94.105

Wir wechseln wieder den abzufragenden Server ("server s.de.net.") und fragen erneut nach vollzeitnerd.de. und bekommen zwei Nameserver meines Webhosting-Anbieteres genannt. Auch hier mit unterschiedlichen Schreibweisen (dt-internet und d-t-internet) zur Redundanz/Absicherung gegen Fehler im Zonenfile.

Tasten wir uns weiter vor:

> server dns05.d-t-internet.de.
*** Adresse für Server dns05.d-t-internet.de kann nicht gefunden werden: Non-authoritative answer.

> server 185.102.94.105
Standardserver:  [185.102.94.105]
Address:  185.102.94.105

> vollzeitnerd.de.
Server:  [185.102.94.105]
Address:  185.102.94.105

vollzeitnerd.de nameserver = dns01.dt-internet.de
vollzeitnerd.de nameserver = dns05.d-t-internet.de

Erst habe ich mit "server dns05.d-t-internet.de." einen der beiden Server ausgewählt ... oder es versucht. Die Antwort war ein non-authoritative "not found". Warum? Weil meine letzte (und noch aktive) Verbindung ja diese hier war: "server s.de.net." Und der DENIC-Nameserver ist nicht dafür da, irgendwas zu beauskunften (d.h. wenn ich wissen will, wer "dns05.d-t-internet.de" ist, kann er mir nicht helfen), der macht nur seinen Job und nix anderes. Immerhin sagt er dazu, dass seine Antwort nicht autoritativ ist (dadurch weiß ich, dass es diesen Hostnamen trotzdem geben könnte, nur eben muss ich die Antwort woanders erfragen).

Aber ich kenne ja die IP des Servers, also wechsle ich darüber da hin: "server 185.102.94.105". Dann wiederhole ich meine Frage nach vollzeitnerd.de und bekomme die gleiche Antwort ... ich bin also offenbar am Ziel angekommen.

Also kann ich jetzt den query-Typ ändern, weg von NS zu:

> set query=A
> vollzeitnerd.de.
Server:  [185.102.94.105]
Address:  185.102.94.105

Name:    vollzeitnerd.de
Address:  80.237.226.3

> set query=MX
> vollzeitnerd.de.
Server:  [185.102.94.105]
Address:  185.102.94.105

vollzeitnerd.de MX preference = 10, mail exchanger = 1.mailrelay.dt-internet.de
vollzeitnerd.de MX preference = 10, mail exchanger = 2.mailrelay.dt-internet.de
vollzeitnerd.de MX preference = 20, mail exchanger = backuprelay.dt-internet.de

> set query=TXT
> vollzeitnerd.de.
Server:  [185.102.94.105]
Address:  185.102.94.105

vollzeitnerd.de
        primary name server = dns01.dt-internet.de
        responsible mail addr = dnsadmin.dt-internet.de
        serial  = 3620380451
        refresh = 10800 (3 hours)
        retry   = 3600 (1 hour)
        expire  = 604800 (7 days)
        default TTL = 38400 (10 hours 40 mins)

Hier habe ich erst den A-Eintrag abgefragt (IPv4), danach den MX-Eintrag (jetzt sehe ich, welche Mailserver Mails @vollzeitnerd.de annehmen) und danach noch nach TXT-Einträgen geguckt. Erfolglos (es gibt keine, aber dafür bekomme ich die SOA-Angaben, also zuständige Nameserver, Seriennummer des Zonenfiles, TTL usw. zurück - das erleichtert mir die Entscheidung, ob ich es später nochmal probieren will.

Neben Windows gibt's natürlich auch unter Linux die Möglichkeit, das Zonenfile abzufragen, entweder mit "host":

$ host autodiscover.beispieldomain.de. 8.8.8.8

Using domain server:
Name: 8.8.8.8
Address: 8.8.8.8#53
Aliases:

autodiscover.beispieldomain.de is an alias for autodiscover.outlook.com.
autodiscover.outlook.com is an alias for autod.ha-autod.office.com.
autod.ha-autod.office.com is an alias for autod.ms-acdc-autod.office.com.
autod.ms-acdc-autod.office.com has address 52.98.214.72
autod.ms-acdc-autod.office.com has address 52.98.208.104
(..)

In diesem Fall habe ich nicht meinen eigenen (z.B. FritzBox)-DNS-Server abgefragt, sondern zur Abwechlung mal einen öffentlichen, der auch öffentlich jedem antwortet (8.8.8.8, betrieben von Google). Und ich habe einen fiktiven Domainnamen "autodiscover.beispieldomain.de" abgefragt, der als "IN CNAME autodiscover.outlook.com." konfiguriert ist (dient zur automatischen Konfiguration von Outlook, wenn man dort ein MS365-Mailkonto @beispieldomain.de anlegt). Netterweise bekomme ich das CNAME-Ziel direkt aufgelöst

Neben "host" gibt es aber noch ein Tool namens "dig", das direkt alle relevanten Infos zu einer Abfrage liefert:

$ dig autodiscover.beispieldomain.de.

; <<>> DiG 9.10.11-zwoelf-v13 <<>> autodiscover.beispieldomain.de
;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62001
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;autodiscover.beispieldomain.de.   IN      A

;; ANSWER SECTION:
autodiscover.dt-internet.de. 38400 IN   CNAME   autodiscover.outlook.com.
autodiscover.outlook.com. 300   IN      CNAME   autod.ha-autod.office.com.
autod.ha-autod.office.com. 60   IN      CNAME   autod.ms-acdc-autod.office.com.
autod.ms-acdc-autod.office.com. 10 IN   A       52.97.218.88
autod.ms-acdc-autod.office.com. 10 IN   A       52.97.170.72
autod.ms-acdc-autod.office.com. 10 IN   A       40.101.91.88

;; AUTHORITY SECTION:
ms-acdc-autod.office.com. 300   IN      NS      ns4-ms-acdc.office.com.
ms-acdc-autod.office.com. 300   IN      NS      ns2-ms-acdc.office.com.
ms-acdc-autod.office.com. 300   IN      NS      ns1-ms-acdc.office.com.
ms-acdc-autod.office.com. 300   IN      NS      ns3-ms-acdc.office.com.

;; ADDITIONAL SECTION:
ns1-ms-acdc.office.com. 2504    IN      A       13.107.244.2
ns2-ms-acdc.office.com. 2504    IN      A       208.84.4.2
ns3-ms-acdc.office.com. 2504    IN      A       150.171.254.2
ns4-ms-acdc.office.com. 2504    IN      A       150.171.0.2

;; Query time: 47 msec
;; SERVER: 80.237.197.14#53(80.237.197.14)
;; WHEN: Wed Jan 11 04:30:00 1970
;; MSG SIZE  rcvd: 346

Hier sehen wir sowohl die Anfrage (Query section - da ich keinen Typ abgefragt habe, ist es automatisch IN A) plus die Antwort (Answer section schön aufgelöst), in der Authority section stehen drin, welche Nameserver autoritativ für dieses Ergebnis zuständig sind, und in der Additional Section deren IP-Adressen. Die Zahlen hinter den Hostnamen (38400 beim ersten CNAME, 300 beim nächsten CNAME usw.) geben jeweils noch dazu die TTL (siehe oben) an.

Durch die zentrale Rolle als "Telefonbuch" des Internet ist das DNS auch Ziel von Angriffsversuchen. Gelingt es jemandem, meinen Rechner von falschen DNS-Einträgen zu überzeugen, dann kann er Seitenaufrufe meines Homebankings oder auch Mail-Verbindungen meines Outlooks auf einen anderen (bösen) Server umzulenken.

Nehmen wir als Grundlage mal den CNAME-Eintrag:

test.beispieldomain.de.     IN CNAME    vollzeitnerd.de.

Und bei einer Abfrage sähe das dann so aus:

$ dig test.beispieldomain.de.

;; QUESTION SECTION:
;test.beispieldomain.de.   IN      A

;; ANSWER SECTION:
test.beispieldomain.de. 38400 IN   CNAME   vollzeitnerd.de.
vollzeitnerd.de.               38400 IN   A       80.237.226.3

;; AUTHORITY SECTION:
vollzeitnerd.de. 38400   IN      NS      dns01.dt-internet.de.
vollzeitnerd.de. 38400   IN      NS      dns05.d-t-internet.de.

;; ADDITIONAL SECTION:
dns01.dt-internet.de. 38400    IN      A       80.237.197.14
dns05.d-t-internet.de. 38400     IN      A       185.102.94.105

In diesem Fall ist test.beispieldomain.de ein Alias für vollzeitnerd.de, und alles andere wird von dort beantwortet.

Wenn der Inhaber von "beispieldomain.de" jetzt Böses im Schilde führt, dann konfiguriert er seinen Nameserver so, dass der auch denkt, er sei für "vollzeitnerd.de" und am besten auch direkt noch für "dt-internet.de" und "d-t-internet.de" autoritativ zuständig, und für alles konfigurieren wir falsche IN A-Einträge mit der IP 89.90.91.92. Wenn man den jetzt abfragen würde, dann würde das Ergebnis so aussehen:

$ dig test.beispieldomain.de.

;; QUESTION SECTION:
;test.beispieldomain.de.   IN      A

;; ANSWER SECTION:
test.beispieldomain.de. 38400 IN   CNAME   vollzeitnerd.de.
vollzeitnerd.de.               38400 IN   A       89.90.91.92

;; AUTHORITY SECTION:
vollzeitnerd.de. 38400   IN      NS      dns01.dt-internet.de.
vollzeitnerd.de. 38400   IN      NS      dns05.d-t-internet.de.

;; ADDITIONAL SECTION:
dns01.dt-internet.de. 38400    IN      A       89.90.91.92
dns05.d-t-internet.de. 38400     IN      A       89.90.91.92

Jetzt rufe ich "test.beispieldomain.de" im Browser auf, und meine FritzBox (bzw. der DSL-Provider dahinter) macht eine DNS-Abfrage auf "test.beispieldomain.de" und bekommt nicht nur das Alias-Ziel, sondern - weil der antwortende Server ja seiner Meinung nach autoritativ ist - direkt den nächsten Hinweis mitgeliefert. Und direkt die Authority-Angaben, wer dafür zuständig ist (dns01 und dns05) und welche IPs die haben.

Der böse Betreiber von beispieldomain.de hat meinem DSL-Anbieter damit sowohl eine falsche IP für "vollzeitnerd.de" unterschoben, als auch direkt noch falsche IPs für die Nameserver meines Hosting-Providers. Und wenn mein DSL-Anbieter das jetzt glaubt (womöglich noch beides), dann wird er das für 38400 Sekunden cachen (der Cache ist dann vergiftet, daher der Begriff DNS Cache Poisoning). Sobald dann irgend ein anderer DSL-Kunde des gleichen Providers meine Seite aufrufen will, oder auch nur irgend eine Webseite meines Hosting-Anbieters (dessen Nameserver-Hostnamen ja auch falsch auflösen), dann wird der Nameserver meines DSL-Anbieters das falsche Ergebnis aus dem Cache holen und der Anwender landet auf dem völlig falschen Server (mit dem Risiko, dass ihn dort z.B. eine Phishing-Seite der ein Trojaner-Download o.ä. erwartet).

Das ist das Grundprinzip. Das ist länger bekannt und sauber konfigurierte Nameserver sind (inzwischen) dagegen immun, aber in bestimmten Fällen wäre es denkbar, dass ein solcher Angriff funktioniert.

Ein weiterer Angriffsvektor ist das DNS-Spoofing: 

• Mein DSL-Anbieter fragt den A-Record zu "vollzeitnerd.de" beim zuständigen Nameserver (dns01.dt-internet.de) ab
• Ein Angreifer erwartet diese Anfrage und beantwortet sie (bewusst falsch), in dem er die Absender-IP fälscht (so dass es aussieht, als käme die Antwort vom angefragten Nameserver)
• Parallel wird versucht, die eigentliche (richtige) Antwort zu verhindern, z.B. in dem der zuständige/abgefragte Nameserver per Denial of Service-Attacke in seiner Einsatzbereitschaft gestört wird.

Auch dieses Prinzip ist lange bekannt und wird durch Zufallswerte in der Art der Anfrage erschwert (zusätzlich zu Techniken wie DNSSec). 

Das klassische DNS-Protokoll ist einerseits unverschlüsselt (d.h. man kann im Klartext die DNS-Abfragen mitlesen) und andererseits nicht ausreichend gegen DNS-Spoofing-Attacken abgesichert.

Gegen letzteres hilft DNSSEC (Domain Name System Security Extension): Die Antwort wird vom (berechtigten) Nameserver digital signiert. In der übergeordneten Zone (bei .de-Domains also beispielsweise auf den DENIC-Nameservern) wird dafür der public key hinterlegt, mit dessen Hilfe die Signatur überprüft werden kann.

Mittels DNSSEC werden die Daten signiert, also unterschrieben. Es erfolgt aber keine Verschlüsselung.

Ein anderer Ansatz ist DNS-over-HTTPS. Die DNS-Anfrage wird dabei über eine HTTPS-Verbindung transportiert, wodurch einerseits die Übertragung verschlüsselt und abhörsicher wird. Und andererseits kann durch das SSL-Zertifikat die Identität zumindest des abgefragten Nameservers geprüft werden. Da DNS-over-HTTPS in erster Linie die Verbindung zwischen Endanwender (de factor nur: zwischen Browser) und seinem DNS-Server betrifft, hat das keine Aussage über die inhaltliche Richtigkeit der Antwort.

Dem Sicherheitsgewinn steht gegenüber, dass man abhängig vom DNS-over-HTTPS-Anbieter wird (z.B. bei Firefox leider voreingestellt: Cloudflare).

Kurzer Exkurs an dieser Stelle: Auf dem eigenen PC gibt es die sog. Hosts-Datei, diese findet man

• auf aktuellen Windows-System im Windows-Verzeichnis\system32\drivers\etc\hosts
• auf Unix-basierten Systemen, also auch Linux und MacOS in /etc/hosts

Das ist eine einfache Text-Datei mit einer Zuordnung IP - Hostname, z.B.

192.168.178.8  drucker.nerd
192.168.178.20 smarthome.nerd

Damit kann ich mir (nur für meinen PC) einfache DNS-ähnliche Einträge selbst setzen und kann zukünftig durch Eingabe von "drucker.nerd" im Browser meinen Drucker direkt aufrufen. Derartige Hosts-Einträge haben immer Vorrang vor DNS-Abfragen.

Die Hosts-Datei wird gerne bei WebEntwicklern genutzt, um Sachen auf einem Testserver unter einem Live-Domainnamen zu testen - da der Live-Domainname vielleicht noch auf die Vorgänger-Webseite zeigt, kann man durch die Hosts-Datei eben schon so tun, als wäre schon die neue IP-Adresse im DNS hinterlegt und schon Dinge testen bevor sie live sind.

Die Hosts-Datei kann auch als einfacher Ad-Blocker genutzt werden: Unter https://someonewhocares.org/hosts/ gibt es eine Liste, auf der die schlimmsten AdServer dieser Erde aufgeführt sind und alle auf die 127.0.0.1 (das ist eine feste IP-Adresse für loopback, also "mich selbst") zeigen. Packt man sich diesen Inhalt in die eigene Hosts-Datei, kann der Browser einfach keine Verbindung mehr zu irgendwelchen Werbeservern aufbauen (weil der Domainnamen immer auf 127.0.0.1 auflöst und damit gar keine Verbindung in das Rechenzentrum des Werbedienstleisters probiert wird) und das Leben wird viel angenehmer (und der PC auch schneller, sicherer und weniger stromfressend). 

Vorteil dieser AdBlock-Variante ist, dass sie ohne weitere Software auskommt (Produkte wie AdBlock Plus sind ja auch nicht unumstritten z.B.). Nachteil ist, dass sie keine Ausnahmen zulässt. Aber Webseiten, die ihre Besucher "mit Adblocker" nicht reinlassen, haben dann eben Pech gehabt.

Aber Achtung: Einträge in der Hosts-Datei können auch umgekehrt zu Sicherheitsproblemen führen, wenn nämlich z.B. die Domain der eigenen Hausbank dort böswillig auf eine andere IP-Adresse gelenkt wird (dann kommt man beim Aufruf der Bank im Online-Banking auf einem ganz anderen Server aus ... was zumindest durch eine https-Zertifikatswarnung auffallen würde).

SPF (Sender Policy Framework) ist eine Technik zur Spam-Vermeidung, bei der man für seine Domain angeben kann, welche Mailserver in diesem Namen Mails verschicken dürfen. DNS hat dabei nur die Aufgabe, die SPF-Angaben zu veröffentlichen, darum kommen TXT-Einträge zum Einsatz.

Schickt nun ein fremder Mailserver (der nicht in dieser Liste steht) eine Mail mit einem solchen Absender, dann kann der Empfänger diese besser als Spam einstufen, weil der Absender offensichtlich gefälscht ist.

Im Zonenfile unserer Beispieldomain sähe das so aus:

IN TXT "v=spf1 A MX ipv4:89.90.91.92 include:spf.protection.outlook.com ~all"

Und wenn wir es fiktiv abfragen, so:

> set query=TXT
> beispieldomain.de.
Server:  fritz.box
Address:  fd00::eadf:70ff:ef98:ae70

Nicht autorisierende Antwort:
beispieldomain.de        text =

        "v=spf1 A MX ip4:89.90.91.92 include:spf.protection.outlook.com ~all"

Wichtig ist, dass im Zonenfile (Also wenn man den SPF-Eintrag setzt) der Inhalt komplett in Anführungszeichen eingeschlossen wird, damit er als zusammenhängender Eintrag gilt.

Auseinandergepfückt:

• v=spf1 sagt erstmal nur, dass das überhaupt ein SPF-Eintrag ist. TXT-Einträge können für alles mögliche verwendet werden, und daran erkennt man, dass es SPF ist
• A und MX geben an, dass sowohl der Webserver ("der mit dem IN A-Eintrag zu dieser Domain, in diesem Fall zu beispieldomain.de") als auch der/die Mailserver (die MX-Einträge, wenn man beispieldomain.de abfragen würde) berechtigt sind, Mails @beispieldomain.de zu verschicken
• Dann steht noch eine einzelne IP4-Adresse in Form einer Domain, vielleicht der Mailserver im Büro (hinter einer festen DSL-IP)
• Und dann ist da noch ein include, das sagt aus, dass alle, die unter "spf.protection.outlook.com" freigeben sind, hier auch freigegeben werden. Includes nutzt man meistens dann, wenn man Server eines Providers für seine Mails nutzt, damit der Provider dann selbst Anpassungen vornehmen muss (würde man die ipv4-Adressen/Netze des Providers hier direkt eintragen, und der Provider ändert was, müsste man als Kunde ja nachbessern). In diesem Fall sieht der verwendete Provider nach Office365 aus. 

Diese vorgenannten Mailserver sind alle befugt, Mails mit dieser Absender-Domain zu verschicken. Heißt: Wenn mein Mailserver eine Mail mit Absender @beispieldomain.de bekommt, kann ich jetzt per DNS-Abfrage nachgucken, wer befugt ist, bekomme o.g. Liste, und wenn der Absender-Mailserver, von dem ich die Mail bekommen habe, in dieser Liste steht, dann sieht das danach aus als wäre das wirklich vom Absender verschickt (und keine Spam-Mail mit Adressfälschung).

In den anderen Fällen kann ich die Mail als Spam aussortieren. Ob ich das tun sollte, darüber sagt die letzte Angabe etwas aus: Würde der SPF-Eintrag auf "-all" enden, hieße das, dass der Rest des Internets ausdrücklich nicht befugt ist (d.h. Mails von irgendwelchen anderen Servern kann ich getrost als Fälschung rausfiltern). In meinem Beispiel ist es aber "~all", und das heißt so viel wie "keine Aussage zum Rest". In dem Fall muss ich selbst beurteilen, ob ich die Mail für Spam oder echt halte.

Der großte Nachteil von SPF ist, dass Fehler nicht direkt auffallen. Zum Beispiel schlägt Microsoft bei MS365 vor, die SPF-Einträge auf "include:alles-von-microsoft, -all" zu setzen, ohne den Kunden zu warnen, was -all bedeutet. Wenn der jetzt irgendwo einen Onlineshop betreibt (dessen IP zwar Mails @die-kundendomain schicken soll, aber nicht im SPF-Record steht), dann werden die sehr oft als Spam aussortiert. Der Kunde merkt das aber gar nicht selbst (der Effekt tritt ja beim Empfänger erst auf) und dank DNS-Caching / TTL auch nicht sofort, sondern viellleicht erst in ein paar Tagen.

Bisher haben wir DNS nur vorwärts genutzt (Domainnamen in z.B. IPs übersetzt).

DNS kommt aber auch andersrum zum Einsatz, sog. ReverseDNS. Wenn wir uns z.B. einen Ausschnitt aus unserer Beispiel-Traceroute aus dem Thema IP-Routing angucken:

 2     7 ms     6 ms     7 ms  braslns-vc1.netcologne.de [195.14.226.161]
  3     6 ms     6 ms     6 ms  ip-core-eup1-ae16.netcologne.de [195.14.215.49]
  4     7 ms     6 ms     6 ms  ip-core-sto1-et2-2-2.netcologne.de [87.79.17.18]
  5     7 ms     6 ms     7 ms  bdr-sto1-ae1.netcologne.de [81.173.192.114]

dann werden die Server hier alle mit einem Hostnamen angezeigt. Woher kennt mein PC die? Er hat sie per DNS abgefragt. Der dafür notwendige Eintrag lautet PTR ("Pointer"), die abzufragende Domain ist die IP mit umgekehrter Block-Sortierung.in-addr-arpa., das sieht dann so aus:

> set query=PTR
> 161.226.14.195.in-addr.arpa.
Server:  fritz.box
Address:  fd00::eadf:70ff:ef98:ae70

Nicht autorisierende Antwort:
161.226.14.195.in-addr.arpa     name = braslns-vc1.netcologne.de

Warum andersrum? IP-Netze werden ja von vorne nach hinten konkreter, d.h. mein Netz daheim hat IPs vom Typ 192.168.178.*

DNS-Delegation auf andere Server funktioniert aber von hinten nach vorne (de / vollzeitnerd / www). 

Wenn man jetzt die IP genauso rumdreht, dann könnte man mit einem Eintrag im Zonenfile

178.168.192.in-addr-arpa. IN NS vollzeitsnerds-nameserver.de.

einfach mein Netzwerk auf meinen Nameserver delegieren und ich könnte dann innerhalb meines Netzes meine IPs selbst vergeben. (Geht natürlich konkret bei privaten IPs wie 192.168.* nicht).

Logischerweise müssen PTR-Einträge nicht im Zonenfile des Domain-Providers gesetzt werden, sondern im Zonenfile des IP-Providers (Rechenzentrum oder z.B. DSL-Anbieter), denn die haben für ihre IPs ja dann eine NS-Delegation vom RIPE (Vergabestelle der IP-Adressen) erhalten.

Der Vollständigkeit halber noch ein Exot unter den Domain-Einträgen: E164 Number Mapping, ENUM abgekürzt.

ENUM war der Idee in den VoIP-Anfängen, Telefonnummern in Domainnamen abzufragen. Hatte man die Telefonnummer 0221 / 1234567 (in internationaler e164-Schreibweise also +492211234567), hätte man dazu die Domain 7.6.5.4.3.2.1.1.2.2.9.4.e164.arpa registrieren können (bzw. kann das noch heute).

Die umgedrehte Schreibweise hat die gleiche Logik wie auch bei den PTR-Records, eine Firma kann sich damit ihre Stammrufnummer auf ihren eigenen Nameserver delegieren lassen und die Durchwahlen dann selbst als Subdomains konfigurieren. Und zuständig für die Vergabe der Teilzone "9.4.e164.arpa" (also alle Rufnummern unterhalb +49) ist im Auftrag der Bundesnetzagentur die DENIC, die wir ja schon von .de-Domains kennen.

Innerhalb des Zonenfiles dieser ENUM-Domain stehen dann als Typ sog. NAPTR-Records (Naming Authority Pointer), das sind etwas aufwendigere Antwort-Typen, bei denen z.B. mit regulären Ausdrücken (=Suchbegriffen und automatische Umwandlung in der Antwort) gearbeitet werden kann. Die Idee dahinter war, dass ich für meine Telefonnummer verschiedene Telefon- (vgl. einer Rufumleitung) aber auch SIP-Ziele (=IP-Telefonie-Accounts) anlegen kann, und so ein übergreifendes Telefonieren zwischen SIP-Providern möglich wäre.

Leider hat sich ENUM nie wirklich durchgesetzt und spielt genau gar keine Rolle im deutschen Telefonie-Umfeld.