Dyamisches DNS. Sergej Keterling Elena Levtchenko

Transkript

1 Dyamisches DNS Sergej Keterling Elena Levtchenko

2 DNS Während der siebziger Jahre war das ARPAnet eine kleine Gemeinde mit nur einigen hundert Hosts. Eine einzige Datei namens Hosts.txt enthielt alle Informationen, die man über diese Hosts haben musste: eine Namen-auf-Adressen-Abbildung aller im ARPAnet eingebundenen Hosts. Und als ARPAnet dann zu den TCP/IP-Protokollen wechselte, explodierte die Benutzeranzahl förmlich. Nun stand man mit der Hosts.txt vor einer Menge von Problemen. Das grundlegende Problem war, dass dieser Mechanismus nicht ausreichend mitwuchs. Im Jahr 1984 gab Paul Mockapetris die RFCs 882 und 883 heraus, die das DNS (Domain Name System) beschrieben. Der RFC 882 wurde inzwischen von den RFCs 1034 und 1035 abgelöst. Das Domain Name System (DNS) ist einer der wichtigsten Dienste im Internet. Das DNS ist eine verteilte Datenbank, die den Namensraum im Internet verwaltet. Das DNS löste die hosts-dateien ab, die bis dahin für die Namensauflösung zuständig waren. Es zeichnet sich aus durch: - dezentrale Verwaltung - hierarchische Strukturierung des Namensraums in Baumform - Eindeutigkeit der Namen - Erweiterbarkeit

3 Verwendung Hauptsächlich wird das DNS zur Umsetzung von Namen in 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 Zahlenkolonnen. 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. Darüber hinaus ermöglicht das DNS eine Entkopplung vom darunterliegenden Aufbau, z.b. Änderung der IP-Adresse, ohne den Domainnamen ändern zu müssen, und sogar rudimentäre Lastverteilung (Load Balancing).

4 DNS Komponente Das DNS besteht aus drei Hauptkomponenten: - Domänennamensraum - Nameservern - Resolver Domänennamensraum Der Domänennamensraum hat eine baumförmige Struktur. Die Blätter und Knoten des Baumes werden als Labels bezeichnet. Ein kompletter Domänenname eines Objektes besteht aus der Verkettung aller Labels. Label sind Zeichenketten, die mindestens ein Zeichen und maximal 63 Zeichen lang sind. Die einzelnen Label werden durch Punkte voneinander getrennt. Ein Domänenname wird mit einem Punkt abgeschlossen (Der hinterste Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domänennamen dazu.) Ein Domänenname darf inklusive aller Punkte maximal 255 Zeichen lang sein. Ein Domänenname wird immer von rechts nach links delegiert und aufgelöst, d.h. je weiter rechts ein Label steht, umso höher

5 steht es im Baum. Der Punkt ganz rechts wird auch als root (Wurzel) im Namensraum bezeichnet. Das erste Label (das links vom Punkt für 'root' steht) wird im Allgemeinen auch als Top Level Domain (TLD) bezeichnet. Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von Resource Records in einer Zonendatei gehalten, die auf einem oder mehreren autoritativen Nameservern vorhanden ist.

6 Nameserver Nameserver sind Programme, die Anfragen zum Domänennamensraum beantworten. Man unterscheidet zwischen autoritativen und nicht-autoritativen Nameservern. Ein autoritativer Nameserver ist verantwortlich für eine Zone. Seine Informationen über diese Zone werden deshalb als gesichert angesehen. Für jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver. Dieser wird im SOA Resource Record einer Zonendatei aufgeführt. Ein nicht-autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen Nameservern sozusagen aus zweiter oder dritter Hand. Seine Informationen werden als nicht gesichert angesehen. Eine Zonendatei ist Teil eines Nameservers im Domain Name System. Sie besteht aus einer Liste von Resource Records. Eine Zonendatei beschreibt eine Zone vollständig. Es muss genau ein SOA Resource Record und mindestens ein NS Resource Record vorhanden sein. SOA bedeutet Start of Authority (Autoritätsursprung). Syntax: <name> [<ttl>] [<class>] <type> <rdata> <name> [<ttl> [<class>]<type> <rdata> <admin-mailaddress> example.com IN SOA master.example.com. mailbox.example.com example.com IN NS ns1.example.com. mail.example.com 1800 IN MX ns2.example.com 1800 IN CNAME ns1.example.com ns1.example.com IN A IN A xxx.external.net IN A Beispiel einer Zonendatei (Name-auf-Adresse-Abbildung) *SOA Start of Authority *NS Hostname eines autoritativen Nameservers *A IPv4-Adresse eines Hosts *CNAME Aliasname für einen Host *MX Mail Exchange - der für diese Domain zuständige Mailserver

7 Ein SOA Resource Record (SOA-RR) enthält hauptsächlich Parameter, die für den Zonentransfer von Bedeutung sind sowie den Namen der Zone und des zuständigen Primary Nameserver. Der SOA- Resource Record befindet sich meist am Anfang einer Zonendatei. Ein NS Resource Record (NS = Name Server) kann zwei unterschiedliche Funktionen realisieren: Ein NS-RR definiert, welche autoritative Nameserver für diese Zone offiziell bekannt sind Ein NS-RR verkettet Zonen zu einem Zonen-Baum (Delegation) Mit einem A Resource Record wird einem DNS-Namen eine IP- Adresse zugeordnet. A-RRs sind die häufigsten Resource Records beim DNS. Mit einem CNAME Resource Record (CNAME für eng. canonical name) wird zu einem vorhandenen DNS-Namen ein Alias-Name definiert. Ein MX Resource Record oder Mail Exchange Resource Record (MX-RR) einer Domain definiert, zu welchem Mailserver eine geschickt werden soll. DNS wird normalerweise verwendet, um zu einem Namen die zugehörige IP-Adresse zu ermitteln. In manchen Fällen ist auch die umgekehrte Auflösung erforderlich. Die IP-Adresse ist bekannt, aber nicht der Name. Zur einer Reversen Auflösung sind PTR Resource Records erforderlich. Syntax: <name> [<ttl>] [<class>] <type> <rdata> <name> [<ttl> [<class>]<type> <rdata> <admin-mailaddress> example.com IN SOA master.example.com. mailbox.example.com example.com IN NS ns1.example.com IN PTR mail.example.com IN PTR ns1.example.com IN PTR IN PTR xxx.external.net. Beispiel einer Zonendatei (Adresse-auf-Name-Abbildung) *SOA *NS *PTR Start of Authority Hostname eines autoritativen Nameservers Domain Name Pointer (für das Reverse Mapping, um IP Adressen Namen zuzuweisen)

8 Resolver sind Ansammlungen von Bibliotheken, die Informationen aus den Nameservern abrufen können. Sie bilden die Schnittstelle zwischen Anwendung und Nameserver. Der Resolver übernimmt die Anfrage einer Anwendung, ergänzt sie falls notwendig und übermittelt sie an den fest konfigurierten Nameserver. Ein Resolver arbeitet entweder iterativ oder rekursiv. Bei einer rekursiven Anfrage schickt der Resolver eine Anfrage an einen ihm bekannten Nameserver und erwartet von ihm eine eindeutige Antwort. Diese Antwort enthält entweder den gewünschten Resource Record oder gibt es nicht. Rekursiv arbeitende Resolver überlassen also die Arbeit zur vollständigen Auflösung anderen. Bei einer iterativen Anfrage bekommt der Resolver entweder den gewünschten Resource Record oder die Adresse eines weiteren Nameserver, den er als nächsten fragt. Der Resolver hangelt sich so von Nameserver zu Nameserver bis er bei einem autoritativen Nameserver landet. Die so gewonnene Antwort übergibt der Resolver an das Programm, das die Daten angefordert hat, beispielsweise an den Webbrowser.

9 Dynamisches DNS und DHCP Das DHCP (Dynamic Host Configuration Protocol) ermöglicht mit Hilfe eines entsprechenden Servers die dynamische Zuweisung einer IP-Adresse und weiterer Konfigurationsparameter an Computer in einem Netzwerk (z.b. Internet oder LAN). Durch DHCP ist die Einbindung eines neuen Computers in ein bestehendes Netzwerk ohne weitere Konfiguration möglich. Auch alle Internet Provider weisen ihren Kunden die IP- Adressen mit Hilfe von DHCP zu. Dies ist nicht immer die gleiche IP, die man noch gestern bzw. bei der letzten Einwahl hatte. Es kann nur Rechnern mit fester, sich also nie ändernden IP- sehr viele Nutzer mit Heimrechnern eine variable IP-Adresse Adresse ein fester Rechnername zugeordnet werden. Da jedoch haben, gibt es inzwischen DynDNS-Betreiber, die dafür sorgen, dass man auch mit solch rasch ändernden Adressen möglichst immer über den selben Rechnernamen erreichbar ist. Ein DynDNS- oder dynamischer Domain Name System-Eintrag bewirkt, dass ein Rechner, der eine wechselnde IP-Adresse besitzt, immer über den selben Namen angesprochen werden kann. Ständig wechselnde Einträge waren im Domain Name System nicht vorgesehen, stattdessen sollten Netzressourcen gespart werden, indem Einträge - oft mehrere Stunden oder sogar Tage - zwischengespeichert werden. Um nun dynamische DNS- Einträge zu ermöglichen, wird die Zeit, wie lange der Eintrag zwischengespeichert werden soll, auf das erlaubte Minimum von sechzig Sekunden gesetzt.

10 DynDNS ermöglicht: Homepage auf dem heimischen PC öffentlich verfügbar machen Heimischen FTP-Server aufstellen VPN Mit dem Telephone Number Mapping werden Telefonnummern im Domain Name System abgelegt, um die IP-Telefonie zu erleichtern. Mobilfunkbetreiber benutzen DNS bei ihren Triple-A- Systemen, um zum Beispiel intern in ihrem System zu einer IP-Adresse eines Kunden die Mobile Subscriber ISDN Number abzufragen. Es gibt auch Ansätze, das Domain Name System zum Tunneln von Nutzdaten zu verwenden und so eine Firewall zu umgehen.

11 Private Homepage Es gibt inzwischen DynDNS-Anbieter, die dafür sorgen, dass man immer über den selben Rechnernamen erreichbar ist: Um einen DynDNS-Eintrag in den Nameservern des Betreibers zu aktualisieren, wird üblicherweise ein DynDNS-Client installiert, dies ist ein Programm, das sich automatisch bei einem IP-Wechsel mit dem DynDNS-Server verbindet und seine neue IP-Adresse übermittelt, z. B.: DynDNS Updater v s (für Windows) (für Linux)

12 DynDNS-Schema Dieses Schema zeigt uns, wie dynamisches Update im Hobby Bereich funktioniert. Wenn Sie eine private Homepage bei sich zuhause aufstellen oder einen FTP- / Mailsserver betreiben möchten, aber über keine statische IP-Adresse verfügen, müssen Sie einen Domainnamen registrieren lassen. Danach müssen Sie ein kleines Programm, das sogenannte DynDNS-Client auf Ihrem PC installieren. Dieses Programm sorgt für den dauerhaften Abgleich Ihrer aktuellen IP-Adresse.

13 Messageformat So sieht eine Update Message aus, wie es in RFC 2136 spezifiziert wird. Sie unterscheidet sich nur geringfügig von einer DNS Message, hat die gleichen Felder, die nur anders befüllt werden. Messageformat Message wird als Update festgelegt Festlegen der zu aktualisierenden Zone Startbedingungen für ein Update DNS-Einräge, die hinzugefügt od. gelöscht werden Ergänzende Daten, ohne Bedeutung für s Update H eader Aufbau des Headers Hier sieht man den Aufbau des Header etwas genauer. ID Nummer ist 16-Bit lang. Das ist eine zufällig generierte Zahl. Sie wird in die Antwort mit einbezogen, damit man sieht, dass sie abgearbeitet wurde.

14 Der Header ist 12 Byte lang. Einige mögliche Werte des Headers: QR - ein Bit Operator, der definiert, ob diese Message eine Anfrage (0) oder eine Antwort (1) ist. Opcode ein 4 Bit Operator, der den Typ dieser Message definiert, z.b. Update (5) RCODE Antwort Code (NOERROR, FORMERROR, SERVFAIL etc...) Z one ZNAME ZTYPE ZCLASS Zone Section ZNAME = Zonenname ZTYPE = SOA ZCLASS = Zonenklasse In diesem Format wird die zu aktualisierende Zone festgelegt. Dabei müssen alle Daten in einer Zone liegen. P rerequisite NAME TYPE CLASS TTL RDLENGTH RDATA Prerequisite Section In diesem Format werden Startbedingungen für ein Update mit 5 verschiedenen Startzuständen festgelegt.

15 Update Wenn ein Datensatz eingefügt werde soll, werden seine Parameter in die entsprechenden Felder eingetragen. Wenn ein Datensatz gelöscht werden soll, werden alle Parameter auf 0 und Class auf ANY gesetzt NAME TYPE CLASS TTL RDLENGTH RDATA Update Section Dynamische Aktualiesierung erlaubt: Einzelne RR hinzufügen Einzelne RR löschen RRsets löschen(gleiche Domain-Namen, Klassen, Typen) Alle Records löschen, die zu einem Domain-Namen gehören Dynamische Aktualiesierung erlaubt nicht: Eine Zone komplett löschen (obwohl alles bis auf SOA-RR und einen NS-RR löschbar ist) Eine neue Zone hinzufügen

16 DHCP/DNS-Aktualisierungsinteraktion frühere Windows DHCP-Clients Frühere Versionen von Windows DHCP-Clients unterstützen keinen direkten dynamischen DNS-Aktualisierungsvorgang und können daher auch nicht direkt mit dem DNS-Server agieren. Für diese DHCP-Clients werden Aktualisierungen für gewöhnlich folgendermaßen durchgeführt: 1. Der Client richtet eine DHCP-Anforderungsmeldung (DHCPREQUEST) an den Server. 2. Der Server antwortet dem Client mit einer DHCPeine IP- Bestätigungsmeldung (DHCPACK) und erteilt ihm Adresslease. 3. Der Server sendet dann Aktualisierungen an den DNSdem Server für den Forward-Lookupeintrag des Clients, bei es sich um einen Host (A)-Ressourceneintrag handelt. 4. Der Server sendet auch Aktualisierungen für den Reverse- Lookupeintrag des Clients, bei dem es sich um einen Pointer (PTR)-Ressourceneintrag handelt.

17 Windows 2000 jetzt Windows 2000 bietet Client- und Serverunterstützung für die Verwendung dynamischer Aktualisierungen, wie in RFC 2136 beschrieben. Bei der Installation eines Windows 2000 DHCP-Servers können Sie den Server so konfigurieren, dass Aktualisierungen mit Hilfe der DHCP-Clients für DNS-Server (Domain Name System (DNS) durchgeführt werden, die dynamische Aktualisierungen unterstützen. Beispiel 1: DHCP/DNS-Aktualisierungsinteraktion für Windows 2000 DHCP-Clients Windows 2000 DHCP-Clients arbeiten mit dem dynamischen DNS- Aktualisierungsprotokoll folgendermaßen: 1. Der Client richtet eine DHCP-Anforderungsmeldung (DHCPREQUEST) an den Server. 2. Der Server antwortet dem Client mit einer DHCP- Bestätigungsmeldung (DHCPACK) und erteilt ihm eine IP- Adresslease. 3. Standardmäßig sendet der Client eine DNS- Aktualisierungsanforderung für den eigenen Forward- Lookupeintrag, einen Host (A)-Ressourceneintrag, an den DNS- Server. 4. Der Server sendet Aktualisierungen für den Reverse- Lookupeintrag des DHCP-Clients - einen Pointer- Ressourceneintrag (PTR) - unter Verwendung des im dynamischen DNS-Aktualisierungsprotokoll festgelegten Vorgangs

18 Sicherheit Sicherheit des dynamischen DNS wurde im RFC 2137 vom D. Eastlake 3rd, 1997 beschrieben. Gerade das DDNS bietet viele Möglichkeiten DNS System anzugreifen. Um ihre Benutzer vor solchen Angriefen zu schützen, ist DNS Sicherheit erforderlich. DNS Sicherheit kann verschiedene Formen annehmen. Unter anderem versucht man die Nameserver so abzusichern, dass er dynamische Aktualisierungen von nicht autorisierten Adressen abweist. Zum Beispiel werden dynamische Aktualisierungen nicht standardmäßig unterstützt. Dafür wird eine allow update Anweisung hinzugefügt, die eine Adressenliste als Argument erwartet. Server mit diesen Adressen sind zum Aktualisieren zugelassen. Selbst das bietet einen minimalen Schutz, weil UDP Pakete leicht abgefangen werden können und die IP-Adresse des Absenders verfälscht werden kann. Deswegen bedient man sich eines Verschlüsselungsverfahrens, wie TSIG mit symmetrischen Schlüsseln, was wiederum auch angriffsanfällig ist, oder Public Key Verfahrens mit asymmetrischen Schlüsseln. Mithilfe von Public Key Verfahren werden Update Nachrichten verschlüsselt. Das funktioniert folgendermaßen: Dyn. DNS Update durchführen DDNS-Request-Msg Hash-Function HASH-Wert Entschlüsseln mit PUBLIC KEY von Host HASH-Wert Hash-Function DDNS-Request-Msg HASH-Wert Verschlüsseln PRIVATE KEY Request-SIG 1. DDNS-Request-Msg Request-SIG Request-SIG DNS-Server Transaktions-SIG DDNS-Response-Msg 2. Host DHCP-Client

19 Ein Schlüsselpaar wird mittels einer mathematischen Formel generiert. Ein Schlüssel wird bekannt gemacht. Der andere geheimgehalten. Um eine Vergrößerung von 4 auf 100 Byte zu vermeiden, wird Nachricht durch eine Einweg-Hash-Funktion geschickt und anschließend nur der Hashwert mit Privatem Schlüssel verschlüsselt. Diese digitale Signatur wird der Nachricht hinzugefügt (SIG Record). Der Empfänger entschlüsselt die digitale Signatur, schickt die Nachricht durch seine Kopie der Einweg-Hash-Funktion. Stimmen die Hashwerte überein, ist die Nachricht nicht verfälscht.

20 Zusammenfassung Die Welt des Internets ist ein ausgesprochen dynamisches Ort geworden. Dynamisches DNS wird im professionellen Bereich schon sein 20 Jahren verwendet, um per Zonentransfer die Synchronisation der Zonendaten zwischen Nameservern zu ermöglichen. Dies erleichtert die Verwaltung der Server im professionellen Bereich und ermöglicht die Aufstellung der eigenen Websites im Hobby Bereich.

21 Quellen DNS und BIND, O Reilly, 2002 RFC 2136, RFC 2137, RFC Anleitung (Linux): Anleitung (Windows): DDNS Providerliste: DDNS Clientliste Windows 2000 Server Dokumentation g_dhcp_imp_interoperabilitydns.htm