DNS-Server
In diesen Übungen werden Sie die das Konzept vom Domain Name System genauer unter die Lupe nehmen,
Die Hosts-Datei
Vorbereitung
Falls Sie ein MAC-Gerät haben, verwenden Sie folgende Anleitung: https://kinsta.com/de/wissensdatenbank/mac-hosts-datei/
- Öffnen Sie den Windows-Editor im Administratoren-Modus indem Sie im Windows-Startmenü nach Editor suchen und dann auf das Suchresultat einen Rechtsklick machen. Wählen Sie dann die Option Als Administrator ausführen. Sie können auch einen anderen Editor Ihrer Wahl nehmen wie z. B. Visual Studio Code oder Notepad++
- Klicken Sie nun im Editor auf Datei um im Menü die Option Öffnen auszuwählen.
- Navigieren Sie in das Verzeichnis C:\Windows\System32\drivers\etc
- Stellen Sie sicher, das Sie im Dateiexplorer die Option Alle Dateien (*.*) aktiviert haben und öffnen Sie die Datei hosts.
-
Fügen Sie nun folgende Zeile in der Datei hinzu:80.74.136.2 tbz.ch www.tbz.ch - Speichern Sie die Datei.
Übungen
Rufen Sie nun die die Webseite der TBZ auf indem Sie auf folgenden Link klicken oder diesen in Ihrem Browser direkt eintragen:
Frage: Was sehen Sie, wenn Sie die Webseite aufrufen?
Es erscheint ein Text, dass dies nicht die TBZ-Webseite sei.
Frage: Können Sie sich vorstellen, weshalb es Administratoren-Rechte benötigt, um die betreffende Datei zu bearbeiten:
Die Hosts Datei ist problematisch, da mit Ihr legitime URL auf fremde Server geleitet werden können. Dadurch ergibt sich ein grosses Missbrauchsportential durch Hacker und Malware. Aus diesem Grund ist die Datei speziell geschützt.
Auftrag: Öffnen Sie eine Kommandozeileneingabe (CMD oder Powershell) und setzen Sie eine Ping auf tbz.ch (ohne www) ab. Was für eine IP-Adresse wird angepingt?
80.74.136.2
Auftrag: Öffnen Sie nun die Webseite https://mxtoolbox.com/DNSLookup.aspx und prüfen Sie, was Sie dort für eine IP-Adresse erhalten für tbz.ch.
149.126.4.25
Frage: Können Sie erklären, was die technische Situation sein könnte, dass sich das Resultat der Webseite und Ihrem Windows-Gerät unterscheidet?
Durch den Eintrag in der Hosts-Datei wurde einen manuellen Eintrag gesetzt, welcher das Betriebssystem immer verwendet, wenn es den gesuchten Namen tbz.ch abruft. Das Betriebssystem fragt somit gar nicht weiter, was die IP-Adresse von tbz.ch ist.
Auftrag: Öffnen Sie nun den Text-Editor erneut und fügen Sie folgende Zeile hinzu:
127.0.0.1 instagram.com www.instagram.com
Versuchen Sie nun die Seite https://instagram.com aufzurufen. Klappt dies?
Nein, die Seite wird nicht geladen.
Frage: Was genau ist die IP-Adresse 127.0.0.1? Recherchieren Sie im Internet zu dieser Adresse.
Die IP-Adresse 127.0.0.1 ist eine sogenannte Loopback-Adresse. Sie verweist auf den eigenen Computer.
Frage: Warum kann nun instagram.com nicht mehr aufgerufen werden, wenn dieser Hostname als Ziel-IP die 127.0.0.1 verwendet?
Der Webbrowser versucht sich nun zur IP-Adresse 127.0.0.1 zu verbinden. Dies ist das lokale Gerät. Da auf diesem Gerät jedoch kein Webserver aktiv ist, kann der Webbrowser keine HTTP Verbindung herstellen.
Auftrag: Kann die Seite https://help.instagram.com aufgerufen werden? Wenn ja, warum?
In der Hosts-Datei wird help.instagram.com nicht auf 127.0.0.1 geleitet. Darum wird dieser Hostname ganz normal aufgelöst.
Vergessen Sie nun nicht, die Einträge in der Hosts-Datei wieder zu entfernen.
Frage: Was für Gründe könnte es geben, dass in einem Unternehmen Einträge in der Hosts-Datei durch die Systemadministration erstellt werden?
- Es können URL's auf der Ebene des Betriebssystems blockiert werden. Diese können auch nicht aufgerufen werden, wenn andere Nameserver hinterlegt werden.
- Es können z.B. interne Hostnamen verwendet werden, welche im öffentlichen DNS-Netzwerk gar nicht existieren.
Frage: Nennen Sie die Gründe, warum sich mit der wachsenden Anzahl an Hosts und Hostnamen, eine Bewirtschaftung der Hostnamen in einer lokalen Hosts-Datei nicht mehr möglich war.
- Es gibt zu viele Hosts, die Datei wäre extrem gross und die Abfrage darin langsam.
- Alle Dateien aller Hosts müssten regelmässig aktualisiert werden, wenn es neue Domains und Subdomains gibt.
- Es birgt ein Sicherheitsrisiko, wenn die z. B. der Hostname des Online-Bankings lokal verwaltet wird, wo Malware potentiellen Zugriff hat.
Auftrag: Öffnen Sie nun die Windows Power-Shell (Nicht CMD) und setzen Sie folgenden Befehl ab:
ipconfig /displaydns
Studieren Sie nun die Daten. Es dürften ziemlich viele sein.
Setzen Sie anschliessend den folgenden Befehl ab:
ipconfig /flushdns
Zeigen Sie anschliessend die Daten erneut an mit:
ipconfig /displaydns
Frage: Was hat sich verändert, nachdem Sie /flushdns aufgerufen haben?
Es werden wesentlich weniger DNS-Einträge angezeigt.
Auftrag: Finden Sie heraus, was die Befehle ipconfig /displaydns und ipconfig /flushdns genau bewirken. Tipp mit ipconfig /? können Sie die Hilfeseite vom Programm ipconfig aufrufen.
Mit /displaydns lässt sich der DNS-Auflösungs-Cache anzeigen
Die Domain
Einführung
In dieser Übung werden Sie die Kommandozeilen-Tools nslookup (Windows) und dig (Mac, Linux) verwenden. Die genaue Verwendungsweise dieser Tools wird in einer späteren Übung erläutert. Für den Anfang müssen Sie wissen, wie Sie die Basis-Funktion der Tools verwenden können:
nslookup (Windows, Mac, Linux)
Unter Windows verwenden Sie nslookup in der CMD oder mit Powershell. Sie tippen den Befehl nslookup gefolgt vom gewünschten Domain-Namen ein. Als Resultat erhalten Sie die IP-Adresse zu diesem Domainnamen:
nslookup tbz.ch [ENTER]
Server: UnKnown
Address: 2001:730:3e82::11
Nicht autorisierende Antwort:
Name: tbz.ch
Address: 149.126.4.25
dig (Mac, Linux)
Unter Mac und Linux können Sie auch dig verwenden. Dieses Tool ist etwas mächtiger, erfüllt aber die selben grundlegenden Aufgaben. Tippen Sie im Terminal ebenfalls den Befehl dig gefolgt vom gewünschten Domainnamen ein:
$ dig tbz.ch [ENTER]
; <<>> DiG 9.18.1-1ubuntu1-Ubuntu <<>> tbz.ch
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50372
;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;tbz.ch. IN A
;; ANSWER SECTION:
tbz.ch. 0 IN A 80.74.136.2
;; Query time: 0 msec
;; SERVER: 172.22.112.1#53(172.22.112.1) (UDP)
;; WHEN: Wed Dec 07 21:46:25 CET 2022
;; MSG SIZE rcvd: 46
Begrifflichkeiten um die Domain
Aufgabe 1: Betrachten Sie das unten stehende Bild. Es beschreibt alle Teile davon, was wir unter einer Domain verstehen:
Domain-Namen sind streng hierarchisch aufgebaut. Unten finden Sie eine Baumdarstellung einiger Domain-Namen. Man nennt dies auch den DNS-Namespace:
Aufgabe 2: Weisen Sie den einzelnen Ebenen 1 - 4 die dazugehörigen Begriffe zu aus der Aufgabe 1.
1. Root (Wurzel)
2. Top-Level-Domain
3. Domain
4. Host oder Subdomain
Aufgabe 3: Finden Sie in Internet mind. 5 verschiedene Top-Level-Domains die wirklich verwendet werden:
Länge eines FQDN
Aufgabe 1: Untenstehend finden Sie zwei FQDN. Der eine ist gültig und der andere nicht:
FQDN 1: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.iten.io.
FQDN 2: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.iten.io.
Schätzen Sie ein, welche der beiden FQDN gültig ist und welcher nicht. Was ist der Grund, weshalb der eine FQDN gültig ist und der andere nicht?
Der FQDN 2 enthält im Label insgesamt 64 Zeichen. Ein einzelnes Label (Teil zwischen zwei Punkten) darf jedoch maximal 63 Zeichen lang sein. Ist ein label länger, so ist es ungültig.
Der FQDN 1 ist gültig, da das Label xxxxxxx.... nur 63 Zeichen enthält.
Leiten Sie nun aufgrund Ihrer Erkenntnis aus der Aufgabe einen Merksatz für FQDN ab:
Ein Label eines FQDN darf nie mehr als 63 Zeichen enthalten.
Aufgabe 2: Untenstehend finden Sie zwei FQDN. Der eine ist gültig und der andere nicht:
FQDN 1: xxxxx..iten.io
FQDN 2: xxxx.x.iten.io
Schätzen Sie ein, welche der beiden FQDN gültig ist und welcher nicht. Was ist der Grund, weshalb der eine FQDN gültig ist und der andere nicht?
Der FQDN 1 enthält im zweiten Label mit 0 Zeichen zwischen xxxx. und .iten. daher ist dieser nicht gültig.
Der FQDN 2 enthält im zweiten Label ein Zeichen. Damit hat jedes Label mindestens ein Zeichen, daher ist dieser gültig.
Ergänzen Sie den Merksatz aus der Aufgabe 1 nun mit der Erkentniss der Aufgabe 2:
Ein Label eines FQDN darf nie mehr als 63 Zeichen enthalten und muss mindestens ein Zeichen enthalten.
Aufgabe: Untenstehend finden Sie drei FQDN. Zwei sind gültig und der andere nicht:
FQDN 1: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.iten.io.
FQDN 2: xxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxx.iten.io.
FQDN 3: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.iten.io.
Schätzen Sie ein, welche der drei FQDN gültig ist und welcher nicht. Was ist der Grund, weshalb der eine FQDN gültig ist und der andere nicht?
Der FQDN 1 und FQDN 2 enthält weniger als 254 Zeichen. (Mit dem abschliessenden Punkt) Der FQDN 3 hingegen hat mehr als 254 Zeichen. (Mit dem abschliessenden Punkt)
Der FQDN 1 und FQDN 2 enthält weniger als 253 Zeichen. (ohne abschliessenden Punkt) Der FQDN 3 hingegen hat mehr als 253 Zeichen. (ohne den abschliessenden Punkt)
Leiten Sie nun aufgrund Ihrer Erkenntnis aus der Aufgabe einen Merksatz für FQDN ab:
Ein kompletter FQDN darf nicht länger als 254 (ASCII) Zeichen sein (Wenn der letzte Punkt gezählt wird, 253 ohne abschliessenden Punkt)
Bonusfrage: Das Internet ist manchmal ungenau! Wenn Sie im Internet nach "Länge FQDN" suchen, werden Sie eine andere max. Länge erhalten. Sie werden sehen, dass dies Zahl genau um eines grösser ist als die Zahl welche Sie im internet finden. Es muss somit ein Zeichen existieren, welches wir bei einem FQDN nicht setzen, es aber trotzdem zu dessen Länge gerechnet wird.
Können Sie raten, was für ein Zeichen dies ist und wo es eigentlich im FQDN wäre? Diese Frage ist sehr schwer und Sie müssen diese nicht korrekt beantworten können. Raten Sie aber und schauen Sie sich die Labels und die Punkte genau an. Lesen Sie anschliessen in der Lösung ob Sie der korrekten Antwort nahe gekommen sind.
Wie Sie gelernt haben, gehört der . am Ende zu einem gültigen FQDN, denn dieser repräsentiert die "leere" Root-Zone, also die Wurzel des DNS-Baums. Er ist somit nicht der Abschluss des FQDN, sondern leitet ein leere Label (mit der Länge 0 ein)
Also eigentlich www.tbz.ch."leere root zone"
Ein Punkt leitet somit immer ein Label ein. Nur ganz am Anfang des FQDN fehlt ein Punkt, obwohl dort ja ein Label anfängt.
Uns genau das ist das "versteckte" Zeichen. Der erste Punkt wird nicht geschrieben, aber im technischen Hintergrund ist der Punkt da und zählt auch zur Gesamtlänge hinzu. Wir haben somit einen Punkt am Anfang + 253 Zeichen + abschliessender Punkt = 255 Zeichen.
Hintergrund: Der RFC Standard schreibt nicht 255 Zeichen vor, sondern 255 Oktette, das sind Bit-Oktette also z. B 1001 1110. Jeder Buchstabe belegt ein Oktett mit den Informationen für ein ASCII Zeichen. Die Punkte hingegen sind im Hintergrund keine Punkte, sondern Oktette, welche angegeben wie lange das nachfolgende Label ist. Also z.B. 0000 1111 = Es folgt ein Label mit 16 ASCII Zeichen. Ganz am Anfang ist ebenfalls solch ein Oktett mit den Längeninformationen vorhanden, es wird aber nicht als Punkt dargestellt.
Aufgrund dieser Ungenauigkeit Oktett != Zeichen steht im Internet überall ein FQDN kann 255 Zeichen lang sein, während es in Wirklichkeit nur 253 Zeichen sind. (Mit abschliessendem Punkt 254)
Erlaubte Zeichen eines FQDN
Sie haben nun herausgefunden, wie lange ein FQDN sein darf und wie dieser von der Struktur her aufgebaut sein darf. Im nächsten Teil geht es darum herauszufinden, welche Zeichen in einem FQDN erlaubt sind, und welche nicht.
Aufgabe 1: Sie finden unten nun einige FQDN. Beurteilen Sie, welche das gültig sind und welche aufgrund nicht erlaubter Zeichen ungültig sind. Testen Sie die Gültigkeit dieser FQDN in einem ersten Schritt ausschliesslich mit den Kommandozeilen-Werkezeugen nslookup (Windows) oder dig (Mac, Linux).
FQDN 1: test.iten.io.
FQDN 2: 1234.iten.io.
FQDN 3: test1234.iten.io.
FQDN 4: test-1234.iten.io.
FQDN 5: -test-1234.iten.io.
FQDN 6: -test1234.iten.io.
FQDN 7: test--1234.iten.io
FQDN 8: äöü.iten.io.
FQDN 9: ✌️.iten.io.
FQDN 10: 新汉德词典.iten.io.
FQDN 11: email@iten.io.
FQDN 12: gehtdas?.iten.io.
FQDN 13: geht?das.iten.io.
FQDN 14: 1234,iten.io.
FQDN 15: test_1234.iten.io.
FQDN 16: test:1234.iten.io.
Leiten Sie aufgrund Ihres Tests ab, was für Zeichen ein FQDN genau enthalten darf. Beachten Sie, es ist einfacher zu definieren was erlaubt ist, anstatt was verboten ist. Machen Sie ggf. eigene Tests um Ihre Thesen zu überprüfen. Fassen Sie alles in einem Merksatz zusammen.
Ein FQDF darf besteht aus den Buchstaben von A - Z und den Zahlen von 0 - 9 und dem Sonderzeichen Bindestrich. Der Bindestrich darf nie am Anfang eines Labels stehen.
Aufgabe 2: Rufen Sie nun die nachfolgenden FQDN aus der vorherigen Aufgabe in einem Webbrowser Ihrer Wahl (Firefox, Chrome, Opera, Vivaldi, Edge, Safari) auf. Können Sie die diese FQDN aufrufen? Wenn ja, warum geht es und was passiert?
FQDN 9: äöü.iten.io.
FQDN 10: ✌️.iten.io.
FQDN 11: 新汉德词典.iten.io.
Der Webbrowser wandelt den FQDN in eine Variante ohne die Sonderzeichen um.
Sie können den sogenannten Puny-Code oder IDN-Konverter auf folgender Seite ausprobieren:
Frage: Macht die Gross- und Kleinschreibung einen Unterschied?
Nein, es macht keinen Unterschied ob eine FQDN gross oder klein geschrieben wird.
nslookup
Wenn Sie die Übung Die Domain bereits bearbeitet haben, sind Sie mit nslookup und dig bereits in Berührung gekommen. In dieser Übung werden Sie sich noch etwas tiefer mit nslookup und dig auseinandersetzen.
Auftrag 1: Nehmen Sie sich 10 bis 15 Minuten Zeit, um sich einen Überblick über das Kommandozeilen-Tool nslookup zu verschaffen:
https://de.wikipedia.org/wiki/Nslookup
https://www.wintotal.de/tipp/nslookup/
https://www.veuhoff.net/nslookup-ein-leitfaden-fuer-anfaenger-ueber-das-befehlszeilentool/
https://www.youtube.com/watch?v=VwKXwzNRp6E
https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/nslookup
Frage: Im nachfolgenden Screenshot sehen Sie einen regulären nslookup für die Domain tbz.ch. Beschreiben Sie was Sie bei 1. und 2. für eine Information zurückerhalten.
1.
2.
1. Dies ist die IP-Adresse des DNS-Servers, welcher uns die Antwort geliefert hat
2. Dies ist die IP-Adresse der angefragten Domain tbz.ch
Auftrag 2: Starten Sie nun die Kommandozeile und führen Sie den nachfolgenden Befehl selbständig aus:
nslookup tbz.ch
Von welchem DNS-Server haben Sie nun die Antwort erhalten? Woher hat nslookup diesen DNS-Server? Tipp: ipconfig
Sie sehen den standardmässig konfigurierten DNS-Server auf Ihrem Gerät. Falls Sie in der TBZ sind und die DNS-Server nicht manuell angepasst haben, sollten Sie die Antwort von xxx.xxx.xxx.xxx erhalten haben.
Auftrag 3: Ändern Sie nun in den IP-Einstellungen Ihres Gerätes die DNS-Server. Sie können z. B. einer der folgenden DNS-Server nehmen:
| IP | |
| 195.186.4.162 | Primärer öffentlicher DNS-Server Swisscom |
| 195.186.1.162 | Sekundärer öffentlicher DNS-Server Swisscom |
| 8.8.8.8 |
Primärere öffentlicher DNS-Server Google |
| 8.8.4.4 |
Sekundärer öffentlicher DNS-Server Google |
| 9.9.9.9 |
Primärere öffentlicher DNS-Server Quad9 |
| 149.112.112.112 |
Sekundärer öffentlicher DNS-Server Quad9 |
| 130.59.31.248 |
Primärer öffentlicher DNS Server SWITCH |
| 130.59.31.251 |
Sekundärer öffentlicher DNS Server SWITCH |
Starten Sie nun einen neuen nslookup auf tbz.ch. Hat sich nun etwas verändert?
Ja, der DNS-Server, welcher die Antwort zurückliefert ist nun jener, der manuell konfiguriert wurde.
Frage: Können Sie sich vorstellen, weshalb immer zwei DNS-Server bereitgestellt werden und auch zwei DNS-Server im Betriebssystem hinterlegt werden können?
Bei der DNS-Abfrage handelt es sich um einen kritischen Vorgang. Funktioniert dieser Vorgang nicht, können keine Domains mehr aufgelöst werden und ganz viele Applikationen funktionieren nicht mehr. Aus diesem Grund setzt man hier auf Redundanz, fällt ein Server aus, so kann das Betriebssystem den zweiten weiter verwenden.
Auftrag 4: Es gibt eine Möglichkeit, wie Sie einen spezifischen DNS-Server abfragen können, ohne dass Sie die DNS-Einstellungen in Ihrem Betriebssystem anpassen müssen. Hierfür können Sie den gewünschten DNS-Server einfach als zweiten Parameter mitgeben. Also z. B.
nslookup tbz.ch 8.8.8.8
Fragen Sie nun bei zwei verschiedenen Nameservern Informationen über die Domain tbz.ch an:
- 8.8.8.8
- 80.67.16.124
Frage: Wie unterscheidet sich das Resultat?
Der DNS-Server von Google gibt eine Nicht autorisierende Antwort zurück. Der zweite DNS Server 80.67.16.124 hat diesen Hinweis hingegen nicht.
Merken Sie sich den Unterschied, in der Ausgabe denn dieser wird in der nächsten Übung relevant.
DNS-Auflösung
Wie Sie in der Übung Die Hosts-Datei herausgefunden haben, ist es nicht optimal, einen DNS-Dienst zentral zu betreiben. Dieser Server wäre viel zu anfällig und der Vorgang um Änderungen an einer DNS-Zone einzupflegen, wären verhältnismässig gross. Aus diesem Grund ist DNS als ein verteilter Dienst aufgebaut. DNS ist somit kein einzelner Server, sondern viele verschiedenen Server, welcher zusammenspielen, um die DNS-Auflösung zu ermöglichen.
Auftrag 1: Schauen Sie sich das untenstehende Schema an. Es zeigt auf wie eine DNS-Auflösung funktioniert.
Beschreibung Bild: Der Client möchte die IP-Adresse vom Urspungsserver von www.tbz.ch wissen. Dazu stellt dieser eine Anfrage an seinem DNS-Resolver. Dieser kümmert sich für uns um die DNS-Auflösung und liefert uns am Ende das Resultat zurück.
Frage: In den vorangegangene Übungen haben Sie jeweils bereits DNS-Resolver verwendet und sogar öffentlich verfügbare DNS-Resolver in ihrem Betriebssystem hinterlegt. Was für DNS-Resolver kennen Sie?
Es gibt öffentliche DNS-Resolver wie die public Google DNS, Quad9, Switch DNS. Auf der anderen Seite haben Sie die DNS-Resolver, welche Ihnen Ihr ISP (Internet Service Provider, Swisscom, Sunrise) zur Verfügung stellt.
Der DNS-Resolver muss nun die Auskunft über die IP-Adresse zum Hostnamen bei verschiedenen DNS-Servern einholen.
Frage: Schauen Sie sich die drei verschiedenen Nameserver an, welche der DNS-Resolver nun fragen wird. Fällt Ihnen etwas auf, wenn Sie an die Übung mit dem FQDN zurückdenken?
Es gibt drei Nameserver, wobei wohl jeder für einen eigenen Teil der des FQDN zuständig ist.
- Root Nameserver für den Root der Doman
- TLD-Server für die Top-Level-Domain
- Domain-Name-Server für die Domain
Der DNS-Sever verteilt die Anfragen somit auf die einzelnen Teile des FQDN. Somit ist nicht ein einzelner Server für den ganzen Domain-Namen zuständig, sondern es ist eine verkettete Abfrage von verschiedenen DNS-Servern . Jeder DNS-Server ist dabei für einen kleinen Teil der ganzen Domain zuständig.
Wie im Ablauf ersichtlich ist, kontaktiert der DNS-Resolver als erstes die Root-Nameserver. Die Root-Nameserver sind eine fest definierte Liste die jeder DNS-Resolver hinterlegt hat. Der DNS-Resolver wird also als erstes immer einen dieser DNS-Server abfragen.
Nachfolgend finden Sie die Liste der Root-Server:
| Servername | IP-Adresse | Betreiber |
| a.root-servers.net | 198.41.0.4 | Verisign, Inc. |
| b.root-servers.net | 199.9.14.201 | University of Southern California, |
| c.root-servers.net | 192.33.4.12 | Cogent Communications |
| d.root-servers.net | 199.7.91.13 | University of Maryland |
| e.root-servers.net | 192.203.230.10 | NASA (Ames Research Center) |
| f.root-servers.net | 192.5.5.241 | Internet Systems Consortium, Inc. |
| g.root-servers.net | 192.112.36.4 | US Department of Defense (NIC) |
| h.root-servers.net | 198.97.190.53 | US Army (Research Lab) |
| i.root-servers.net | 192.36.148.17 | Netnod, Inc. |
| j.root-servers.net | 192.58.128.30 | Verisign, Inc. |
| k.root-servers.net | 193.0.14.129 | RIPE NCC |
| l.root-servers.net | 199.7.83.42 | ICANN |
| m.root-servers.net | 202.12.27.33 | WIDE Project |
Frage: Was fällt Ihnen auf, wenn Sie die Betreiber anschauen? Wie setzen sich die Betreiber zusammen? Warum ist nicht einfach nur ein Betreiber für alle Root-Nameserver zuständig?
Die Betreiber der Root-Nameserver sind zusammengesetzt auf öffentlichen Organistionen wie Universitäten, Gemeinnütigen Organisationen (ICANN, RIPE NCC), Regierungen (NASA, US Army, DoD) und privaten Firmen wie Versisign und Netnod.
Damit möchte man die Authentizität von DNS sicherstellen, weil viele verschiedenen Organisationen gemeinsam für die Root-Nameserver zuständig sind. Keine Organisation alleine sollte die Macht über das ganze DNS haben.
Die Root-Nameserver sind somit unser Einstiegspunkt des DNS-Resolvers. Sie können diese ebenfalls mit nslookup abfragen.
Auftrag 2: Öffnen Sie nslookup und stellen Sie eine Anfrage für tbz.ch an einen der oben stehenden Root-Nameserver. (Tipp. Sie haben in der Übung nslookup gelernt, wie Sie einen spezifischen DNS-Server abfragen können). Sie sollten nun die untenstehende Antwort erhalten:
Name: tbz.ch
Served by:
- b.nic.ch
130.59.31.43
2001:620:0:ff::58
ch
- f.nic.ch
194.146.106.10
2001:67c:1010:2::53
ch
- e.nic.ch
194.0.17.1
2001:678:3::1
ch
- d.nic.ch
194.0.25.39
2001:678:20::39
ch
- a.nic.ch
130.59.31.41
2001:620:0:ff::56
ch
Frage: Schauen Sie sich nun erneut die Grafik mit dem Ablauf einer DNS-Abfrage an. Was könnten die die vom Root-Server erhaltene Antwort genau sein?
Der Root-Server schickt uns in der Antwort die zuständigen DNS-Server für die .CH Top-Level-Domain. Wir erhalten den Namen und die zugehörige IPv4 und IPv6 Adressen.
Frage: Was wird der DNS-Resolver mit diesen Informationen nun als nächstes machen?
Der DNS-Resolver schickt eine Anfrage an einen dieser Nameserver um den nächsten Teil des FQDN aufzulösen.
Auftrag 3: Stellen Sie nun eine DNS-Abfrage an einen der erhaltenen Top-Level-Domain Nameservern. Wie lautete der dazugehörige nslookup Befehl?
nslookup tbz.ch 130.59.31.4
Frage: Was erhalten Sie für für eine Information in der Antwort vom Top-Level-Domain Nameserver?
Der Top-Level-Domain Nameserver gibt uns die Domain-Nameserver der Domain tbz.ch zurück:
nslookup tbz.ch a.nic.ch
Server: UnKnown
Address: 130.59.31.41
Name: tbz.ch
Served by:
- ns2.hosting.ch
193.223.77.3
tbz.ch
- ns1.hosting.ch
80.67.16.124
tbz.ch
Frage: Wie lauten die zuständigen Domain-Nameserver der Domain tbz.ch?
ns1.hosting.ch
ns2.hosting.ch
Frage: Was wird der DNS-Resolver mit diesen Informationen nun als nächstes machen?
Der DNS-Resolver schickt eine Anfrage an einen dieser Domain-Nameserver um den nächsten Teil des FQDN aufzulösen.
Auftrag 4: Stellen Sie nun eine DNS-Abfrage an einen der erhaltenen Top-Level-Domain Nameservern. Wie lautete der dazugehörige nslookup Befehl?
nslookup tbz.ch 193.223.77.3
Frage: Was haben Sie nun für eine Information in der Antwort vom Domain-Nameserver erhalten?
Der Domain-Nameserver hat uns nun die IP-Adresse von tbz.ch mitgeteilt.
Frage: Wie lautet die IP-Adresse von tbz.ch?
149.126.4.25
Auftrag 5: Wodurch unterscheidet sich diese Antwort von den bisherigen Antworten?
Wir haben keine weiteren DNS-Server mehr erhalten, sondern die finale Antwort mit der IP-Adresse. Die DNS-Auflösung ist für den Resolver damit nun beendet.
Frage: Was ist nun die letzte Aufgabe, welcher der DNS-Resolver macht?
Der DNS-Resolver übermittelt die Antwort zurück an den Client. Dieser kann nun mit der IP-Adresse den Server von tbz.ch erreichen.
Zusammenfassende Fragen
Frage: Beschreiben Sie in zwei bis drei Sätzen die Aufgaben und Eigenschaften von Root-Nameserver:
Die Root-Nameserver stellen den Einstiegspunkt in die DNS-Auflösung dar. Jeder DNS-Resolver kennt die Root-Nameserver, welche weltweit auf verschiedene Firmen und Organisation verteilt.
Frage: Beschreiben Sie in zwei bis drei Sätzen die Aufgaben und Eigenschaften von Top-Level-Nameserver:
Die Top-Level-Nameserver sind dafür zuständig, um einem DNS-Resolver die Nameserver der Domains unter dieser Top-Level-Domains zu liefern. Die Top-Level-Domains kennen somit alle Nameserver der Ihnen untergeordneten Domains.
Frage: Beschreiben Sie in zwei bis drei Sätzen die Aufgaben und Eigenschaften von Domain-Nameserver:
Die Domain-Nameserver enthalten die IP-Adressen der Hosts und Sub Domains unter der betreffenden Domain. Auf diesem Nameserver passt der Inhaber von tbz.ch seine DNS-Einträge an.
Frage: Überlegen Sie, was die Vorteile einer verteilten Lösung auf verschiedene Nameserver sein können:
- Die Last wird auf viele verschiedenen Nameserver verteilt.
- Der Inhaber einer DNS-Zone kann einfach auf einem Nameserver die Anpassung vornehmen. Diese wird dann automatisch weltweit verfügbar sein.
Weitere DNS-Auflösungen.
Auftrag 1: Führen Sie eine komplette DNS-Auflösung für die Domain www.iten.io durch. Notieren Sie alle beteiligten Nameserver:
Der DNS-Resolver fragt einen der Root-Nameserver:
a.root-servers.net 198.41.0.4
b.root-servers.net 199.9.14.201
c.root-servers.net 192.33.4.12
d.root-servers.net 199.7.91.13
u.s.w
Beispiel: nslookup www.iten.io 198.41.0.4
Die Root-Nameserver liefern folgende Antwort für den Top-Level-Domain Nameserver:
- b0.nic.io
65.22.161.17
2a01:8840:9f::17
io
- a0.nic.io
65.22.160.17
2a01:8840:9e::17
io
- a2.nic.io
65.22.163.17
2a01:8840:a1::17
io
- c0.nic.io
65.22.162.17
2a01:8840:a0::17
io
Der DNS-Resolver frag nun einer der erhaltenen TLD-Nameserver:
Beispiel: nslookup www.iten.io 65.22.161.17
Name: www.iten.io
Served by:
- dns2.registrar-servers.com
iten.io
- dns1.registrar-servers.com
iten.io
Der DNS-Resolver frag nun einen der erhaltenen Domain-Nameserver:
Beispiel: nslookup www.iten.io dns1.registrar-servers.com
Server: UnKnown
Address: 156.154.132.200
Name: iten.io
Address: 80.74.136.2
Aliases: www.iten.io
Die IP-Adresse von www.iten.io lautet 80.74.136.2
Auftrag 2: Führen Sie eine komplette DNS-Auflösung für die Domain support.google.com durch. Notieren Sie alle beteiligten Nameserver:
Der DNS-Resolver fragt einen der Root-Nameserver:
a.root-servers.net 198.41.0.4
b.root-servers.net 199.9.14.201
c.root-servers.net 192.33.4.12
d.root-servers.net 199.7.91.13
u.s.w
Beispiel: nslookup support.google.com 198.41.0.4
Die Root-Nameserver liefern folgende Antwort für den Top-Level-Domain Nameserver:
Name: support.google.com
Served by:
- e.gtld-servers.net
192.12.94.30
2001:502:1ca1::30
com
- b.gtld-servers.net
192.33.14.30
2001:503:231d::2:30
com
- j.gtld-servers.net
192.48.79.30
2001:502:7094::30
com
- m.gtld-servers.net
192.55.83.30
2001:501:b1f9::30
com
- i.gtld-servers.net
192.43.172.30
2001:503:39c1::30
com
- f.gtld-servers.net
192.35.51.30
2001:503:d414::30
com
- a.gtld-servers.net
192.5.6.30
2001:503:a83e::2:30
com
- g.gtld-servers.net
192.42.93.30
2001:503:eea3::30
com
- h.gtld-servers.net
192.54.112.30
2001:502:8cc::30
com
- l.gtld-servers.net
192.41.162.30
2001:500:d937::30
com
Der DNS-Resolver frag nun einer der erhaltenen TLD-Nameserver:
Beispiel: nslookup support.google.com 192.12.94.30
Server: UnKnown
Address: 192.12.94.30
Name: support.google.com
Served by:
- ns2.google.com
2001:4860:4802:34::a
216.239.34.10
google.com
- ns1.google.com
2001:4860:4802:32::a
216.239.32.10
google.com
- ns3.google.com
2001:4860:4802:36::a
216.239.36.10
google.com
- ns4.google.com
2001:4860:4802:38::a
216.239.38.10
google.com
Der DNS-Resolver frag nun einen der erhaltenen Domain-Nameserver:
Beispiel: nslookup support.google.com 216.239.32.10
Server: ns1.google.com
Address: 216.239.32.10
Name: support.google.com
Addresses: 2a00:1450:400a:803::200e
172.217.168.78
Die IP-Adresse von www.iten.io lautet 172.217.168.78
Rekursive und Iterative Abfragen
Eine DNS-Anbfrage kann auf zwei Arten stattfinden:
- Rekursive Abfrage: Der fragende DNS-Server stellt einem anderen DNS-Server eine Anfrage und wartet, bis er eine vollständige Antwort inkl. IP-Adresse erhält. Der andere DNS-Server kümmert sich vollständig um die DNS-Abfrage.
- Iterative Abfrage: der fragende DNS-Server stellt einem anderen DNS-Server eine Anfrage, erhält einen Verweis auf anderen zuständigen Nameserver, und stellt dann bei diesem Nameserver eine weitere Anfrage. Dies macht der fragende DNS-Server solange, bis er einen DNS-Server findet, der eine IP-Adresse zurück liefert.
Auftrag 1: In einer regulären DNS-Auflösung kommen in der Regel beide Varianten zum Einsatz. Studieren Sie den DNS-Ablauf erneut und beurteilen Sie, bei welchen Abfragen (1 - 10) es sich um rekursive Abfrage, iterative Abfragen und gar keine DNS-Abfragen handelt:
Iterative Abfragen:
Rekursive Abfragen:
Keine DNS-Abfragen:
Iterative Abfragen: 2, 3, 4, 5, 6, 7
Rekursive Abfragen: 1, 8
Keine DNS-Abfragen: 9, 10
Auftrag 2: Vervollständigen Sie folgende Sätze:
Wenn der DNS-Client eine Abfrage dem DNS-Resolver stellt und wartet bis der DNS-Resolver die IP-Adresse der Domain liefert, dann handelt es sich um eine ___________________ DNS-Abfrage.
Wenn der DNS-Client eine Abfrage dem DNS-Resolver stellt und wartet bis der DNS-Resolver die IP-Adresse der Domain liefert, dann handelt es sich um eine rekursive DNS-Abfrage.
Wenn ich mit nslookup direkt bei einem DNS-Server eine Anfrage stelle, dann handelt es sich um eine _______________ DNS-Abfrage.
Wenn ich mit nslookup direkt bei einem DNS-Server eine Anfrage stelle, dann handelt es sich um eine iterative DNS-Abfrage.
Daraus resultiert, dass wir die finale Antwort von zwei Arten von Nameservern erhalten können. Eine direkt vom zuständigen Nameserver der betreffenden Domain oder eine von einem Resolver, der die Abfragen für uns übernimmt.
Auftrag 3: Überprüfen Sie den Unterschied der beiden Antwort-Typen mit nslookup.
Fragen Sie als erstes einen öffentlichen DNS-Resolver. Dadurch führen Sie eine rekursive Anfrage aus:
nslookup www.tbz.ch 8.8.8.8
Nun führen Sie in einem weiteren CMD-Fenster eine direkt Anfrage an den zuständigen Domain-Nameserver aus. Dadurch führen Sie eine iterative Anfrage aus:
nslookup www.tbz.ch 80.67.16.124
Frage: Was für einen Unterschied fällt Ihnen auf?
Bei der rekursiven Antwort erhalten wir ein nicht autorisierende Antwort. Bei der direkten iterativen Abfrage erhalten wir diesen Hinweis nicht. Es ist somit eine autorisierte Antwort.
Frage: Was sagt uns die Information, dass es sich um eine autorisierende Antwort handlet?
Die Antwort dieser DNS-Abfrage stammt vom zuständigen Nameserver der diese Domain verwaltet. Es ist keine Antwort, die über einen dritten Nameserver weitergereicht wurde.
DNS-Zonen
Im Jahr 1987 veröffentlichte die Internet Engineering Task Force (IETF) in ihrer Spezifikation namens RFC 1035 „Domain Names - Implementation And Specification“ den Begriff der DNS-Zone. In diesem Dokument wird der Zusammenhang zwischen Nameservern und DNS-Zonen erläutert.
Alle Informationen zum Thema DNS-Zonen sind im betreffenden RFC-Dokument ersichtlich: https://www.rfc-editor.org/rfc/rfc1035
Der DNS-Namensraum wird durch DNS-Zonen definiert, die von einer spezifischen Organisation oder Person verwaltet werden. Eine Zone ist eine administrative Einheit, die mindestens eine Domain und ggf. weitere Subdomains umfasst. Subdomains können jedoch auch als eigene Zonen konfiguriert werden.
Die Zonendatei, auch als DNS Zone File bezeichnet, ist die technische Grundlage zur Speicherung der DNS Informationen einer Zone. Sie ist eine Textdatei, die auf einem Server gespeichert wird. Der Aufbau einer DNS Zone File ist im bereits erwähnten RFC 1035 definiert. Jede Zone File ist zeilenbasiert strukturiert und enthält je Zeile eine „Directive“ oder einen „Resource Record“.
Auf der untenstehenden Grafik ist ersichtlich, dass jeder Teil des DNS-Namespaces über eine eigene Zonen-Datei verfügt. Die Root-Zone enthält eine eigene Zonendatei. In dieser Datei sind die DNS-Einträge vorhanden, welche auf die Nameserver für die Top-Level-Domains verweisen. So ist z. B. ein Verweis auf die Nameserver der TLD .ch enthalten.
Die Nameserver der Top-Level-Domains enthalten wiederum eine eigene Zonendatei, in der die Nameserver-Informationen aller untergeordneten Domains enthalten sind. Die Zonendatei der .ch-Zone enthält somit alle .ch Domains wie tzb.ch, google.ch, coop.ch u.s.w.
Die eigentlichen DNS-Information von tbz.ch liegen dann in der Zonendatei von tbz.ch. Darin enthalten sind all die DNS-Informationen für die verschiedenen Hosts wie www.tbz.ch und mail.tbz.ch. In gewissen Fällen sind Subdomains in eigenen Zonendateien ausgelagert und die Zonendatei der übergeordneten Zone enthält einen Verweis für diese Subdomain.
Auftrag 1: Die Zonendatei der Root-Zone ist öffentlich einsehbar. Es handelt sich genau im jene Datei, welche auf allen 13 Root-Nameserver (inkl. deren Spiegelungen) verteilt ist.
https://www.iana.org/domains/root/files
Öffnen Sie das Root Zone File (HTTP) und suchen Sie darin die Informationen zur .CH Zone. Wie lauten diese?
ch. 172800 IN NS a.nic.ch.
ch. 172800 IN NS b.nic.ch.
ch. 172800 IN NS d.nic.ch.
ch. 172800 IN NS e.nic.ch.
ch. 172800 IN NS f.nic.ch.
ch. 86400 IN DS 10 13 2 0E175543A74D9083EA977BAB2BEE98A771995F80982FB796B2B0B9CC6413D1A6
ch. 86400 IN RRSIG DS 8 1 86400 20221227050000 20221214040000 18733 . D39MuhB3NqrjbpFLj+L/Guws9+ROsLIBe6AuD1uf3X4s2k+YHgzGKZPVzRwNc97cjY5l6lbubSWMc50mtCyDCEoMYgQHl3GpinKitY2r6AWGJejYcgDl6M7Q0YJdCO9AX3gbGEXw0ixIBoALgXxB3/GYF0nfM1vmgBW3qCFL14ruj691UgtD/rb0f1RpFCrFSF4EuNL5F/P+v1spPpoAmrVbiovdTy6GejvLJlnpZ96y+Leg9te1J61MUl/Hh6gFrBNB6zBl+wLl2gOrup8ajxiC5IGEDRl/5gisb9mA7gkAz/psNCSakKlqR51qxCf/fS+a48t4Ma0j/9SMQUbRag==
ch. 86400 IN NSEC chanel. NS DS RRSIG NSEC
ch. 86400 IN RRSIG NSEC 8 1 86400 20221227050000 20221214040000 18733 . 3IKglUDT/CBlMwfkSP9MdNLARS1UyZWNgj41TAftS0hB4ZIappbJgTEhQpFNssjAVipHC6wGodv5sZkJ/SLUDZb8AGZAh6O66X58SONmx0LDBmLj5vpzCi+ivQHB89whi1En18y/92INeZW0lx8eEWD4XaZSqveu/EidN4qyDLpdKin3acsY1wAV8+3TL7cRAkCEnRB7B5xJshZH7DThUyUb3tdok4Kw8Csi6XSiGlFW30JfLeX+1bla7HwcbfyzMbDnawt2lfMKVzI9quGVvoykgSiSMHO/idGfiH44fSWOtt7nkQh8lQLqQfirvr5amKepEyIGm1HCgdpq32Xk2A==
ns.itu.ch. 172800 IN A 156.106.192.121
ns.itu.ch. 172800 IN AAAA 2a00:7580:60:2141:0:0:0:10
a.nic.ch. 172800 IN A 130.59.31.41
a.nic.ch. 172800 IN AAAA 2001:620:0:ff:0:0:0:56
b.nic.ch. 172800 IN A 130.59.31.43
b.nic.ch. 172800 IN AAAA 2001:620:0:ff:0:0:0:58
d.nic.ch. 172800 IN A 194.0.25.39
d.nic.ch. 172800 IN AAAA 2001:678:20:0:0:0:0:39
e.nic.ch. 172800 IN A 194.0.17.1
e.nic.ch. 172800 IN AAAA 2001:678:3:0:0:0:0:1
f.nic.ch. 172800 IN A 194.146.106.10
f.nic.ch. 172800 IN AAAA 2001:67c:1010:2:0:0:0:53
Die Root-Zone wird von der Organisation IANA verwaltet. https://www.iana.org/domains Sämtliche Anpassung an der Zone werden von dieser Organisation koordiniert. Berechtigt für Änderungen sind alle Betreiber einer Top-Level-Domain wie z. B. die SWITCH für .ch und die DENIC für .de.
Auftrag 2: Auch die Zonendatei der .CH Zone kann öffentlich abgerufen werden. Diese ist mit rund einem Gigabyte aber wesentlich grösser und enthält mit rund 11 Millionen Einträge, wesentlich mehr Informationen als die Root-Zone.
Nicht jede Zone einer TLD ist öffentlich einsehbar. Dies hängt ganz von der Organisation ab, welche die betreffende Zone betreut.
Frage: Auf welchen Nameservern ist die Zonendatei der .CH Zone genau abgelegt? Geben Sie mindestens 3 Nameserver an. (Tipp: Insgesamt sind es 5 Nameserver auf denen die Datei abgelegt ist)
a.nic.ch. 172800 IN A 130.59.31.41
b.nic.ch. 172800 IN A 130.59.31.43
d.nic.ch. 172800 IN A 194.0.25.39
e.nic.ch. 172800 IN A 194.0.17.1
f.nic.ch. 172800 IN A 194.146.106.10
Auftrag 3: Finden Sie heraus, wer für die Betreuung der .CH Zone zuständig ist. (Tipp. schauen Sie sich mal die TLD-Nameserver von .CH an) Wie müssen Sie vorgehen, wenn Sie eine eigene Domain in der .CH Zone hinterlegt haben möchten?
In der Schweiz ist die Organisation SWITCH für die Verwaltung zuständig.
Möchte man eine Domain in der .CH Zone hinterlegt haben, so muss man die gewünschte Domain zu erst kaufen (registrieren). Der Reigstrar hinterlegt dann die gewünschten Nameserver-Informationen in der .CH Zone.
Die Zonen-Datei der .CH Zone ist mit einem Gigabyte wesentlich grösser als die Zonendatei der Root-Zone. Aus diesem Grund ist die nachfolgende Aufgabe freiwillig.
Auftrag optional:
Diesen Auftrag schauen wir uns in der Klasse gemeinsam am Beamer an.
Laden Sie die Zonen-Datei hier herunter und öffnen Sie diese in einem geeigneten Editor. Manche Editoren kommen mit der grossen Dateigrösse nicht zurecht. Der Editor Visual Studio Code funktioniert jedoch recht gut.
Öffnen Sie die Datei uns suchen Sie die Informationen zur Domain tbz.ch. Wie lauten diese:
tbz.ch. 3600 IN NS ns1.hosting.ch.
tbz.ch. 3600 IN NS ns2.hosting.ch.
Nehmen Sie sich 5 Minuten Zeit und stöbern Sie etwas in der Zonen-Datei. Können Sie anhand der Daten ungefähr herausfinden wie viele Tennic-Clubs (tc-) es in der Schweiz gibt, was die Migros (migros) alles für Domains verwendet oder es Domains mit Ihrem Namen gibt.
Frage: Wie finden Domains mit Umlauten (äöü) oder z. B. Emojis ✌️ in der Zonen-Datei? Denken Sie an die letzte Übung mit den Domain-Namen.
Wenn die Domain mit xn-- beginnt, wird diese ein Sonderzeichen oder Emoji enthalten.
Die Zone einer Domain
Die Zone einer spezifischen Domain ist in der Regel nicht öffentlich einsehbar, da diese mitunter sensible Informationen enthalten kann. Sie sehen aber nun nachfolgend ein Beispiel, wie die Zonendatei der DNS-Zone von tbz.ch aussehen könnte:
$TTL 600
@ IN SOA ns1.hosting.ch hostmaster.tbz.ch. (
2125762 ; Serial
604800 ; Refresh Time
86400 ; Retry Time
2419200 ; Expire Time
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.hosting.ch.
@ IN NS ns2.hosting.ch.
@ IN A 149.126.4.25
@ IN MX tbz-ch.mail.protection.outlook.com.
@ IN TXT "MS=ms26028428"
@ IN TXT "0hh6wyw3v2cqrtmmmyv7lfhpx5xtnsy3"
@ IN TXT "v=spf1 a:edge-mta001.tam.ch a:edge-mta002.tam.ch ip4:91.250.83.194 ip4:80.74.157.0/24 include:spf.protection.outlook.com a:mail01.refline.ch a:mail02.refline.ch -all"
intranet IN CNAME intranet.tam.ch.
www IN CNAME s016.cyon.net.
Der erste Block von Zeile 1 bis Zeile 8 enthält den SOA-Eintrag mit den grundlegende Zonen-Informationen. Dieser Eintrag steuert wie lange die Datei im Cache bleiben darf und wie die Regeln bei einem Sync zwischen einem Primary- und Secondary-Nameserver sind. Dies wird gemacht, wenn zwei Nameserver zur besseren Redundant existieren und die Daten zwischen den beiden Nameservern abgeglichen werden müssen. Dies ist aber nicht teil dieses Moduls, hier arbeiten wir der Einfachheit halber nur mit einem Nameserver.
-
- TTL (Time to live): Die Dauer wie lange diese Zone von einem DNS-Client oder Resolver darf im Cache behalten werden. Je kürzer diese TTL gehalten ist, desto schneller propagieren Änderungen an der DNS-Zone, jedoch verursacht dies auch eine höhere Last auf dem Server.
-
- Primary Master für diese Zone (ns1.hosting.ch):
- er definiert, an wen dynamische Updates gesendet werden sollen (siehe: Dynamisches Update)
- er gibt an, an wen keine Notifies gesendet werden (siehe: Zonentransfer)
- Primary Master für diese Zone (ns1.hosting.ch):
- RNAME (hostmaster.tbz.ch): Mail-Adresse des Verantwortlichen für diese Zone. (Das
@wird durch.ersetzt. Punkte vor dem@werden durch\.ersetzt; beispielsweisemax\.mustermann.wikipedia.orgfür die E-Mail Adressemax.mustermann@wikipedia.org) -
- Serial: Seriennummer, die bei jeder Änderung um den Wert ein erhöht wird (vorzugsweise JJJJMMTTVV; dient als Hinweis, wann die Zone zuletzt aktualisiert wurde)
-
- REFRESH: Sekundenabstand, in dem sekundäre Nameserver die Seriennummer vom primären Master abfragen sollen, um Änderungen der Zone festzustellen. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 86400 ≙ 24 Stunden.
-
- RETRY: Sekundenabstand, in dem, bei ausbleibender Antwort des Masters, sekundäre Nameserver nochmals seine Seriennummer abfragen sollen. Dieser Wert muss kleiner als jener zum Refresh sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 7200 ≙ 2 Stunden.
-
- EXPIRE: Sekundenabstand, nach dem bei ausbleibender Antwort des Masters sekundäre Nameserver keine Antworten über die Zone mehr geben sollen. Dieser Wert muss größer als die Summe jener zum Refresh und Retry sein. Empfehlung vom RIPE NCC für kleine und stabile Zonen: 3600000 ≙ 1000 Stunden.
Nun folgen auf den Zeilen 9 bis 17 die DNS-Informationen der Zone tbz.ch. Beachten Sie die Regeln auf folgender Wikipedia-Seite zum Aufbau der DNS-Informationen:
https://de.wikipedia.org/wiki/Zonendatei
Ein einzelner DNS-Eintrag ist jeweils wie folgt aufgebaut:
Auftrag: Recherchieren Sie nun die Bedeutung der folgenden Ressource-Typen (TYPE).
A:
Der A-Eintrag verweist auf eine IPv4 Adresse
AAAA:
Der AAAA-Eintrag verweist auf eine IPv6 Adresse
CNAME:
Der CNAME-Eintrag (Canonical Name) verweist auf einen anderen DNS-Eintrag z. B.
tbz.ch IN A 149.126.4.25
www.tbz.ch IN CNAME tbz.ch
Der Eintrag www.tbz.ch verweist auf tbz.ch, welcher wiederum auf die IP-Adresse 149.126.4.25. Somit verweist der DNS-Eintrag www.tbz.ch auf die IP-Adresse 1459.126.4.25
MX:
Der MX-Eintrag (Mail Exchange) verweist auf den Hostnamen (nicht die IP-Adresse) eines Mailservers. Der MX-Eintrag wird somit nur von Mailservern abgefragt. Hat der Mailserver nur eine IP-Adresse, so muss ein A-Eintrag erstellt werden, auf den der MX-Eintrag verweisen kann. z .B
tbz.ch IN MX mail.tbz.ch.
mail.tbz.ch IN A 104.47.11.74
TXT:
Der TXT-Eintrag beinhaltetet eine Text-Information. Diese wird in der DNS-Zone hinterlegt und kann z. B. zur Domainbasierten Verifikation oder Bereitstellung zusätzlicher Informationen wie SPF und DKIM verwendet werden.
Auftrag 0002
Der Auftrag
Die Firma HighEnd Elektro AG möchte einen eigenen DNS-Resolver für das Unternehmen verwenden, damit man diesbezüglich nicht von einen anderen Unternehmen abhängig ist. Das Unternehmen hat bereits vor ein paar Jahren die gesamte Server-Infrastruktur in die Cloud ausgelagert und verfügt über keine lokale Server-Infrastruktur mehr. Aus diesem Grund soll die Installation und der Betrieb komplett von Ihrer Firma bereitgestellt werden. Die HighEnd Elektro AG stellt konkrete Anforderungen, welche der DNS-Resolver erfüllen muss:
- Der DNS-Resolver muss grundsätzlich von überall her für die Mitarbeiter aus dem Internet erreichbar sein.
- Der DNS-Resolver darf nicht als öffentlicher DNS-Resolver fungieren, aus diesem Grund darf der DNS-Resolver nur Anfragen aus folgenden Netzwerken beantworten
- 31.10.147.0/24
- 80.74.144.0/24
- Ihr eigenes Netz bez. IP-Adresse von dem Sie arbeiten.
- Der DNS-Resolver soll neben der reinen Resolving-Funktion auch noch weitere Aufgaben übernehmen. So hat das Unternehmen eine Intranet-Webseite mit der IP 80.74.136.2. Diese soll über über den Domain-Namen high-end.intern erreichbar sein, wenn der DNS-Resolver verwendet wird.
- Das Unternehmen möchte, dass gewisse Domains aus dem Unternehmen heraus nicht aufgerufen werden können und daher vom Resolver blockiert werden. Es handelt sich hierbei um folgende Domains:
- facebook.com (ink. www)
- youtube.com (ink. www)
- tiktok.com (ink. www)
- instagram.com (ink. www)
Um die Wartbarkeit des Systems zu gewährleisten, wird eine vollständige technische Dokumentation erwartet. Diese beinhaltete ein Dokumentation des Installations-Vorgangs, die relevanten Konfigurationen sowie ein Test-Protokoll, welches die Funktionstüchtigkeit des Systems bei der Übergabe belegt.
Erwartete Abgabe
Folgende Abgaben werden erwartet:
- Vollständig installierter und getesteter DNS-Server
- Sämtliche relevanten Konfigurationen vom DNS-Server im Format .txt
- Technische Dokumentation gem. Vorlage als Word oder PDF:
Vorführung im Unterricht
In der Unterrichtswoche nach der Abgabe, wird jede Gruppe das System kurz präsentieren. Dabei wird getestet, ob die wichtigsten Funktionen erfüllt werden. Weiter wird jedes Mitglied der Gruppe ein bis zwei Fragen zur Umsetzung des Systems beantworten müssen.
Formalitäten
Bei voller Zufriedenheit der Arbeit erwartet Sie einen Lohn von CHF 9000.
Der Zeitaufwand für die Arbeit beträgt ungefähr 3 bis 4 Lektionen.
DNS Server installieren
In dieser Übung werden Sie einen DNS-Server installieren und konfigurieren. Hierzu werden Sie auf der AWS Academy Lab-Umgebung einen virtuellen Server (EC2 Instanz) starten. Auf diesem virtuellen Server werden Sie den weitverbreiteten Open-Source DNS Server Bind installieren.
Sicherheitsgruppe erstellen
Als erstes muss in AWS eine Sicherheitsgruppe erstellt werden. Mit dieser Sicherheitsgruppe wird die Firewall des Servers konfiguriert. Hierbei ist es wichtig, dass wir den eingehenden Datenverkehr für DNS-Pakete zulassen.
- Starten Sie die AWS Academy Lab-Umgebung.
- Klicken Sie auf Services -> Datenverarbeitung um die EC2 Übersicht zu öffnen.
- Klicken Sie in der Gruppe Ressourcen auf Sicherheitsgruppen um zur Übersicht mit den Sicherheitsgruppen zu gelangen.
- Klicken Sie auf den orangen Button Sicherheitsgruppe erstellen.
- Wählen Sie einen passenden Namen wie z. B. DNS-Server. Diese Sicherheitsgruppe können Sie dann für alle DNS-Server verwenden, welche Sie in der AWS-Umgebung erstellen. Setzen Sie ebenfalls eine aussagekräftige Beschreibung wie "Gewaehrt den Zugriff fuer DNS-Dienste von extern" (Sonderzeichen sind nicht erlaubt)
- Klicken Sie nun unter Regeln für eingehenden Datenverkehr auf Regel hinzufügen.
- Fügen Sie nun drei Regeln hinzu. Jeweils eine für DNS (TCP), DNS (UDP), und SSH. Setzen Sie bei allen drei Regeln die erlaubte Quelle auf Anywhere IPv4:
- Bei Regeln für ausgehenden Datenverkehr sollte bereits eine Regel existieren für den gesamten Datenverkehr. Diese können Sie so belassen:
- Bestätigen Sie nun mit dem orangen Button Sicherheitsgruppe erstellen
VM anlegen
Nun können Sie als nächsten Schritt eine neue Virtuelle Maschine (EC2 Instanz) anlegen:
- Wechseln Sie wieder in das EC2-Dashboard. Alternativ können Sie im Menü aber auch direkt zu Instances wechseln:
- Klicken Sie nun auf den Button Instance starten:
- Wählen Sie einen passenden Namen für Ihren DNS Server.
- Wählen Sie nun Amazon Linux als Server Image aus:
- Wählen Sie den Instanz-Typ t2.medium aus.
- Wählen Sie Ihren vorgängig erstellten Gruppen-SSH-Key aus, damit dieser bei der EC2-Instanz hinterlegt wird.
- Nun können Sie im Abschnitt Netzwerk-Einstellungen die zuvor erstellte Sicherheitsgruppe hinzufügen.
- Weisen Sie der EC2-Instanz eine statische IP-Adresse zu.
Statische IP-Adresse zuweisen
Standardmässig erhält eine VM keine statische IP-Adresse in AWS. Bei jedem Neustart einer Instanz wird dynamisch eine neue IP-Adresse zugewiesen. Dies ist bei einem Server ungünstig, da dieser immer unter der selben IP-Adresse erreichbar sein sollte. Statische IP-Adressen bei AWS sind eine kostenpflichtige Dienstleistung. Aus diesem Grund müssen Sie nun zu erst eine statische IP-Adresse erstellen und diese dann der erstellten VM zuweisen.
Verbindung mit einem SSH-Client
Es ist am bequemsten per SSH auf einem Server zu arbeiten. Dazu haben Sie ein lokales Terminal auf Ihrem Gerät, welches eine SSH-Verbindung zum Server aufbaut.
Das kryptographische Netzwerkprotokoll Secure Shell (SSH) ermöglicht es, Netzwerkdienste über unsichere Netzwerke sicher zu betreiben. Mit SSH kann man eine lokale Kommandozeile auf einen entfernten Rechner setzen, auf welchem dann die Ausgaben der entfernten Konsole angezeigt und lokale Tastatureingaben an den entfernten Rechner gesendet werden. Dadurch kann man z. B. einen Server, der in einem entfernten Rechenzentrum steht, fernwarten. Mit der neueren Protokollversion SSH-2 sind weitere Funktionen wie die Datenübertragung per SFTP verfügbar.
Sie dürfen natürlich jedes Terminal verwenden. Diese Anleitung zeigt die Konfiguration anhand vom Tabby Terminal. Es ist aber auch möglich die Verbindung mit Putty oder einem
- Laden Sie die Software Tabby Terminal von folgender Seite herunter und installieren Sie diese: https://tabby.sh
Laden Sie die Version tabby-1.0.187-setup-x64.exe herunter. - Starten Sie die Software und öffnen Sie die Einstellungen. Navigieren Sie dort zu Profiles & connections und fügen Sie ein neues Profil hinzu:
- Sie müssen nun ein Basis-Profil als Vorlage auswählen. Nehmen Sie hier SSH connection:
-
Nun tragen Sie ihre öffentliche IP-Adresse (44.194.159.38 ist nur ein Beispiel) sowie den Port 22 ein. Als Benutzername setzen Sie ec2-user. Als Authentifizierungs-Methode Wählen Sie Key. Nun können Sie über den Button Add a private key den Gruppenschlüssel hinzufügen. - Wählen Sie hier den Grupenschlüssel, welchen Sie vom Gruppenleiter erhalten haben sollten:
- Speichern Sie das Profil und starten Sie anschliessend die Verbindung:
- Möglicherweise müssen Sie nun den Host-Fingerprint bestätigen. Speichern Sie den Fingerprint und fahren sie fort.
- Die Verbindung sollte nun möglich sein und Sie sollten den Willkommens-Bildschirm sehen:
DNS Server (Bind) installieren
- Verbinden Sie sich per SSH von Ihrem lokalen Terminal auf den Server.
- Wechseln Sie direkt in den Administrator-Modus mit sudo su
-
Installieren Sie nun über die Paketverwaltung yum die Software bind:
yum install bindYum wird Ihnen dann eine Auflistung der zu installierenden bind-Version inkl. aller Abhänigkeiten anzeigen. Bestätigen Sie die Installation indem Sie y eintippen.
Install 1 Package (+8 Dependent packages) Total download size: 4.2 M Installed size: 11 M Is this ok [y/d/N]: ySie können nachvollziehen, wie yum nun die Software bind installiert.
- Verifizieren Sie nun, dass bind installiert ist. Mit dem Befehl yum list installed können Sie eine Liste aller installierte Softwarepakete einsehen:
yum list installedSie sehen nun eine Liste mit allen installierten Softwarepaketen
# yum list installed Loaded plugins: extras_suggestions, langpacks, priorities, update-motd Installed Packages GeoIP.x86_64 1.5.0-11.amzn2.0.2 installed PyYAML.x86_64 3.10-11.amzn2.0.2 installed acl.x86_64 2.2.51-14.amzn2 installed acpid.x86_64 2.0.19-9.amzn2.0.1 installed amazon-linux-extras.noarch 2.0.1-1.amzn2 installed amazon-linux-extras-yum-plugin.noarch 2.0.1-1.amzn2 installed amazon-ssm-agent.x86_64 3.1.1732.0-1.amzn2 installed [...]Wie Sie sicherlich bemerkt haben, ist die Liste sehr lange. Aus diesem Grund werden Sie nun den Output mit dem Befehl grep nach bind filtern. Hierzu fügen Sie hinter dem bereits bestehenden Befehl einen weiteren Befehl an, mit dem Zeichen | übergeben Sie die Ausgabe aus dem vorhergehenden Befehl an den nachfolgenden.
yum list installed | grep bindSie erhalten nun eine List, welche nach dem Stichwort bind gefiltert ist.
Nun ist die Liste etwas übersichtlicher.# yum list installed | grep bind bind.x86_64 32:9.11.4-26.P2.amzn2.5.2 @amzn2-core bind-export-libs.x86_64 32:9.11.4-26.P2.amzn2.5.2 installed bind-libs.x86_64 32:9.11.4-26.P2.amzn2.5.2 installed bind-libs-lite.x86_64 32:9.11.4-26.P2.amzn2.5.2 installed bind-license.noarch 32:9.11.4-26.P2.amzn2.5.2 installed bind-utils.x86_64 32:9.11.4-26.P2.amzn2.5.2 installed rpcbind.x86_64 0.2.0-44.amzn2 installed
Nun ist die Software bind installiert. Im nächsten Kapitel werden Sie den Dienst starten und die Konfiguration genauer unter die Lupe nehmen.
Verwendete Befehle
yum: Mit der Paketverwaltung yum können Sie ganz einfach Software auf Ihrem RHEL-Basierten Linux installieren (rhel, centos, Amazon linux, fedora). Yum organisiert die Software in sogenannten Repositories. Dies sind Verzeichnisse, in denen bekannte Software zur Verfügung gestellt wird. In den Standard-Repositories sind die am meisten verwendeten Softwarepakete vorhanden. Weiter können aber zusätzliche Software-Repositories eingebunden werden, damit auch eine spezielle Software installiert werden kann. Im Rahmen dieses Moduls ist dies aber nicht nötig.
yum stellt eine Reihe von befehlen zur Verfügung, um Software auf dem Serverzu verwalten:
- yum list <pakete> Liste der installierten und verfügbaren Paketen <pakete>
- yum list all Liste aller installierten und verfügbaren Pakete
- yum list available <pakete> Liste aller verfügbaren und installierbaren Pakete
- yum list updates <pakete> Liste aller verfügbaren Pakete <pakete> , die aktueller als die installierten sind
- yum list installed <pakete> Liste aller installierten Pakete <pakete>
- yum info <pakete> Kurzbeschreibung zu installierten und verfügbaren Paketen <pakete>
- yum search <zeichenkette> Paketnamen und Beschreibungen durchsuchen nach <zeichenkette>
- yum install <pakete> Installiere die aktuelleste Version der Pakete <pakete> (inkl. der abhängigen!)
- yum check-update gibt es aktuellere Pakete in den Repos?
- yum update aktualisiere alle z.Z. installierten Pakete
- yum update <pakete> aktualisiere die Pakete <pakete> (inkl. der abhängigen!)
- yum erase <pakete> deinstalliere Pakete <pakete> (inkl. aller abhängigen Pakete!)
- yum remove <pakete> deinstalliere Pakete <pakete> (inkl. aller abhängigen Pakete!)
In anderen Linux-Distributionen kommen andere Paketverwaltungen zum Einsatz. Debian derivate (debian, ubuntu, kali linux) haben mit apt-get ein sehr ähnliches Tool zur Verfügung.
grep: Der Befehl grep ist ein Linux-Befehl, der dazu verwendet wird, um Zeichenfolgen in Textdateien zu suchen. Es durchsucht Dateien nach bestimmten Zeichenketten, die angegeben wurden, und gibt alle Zeilen zurück, in denen es die angegebene Zeichenfolge gefunden hat. Es kann auch dazu verwendet werden, um einzelne Dateien oder mehrere Dateien nach den angegebenen Zeichenketten zu durchsuchen.
pipe: Dies ist ein Begriff, der sich aus dem englischen Wort "Pipeline" ableitet, was übersetzt so viel wie "Rohrleitung" bedeutet. Unter Linux bildet eine Pipe einen Datenstrom zwischen zwei Prozessen, die nicht immer miteinander verbunden sind. Dies bedeutet, dass das Ergebnis (Ausgabe) eines Programms als Eingabe für ein anderes Programm genutzt werden kann. Dadurch können größere Aufgaben in kleinere Teilaufgaben aufgeteilt werden, um eine bessere Übersicht zu erhalten.
Konfiguration von Bind
Wir schauen uns nun die Konfiguration von Bind an. Konfigurationen unter Linux sind in der Regel einfache Text-Dateien, welche die nötigen Anweisungen für die Software enthalten.
Grundkonfiguration
Die Konfiguration des BIND-Servers erfolgt über das Verzeichnis /etc. Nach der Installation sollten sich hier folgende Dateien finden:
named.conf
named.iscdlv.key
named.rfc1912.zones
named.root.key
Der Prozess von BIND ist als named bekannt. Daher beziehen sich viele der Dateien auf "named" anstelle von "BIND".
Die Datei named.conf ist die Haupt-Konfiguration von Bind. Öffnen Sie die Konfiguration nun mit dem Befehl nano.
Sie werden nun feststellen, dass die Konfiguration für Bind in gewissen Gruppen zusammengefasst ist, welche durch geschweifte Klammern { } umschlossen werden. In der Gruppe options finden Sie die Grundkonfigurationen.
| Zeile | Bedeutung |
| listen-on port 53 { 127.0.0.1; }; | Definiert auf welcher IP-Adresse und welchem Port der DNS-Server eingehende Verbindungen annehmen soll. Bei 127.0.0.1 handelt es sich um die localhost Adresse des Servers, der Dienst wird daher nur Verbindungen vom eigenen Server annehmen. |
|
listen-on-v6 port 53 { ::1; };
|
Dasselbe gibt es auch in einer separaten Variante für IPv6 |
|
allow-query { localhost; };
|
Definiert, wer (welche IP-Adresse) eine DNS-Abfrage stellen darf. Standardmässig ist der Wert auf localhost gesetzt. Der Dienst wird daher nur DNS-Abfragen vom eigenen Server beantworten. |
|
directory
|
In dem angegeben Verzeichnis werden die Dateien mit den DNS-Informationen (Zonen) abgelegt. |
|
recursion yes;
|
Definiert ob der Server rekursive DNS-Abfragen bearbeitet oder nicht. Standardmässig ist diese Option auf yes wodurch der Dienst als DNS-Resolver fungiert. Soll der Dienst nur als authoritativer Nameserver arbeiten, dann muss diese Option auf no gesetzt werden. |
Die grundlegenden Einstellungen sind soweit in Ordnung. Es muss aber eine Einstellung angepasst werden, damit der DNS-Server Anfragen von unserer IP-Adresse überhaupt annimmt.
Im Kontext von Einstellungen unter Linux spricht man bei den einzelnen Einstellungsmöglichkeiten von Direktiven.
- Die listen-on Direktive ist derzeit auf 127.0.0.1 gesetzt. Aus diesem Grund nimmt der DNS-Server keine Verbindungen von extern an. Um das zu ändern, setzen Sie die Direktive auf any. Den Port 53 können Sie belassen, da dies der Standard-Port für DNS ist:
listen-on port 53 { any; };
Damit ist die Basis-Konfiguration abgeschlossen. Im nächsten Schritt werden wir nun eine DNS-Zone einrichten.
Starten des Dienstes
Bis jetzt ist der DNS-Dienst noch nicht gestartet. Mit dem Befehl systemctl können wir einen Dienst steuern:
systemctl enable named Aktiviert den Dienst und trägt diesen im Autostart ein
systemctl enable named Deaktiviert den Dienst und entfernt diesen aus dem Autostart
systemctl start named Startet den Dienst
systemctl stop named Stoppt den Dienst
systemctl restart named Startet den Dienst neu
Verschaffen Sie sich einen weitergehenden Überblick über systemctl und wie damit ein Dienst verwaltet werden kann auf folgender Seite: https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units-de
Hilfe Hilfe, der Dienste startet nicht!
Bei fehlerhaften Konfigurationen kann es sein, dass ein Serverdienst nicht starten kann. Hier gibt es verschiedenen Möglichkeiten die Ursache zu finden. Nachfolgend ist eine Meldung ersichtlich, dass der Dienst named (bind) nicht gestartet werden konnte:
# systemctl start named.service
Job for named.service failed because the control process exited with error code. See "systemctl status named.service" and "journalctl -xe" for details.
Möglichkeit 1: Systemctl gibt Ihnen einen kurzen Auszug der letzten Informationen aus dem Log zurück mit systemctl status named.service. Dies sieht wie folgt aus:
# systemctl status named.service
● named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2022-12-14 15:10:12 UTC; 9s ago
Process: 4379 ExecStop=/bin/sh -c /usr/sbin/rndc stop > /dev/null 2>&1 || /bin/kill -TERM $MAINPID (code=exited, status=0/SUCCESS)
Process: 4317 ExecReload=/bin/sh -c /usr/sbin/rndc reload > /dev/null 2>&1 || /bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS)
Process: 3093 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS)
Process: 4390 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z "$NAMEDCONF"; else echo "Checking of zone files is disabled"; fi (code=exited, status=1/FAILURE)
Main PID: 3095 (code=exited, status=0/SUCCESS)
Dec 14 15:10:12 ip-172-31-72-77.ec2.internal systemd[1]: Starting Berkeley Internet Name Domain (DNS)...
Dec 14 15:10:12 ip-172-31-72-77.ec2.internal bash[4390]: /etc/named.conf:62: missing ';' before end of file
Dec 14 15:10:12 ip-172-31-72-77.ec2.internal systemd[1]: named.service: control process exited, code=exited status=1
Dec 14 15:10:12 ip-172-31-72-77.ec2.internal systemd[1]: Failed to start Berkeley Internet Name Domain (DNS).
Dec 14 15:10:12 ip-172-31-72-77.ec2.internal systemd[1]: Unit named.service entered failed state.
Dec 14 15:10:12 ip-172-31-72-77.ec2.internal systemd[1]: named.service failed.
Es wird ersichtlich, dass in auf der Zeile 62 in der Datei /etc/named.conf wohl ein Zeichen fehlt.
Möglichkeit 2: Manchmal möchten Sie auch das gesamte Log einsehen. Bind loggt standardmässig alle Informationen in das Log /var/log/messages. Hier können Sie einfach nach dem Stichwort named suchen:
# grep named /var/log/messages
Dec 14 15:09:15 ip-172-31-72-77 named[3095]: received SIGHUP signal to reload zones
Dec 14 15:09:15 ip-172-31-72-77 named[3095]: loading configuration from '/etc/named.conf'
Dec 14 15:09:15 ip-172-31-72-77 named[3095]: /etc/named.conf:62: missing ';' before end of file
Dec 14 15:09:15 ip-172-31-72-77 named[3095]: reloading configuration failed: failure
Auch hier ist die Ursache ersichtlich.
Möglichkeit 3: Bind bietet ein Tool, dass uns erlaubt eine Konfiguration auch zu testen bevor man einen Neustart vornimmt. Mit named-checkconf kann während der Laufzeit geprüft werden, ob ein Konfigurationsfehler vorliegt. So kann dieser Fehler behoben werden, bevor der Dienst neu gestartet wird. So kann ein Ausfall des Dienstes verhindert werden.
# named-checkconf
/etc/named.conf:62: missing ';' before end of file
Diese Möglichkeit funktioniert natürlich nur bei Fehlern, welche durch ein Konfigurationsproblem verursacht werden. Wenn andere Fehler vorliegen wie z. B. zu wenig Speicher oder RAM, dann müssen die Informationsn aus dem Log beigezogen werden.
Zugriffsbeschränkung
Tipp: Testen Sie eine DNS-Abfrage wenn der Dienst jeweils gestartet und beendet ist. Notieren Sie die Unterschiede und halten Sie diese für Ihr Testprotokoll wie auch Troubleshooting-Möglichkeiten in Ihrer Dokumentation fest.
Erhalten Sie beim Testen einen REFUSED Fehler? Wenn ja, dann läuft Ihr DNS-Dienst aber es fehlt noch eine Konfiguration.
Was für eine Fehlermeldung haben Sie erhalten? Welche Option wird dafür verantwortlich sein? Prüfen Sie den Abschnitt Grundkonfiguration.
Tipp: Die Erkenntnisse aus der obigen Fragestellung gehört in die Dokumentation zum Testing und Troubleshooting.
Bind erlaubt es, zu steuern, welchen IP-Adressen eine DNS-Abfrage stellen dürfen. Hierzu kann eine Liste mit erlaubten IP-Adressen angelegt werden. Diese sollte am besten im Verzeichnis /etc/named/ erstellt werden. z. B.
# cat /etc/named/zugriff.acl
acl "erlaubte-ips" {
1.2.3.4;
2.3.4.5;
localhost;
localnets;
};
Ihre derzeitige IP-Adresse können Sie unter https://ip.metanet.ch herausfinden.
Damit diese Zugriffsliste auch verwendet wird, muss diese nun in der Konfiguration /etc/named.conf hinterlegt werden.
Sie können diese ganz unten bei den bestehenden Includes ergänzen:
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/named/zugriff.acl";
Zu guter Letzt, müssen Sie nur noch die Zugriffsliste in der Direktive allow-query angeben:
allow-query { erlaubte-ips; };
Testen Sie anschliessend erneut und halten Sie Ihre Ergebnisse im Dokument fest.
DNS Zonen erstellen
Diese Anleitung beschreibt, wie Sie eine generische DNS-Zone erstellen können. Sie benötigen ggf. mehrere DNS-Zonen um die Anforderungen Ihres Auftrags zu erfüllen. Legen Sie als erstes die nachfolgende Test-Zone an und anschliessend die benötigten DNS-Zonen.
DNS-Zonen
Eine DNS-Zone benötigt zwei Teile:
- Einen Eintrag in der Datei /etc/named.conf, welcher dem DNS-Server mitteilt das eine Zone existiert und was für ein Typ die Zone ist.
- Der eigentliche Inhalt der Zone, welcher als eigene Datei abgelegt ist.
Named.conf
Fügen Sie nun ganz am Ende der Datei /etc/named.conf folgenden Abschnitt ein:
zone "test.tbz" {
type master;
file "/var/named/test.tbz";
};
- Sie teilen damit dem DNS-Server mit, dass nun die Konfiguration für die DNS-Zone test.tbz folgt.
- Dabei setzen Sie den Typ der DNS-Zone mit der Direktive type auf master.
- Mit der Direktive file geben Sie den Pfad zur Datei mit dem Inhalt der DNS Zone an. Diese Datei existiert derzeit noch nicht uns muss im nächsten Schritt von uns angelegt werden.
Bei vielen Zonen wird die Datei named.conf schnell mal unübersichtlich gross. Aus diese Grund empfiehlt es sich hier analog der Zugriffsliste eine separate Datei mit den DNS-Zonen unter /etc/named/ (z. B. /etc/named/dns.zones) zu erstellen und diese mit include einzubinden. Setzen Sie diese Lösung für Ihre benötigten DNS-Zonen um.
Das Zonen-File
Wechseln Sie nun in das Verzeichnis /var/named und erstellen Sie eine neue Datei mit dem Namen test.tbz
In dieser Datei fügen Sie nun den nachfolgenden Inhalt ein:
$TTL 600
@ IN SOA ns1.test.tbz. admin.test.tbz. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.test.tbz.
@ IN A 8.8.8.8
ns1 IN A <IP des DNS-Servers>
Sehen wir uns das Zonen-File etwas genauer an:
- Die TTL (Time to life) definiert, wie lange ein DNS-Resolver die Zonen-Informationen im Cache behalten wird. Eine niedrige TTL wird die Last auf dem Server erhöhen, da ein DNS-Resolver zur Abfrage der selben DNS-Zone mehr Requests stellen wird. Der Wert wird in Sekunden angegeben.
- Der Origin definiert den Namen der DNS-Zone.
- Es folgt ein Block mit den Basis Zonen-Informationen, hier ist vor allem die Serial relevant. Bei der Serial handelt es sich sozusagen um eine Version der Zone, bei jeder Anpassung muss die Serial erhöht werden, damit Slave-DNS-Server eine Änderung in der Zone erkennen können.
DNS-Zone überprüfen.
Ist der Inhalt einer DNS-Zone nicht korrekt, kann der DNS-Dienst nicht mehr gestartet werden. Aus diesem Grund sollte die Zone vor einem Neustart überprüft werden.
named-checkzone test.tbz /var/named/test.tbz
DNS-Zone testen
Verwenden Sie die bekannten Tools um zu testen, ob die von Ihnen angelegten DNS-Zonen funktionieren. Im einen weiterführenden Test, können Sie Ihren Nameserver auch bei Ihrem Windows hinterlegen und die betreffenden Domains aufrufen.
Logging
Abschliessend richten Sie noch die Log-Funktion für den Dienst ein. Das Log enthält alle relevanten Informationen aus dem Betrieb des Dienstes und erlaubt im Nachhinein Fehler nachzuvollziehen.
Passen Sie als erstes den Abschnitt logging in der Datei /etc/named.conf wie folgt an:
logging {
channel default_file {
file "/var/log/named/default.log" versions 3 size 5m;
severity dynamic;
print-time yes;
};
channel resolver_file {
file "/var/log/named/resolver.log" versions 3 size 5m;
severity debug 11;
print-time yes;
};
channel queries_file {
file "/var/log/named/queries.log" versions 3 size 5m;
severity debug 11;
print-time yes;
};
channel database_file {
file "/var/log/named/database.log" versions 3 size 5m;
severity debug 11;
print-time yes;
};
category default { default_file; };
category queries { queries_file; };
category database { database_file; };
category resolver { resolver_file; };
};
Nun müssen die dazugehörigen Log-Dateien erstellt und mit den richtigen Berechtigungen versehen werden:
mkdir -p /var/log/named/
touch /var/log/named/default.log
touch /var/log/named/resolver.log
touch /var/log/named/queries.log
touch /var/log/named/database.log
chown named: /var/log/named/default.log
chown named: /var/log/named/resolver.log
chown named: /var/log/named/queries.log
chown named: /var/log/named/database.log
Anschliessend können Sie den Dienst neu starten und in das Verzeichnis /var/log/named wechseln.
Sie haben nun verschiedene Möglichkeiten, die Informationen in den Logs auszuwerten:
tail -f: Mit dem Befehlt "tail -f" können Sie die Log-Informationen fortlaufend ausgeben. Mit der Tastenkombination CTRL + C können Sie die Ausgabe wieder schliessen.
tail -f /var/log/named/resolver.log
Wenn Sie nur nach den Informationen einer bestimmten Domain suchen, macht es Sinn wenn Sie die Ausgabe mit grep filtern:
tail -f /var/log/named/resolver.log | grep domain.ch
Mit dem * als Wildcard-Zeichen, können Sie auch gleichzeitig mehrere Logdateien ausgeben:
tail -f /var/log/named/*.log
grep: Mit grep können Sie auch direkt innerhalb der Dateien suchen. Damit durchsuchen Sie dann den gesamten Inhalt der betreffenden Logdatei:
grep domain.ch /var/log/named/resolver.log
Mit dem * als Wildcard-Zeichen, können Sie auch gleichzeitig mehrere Logdateien durchsuchen:
grep domain.ch /var/log/named/*.log
Bedeutung Log
- Default: Im Default-Log werden die normalen BIND-Informationen geloggt.
- Queries: Hier werden die eingehenden DNS-Anfragen verzeichnet.
- Database: Hier werden abfragen in die lokale DNS-Datenbank (Cache) verzeichnet.
- Resolver: Hier werden die DNS-Abfragen verzeichnet, welcher der Resolver auf andere DNS-Server macht.
Dokumentation
Notieren Sie in der Dokumentation welche Logs sich wo befinden und was diese bedeuten. Machen Sie ggf. auch ein zwei Beispiele und beschreiben Sie, was im Log aufgezeichnet wird.