1.8 Explain the functions of network services.
Erläutern Sie die Funktionen von Netzwerkdiensten.
Erläutern Sie die Funktionen von Netzwerkdiensten.
DNS Service
Das Domain Name System (DNS) ist einer der wichtigsten Dienste in vielen 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 example.org. 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 192.0.2.42 oder eine IPv6-Adresse wie 2001:db8:85a3:8d3:1319:8a2e:370:7347, und führt so zum richtigen Rechner.
A, AAAA Record
Mit einem A Resource Record wird einem DNS-Namen eine IPv4-Adresse zugeordnet. A Resource Records sind die häufigsten Resource Records im DNS.
Neben der Host-IP-Adressen-Zuordnung werden A RRs auch für DNSBLs oder zur Angabe von Subnetzmasken zu Rückwärtsauflösungen gemäß RFC 1101 verwendet.
Der entsprechende Recordtyp für IPv6 ist AAAA.
Aufbau
Name
veröffentlichter Name
TTL
time to live: gibt an, wie lange in Sekunden dieser Resource Record in einem Cache gültig sein darf (optional; ohne Angabe wird ein zuvor explizit – per $TTL-Anweisung am Anfang der Zonendatei – definierter Standardwert angenommen)
IN
class: Internet (optional; Alternativen sind die Klassen HS für HESIOD und CH für CHAOS, zwei seit langem obsolete, experimentelle Netzwerkprojekte; ohne Angabe wird IN angenommen)
A
Record Type
Length
die Länge des Eintrags, in diesem Fall 4 für die 4 Bytes der IP-Adresse.
Adresse
die IP-Adresse, unter der der gesuchte Server erreichbar ist
Beispiel
www.example.com. 3600 IN A 172.27.171.106
TXT
Ursprünglich erdacht für frei definierbaren und von Menschen lesbaren Text in DNS Einträgen. Seit den frühen 1990ern enthält dieser Eintrag häufig jedoch u. a. auch maschinenlesbare Daten wie in RFC 1464 spezifiziert, Sender Policy Framework (SPF), DomainKeys, DMARC(Domain-based Message Authentication, Reporting and Conformance), DNS-SD und Google-Site Verification.
SPF
Mit einem SPF Resource Record konnte eine Sender Policy (siehe Sender Policy Framework) für einen DNS-Namen definiert werden. Dieser Resource-Record-Typ wurde jedoch im April 2014 widerrufen, da Sender Policies inzwischen weite Verbreitung innerhalb von TXT-Records gefunden hatten und das zuständige Standardisierungsgremium nicht damit rechnete, dass sich ein dedizierter Resource Record durchsetzen würde. Somit ist TXT der einzig standardkonforme RR-Typ für SPF.
Der dedizierte SPF-Record-Typ wird von einigen SPF-Implementierungen und von BIND ab Version 9.4 unterstützt.
Der SPF Eintrag soll das Fälschen der Absenderadresse einer E-Mail verhindern. Es entstand als Verfahren zur Abwehr von Spam. Der Record-Typ ist veraltet und wurde durch TXT ersetzt.
Aufbau
Name
der zu schützende Domain-Name
TTL
gibt an, wie lange der RR im Cache gehalten werden darf
IN
SPF (99)
text
eine Sender Policy entsprechend der SPF-Spezifikation
Beispiel
example.com. 3600 IN SPF "v=spf1 mx -all"
DKIM
DKIM (DomainKeys Identified Mail) ist eine Methode der E-Mail-Authentifizierung. DKIM fügt Ihren Mails eine Signatur hinzu, die Ihrer Domain zugeordnet ist und bei allen ausgehenden E-Mails genutzt wird. Das Verwenden eines DomainKey ist eine Technik (ähnlich wie SPF), die das Fälschen des Absenders einer E-Mail erschweren soll.
So funktioniert DKIM:
Wenn eine E-Mail versendet wurde, fügt DKIM eine sogenannte DKIM-Signatur zum Header der E-Mail hinzu. Wenn die E-Mail empfangen wird, fragt der empfangende Server den öffentlichen Schlüssel ab, der per TXT-Resource Record in der DNS-Zone der Domain veröffentlicht wurde. Mit diesem Schlüssel wird überprüft, ob die Signatur korrekt ist. Ziel dieses Verfahres ist, Spammern und Phishern ihre kriminellen Vorhaben zu erschweren.
Beispiel eines DKIM-Eintrags:
Host: Record-Type Wert/Data/Ziel:
default._domainkey.ihredomain.de IN TXT v=DKIM1;p=fhshk8ernksdnfu3zieewef+ksandkw/urzKDJdsadf
SRV
Mittels SRV (Service) Resource Records kann per DNS propagiert werden, welche IP-basierenden Dienste in einer Domain angeboten werden. Zu jedem Dienst werden weitere Informationen geliefert, wie zum Beispiel der Server-Name, der diesen Dienst bereitstellt.
Ein Dienst wird durch den Namen und das mit einem Punkt angehängte Protokoll bezeichnet. Beiden Komponenten wird ein _ vorangestellt, um Verwechslungen mit anderen Domain-Namen zu verhindern.
Aufbau
Service
Dienst + Protokoll + Domain
TTL (Time to live)
gibt an, wie lange dieser RR (Resource Record) im Cache gehalten werden darf
IN
SRV
Der String "SRV"
Priorität
falls mehrere identische Dienste angeboten werden, hat die niedrigste Priorität Vorrang (die Dienste mit höherem Prioritätswert dienen im Falle eines Ausfalls als Ersatz)
Gewicht
innerhalb gleicher Priorität sollte die Wahrscheinlichkeit für die Auswahl eines Dienstes relativ zum Gewicht sein (bei einem Dienst mit Gewicht 3 und einem mit Gewicht 2 sollte also im Mittel zu 60 % der erste Dienst gewählt werden – dies dient zur Lastverteilung)
Port
Server
Server, der diesen Dienst bereitstellt (dabei darf es sich weder um eine IP-Adresse noch um einen Alias, also eine Domain mit einem CNAME RR, handeln)
Beispiel
_ldap._tcp.example.com. 3600 IN SRV 10 0 389 ldap01.example.com.
Ein Client kann in diesem Beispiel per DNS ermitteln, dass in der DNS-Domain example.com der LDAP-Server ldap01 existiert, der über TCP Port 389 erreichbar ist.
MX
Ein MX Resource Record (englisch MX-Eintrag, eigentlich Mail Exchange Resource Record, MX-RR) einer Domain ist ein Resource Record im Domain Name System, der sich ausschließlich auf den Dienst E-Mail bezieht.
Ein MX-Record sagt aus, unter welchem Fully Qualified Domain Name (FQDN) der Mail-Server zu einer Domäne oder Subdomäne erreichbar ist. Es ist üblich, für eine Domäne mehrere MX-Records zu definieren mit unterschiedlichen Prioritäten, so dass bei Ausfall eines Mail-Servers ein anderer die E-Mails entgegennehmen kann. Dies erhöht die Wahrscheinlichkeit, dass eine Mail trotzdem an die Empfängerdomain zugestellt werden kann.
Schließlich ermöglicht dieses Verfahren, einzelne (physisch getrennte) Mailserver für Wartungsarbeiten vom Netz zu nehmen, ohne den Empfang von Mails zu gefährden.
Beim Versand einer E-Mail fragt der Ausgangs-Mailserver zunächst den MX-RR der Domain (der Teil der E-Mail-Adresse nach dem „@“) ab, dem die Empfängeradresse zugeordnet ist. Im Regelfall existiert mindestens ein MX-RR zu jeder Domain (auch Sub-Domains). Der Ausgangsserver baut dann eine SMTP-Verbindung mit dem ersten gelisteten Mailserver der Eingangsdomain auf. Falls kein MX-RR vorhanden ist, versucht der Mailserver den A Resource Record (die IP-Adresse) der Domain festzustellen. Wenn das DNS auf diese Anfrage eine IP-Adresse zurückgibt, versucht der Mailserver zu dieser IP-Adresse eine SMTP-Verbindung aufzubauen. Gelingt auch das nicht, meldet er einen Fehler (Host unknown).
Falls ein MX-RR vorhanden ist, schickt er die E-Mail an den Mailserver, der dort vermerkt ist. Falls mehrere MX-RRs vorhanden sind, wird die E-Mail an den Mailserver mit der niedrigsten Wertigkeit („preference“) gesendet. Daher wird diese Wertigkeit auch häufig als Distanz bezeichnet. Falls dieser nicht erreichbar ist, versucht der Mailserver den nächsten Mailserver in der MX-Liste zu erreichen usw. Dadurch kann der Ausfall eines Mailservers relativ einfach kompensiert werden.
Aufbau
Domäne
für welche der Eintrag ist
Klasse
IN (Internet)
Typ
MX (Mail Exchange) - Liste
Priorität
Gibt die Priorität des Eintrags an (Einträge mit niedrigeren Werten werden bevorzugt)
Mail-Server
Name des Mail-Servers
https://de.wikipedia.org/wiki/MX_Resource_Record
CNAME
Ein CNAME Resource Record (CNAME RR) ist im Domain Name System (DNS) dazu vorgesehen, einer Domäne einen weiteren Namen zuzuordnen. Die Abkürzung "CNAME" steht für canonical name (canonical = anerkannt, bezeichnet also den primären, quasi echten Namen).
Im einfachsten Fall verweist der von einem CNAME Resource Record definierte weitere Domänenname ("Alias") auf den Domänennamensteil in einem A Resource Record (oder einem AAAA Resource Record). Dieser Resource Record wiederum verbindet dann den ursprünglichen Domänennamen mit einer IP-Adresse. Beim Wechsel einer IP-Adresse muss folglich nur noch dieser Resource Record geändert werden und alle per CNAME Resource Record definierten Aliase verweisen ebenfalls auf die neue IP-Adresse. Im Gegenzug ist die Namensauflösung über den CNAME Resource Record aufwendiger.
CNAME Resource Records sind in den Internetstandards RFC 1034 und RFC 1035 von 1987 definiert und im RFC 2181 von 1997 nochmals klargestellt, weil diesbezügliche Leistungsanforderungen der Standards ignoriert wurden.
Der Begriff des canonical name wurde vielfach als Einschränkung interpretiert, einen letztlich offiziellen Namen festlegen zu müssen. Daraus wurde wiederum abgeleitet, weitere Namen dürften nur solche von CNAME Resource Records sein, auf die andere CNAME Resource Records aber nicht verweisen dürften. Tatsächlich ist aber gemeint, dass es kein Name eines anderen Resource Records sein muss, sondern dass der Name auch nur irgendwo außerhalb vom Domain Name System anerkannt sein kann.
Ein NS-, MX-, PTR- oder SRV Resource Record darf nicht auf einen CNAME Resource Record verweisen. Umgekehrt darf ein PTR Resource Record aber durchaus nur über einen CNAME Resource Record zugänglich sein. Der Name eines CNAME Resource Records darf nicht als Name anderer Resource Records verwendet werden, da er stellvertretend für alle Resource Records des Ziels steht. Einzige Ausnahme hiervon bilden die Domain Name System Security Extensions.
Einzige Ausnahme hiervon bilden die Domain Name System Security Extensions.
Syntax
<Name> IN CNAME <Ziel>
NS
Ein NS-RR (Name Server Resource Record) ist ein Datensatz eines DNS Servers und kann zwei unterschiedliche Funktionen erfüllen:
Er definiert, welche Nameserver für diese Zone offiziell zuständig sind, oder
er verkettet Zonen zu einem Zonen-Baum (Delegation).
Anmerkung zu Funktion 1: Eine Zone kann noch weitere autoritative Nameserver besitzen, für die keine NS-RRs existieren. Derartige Server werden als Stealth-Server oder hidden primary bezeichnet.
Aufbau
Ein NS-RR hat folgende Elemente:
Domäne
für welche der Eintrag ist
TTL
gibt in Sekunden an, wie lange dieser RR in einem Cache gültig sein darf
Protokoll
IN (Internet)
Dienst
NS (Name Server) – Liste
Server
Name des für diese Domäne autoritativen Nameservers
PTR
PTR (kurz für ‚Pointer‘) Resource Records ordnen im Domain Name System einer gegebenen IP-Adresse einen oder mehrere Hostname(s) zu. Sie stellen damit gewissermaßen das Gegenstück zur klassischen Zuordnung einer oder mehrerer IP-Adresse(n) zu einem gegebenen Hostname per A- oder AAAA Resource Record dar. PTR-Records können von Domaininhabern nicht über einen DNS-Dienst (wie zum Beispiel BIND) eigenständig verwaltet werden, stattdessen müssen Änderungen beim jeweiligen Provider beantragt werden.
PTR Resource Records sind ein zentrales Element des Reverse DNS. Sie werden üblicherweise in folgenden Fällen verwendet:
in der in-addr.arpa-Zone (für den Reverse-Lookup von IPv4-Adressen),
in der Zone ip6.arpa (für den Reverse-Lookup von IPv6-Adressen) sowie
in anderen Zonen für Hostnames, auf die ein CNAME Resource Record aus einer der vorgenannten Zonen zeigt.
in Verbindung mit DNS-Based Service Discovery für die Auflistung von existierenden Ressourcen im Netzwerk
Aufbau
IP-Adresse
IP-Adresse in umgekehrter Reihenfolge der Komponenten plus entsprechende Zone (s. o.); durch Delegation sind auch andere Hostnames möglich.
TTL
Time To Live: gibt an, wie lange (in Sekunden) dieser Resource Record in einem Cache gültig ist (optional; ohne Angabe wird ein zuvor explizit – per $TTL-Anweisung am Anfang der Zonendatei – definierter Defaultwert angenommen).
IN
Class: Internet (optional; Alternativen sind die Klassen HS für HESIOD und CH für CHAOS, zwei seit langem obsolete, experimentelle Netzwerk-Projekte, ohne Angabe wird IN angenommen).
Typ
PTR
Name
der der IP-Adresse zugeordnete Name
Beispiel (IPv4)
1.0.0.10.in-addr.arpa. 3600 IN PTR example.com.
In diesem Beispiel würde ein Client, der einen DNS-Server nach der IP-Adresse 10.0.0.1 fragt, als Antwort example.com. erhalten.
Beispiel (IPv6)
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR test-ipv6.example.com.
In diesem Beispiel würde ein Client, der nach der IPv6-Adresse 2001:db8::1 fragt, als Antwort test-ipv6.example.com erhalten.
Internal vs. external DNS
offen
Third-party/cloud-hosted DNS
skalierbar
offen
DNS Hierarchy
Forward zone
Falls der angefragte Namensraum außerhalb der eigenen Domäne liegt, wird die Anfrage an einen fest konfigurierten Nameserver weitergeleitet.
Forward vs. reverse zone
Forward
Client: Wie lautet die IP-Adresse von google.com
DNS: 216.58.211.142
Reverse
Client: Wer ist 216.58.211.142?
DNS: Es ist google.com
DHCP
Das Dynamic Host Configuration Protocol (DHCP) ist ein Kommunikationsprotokoll in der Computertechnik. Es ermöglicht die Zuweisung der Netzwerkkonfiguration an Clients durch einen Server.
DHCP wurde im RFC 2131 definiert und bekam von der Internet Assigned Numbers Authority die UDP-Ports 67 und 68 zugewiesen.
https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
MAC reservations
offen
DHCP Pool/Adressberich
offen
DHCP IP exclusion
offen
DHCP Scompe options
offen
DHCP - Lease time
DHCP - TTL
Die Time to live (TTL, deutsch Lebenszeit) ist die Gültigkeitsdauer, die Daten in Rechnernetzen mitgegeben wird.
Internet Protocoll
Beim Internet Protocol (IP) gibt die TTL eines Datenpakets im Internet die verbleibende maximale Lebenszeit in Sekunden an. Dabei muss jede passierte Zwischenstation (Hop) die TTL jedoch um mindestens 1 reduzieren, sodass die TTL in der Praxis schlicht die Anzahl Hops angibt. Das Datenfeld für die TTL ist ein Oktett (8-Bit-Feld), daher beträgt der maximal mögliche Wert 255. Wenn ein Datenpaket nach Ablauf seiner TTL noch nicht sein Ziel erreicht hat, wird es verworfen. Dabei sendet die letzte Station die ICMP-Antwort Typ 11: Time exceeded mit Code 0: Time to live exceeded in transit an den Absender. Angewandt wird dieses Verfahren z. B. beim Programm Traceroute.
Die TTL des Internet Protocol wurde so selten gemäß dem Internetstandard implementiert, dass sie bei IPv6 durch ein gleich bemessenes Hop Limit ersetzt wurde und eine zeitliche Lebensdauerbeschränkung höheren Protokollen überlassen bleibt.
Domain Name System
Im Domain Name System (DNS) gibt die TTL jedes Resource Records an, wie lange eine soeben erfolgte Namensauflösung voraussichtlich mindestens gültig bleibt. In diesem Zeitraum kann auf das DNS-Cachingzurückgegriffen werden. Nach Ablauf der TTL sollte der Client die jeweilige Namensauflösung verwerfen und bei Bedarf wiederholen.
Während eine kurze TTL zu erheblicher Belastung von Servern führen kann, verzögert eine lange TTL notwendige Umstellungen entsprechend. Eine nicht ungewöhnliche TTL von 86400 Sekunden bedeutet zum Beispiel, dass jede Änderung erst nach 24 Stunden abgeschlossen ist. Dagegen verwenden dynamische DNS-Dienste TTL-Werte von typischerweise 60 Sekunden, damit nach (häufigeren) Adressänderungen zeitnah die jeweils neuen Daten verwendet werden.
nach (häufigeren) Adressänderungen zeitnah die jeweils neuen Daten verwendet werden.
DHCP relay
DHCP-Relay ist eine Funktion, um DHCP über Netzwerkgrenzen (Broadcastdomäne) hinaus nutzen zu können. Damit wird die Notwendigkeit der Bereitstellung eines DHCP-Servers in jedem Subnetz, in dem sich DHCP-Clients befinden, vermieden. Die DHCP-Relay-Funktion wird meist durch den Router selbst erbracht. Dabei werden Client-seitig mittels Broadcast verschickte DHCP-Anfragen durch den DHCP-Relay empfangen und mittels Unicast einem oder mehreren DHCP-Servern zugestellt. Der DHCP-Relay-Agent wird funktional auf der Schnittstelle des Routers platziert.
DHCP - IP helper
Anfrage wird über IP helper an den DNS Server übermittelt
-
- 1 / 24
-
Flashcards
DNS Service
Das Domain Name System (DNS) ist einer der wichtigsten Dienste in vielen 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 example.org. 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 192.0.2.42 oder eine IPv6-Adresse wie 2001:db8:85a3:8d3:1319:8a2e:370:7347, und führt so zum richtigen Rechner.
A, AAAA Record
Mit einem A Resource Record wird einem DNS-Namen eine IPv4-Adresse zugeordnet. A Resource Records sind die häufigsten Resource Records im DNS.
Neben der Host-IP-Adressen-Zuordnung werden A RRs auch für DNSBLs oder zur Angabe von Subnetzmasken zu Rückwärtsauflösungen gemäß RFC 1101 verwendet.
Der entsprechende Recordtyp für IPv6 ist AAAA.
Aufbau
Name
veröffentlichter Name
TTL
time to live: gibt an, wie lange in Sekunden dieser Resource Record in einem Cache gültig sein darf (optional; ohne Angabe wird ein zuvor explizit – per $TTL-Anweisung am Anfang der Zonendatei – definierter Standardwert angenommen)
IN
class: Internet (optional; Alternativen sind die Klassen HS für HESIOD und CH für CHAOS, zwei seit langem obsolete, experimentelle Netzwerkprojekte; ohne Angabe wird IN angenommen)
A
Record Type
Length
die Länge des Eintrags, in diesem Fall 4 für die 4 Bytes der IP-Adresse.
Adresse
die IP-Adresse, unter der der gesuchte Server erreichbar ist
Beispiel
www.example.com. 3600 IN A 172.27.171.106
TXT
Ursprünglich erdacht für frei definierbaren und von Menschen lesbaren Text in DNS Einträgen. Seit den frühen 1990ern enthält dieser Eintrag häufig jedoch u. a. auch maschinenlesbare Daten wie in RFC 1464 spezifiziert, Sender Policy Framework (SPF), DomainKeys, DMARC(Domain-based Message Authentication, Reporting and Conformance), DNS-SD und Google-Site Verification.
SPF
Mit einem SPF Resource Record konnte eine Sender Policy (siehe Sender Policy Framework) für einen DNS-Namen definiert werden. Dieser Resource-Record-Typ wurde jedoch im April 2014 widerrufen, da Sender Policies inzwischen weite Verbreitung innerhalb von TXT-Records gefunden hatten und das zuständige Standardisierungsgremium nicht damit rechnete, dass sich ein dedizierter Resource Record durchsetzen würde. Somit ist TXT der einzig standardkonforme RR-Typ für SPF.
Der dedizierte SPF-Record-Typ wird von einigen SPF-Implementierungen und von BIND ab Version 9.4 unterstützt.
Der SPF Eintrag soll das Fälschen der Absenderadresse einer E-Mail verhindern. Es entstand als Verfahren zur Abwehr von Spam. Der Record-Typ ist veraltet und wurde durch TXT ersetzt.
Aufbau
Name
der zu schützende Domain-Name
TTL
gibt an, wie lange der RR im Cache gehalten werden darf
IN
SPF (99)
text
eine Sender Policy entsprechend der SPF-Spezifikation
Beispiel
example.com. 3600 IN SPF "v=spf1 mx -all"
DKIM
DKIM (DomainKeys Identified Mail) ist eine Methode der E-Mail-Authentifizierung. DKIM fügt Ihren Mails eine Signatur hinzu, die Ihrer Domain zugeordnet ist und bei allen ausgehenden E-Mails genutzt wird. Das Verwenden eines DomainKey ist eine Technik (ähnlich wie SPF), die das Fälschen des Absenders einer E-Mail erschweren soll.
So funktioniert DKIM:
Wenn eine E-Mail versendet wurde, fügt DKIM eine sogenannte DKIM-Signatur zum Header der E-Mail hinzu. Wenn die E-Mail empfangen wird, fragt der empfangende Server den öffentlichen Schlüssel ab, der per TXT-Resource Record in der DNS-Zone der Domain veröffentlicht wurde. Mit diesem Schlüssel wird überprüft, ob die Signatur korrekt ist. Ziel dieses Verfahres ist, Spammern und Phishern ihre kriminellen Vorhaben zu erschweren.
Beispiel eines DKIM-Eintrags:
Host: Record-Type Wert/Data/Ziel:
default._domainkey.ihredomain.de IN TXT v=DKIM1;p=fhshk8ernksdnfu3zieewef+ksandkw/urzKDJdsadf
SRV
Mittels SRV (Service) Resource Records kann per DNS propagiert werden, welche IP-basierenden Dienste in einer Domain angeboten werden. Zu jedem Dienst werden weitere Informationen geliefert, wie zum Beispiel der Server-Name, der diesen Dienst bereitstellt.
Ein Dienst wird durch den Namen und das mit einem Punkt angehängte Protokoll bezeichnet. Beiden Komponenten wird ein _ vorangestellt, um Verwechslungen mit anderen Domain-Namen zu verhindern.
Aufbau
Service
Dienst + Protokoll + Domain
TTL (Time to live)
gibt an, wie lange dieser RR (Resource Record) im Cache gehalten werden darf
IN
SRV
Der String "SRV"
Priorität
falls mehrere identische Dienste angeboten werden, hat die niedrigste Priorität Vorrang (die Dienste mit höherem Prioritätswert dienen im Falle eines Ausfalls als Ersatz)
Gewicht
innerhalb gleicher Priorität sollte die Wahrscheinlichkeit für die Auswahl eines Dienstes relativ zum Gewicht sein (bei einem Dienst mit Gewicht 3 und einem mit Gewicht 2 sollte also im Mittel zu 60 % der erste Dienst gewählt werden – dies dient zur Lastverteilung)
Port
Server
Server, der diesen Dienst bereitstellt (dabei darf es sich weder um eine IP-Adresse noch um einen Alias, also eine Domain mit einem CNAME RR, handeln)
Beispiel
_ldap._tcp.example.com. 3600 IN SRV 10 0 389 ldap01.example.com.
Ein Client kann in diesem Beispiel per DNS ermitteln, dass in der DNS-Domain example.com der LDAP-Server ldap01 existiert, der über TCP Port 389 erreichbar ist.
MX
Ein MX Resource Record (englisch MX-Eintrag, eigentlich Mail Exchange Resource Record, MX-RR) einer Domain ist ein Resource Record im Domain Name System, der sich ausschließlich auf den Dienst E-Mail bezieht.
Ein MX-Record sagt aus, unter welchem Fully Qualified Domain Name (FQDN) der Mail-Server zu einer Domäne oder Subdomäne erreichbar ist. Es ist üblich, für eine Domäne mehrere MX-Records zu definieren mit unterschiedlichen Prioritäten, so dass bei Ausfall eines Mail-Servers ein anderer die E-Mails entgegennehmen kann. Dies erhöht die Wahrscheinlichkeit, dass eine Mail trotzdem an die Empfängerdomain zugestellt werden kann.
Schließlich ermöglicht dieses Verfahren, einzelne (physisch getrennte) Mailserver für Wartungsarbeiten vom Netz zu nehmen, ohne den Empfang von Mails zu gefährden.
Beim Versand einer E-Mail fragt der Ausgangs-Mailserver zunächst den MX-RR der Domain (der Teil der E-Mail-Adresse nach dem „@“) ab, dem die Empfängeradresse zugeordnet ist. Im Regelfall existiert mindestens ein MX-RR zu jeder Domain (auch Sub-Domains). Der Ausgangsserver baut dann eine SMTP-Verbindung mit dem ersten gelisteten Mailserver der Eingangsdomain auf. Falls kein MX-RR vorhanden ist, versucht der Mailserver den A Resource Record (die IP-Adresse) der Domain festzustellen. Wenn das DNS auf diese Anfrage eine IP-Adresse zurückgibt, versucht der Mailserver zu dieser IP-Adresse eine SMTP-Verbindung aufzubauen. Gelingt auch das nicht, meldet er einen Fehler (Host unknown).
Falls ein MX-RR vorhanden ist, schickt er die E-Mail an den Mailserver, der dort vermerkt ist. Falls mehrere MX-RRs vorhanden sind, wird die E-Mail an den Mailserver mit der niedrigsten Wertigkeit („preference“) gesendet. Daher wird diese Wertigkeit auch häufig als Distanz bezeichnet. Falls dieser nicht erreichbar ist, versucht der Mailserver den nächsten Mailserver in der MX-Liste zu erreichen usw. Dadurch kann der Ausfall eines Mailservers relativ einfach kompensiert werden.
Aufbau
Domäne
für welche der Eintrag ist
Klasse
IN (Internet)
Typ
MX (Mail Exchange) - Liste
Priorität
Gibt die Priorität des Eintrags an (Einträge mit niedrigeren Werten werden bevorzugt)
Mail-Server
Name des Mail-Servers
https://de.wikipedia.org/wiki/MX_Resource_Record
CNAME
Ein CNAME Resource Record (CNAME RR) ist im Domain Name System (DNS) dazu vorgesehen, einer Domäne einen weiteren Namen zuzuordnen. Die Abkürzung "CNAME" steht für canonical name (canonical = anerkannt, bezeichnet also den primären, quasi echten Namen).
Im einfachsten Fall verweist der von einem CNAME Resource Record definierte weitere Domänenname ("Alias") auf den Domänennamensteil in einem A Resource Record (oder einem AAAA Resource Record). Dieser Resource Record wiederum verbindet dann den ursprünglichen Domänennamen mit einer IP-Adresse. Beim Wechsel einer IP-Adresse muss folglich nur noch dieser Resource Record geändert werden und alle per CNAME Resource Record definierten Aliase verweisen ebenfalls auf die neue IP-Adresse. Im Gegenzug ist die Namensauflösung über den CNAME Resource Record aufwendiger.
CNAME Resource Records sind in den Internetstandards RFC 1034 und RFC 1035 von 1987 definiert und im RFC 2181 von 1997 nochmals klargestellt, weil diesbezügliche Leistungsanforderungen der Standards ignoriert wurden.
Der Begriff des canonical name wurde vielfach als Einschränkung interpretiert, einen letztlich offiziellen Namen festlegen zu müssen. Daraus wurde wiederum abgeleitet, weitere Namen dürften nur solche von CNAME Resource Records sein, auf die andere CNAME Resource Records aber nicht verweisen dürften. Tatsächlich ist aber gemeint, dass es kein Name eines anderen Resource Records sein muss, sondern dass der Name auch nur irgendwo außerhalb vom Domain Name System anerkannt sein kann.
Ein NS-, MX-, PTR- oder SRV Resource Record darf nicht auf einen CNAME Resource Record verweisen. Umgekehrt darf ein PTR Resource Record aber durchaus nur über einen CNAME Resource Record zugänglich sein. Der Name eines CNAME Resource Records darf nicht als Name anderer Resource Records verwendet werden, da er stellvertretend für alle Resource Records des Ziels steht. Einzige Ausnahme hiervon bilden die Domain Name System Security Extensions.
Einzige Ausnahme hiervon bilden die Domain Name System Security Extensions.
Syntax
<Name> IN CNAME <Ziel>
NS
Ein NS-RR (Name Server Resource Record) ist ein Datensatz eines DNS Servers und kann zwei unterschiedliche Funktionen erfüllen:
Er definiert, welche Nameserver für diese Zone offiziell zuständig sind, oder
er verkettet Zonen zu einem Zonen-Baum (Delegation).
Anmerkung zu Funktion 1: Eine Zone kann noch weitere autoritative Nameserver besitzen, für die keine NS-RRs existieren. Derartige Server werden als Stealth-Server oder hidden primary bezeichnet.
Aufbau
Ein NS-RR hat folgende Elemente:
Domäne
für welche der Eintrag ist
TTL
gibt in Sekunden an, wie lange dieser RR in einem Cache gültig sein darf
Protokoll
IN (Internet)
Dienst
NS (Name Server) – Liste
Server
Name des für diese Domäne autoritativen Nameservers
PTR
PTR (kurz für ‚Pointer‘) Resource Records ordnen im Domain Name System einer gegebenen IP-Adresse einen oder mehrere Hostname(s) zu. Sie stellen damit gewissermaßen das Gegenstück zur klassischen Zuordnung einer oder mehrerer IP-Adresse(n) zu einem gegebenen Hostname per A- oder AAAA Resource Record dar. PTR-Records können von Domaininhabern nicht über einen DNS-Dienst (wie zum Beispiel BIND) eigenständig verwaltet werden, stattdessen müssen Änderungen beim jeweiligen Provider beantragt werden.
PTR Resource Records sind ein zentrales Element des Reverse DNS. Sie werden üblicherweise in folgenden Fällen verwendet:
in der in-addr.arpa-Zone (für den Reverse-Lookup von IPv4-Adressen),
in der Zone ip6.arpa (für den Reverse-Lookup von IPv6-Adressen) sowie
in anderen Zonen für Hostnames, auf die ein CNAME Resource Record aus einer der vorgenannten Zonen zeigt.
in Verbindung mit DNS-Based Service Discovery für die Auflistung von existierenden Ressourcen im Netzwerk
Aufbau
IP-Adresse
IP-Adresse in umgekehrter Reihenfolge der Komponenten plus entsprechende Zone (s. o.); durch Delegation sind auch andere Hostnames möglich.
TTL
Time To Live: gibt an, wie lange (in Sekunden) dieser Resource Record in einem Cache gültig ist (optional; ohne Angabe wird ein zuvor explizit – per $TTL-Anweisung am Anfang der Zonendatei – definierter Defaultwert angenommen).
IN
Class: Internet (optional; Alternativen sind die Klassen HS für HESIOD und CH für CHAOS, zwei seit langem obsolete, experimentelle Netzwerk-Projekte, ohne Angabe wird IN angenommen).
Typ
PTR
Name
der der IP-Adresse zugeordnete Name
Beispiel (IPv4)
1.0.0.10.in-addr.arpa. 3600 IN PTR example.com.
In diesem Beispiel würde ein Client, der einen DNS-Server nach der IP-Adresse 10.0.0.1 fragt, als Antwort example.com. erhalten.
Beispiel (IPv6)
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 3600 IN PTR test-ipv6.example.com.
In diesem Beispiel würde ein Client, der nach der IPv6-Adresse 2001:db8::1 fragt, als Antwort test-ipv6.example.com erhalten.
Internal vs. external DNS
offen
Third-party/cloud-hosted DNS
skalierbar
offen
DNS Hierarchy
Forward zone
Falls der angefragte Namensraum außerhalb der eigenen Domäne liegt, wird die Anfrage an einen fest konfigurierten Nameserver weitergeleitet.
Forward vs. reverse zone
Forward
Client: Wie lautet die IP-Adresse von google.com
DNS: 216.58.211.142
Reverse
Client: Wer ist 216.58.211.142?
DNS: Es ist google.com
DHCP
Das Dynamic Host Configuration Protocol (DHCP) ist ein Kommunikationsprotokoll in der Computertechnik. Es ermöglicht die Zuweisung der Netzwerkkonfiguration an Clients durch einen Server.
DHCP wurde im RFC 2131 definiert und bekam von der Internet Assigned Numbers Authority die UDP-Ports 67 und 68 zugewiesen.
https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
MAC reservations
offen
DHCP Pool/Adressberich
offen
DHCP IP exclusion
offen
DHCP Scompe options
offen
DHCP - Lease time
DHCP - TTL
Die Time to live (TTL, deutsch Lebenszeit) ist die Gültigkeitsdauer, die Daten in Rechnernetzen mitgegeben wird.
Internet Protocoll
Beim Internet Protocol (IP) gibt die TTL eines Datenpakets im Internet die verbleibende maximale Lebenszeit in Sekunden an. Dabei muss jede passierte Zwischenstation (Hop) die TTL jedoch um mindestens 1 reduzieren, sodass die TTL in der Praxis schlicht die Anzahl Hops angibt. Das Datenfeld für die TTL ist ein Oktett (8-Bit-Feld), daher beträgt der maximal mögliche Wert 255. Wenn ein Datenpaket nach Ablauf seiner TTL noch nicht sein Ziel erreicht hat, wird es verworfen. Dabei sendet die letzte Station die ICMP-Antwort Typ 11: Time exceeded mit Code 0: Time to live exceeded in transit an den Absender. Angewandt wird dieses Verfahren z. B. beim Programm Traceroute.
Die TTL des Internet Protocol wurde so selten gemäß dem Internetstandard implementiert, dass sie bei IPv6 durch ein gleich bemessenes Hop Limit ersetzt wurde und eine zeitliche Lebensdauerbeschränkung höheren Protokollen überlassen bleibt.
Domain Name System
Im Domain Name System (DNS) gibt die TTL jedes Resource Records an, wie lange eine soeben erfolgte Namensauflösung voraussichtlich mindestens gültig bleibt. In diesem Zeitraum kann auf das DNS-Cachingzurückgegriffen werden. Nach Ablauf der TTL sollte der Client die jeweilige Namensauflösung verwerfen und bei Bedarf wiederholen.
Während eine kurze TTL zu erheblicher Belastung von Servern führen kann, verzögert eine lange TTL notwendige Umstellungen entsprechend. Eine nicht ungewöhnliche TTL von 86400 Sekunden bedeutet zum Beispiel, dass jede Änderung erst nach 24 Stunden abgeschlossen ist. Dagegen verwenden dynamische DNS-Dienste TTL-Werte von typischerweise 60 Sekunden, damit nach (häufigeren) Adressänderungen zeitnah die jeweils neuen Daten verwendet werden.
nach (häufigeren) Adressänderungen zeitnah die jeweils neuen Daten verwendet werden.
DHCP relay
DHCP-Relay ist eine Funktion, um DHCP über Netzwerkgrenzen (Broadcastdomäne) hinaus nutzen zu können. Damit wird die Notwendigkeit der Bereitstellung eines DHCP-Servers in jedem Subnetz, in dem sich DHCP-Clients befinden, vermieden. Die DHCP-Relay-Funktion wird meist durch den Router selbst erbracht. Dabei werden Client-seitig mittels Broadcast verschickte DHCP-Anfragen durch den DHCP-Relay empfangen und mittels Unicast einem oder mehreren DHCP-Servern zugestellt. Der DHCP-Relay-Agent wird funktional auf der Schnittstelle des Routers platziert.
DHCP - IP helper
Anfrage wird über IP helper an den DNS Server übermittelt
