11.3 Verteilte Verzeichnisse können ein verteiltes Betriebssystem unterstützen dienen der Abbildung von Namen auf Daten aller Art sollten ihre Information persistent halten (Dateien, Datenbank) müssen hochzuverlässig sein typisch: Verwendung mehrfach replizierter Dateien Beispiele - im lokalen Netz: Sun NIS (BS-unterstützend) - im Internet: DNS (BS-unabhängig) 1
11.3.1 Sun NIS Network Information System, ehemals Yellow Pages (basiert auf SunRPC über UDP) Dieser Verzeichnisdienst unterstützt mehrere Abbildungen: (lokal) passwd.byname: user name uid /etc/passwd hosts.byname: host name IP address /etc/hosts mail.aliases: mail alias mail addresses /etc/aliases services.byname: service name port #, protocol /etc/services rpc.bynumber: rpc serv. name rpc program # /etc/rpc..... und andere - siehe man ypfiles 2
Benutzung, z.b. für Namensauflösung, mit Befehl ypmatch name map Dahinter verbirgt sich der Aufruf einer Bibiliotheksroutine (siehe man ypclnt) yp_match(...) (diese benutzt Fernaufrufe... siehe unten) Weitere Befehle: ypmatch x ypcat map Anzeige praktischer Kurzformen (nicknames) für einige ausgewählte Abbildungen Auflistung aller Einträge der Abbildung 3
Funktionsweise: Replizierte Anbieter (Programm ypserv), per Fernaufruf ansprechbar: Klienten wie ypmatch fragen lokalen Repräsentanten des NIS (Programm ypbind) per RPC nach einem geeigneten Replikat; ypbind schickt Broadcast RPC an die ypserv-replikate, merkt sich das erste, das antwortet, für spätere Anfragen und teilt es dem Klienten mit; dieser wendet sich daraufhin direkt an das Replikat. Es gibt eine Primärkopie und i.a. mehrere Sekundärkopien. 4
ypserv master (Primärkopie) ypserv.......... ypserv slaves (Sekundärkopien) ypbind............. Klientenprozesse Klientenstationen ypwhich host ypwhich m map liefert den Namen der Station, auf der sich der für host aktuell verwendete Server befindet liefert den Namen der Station, auf der sich der für die Abbildung map zuständige Master befindet (ohne map: Liste der Masters für alle Abbildungen) ypcat ypservers liefert Liste aller Servers 5
Daten bei Master und Slaves: /etc/... Rohdaten, vom Systemverwalter manipuliert /var/yp/... daraus abgeleitete Maps, von den Servers benutzt Änderung der Abbildungen: 1. Systemverwalter modifiziert Rohdaten und erstellt neue Map(s) mittels make. 2. Das vorgesehene Makefile sorgt dafür, daß die Slaves von der Änderung informiert werden (Befehl yppush, führt RPCs aus). 3. Slaves wenden sich an die Master-Station: Befehl ypxfr wendet sich per RPC an ypxfrd, beschafft aktualisierte Rohdaten (!) und generiert daraus die neuen Maps. (4. ypxfr auch in regelmäßigen Zeitabständen!) 6
Ausnahme: Passwort-Änderung ohne Beteiligung des Systemverwalters Befehl yppasswd kontaktiert yppasswdd-prozess auf Master-Station; dieser Prozess übernimmt Rolle des Verwalters. Master Slave Client ypserv ypserv ypbind yppush ypxfrd yppasswdd client yppasswd 7
Charakterisierung des NIS: quasi-aktive Replikation mit Primärkopie, erlaubt Heterogenität; Konsistenz sehr schwach...... aber für die Zwecke des NIS ausreichend: Änderungen selten, temporäre Inkonsistenz unproblematisch. 8
11.3.2 DNS Domain Name System Auflösung von menschenlesbaren Rechner-Namen zu Adressen www.inf.fu-berlin.de -> 160.45.117.8 Ursprünglich zentrale Registrierung per E-Mail beim Stanford Research Institute (SRI) in Datei HOSTS.TXT Beschaffung wöchentlich mittels FTP, Basis für /etc/hosts Seit 1983 DNS (Mockapetris et al.) Dezentrale Verwaltung durch Netz von domain name servers für bestimmte Bereiche der Domänen-Hierarchie mit Caching für Lastreduzierung und Replikation für Ausfallsicherheit 9
"" A.ROOT-SERVERS.NET 198.41.0.4 "de" f.nic.de 81.91.164.5 "uk" ns1.nic.uk 195.66.240.130 "org" tld1.ultradns.net 204.74.112.1 "fu-berlin.de" ns1.fu-berlin.de 160.45.8.8 "tu-berlin.de" names.zrz.tu-berlin.de 130.149.4.20 "inf.fu-berlin.de" sahib.inf.fu-berlin.de (= ns1.inf.fu-berlin.de) 160.45.110.10 "physik.fu-berlin.de" nukleon.physik.fu-berlin.de 160.45.32.130 tim.inf.fu-berlin.de (= www.inf.fu-berlin.de) 160.45.117.8 vader.inf.fu-berlin.de 160.45.110.12 Normalerweise gibt es mehrere DNS-Server pro Domäne (evtl. rotierend) 10
DNS-Abfragen auf mehrere Arten möglich: NS2 NS2 NS2 2. NS3 2. NS3 2. NS3 NS1 NS1 NS1 3. 1. 3. 1. 1. 4. resolver resolver resolver iterativ rekursiv gemischt Rekursive Weiterleitung durch DNS-Server ist optional. Caching der Antworten reduziert Kommunikationsvolumen. 11
Programme wenden sich nicht direkt an DNS-Server, sondern verwenden lokalen resolver (Bibliothek, Prozess) Typische Konfiguration eines UNIX-resolvers: Datei /etc/resolv.conf search mi.fu-berlin.de inf.fu-berlin.de math.fu-berlin.de nameserver 160.45.110.15 (pyramid.mi.fu-berlin.de) nameserver 160.45.110.10 (sahib.inf.fu-berlin.de) nameserver 160.45.8.8 (ns1.fu-berlin.de) Einfache Rechner-Namen ohne Domänen-Teil werden der Reihe nach um die bei search angegebenen Domänen erweitert. Sofern der erste bei nameserver angegebene DNS-Server nicht antwortet, werden die nachfolgenden der Reihe nach kontaktiert. 12
Die Datenbank eine DNS-Servers besteht aus mehreren Zonen-Dateien, normalerweise zwei pro Domäne: - Abbildung von Namen auf Adressen - Abbildung von Adressen auf Namen (optional) Zonen-Dateien werden vom Master-Server auf Slave-Server repliziert. Eine Zone enthält mehrere resource records (RR) der Form <name> [<TTL>] [<class>] <type> <rdata> name ist ein Rechner-Name oder die spezielle kodierte Adresse davon TTL steuert die Verweildauer im Cache eines DNS-Servers/Resolvers class gibt die behandelte Protokollfamilie an (IN = Internet) type bestimmt den Typ des Eintrags und gültige Werte für rdata rdata beschreibt Eigenschaften von name, z.b. zugehörige Adresse 13
Pro Zone steuert ein SOA (start of authority ) RR die Replikation auf Slave-Server: inf.fu-berlin.de. IN SOA sahib.inf.fu-berlin.de. \ hostmaster.inf.fu-berlin.de. ( 667 ; serial number 10801 ; refresh time, 3 hours 1 sec 3600 ; retry time, 1 hour 1209600 ; expiry time, 14 days 86400 ; default TTL for RR caching, 1 day ) Replikat muss aktualisert werden, falls höhere serial-nummer Slave-Server kontaktiert den Master alle refresh Sekunden zur Prüfung Wenn Master nicht erreichbar, neuer Versuch alle retry Sekunden Falls nach expiry Sekunden keine Antwort, Zone ungültig Ausserdem: Alle RR-Einträge der Zone dürfen maximal TTL Sekunden in DNS Caches verbleiben, sofern nicht individuell angegeben. 14
Normale A RR bilden dann Namen auf Adressen ab. Mit einem CNAME RR kann man alternative Namen (alias) vergeben. tim.inf.fu-berlin.de. IN A 160.45.117.8 www.inf.fu-berlin.de. IN CNAME tim.inf.fu-berlin.de. Weitere Einträge geben gültige DNS-Server für die Zone an: inf.fu-berlin.de. IN NS sahib.inf.fu-berlin.de. sahib.inf.fu-berlin.de. IN A 160.45.110.10 sowie Delegation an Server für untergeordnete Domänen: spline.inf.fu-berlin.de. IN NS bla.spline.inf.fu-berlin.de. bla.spline.inf.fu-berlin.de. IN A 160.45.117.70 Dabei muss auch die Adresse des zuständigen Servers als glue record angegeben werden, um Anfragen korrekt weiterzuleiten. 15
Viele weitere RR-Typen: MX HINFO TXT AAAA... mail exchanger = zuständiger E-Mail-Server host info = Maschinentyp und Betriebssystem Freitext! IPv6-Adresse Zu jeder Zone sollte es auch eine reverse-zone gegeben für korrespondierende Rückwärtsauflösung von Adresse zu Name. Realisiert mit spezieller Pseudo-Domäne in-addr.arpa : 117.45.160.in-addr.arpa IN NS sahib.inf.fu-berlin.de. 8.117.45.160.in-addr.arpa IN PTR tim.inf.fu-berlin.de. umgekehrte IP-Adresse als "Domäne" 16
IDNA - International Domain Names in Applications Problem: Für Domänen-Namen ist nur eine sehr kleine Untermenge von ASCII-Zeichen erlaubt: A-Z, 0-9 und - Darstellung von anderen Zeichen (Umlaute, Akzente,...) oder anderen Schrift-Systemen (Griechisch, Japanisch,...) nicht möglich. Abhilfe: Anwendungen kodieren Namen zunächst in kompatible Form "Punycode" (analog zu UNICODE als UTF-8-Kodierung), z.b. bücher.de -> xn--bcher-kva.de xn-- reservierter IDNA-Prefix als Markierung bcher Zeichen des Original-Namens ohne Sonderzeichen - Trennzeichen kva Kombination aus Sonderzeichen (UNICODE) und Position17
Bonjour / Rendezvous DNS as discovery service Idee: DNS-System zum Auffinden von Geräten und Diensten verwenden Dazu Verwendung von PTR, SRV (service) und TXT RRs: _printer._tcp.local. IN PTR LaserWriter 8500._printer._tcp.local. LaserWriter 8500._printer._tcp.local. IN SRV 0 0 515 myhost.local. LaserWriter 8500 _printer _tcp.local. IN TXT #pdl=application/postscript#color=t Name des antwortenden Dienstes Protokoll für Dienst (hier: LPR) zugrundeliegendes Transport-Protokoll spezielle mdns-domäne für lokales Netz (opt) 0 0 Priorität/Gewicht des Dienstes, steuert Auswahl 515 myhost.local. Port und Name des anbietenden Rechners Auflisten durch PTR-Anfrage an DNS-Server, oder Multicast für.local SRV-Anfrage liefert Host/Port, TXT-Anfrage liefert Dienst-Details 18