Benutzer Diskussion:Khalilalim
DNS
Das Domain Name System (DNS) spielt eine essentielle Rolle in IP-basierten Netzwerken. Seine Hauptaufgabe ist die Beantwortung von Anfragen zur Namensauflösung.
Das DNS funktioniert ähnlich wie eine Telefonauskunft. Der Benutzer kennt die Domain (den für Menschen merkbaren Namen eines Rechners im Internet) – zum Beispiel itw-berlin.net. Diese sendet er als Anfrage in das Internet. Die Domain wird dann dort vom DNS in die zugehörige IP-Adresse (die „Anschlussnummer“ im Internet) umgewandelt – zum Beispiel eine IPv4-Adresse der Form 88.99.60.173 oder eine IPv6-Adresse wie 2a01:4f8:10a:cec::2, und führt so zum richtigen Rechner.
Überblick
- Das DNS ist ein weltweit auf Tausenden von Servern verteilter hierarchischer Verzeichnisdienst, der den Namensraum des Internets verwaltet. Dieser Namensraum ist in sogenannte Zonen unterteilt.
- Hauptsächlich wird das DNS zur Umsetzung von Domainnamen in IP-Adressen (forward lookup) benutzt.
- Dies ist vergleichbar mit einem Telefonbuch, das die Namen der Teilnehmer in ihre Telefonnummer auflöst.
- Das DNS bietet somit eine Vereinfachung, weil Menschen sich Namen weitaus besser merken können als Zahlenketten.#
- Dieser Punkt gewinnt im Zuge der Einführung von IPv6 noch mehr an Bedeutung, denn dann werden einem Namen jeweils IPv4- und IPv6-Adressen zugeordnet.
- So löst sich beispielsweise der Name
www.itw-berlin.netin die IPv4-Adresse88.99.60.173und die IPv6-Adresse2a01:4f8:10a:cec::2auf.
Mit dem DNS ist auch eine umgekehrte Auflösung von IP-Adressen in Namen (reverse lookup) möglich.
- In Analogie zum Telefonbuch entspricht dies einer Suche nach dem Namen eines Teilnehmers zu einer bekannten Rufnummer, was innerhalb der Telekommunikationsbranche unter dem Namen Inverssuche bekannt ist.
Allgemeine Komponenten
Domain-Namensraum
- Baumförmige Struktur
- Blätter und Knoten werden als Labels bezeichnet
- Kompletter Domainname = Verkettung aller Labels eines Pfades
- Labels werden durch Punkt getrennt
- Domainname wird mit Punkt abgeschlossen
Fully Qualified Domain Name (FQDN)
Der vollständige Name einer Domain wird als ihr Fully Qualified Domain Name (FQDN) bezeichnet. Der Domain-Name ist in diesem Fall eine absolute Adresse und darf inklusive aller Punkte maximal 255 Bytes lang sein.
Der FQDN www.itw-berlin.net. ergibt sich durch:
3rd-level-label. | 2nd-level-label. | Top-Level-Domain. | root-label ------------------------------------------------------------------ www . itw-berlin . net .
Ein Domainname wird immer von rechts nach links delegiert und aufgelöst, das heißt je weiter rechts ein Label steht, umso höher steht es im Baum.
.net.itw-berlin.www
root-label. | Top-Level-Domain. | 2nd-level-label. | 3rd-level-label.
------------------------------------------------------------------
. net . itw-berlin . www
Nameserver
- bietet Namensauflösung an
- autoritativ
- verantwortlich für eine Zone
- wird als gesichert angesehen
- Redundanz vorgeschrieben
- primärer Nameserver
- sekundärer Nameserver
- Zonentransfer
- nicht-autoritativ
- bezieht Informationen von anderen Nameservern
- wird als nicht gesichert angesehen
- speichert Informationen im RAM (caching)
- autoritativ
Zusammenarbeit der einzelnen Nameserver
Ein nicht-autoritativer Nameserver bedient sich folgender Strategien um Informationen über andere Teile des Namensraumes zu finden:
- Delegierung
- leitet Anfragen an Subdomain Nameserver weiter
- Weiterleitung (forwarding)
- bei ausserhalb liegenden Namensräumen, Weiterleitung an fest konfigurierten Nameserver
- oder Auflösung über die Root-Nameserver (ausschliesslich Beantwortung iterativer Anfragen)
Resolver
- Resolver sind einfach aufgebaute Software-Module, die auf dem Rechner eines DNS-Teilnehmers installiert sind und die Informationen von Nameservern abrufen können.
- Sie bilden die Schnittstelle zwischen Anwendung und Nameserver.
- Der Resolver übernimmt die Anfrage einer Anwendung, ergänzt sie, falls notwendig, zu einem FQDN und übermittelt sie an einen normalerweise fest zugeordneten Nameserver.
- Ein Resolver arbeitet entweder rekursiv oder iterativ.
rekursiv
- Resolver schickt Nameserver die Anfrage
- kennt der Nameserver die Antwort erhält der Resolver die Antwort direkt, sonst schickt er die Anfrage weiter (s. Zusammenarbeit der einzelnen Nameserver)
- am Ende erhält der Resolver die endgültige ANtwort
iterativ
- Resolver erhält entweder die Antwort vom ersten Nameserver oder den Verweis zum nächsten Nameserver
- in diesem Fall fragt der Resolver den nächsten Nameserver
- dies geschieht so lange, bis er eine Antwort hat
Bekannte Programme zur Überprüfung der Namensauflösung sind nslookup und dig.
Protokoll
- DNS-Anfragen normalerweise per
UDP-Port 53zum Namensserver - bei DNS-UDP-Paketen grösser als 512 Bytes werden die Antworten abgeschnitten
- Client wird dann per Truncate-Flag informiert und kann Anfrage per
TCP-Port 53wiederholen - Zonentransfers immer über
TCP-Port 53, Auslösung aber per UDP.
DNS-Server Raum102
Wir haben für den Schulungsraum 102 einen eigenen DNS-Server aufgesetzt um eine Namensauflösung aller Router, Server und Clients zu ermöglichen.
Die Domain lautet hier raum102.itw. Wie wir dies realisiert haben erläutern wir im weiteren Verlauf.
Konventionen unseres neuen DNS-Servers
Zu Beginn machen wir uns kurz Gedanken wie die Domäne, der Servername und die IP-Adresse lauten sollen.
Weiter sollten wir uns überlegen, welchen Dienst wir hierfür einsetzen möchten.
Primary DNS-Server Domain: raum102.itw Servername: ns1.raum102.itw IP-Address: 10.0.0.3 Alias: nameserver1
Als DNS-Dienst wollen wir bind9 verwenden.
Vorraussetzungen
Betriebssystem aktualisieren
# apt update && apt upgrade
Statische IP setzen
# vi /etc/network/interfaces
# vi /etc/resolv.conf
bind9 installieren
# apt install -y bind9 bind9utils bind9-doc dnsutils
Zonendateien anlegen
Resource Records kurz erklärt
SOA - enthält z.B Seriennummer, Gultigkeitsdauer ...
@ IN SOA ns1.raum102.itw. root.raum102.itw. (
2019092301 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
SOA bedeutet Start of Authority (dt. Beginn der Zuständigkeit) und ist wichtiger Bestandteil einer Zonendatei im DNS. Seriel wird bei jeder Änderung inkrementiert (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. 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. 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. TTL gibt in Sekunden an, wie lange dieser RR in einem Cache gültig sein darf.
NS - Delegierung der Nameserver untereinander
IN NS ns1.raum102.itw.
A - weist einem Namen eine IPv4-Adresse zu ;IP address of Name Server ns1 IN A 10.0.0.3 ;A - Record HostName To Ip Address nfs IN A 10.0.0.140 bup IN A 10.0.0.141 r1 IN A 10.0.0.1 r2 IN A 10.0.0.2
AAAA - weist einem Namen eine IPv6-Adresse zu ;wird hier nicht verwendet
CNAME - verweist von einem Namen auf einen anderen Namen (Alias) ;CNAME record nameserver1 IN CNAME ns1.raum102.itw. fileserver IN CNAME nfs.raum102.itw. backupserver IN CNAME bup.raum102.itw. router01 IN CNAME r1.raum102.itw. router02 IN CNAME r2.raum102.itw.
MX - weist einem Namen einen Mailserver zu (SMTP) ;wird hier nicht verwendet
PTR - weist einer IP-Adresse einen Namen zu (Reverse Lookup) ;Reverse lookup for Name Server 3 IN PTR ns1.raum102.itw. ;PTR Record IP address to HostName 140 IN PTR nfs.raum102.itw. 141 IN PTR bup.raum102.itw. 1 IN PTR r1.raum102.itw. 2 IN PTR r2.raum102.itw.
TXT - kann einem Namen einen frei definierbaren Text zuweisen (Abwehr von Spam) ;wird hier nicht verwendet
Forward lookup Zone anlegen
# vi /etc/bind/fwd.raum102.itw
;
; BIND forward zone file for raum102.itw
;
$TTL 604800
@ IN SOA ns1.raum102.itw. root.raum102.itw. (
2019092301 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;@ IN NS localhost.
;@ IN A 127.0.0.1
;@ IN AAAA ::1
;Name Server Information
IN NS ns1.raum102.itw.
;IP address of Name Server
ns1 IN A 10.0.0.3
;A - Record HostName To Ip Address
nfs IN A 10.0.0.140
bup IN A 10.0.0.141
r1 IN A 10.0.0.1
r2 IN A 10.0.0.2
;CNAME record
nameserver1 IN CNAME ns1.raum102.itw.
fileserver IN CNAME nfs.raum102.itw.
backupserver IN CNAME bup.raum102.itw.
router01 IN CNAME r1.raum102.itw.
router02 IN CNAME r2.raum102.itw.
Reverse lookup Zone anlegen
# vi /etc/bind/rev.raum102.itw
;
; BIND reverse zone file for raum102.itw
;
$TTL 604800
@ IN SOA ns1.raum102.itw. root.raum102.itw. (
2019092301 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;Name Server Information
IN NS ns1.raum102.itw.
;Reverse lookup for Name Server
3 IN PTR ns1.raum102.itw.
;PTR Record IP address to HostName
140 IN PTR nfs.raum102.itw.
141 IN PTR bup.raum102.itw.
1 IN PTR r1.raum102.itw.
2 IN PTR r2.raum102.itw.
Zonendateien einbinden
# vi /etc/bind/named.conf.local
zone "raum102.itw" IN { //domain name (forward zone)
type master; //primary DNS
file "/etc/bind/fwd.raum102.itw"; //forward zone file
allow-update { none; }; //none, because its primary DNS
};
zone "0.0.10.in-addr.arpa" IN { //reverse zone
type master; //primary DNS
file "/etc/bind/rev.raum102.itw"; //reverse zone file
allow-update { none; }; //none, because its primary DNS
};
Konfiguration eines sekundären DNS-Servers
- Um Ausfallsicherheit zu gewährleisten, kann es sinnvoll sein, mehrere DNS-Server zu betreiben.
- Tatsächlich ist es sogar vorgeschrieben, dass eine öffentlich zugängliche Domain von mindestens zwei Servern bedient werden muss.
- Oft sind es sogar fünf oder mehr. In einem privaten Netz kommt man dagegen in der Regel mit einem aus.
- Damit man die verschiedenen Server aber nicht alle einzeln konfigurieren muss, und sich bei routinemäßigen Veränderungen der Zonen Fehler bzw. Abweichungen zwischen den Zonendaten einschleichen, gibt es Zonentransfers.
- Dafür werden die Daten dann immer nur auf einem primären Nameserver angepasst und dieser transferiert die aktuellen Zonendaten dann an einen oder mehrere sekundäre Server weiter, so dass die Daten immer konsistent bleiben.
- Für einen Client macht es keinen Unterschied, ob er mit einem primären oder einem sekundären Server kommunizieret.
Änderungen auf dem primären Server
- Als erstes muss man dem primären Server beibringen, an welche Rechner er die Zonendaten überhaupt übertragen darf.
- Das passiert in der Datei /etc/bind/named.conf.options, wo man irgendwo im durch geschweifte Klammern eingefassten options-Block Folgendes einträgt:
allow-transfer { 192.168.0.200; };
notify yes;
allow-transfer gibt dabei an, welchen Hosts ein Zonentransfer erlaubt werden soll. Die Angabe mehrerer IP-Adressen hintereinander ist möglich, es sollte jedoch unbedingt darauf geachtet werden, dass kein Semikolon fehlt. Die Direktive notify yes gibt an, dass der primäre Server seine Stellvertreter von selbst darauf aufmerksam macht, sobald aktualisierte Zonendateien verfügbar sind.
Nach den Änderungen muss der Dienst neu gestartet werden.
- Die Unterscheidung zwischen alten und neuen Daten erfolgt ausschließlich über die Seriennummer im SOA-Header der Zone.
- Wenn man beim Editieren vergisst, diese zu erhöhen, findet kein Zonentransfer statt und die Slaves arbeiten mit den veralteten Daten weiter.
Einrichtung des sekundären Servers
- Als erstes muss in der Datei named.conf.options eingetragen werden, von welchem Host die Benachrichtigungen kommen werden:
allow-notify { 192.168.0.10; };
- Dann müssen in named.conf.local die Zonen eingetragen werden, für die der Server als Slave agieren soll, und wer sein Meister ist:
zone "domainname" {
type slave;
masters { 192.168.0.10; };
file "back/domainname.bak";
};
zone "0.168.192.in-addr.arpa" {
type slave;
masters { 192.168.0.10; };
file "back/0.168.192.bak";
};
- Die File-Direktiven zeigen in diesem Fall nicht auf existierende Zonendateien, sondern auf den Ort, wo der Server die erhaltenen Zonendaten ablegen soll.
- In diesem Fall im Verzeichnis back im Bind-Homeverzeichnis /var/cache/bind. Da dieses noch nicht existiert, muss es erst passend angelegt werden:
sudo mkdir /var/cache/bind/back sudo chown bind /var/cache/bind/back
- Eigene Zonendateien besitzt ein sekundärer Nameserver nicht.
- Natürlich muss der Dienst auch hier nach der Änderung neu gestartet werden. Getestet werden kann er dann genau wie ein primärer Server.
Syntax der named.conf.* und der Zonendateien überprüfen
# named-checkzone raum102.itw /etc/bind/fwd.raum102.itw zone raum102.itw/IN: loaded serial 20 OK # named-checkzone 0.0.10-in-addr.arpa /etc/bind/rev.raum102.itw zone 0.0.10-in-addr.arpa/IN: loaded serial 20 OK
bind9 Installation abschließen
~# systemctl restart bind9~# systemctl enable bind9~# systemctl status bind9~# vi /etc/resolv.conf-->nameserver 10.0.0.3~# service networking restart
Namensauflösung testen
# dig google.de
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> google.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3983
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: bea27b6c0abfa5c4d5c979555d8b180addb5f0df1c69bfd0 (good)
;; QUESTION SECTION:
;google.de. IN A
;; ANSWER SECTION:
google.de. 300 IN A 172.217.17.35
;; AUTHORITY SECTION:
google.de. 83363 IN NS ns1.google.com.
google.de. 83363 IN NS ns2.google.com.
google.de. 83363 IN NS ns3.google.com.
google.de. 83363 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 168448 IN A 216.239.32.10
ns2.google.com. 168448 IN A 216.239.34.10
ns3.google.com. 168448 IN A 216.239.36.10
ns4.google.com. 168448 IN A 216.239.38.10
ns1.google.com. 168448 IN AAAA 2001:4860:4802:32::a
ns2.google.com. 168448 IN AAAA 2001:4860:4802:34::a
ns3.google.com. 168448 IN AAAA 2001:4860:4802:36::a
ns4.google.com. 168448 IN AAAA 2001:4860:4802:38::a
;; Query time: 20 msec
;; SERVER: 10.0.0.3#53(10.0.0.3)
;; WHEN: Mi Sep 25 09:32:26 CEST 2019
;; MSG SIZE rcvd: 340
DNS Einträgen
- A-Records
stehen für einen Hosteintrag z.B. www. und verweisen auf eine IP Adresse eines Servers z.B. Webserver.
Beispiel: Für die Domain deinedomain.com ist ein A-Record gesetzt, der auf die IP Adresse 77.244.243.2 zeigt.
- AAAA
steht für die gleiche Art von Eintrag wie für den „normalen“ „A“ Record, dieser Eintrag ist jedoch für die Verwendung von IPv6 Adressen vorgesehen. Bei Verwendung von IPv6 hat dieser Eintrag gegenüber dem normalen "A" Eintrag Priorität. Beispiel: Für die Domain deinedomain.com ist ein AAAA-Record gesetzt, der auf die IPv6 Adresse f3b0:1:cb3a:b4b0:7872:5ef9:93bb:e7a2 zeigt.
- ALIAS/ANAME Records
haben den gleichen Zweck wie CNAME Records, sind allerdings technisch anders aufgebaut. Es geht darum der Domain über einen Hostnamen eine IP zuzuordnen. Sie ermöglichen z.B. den Root Record in der Domain auf einen Zielhostnamen zu verweisen.
Beispiel: Für die Domain deinedomain.com ist ein ALIAS-Record gesetzt, der auf den Hostname www.deinedomain.com zeigt.
- CNAME
Dieser DNS Eintrag wird eingesetzt, wenn statt einer IP-Adresse auf den Hostname verwiesen werden soll. CNAME Einträge können im Gegensatz zu ALIAS/ANAME Einträgen nur mit Subdomains verwendet werden. Beispiel: Für die Subdomain test.deinedomain.com ist ein CNAME-Record gesetzt, der auf den Hostname www.deinedomain.com zeigt.
- MX Records
sind dafür zuständig einer Domain einen oder mehrere Mailserver mit Priorität (10, 20, 30 etc.) anzugeben. Der niedrigste Wert steht für den ersten zu verwendenden Mailserver.
Beispiel: Für die Domain deinedomain.com ist ein MX Eintrag gesetzt, der auf den easyname Mailserver mx01.easyname.eu zeigt. NS-Records
- NS Records
werden verwendet um für eine einzelne Subdomain einen Nameserver festzulegen
Beispiel: Für die Subdomain test.deinedomain.com ist ein NS Eintrag gesetzt, der auf den easyname Nameserver ns1.easyname.eu zeigt.
- SRV-Records
ermöglichen die Definition zur Verfügbarkeit von unter einer Domain angebotenen IP-basierter Dienste und werden für die Verwendung bestimmter Dienste und Anwendungen wie beispielsweise SIP/VoIP oder XMPP (Office 365, Jabber, Instant Messaging, etc) benötigt. Du kannst über einen SRV Eintrag bei uns auch den Port sowie das Protokoll angeben. Beispiel: Für _sip._tls.deinedomain.com ist ein SRV Eintrag gesetzt um den SIP Dienst zu verwenden mit dem TLS Protokoll. Dieser Eintrag zeigt auf den Hostname 443 sipdir.online.lync.com.
- TXT-Records
enthalten frei wählbaren Text. Auf einigen Systemen dient der Inhalt dazu, Verwaltungsdaten zu kodieren. TXT-Records werden auch benutzt um einen SPF Eintrag zu erstellen.
Beispiel: Für die Domain deinedomain.com ist ein TXT Eintrag gesetzt mit folgendem Inhalt:"v=spf1 include:spf.easyname.com -all"