Worddokument herunterladen
Werbung
Folie 1 Internetadressen • weltweit eindeutig • Vergabe durch zentrale Behörde – InterNIC – Tochtergesellschaft DENIC • Strukurierung durch Klasseneinteilung Eine IP-Adresse identifiziert weltweit eindeutig einen Internetanschluß (Station oder Router). Die Einmaligkeit der IP-Adresse wird durch eine zentrale Behörde InterN1C (Internet Network Information Center) mit Adresse rs. internic. net garantiert, die auch die IP-Adressen vergibt. InterN1C hat zu ihrer Entlastung auch bestimmte nationale Behörden beauftragt IP-Adressen zu vergeben. Für Deutschland wird dieses von DENIC übernommen, wobei Anträge an folgende Adresse zu richten sind: IntraNet GmbH Dickstr. 35 53773 Hennef Tel: +49 2242 927140 Fax: +49 2242 927199 E-Mail: [email protected] WWW: http://www.intra.de/ InterN1C und ihre Vertreter vergeben jedoch nicht jede einzelne IP-Adresse, sondern eine Gruppe von Adressen, die dann von einem Internet-Anbieter (Provider) weitervergeben werden. Die Anbieter können verschiedengröße und demzufolge verschiedene Anzahl von Adressen verlangen. Deshalb wurden die Adreßgruppen in fünf verschiedene Klassen A bis E aufgeteilt. Dadurch haben die IP-Adressen eine Struktur erhalten, die unterschiedlich für die fünf Adreßklassen A bis E ist. Die hochwertigen Bits des letzten Byte (von rechts) bestimmen die Zugehörigkeit einer IPAdresse zu einer Adreßklasse Folie 2 IP-Adressklassen • Klasse A [1] 0 [7] Netz-ID [24] Host-Identifikator (Host-ID) – 0.0.0.0 - 127.255.255.255 • Klasse B [1] [1] 1 0 [14] Netz-ID [16] Host-Identifikator (Host-ID) – 128.0.0.0 - 191.255.255.255 • Klasse C [1] [1] [1] 1 1 0 [21] Netz-ID [8] Host-ID – 192.0.0.0 - 223.255.255.255 • Klasse D [1] [1] [1] [1] 1 10 1 0 [28] Identifikator der Multicast-Gruppe – 224.0.0.0 - 239.255.255.255 • Klasse E [1] [1] [1] [1] [1] 1 1 1 1 0 [27] reserviert für die Zukunft – 240.0.0.0 - 247.255.255.255 Klasse A: Dieser Adreßklasse wird durch das hochwertigste Bit = 0 der Adresse identifiziert. Das bedeutet, daß die Adressen dieser Klasse im Bereich von 0.0.0.0 bis 127.255.255.255 liegen. Der Identifikator des Netzes bei der Klasse A (d. h. sein Netz-ID) wird durch 7 Bit kodiert, was theoretisch 27 = 128 unterschiedliche Netze ergibt. Die Anzahl der möglichen IPAdressen innerhalb eines Netzes ist 224 =16777216. Deshalb werden diese Adressen nur an besonders privilegierte große Anwender vergeben. Die theoretische Anzahl von Netz-ID einer Klasse wird in der Praxis reduziert, da bestimmte Netz-ID Spezialadressen darstellen (siehe Abb. 10). Klasse B: Diese Adreßklasse wird durch die hochwertigsten zwei Bit 1 0 der Adresse identifiziert. Der Adressenbereich geht dementsprechend von 128.0.0.0 bis 191.255.255.255. Der Netz-ID ist 14 Bit lang, was theoretisch 214 = 16384 unterschiedliche Netze ergibt. Die Anzahl der möglichen IP-Adressen innerhalb eines Netzes ist 216 = 65536. Klasse C: Die Klasse C wird durch die hochwertigsten drei Bit = 1 1 0 der Adresse identifiziert. Das bedeutet, daß die Adressen dieser Klasse im Bereich von 192.0.0.0 bis 223.255.255.255 liegen. Der 21-Bit-lange Netz-ID erlaubt theoretisch die eindeutige Identifizierung von 221 = 2097152 verschiedenen Netzen mit je 28 = 256 IP-Adressen. Diese Klasse wird an kleine Anbieter vergeben. Klasse D: Diese Adreßklasse identifiziert eine Multicast-Gruppe und wird durch die hochwertigsten vier Bit - 1110 der Adresse identifiziert. Der Adressenbereich geht dementsprechend von 224.0.0.0 bis 239.255.255.255. Der 28-Bit-lange Identifikator der Multicastgruppe erlaubt 228 = 268435456 Gruppen. Klasse E: Diese Klasse wird für die Zukunft reserviert. Ihr Adreßbereich geht von 240.0.0.0 bis 247.255.255.255. Folie 3 Subnetze • Klassische und nach außen sichtbare IP-Adresse Netz-ID HOST-ID • interne Strukturierung der IP-Adresse Netz-ID Sunnetz-ID HOST-ID Strukturierung eines Host-ID in Subnetze Der Host-ID identifiziert eindeutig einen Internetknoten. Die Subnetz-unterstützung erlaubt dem Internet-Anbieter (bzw. dem Netzadministrator), die hochwertigen Bits des vom InterN1C zugewiesenen Adreßbereiches mit Host-IDs für eine weitere interne Aufteilung in Subnetze zu nutzen. Für diesen Zweck werden die hochwertigen Bits des Host-ID zur Identifizierung eines Subnetzes genutzt. Das bedeutet, daß die IP-Adresse in der klassischen Form intern (d. h. vom Netzadministrator) weiter in Subnetze strukturiert wird. Zum Beispiel verfügt ein Anbieter über ein Netz der Klasse C. Das bedeutet, daß er die ersten 8 Bit (= 1 Byte) von rechts als Host-ID vergeben darf. Er könnte aber entscheiden, diese 8 Bit weiter zu strukturieren, indem die 3 hochwertigen Bits als Subnetz-ID genutzt werden. Das bedeutet, daß er die theoretisch zur Verfügung stehenden 28 = 256 Host-Adressen in 23 = 8 Subnetze mitie 25= 32 Host-Adressen aufgeteilt hat. Diese Subnetze können dann verschiedene Abteilungen im Unternehmen mit separaten LANs repräsentieren. Die Stationen im Subnetz können z. B. Broadcast-Nachrichten an alle Stationen des Subnetzes senden und dadurch Gruppenkommunikation betreiben. Die Subnetze können weiterhin durch Router voneinander getrennt werden, die dann Firewalls implementieren und dadurch verschiedene Sicherheitsbereiche bilden. Wieviel Bit dabei für den Subnetz-ID genutzt werden, bleibt dem Netzadministrator überlassen. Er muß dies aber dem lokalen Anwender durch die sogenannte Subnetmaske mitteilen. Diese Subnetzmaske wird von den Routern des Netzes genutzt, um sie mit der klassischen IP-Adresse eines Host boolisch zu multiplizieren und dadurch den internen Subnetz-ID und den neuen Host-ID zu ermitteln. Folie 4 Eintragung einer Domain im DNS Virtuelle ROOT-DOMAIN arpa gov 193 edu fr Normale DNS-Eintragung de fh-fulda 193.174.26 Top-LevelDomain SubDomain 174 26 fh-fulda.de Inverse DNS-Eintragung DNS dagegen ist eine verteilte Datenbank, in der die DNSNamensserver hierarchisch aufgebaut sind. jeder DNS-Server verwaltet nur einen Teil der Internet-Namen (die Namen seiner Domain) und tauscht Informationsanforderungen mit anderen DNS-Servern aus. Wenn ein DNS-Server der unteren Ebene keine Eintragung über eine IP-Adresse oder einen Internet-Namen hat, wird die DNS-Anforderung zum höherliegenden autorisierten DNSServer gesendet. Die hierarchische Struktur der Domains erleichtert die Lokalisierung des autorisierten DNS-Servers. Die Antwort wird dann in dem Cache des lokalen DNS-Servers gespeichert, so daß die nachfolgenden Anforderungen direkt von ihm abgewickelt werden. DNS bietet zwei Abbildungsdienste an: Normale Abbildung: Abbildung von alphanumerischen Internetnamen in numerischen Internetadressen. Da die Internetnamen strukturiert sind, werden die entsprechenden Domains und ihre DNS-Server dieser globalen (baumformigen) Hierarchie folgen. In der Wurzel des Baumes steht ein RootDomain, der keinen Namen hat, aber von einer Gruppe von Root-Servern verwaltet wird (Abb. 27), Die unterliegende Domain-Ebene bilden die Top-LevelDomains, die sich im wesentlichen nach geographischen (z. B. de für Deutschland, f r für Frankreich, bg für Bulgarien, es für Spanien,ca für Canada) oder nach organisatorischen Merkmalen unterscheiden. Auf Grund der Hierarchie wird ein Auftrag von DNS-Server zu DNS-Server gesendet, bis er den lokalen DNSServer des Objekts erreicht hat. Folie 5 Top-Level-Domains Bezeichnung Bedeutung com edu gov int mil net org komerzielle Organisaton US-Bildungsorganisation US-Regierungsorganisation internationale Organisation US-Militärorganisation Organisation mit Netzwerkunterstützung nicht kommerzielle Einrichtung Reverse Abbildung Dieser DNS-Dienst bildet eine numerische IP-Adresse in einem alphanumerischen Internetnamen ab. Im Gegensatz zu dem Internetnamen bietet die IP-Adresse keine Struktur an. Die Aufteilung der Adressen in Klassen und ihre Zuweisung an bestimmte Domains erfolgt über die entsprechende NIC-Behörde auf eine willkürliche Art und Weise. Die baumförmige Struktur von DNS-Servern würde eine solche Abbildung nicht unterstützen, da sie der Struktur der Internetnamen folgt. Die reverse Abbildung würde dann eine Suche in allen Domains bedeuten. Um eine zu umfassende Suche zu vermeiden, hat DNS einen separaten Zweig in die Baumstruktur eingebaut. In diesem Zweig wird die Aufzeichnung der IP-Adressen und der dazugehörigen Namen erneut vorgenommen, aber auf der Grundlage der IPAdresse strukturiert. Eine spezielle Top-Level-Domain ist arpa, die die Wurzel des Baumes bildet, gefolgt von dem hochwertigen Byte der IP-Adresse, usw. In den Blättern des arpa-Zweiges sind dann die entsprechenden Internetnamen zu finden. Wie schon oben erwähnt, soll eine neue Organisation eine IP-Adresse von InterNIC (rs.internic.net) bekommen. In unserem Beispiel wäre dies eine Netzadresse der Klasse C 193.174.26. Diese Adresse wird dann in die Top-Level-Domain arpa eingetragen (Abb. 28). Aus der Sicht der restliche Zweigen des DNS-Baumes wird dieser Zweig folgender »Adresse« entsprechen: 26.174.193.in-addr.arpa Gleichzeitig erhält die Organisation Fachhochschule Fulda eine Registrierung unter f h- f u 1 da unterhalb der Top-Level-Domain de. Dieses ergibt einen Internet-Namen für die Organisation (die sogenannte DNS-Zone) fh-fulda.de Sie wird von einem primären DNS-Server verwaltet. Diese Zone kann dann in Unterzonen aufgeteilt werden, z. B. informatik. fh-fulda.de, die von einem sekundären DNS-Server verwaltet werden. Eine neue DNS-Eintragung erfolgt allerdings in den primären DNS-Server. Die sekundären DNS-Server müssen dann diese Aktualisierung in regelmäßigen Abständen (z. B. alle 3 Stunden) abfragen. Leider besteht zwischen den beiden Registrierungen in dem DNSBaum keine unmittelbare Verbindung, was von Eindringlingen zum Durchbrechen von Sicherheitssytemen mißbraucht werden kann. Die restliche Strukturierung des IP-Adreßraumes durch Subnetze, sowie des Internetnamens durch weitere Subdomains ist dem lokalen Netzwerkadministrator überlassen. Die Datenbank eines DNS-Servers verwaltet folgende Datentypen: A die IP-Adresse eines Hosts CNAME der Namen eines Alias HINFO den Identifikator des Hosts und des Betriebssystems eines Host. MX Identifiziert einen Mail-Austausch für eine Domain [20]. NS den Identifikator des autorisierten Namensservers für die Domain. PTR den Zeiger zum anderen Teil des Domain-Adreßraumes. SOA den Identifikator des Starts einer Zone. Diese Daten können über eine DNS-Anfrage abgefragt werden. Der DNS-Server sendet dann eine DNS-Antwort mit den entsprechenden Daten zurück. Eine DNS-Anfrage oder eine DNSAntwort haben einen Header (12 Byte lang), der den Typ der Anfrage und die Anzahl der Anfragen/Antworten festlegt. Zum Beispiel könnte ein Namensserver nach der A-Information (normale Anfrage vom Typ A) für den Internet-Namen fh.fulda.de abgefragtwerden.1mDNS-Serverwurdendann folgende Eintragung angesprochen: fh-fulda.de IN A 193.174.26 Diese Eintragung mit der IP-Adresse wird dann mit der Antwort zurückgesendet. Wenn aber die Anfrage zum falschen Nameserver gesendet wurde, wird die Antwort keine 1P-Adresse beinhalten, sondern eine oder mehrere NS-Eintragungen, d. h. Adressen von Nameservern, die diese Domain verwalten. Eine DNS-Anfrage vom Typ PTR kann nach dem Namen 67.26.174.193. in-addr.arpa suchen. Der DNS-Server sendet dann den lnternetnamen ulm.fh-fulda.de zurück: DNS-Anfrage: 67.26.174.193. in-addr. arpa, type = PTR, class = IN DNS-Antwort: 67.26.174.193.in-addr.arpa name = ulm.informatik.fh-fulda.de TTL = 86400 Sekunden (1 Tag) Eine Antwort vom Typ NS ist auch möglich und würde den Namen des DNS-Servers liefern, der für die entsprechende Domain verantwortlich ist. Folie 6 Dynamisches DNS • Gründe – DNS basiert auf statischen IP-Adressen – Wachstum des Internets mit einer vermehrten Änderung von RoutingInformationen für IP-Adressen • Ziele – Dynamischer Update Mechanismus – Vereinfachung der Administration DYNAMIC DNS Der Bedarf für eine dynamische DNS-Version läßt sich vor allem verstehen, wenn man sich die derzeitigen Windows-Netzwerke ansieht. Unter Windows NT (Version 4.0) existieren derzeit zwei Dienste, welche die Umsetzung von Rechnemamen zu IP-Adresse erledigen: DNS und WINS (Windows Intemet Naming Service). Doch basiert die Implementierung von Microsoft-DNS nicht auf der im Unix-Lager allgemein verwendeten BIND-Software, sondern vielmehr auf einer Microsoft-eigenen aber weitgehend kompatiblen Implementation dieses Konzepts. WINS erlaubt seinerseits eine dynamische Registrierung von NetBIOS-Namen und den zugehörigen IP-Adressen. Die Namen und die zugehörigen IP-Adressen nach dem Schema des DNS sind dagegen statisch in die entsprechende Datenbank einzutragen. Immer wenn die Routing-Information für eine IP-Adresse zu ändern ist, muß man die komplette Datenbank mit den Namensinformationen neu laden. Ein dynamischer UpdateMechanismus dagegen läßt es möglich werden, nur einen einzelnen Eintrag neu anzulegen beziehungsweise einen alten zu überschreiben. Für den Netzwerkverwalter eines auf NT 5.0 basierenden Netzwerks bedeutet dies eine Erleichterung: Änderungen in einer Domäne, etwa das Hinzufügen eines Subtrees, lassen sich im laufenden Betrieb des Name-Servers durchführen. Die statische Zuteilung der Information (Umsetzung von Namen zu Adressen) ist für ein typisches Windows-NT/Windows-95-Netzwerk oftmals nicht erwünscht, da die üblicherweise kleinen Netzwerke keine statischen IP-Adreßzuweisungen besitzen. Sie greifen vielmehr auf das DHCP (Dynamic Host Configuration Protocol) zurück, bei dem während der Boot-Phase eines Systems eine IP-Adresse dynamisch vom Host zugewiesen wird. Die Intemet Engineering Task Force (IETF) diskutiert derzeit einen Vorschlag für eine dynamische Zuweisung von DNS-Information. Sie ist über die Web-Seite der IETF (http://ds.intemic.net/intemetdrafts/) einzusehen. Ein Client-Rechner bekommt seine IPAdresse über das DHCP zugeteilt. Daraufhin hat er die Möglichkeit, über ein standardisiertes Protokoll seinen DNS-Namen und seine IP-Adresse in der DNS-Datenbank einzutragen. Mit Windows NT 4.0 funktioniert dies allerdings noch nicht, da Microsoft diese Technik bei seinem DNS nicht eingebaut hat. Der Grund hierfür ist darin zu suchen, daß der Standard "Dynamic DNS" immer noch nicht endgültig verabschiedet ist. Doch wird Microsoft auf alle Fälle das Dynamic DNS mit Windows NT 5.0 zur Auslieferung bringen, selbst wenn die endgültige Version noch nicht als Standard verabschiedet wurde, wenn NT 5.0 auf den Markt kommt. In IETF-Kreisen sieht man in dieser Situation allerdings einen Grund, die Standardisierung schnell voranzutreiben, damit die Windows-NT-Welt konform zum Rest der Welt bleibt - zumindest was die Namensauflösung angeht. Zudem arbeitet der augenblickliche Vorschlag nach einem Replikationsmodell, bei dem die Information nur von einem einzigen "Master" heruntergeladen wird. Falls dieser Master im Netzwerk nicht erreichbar ist, sind keine dynamischen Update-Vorgänge machbar. Daher bemüht sich vor allem Microsoft um eine andere Architektur , bei der diese Registriervorgänge auch dann funktionieren, wenn der Master nicht erreichbar ist ähnlich wie das im WINS bereits möglich ist. Nun ist es allerdings nicht so, daß WINS die technisch bessere Lösung wäre - auch wenn nach dem bisher gesagten ein solcher Eindruck entstanden sein mag. Das hat folgende Gründe: - Die Integration von DNS und WINS (so wie bisher bei Windows NT optional möglich) erlaubt keine "umgekehrten Abfragen", also keine Abbildung von IP-Adressen auf den DNSNamen. Die Bedeutung dieses "Reverse Lookup" nimmt aber mit der Verbreitung des WWW und damit verknüpft mit der steigenden Gewichtung von Firewall-Diensten enorm zu. Ein effizientes "Reverse Lookup" ist für den Datendurchsatz unabdingbar. Kommt eine dynamische Form des DNS zum Einsatz, ist dieses Problem gelöst. - Die Kombination aus DNS und WINS schließt eine Backup-Möglichkeit des primären DNSServers auf Nicht-Microsoft-Systemen - und das sind im Bereich der großen Server doch einige - aus. Name-Server des DNS auf Unix-Systemen besitzen zum Beispiel keine Möglichkeit, auf WINS zuzugreifen. Die Wahrscheinlichkeit, daß diese Möglichkeit implementiert wird, ist sehr gering. Sollte ein Unternehmen die Migration zu Netzwerken mit Windows NT ins Auge fassen, sind DNS-Server aus dem Hause Microsoft zunächst als Backup-Systeme für die typischerweise eingesetzten DNS-Server auf Unix-Systemen zu verwenden. Dies ist allerdings nur mit "dynamischen DNS" zu realisieren. - Host-Rechner mit dem Unix-Betriebssystem können sich nicht in WINS eintragen. Damit wäre auch ein dynamisches Registrieren in der WINS-DNS-Kombination von vorneherein zum Scheitern verurteilt. Da aber Dynamic DNS als ein Standard der IETF veröffentlicht wird, können künftige Systeme, die diesem Standard entsprechen, mit dem neuen DNS arbeiten. Dabei ist es dann einerlei, welche Betriebssysteme diese Rechner verwenden solange der Standard nur richtig implementiert ist. - Ein weiterer massiver Schwachpunkt von WINS ist die fehlende Sicherheit. Dieser Dienst besitzt keine vernünftigen Mittel, um im Bereich der Security etwas Sinnvolles realisieren zu können. Die IETF will aber speziell im Bereich der Sicherheit einiges einbauen, damit zum Beispiel mit den Einträgen in die DNS-Datenbank kein Schindluder getrieben wird. Folie 7 Das DNS-Format (1) • Update Message Format HEADER ZONE Festlegen der zu aktualisierenden Zone PREREQUISITE RRs und RRsets, welche vorher (nicht) vorhanden sein müssen UPDATE RRs oder RRsets, welche hinzugefügt bzw. gelöscht werden ADDITIONAL DATA Ergänzende Daten Das DNS-Message Format wird im RFC1035 beschrieben. Einige Erweiterungen sind notwendig (z.B. werden mehr Fehlerbehandlungen beim UPDATE benötigt, als bei einer Abfrage) und einige Felder müssen überladen werden. Die HEADER-Sektion legt fest, daß die Message ein UPDATE ist. Die ZONE-Sektion benennt die Zone, welche aktualisiert werden soll. Die PREREQUISITE-Sektion enthält die Startbedingungen, welche für dieses UPDATE benötigt werden. Die UPDATE-Sektion beinhaltet die durchzuführenden Änderungen. Die ADDITIONAL-DATA-Sektion seien der Vollständigkeit halber erwähnt, sind für das UPDATE jedoch ohne Bedeutung. Folie 8 Das DNS-Format (2) • Message Header 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ID QR Opcode Z RCODE ZOCOUNT PRCOUNT UPCOUNT ADCOUNT Das IPDATE benutzt den gleichen HEADER, wie das DNS, jedoch werden den einzelnen Sektionen andere Bedeutungen zugewiesen. Beschreibung der Felder: (1) ID - 16 bit Die ID ermöglicht die Identifizierung der Anforderung und dient beim Client zur Unterscheidung von anderen Anforderungen. Der Server kann an der ID erkennen, ob diese Anforderung schon einmal vorgelegen hat. (2) QR - 1 bit Dieses Feld ermöglicht die Unterscheideung zwischen Anfrage (0) und Antwort (1). (3) Opcode - 4 bit Der Opcode identifiziert unter anderem, ob es sich bei der Nachricht um ein UPDATE handelt (Wert = 5) (4) Z - 7 bit Dieses Feld ist für zukünftigen Gebrauch reserviert. (5) RCODE - 4 bit Fehlercode Folie 9 Das DNS-Format (3) • Zone Section 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ZNAME ZTYPE ZCLASS Die ZONE-Sektion hat dasselbe Format, wie im RFC1035 beschrieben. Das UPDATE nutzt diese Sektion um die Zone zu kennzeichnen, in der ein oder mehrere Datensätze aktualisiert werden sollen. Diese Datensätze müssen alle einer Zone angehören; hieraus ergibt sich, daß die ZONE-Sektion nur einen Datensatz beinhalten darf. ZNAME ZTYPE ZCLASS - Zonenname SOA = Identifikator des Starts einer Zone Klasse der Zone Folie 10 Das DNS-Format (4) • Prerequisite Section 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 NAME TYPE CLASS TTL RDLENGTH RDATA Diese Sektion beinhaltet die Bedingungen eines RRsets, welche erfüllt sein müssen, wenn eine Update-Aufforderung vom Primary Master Server in Empfang genommen wird. Man unterscheidet 5 Zustände eines RRsets: (1) RRset existiert (Wert unabhängig). Wenigstens ein RR mit ein vorgeschrieben NAME und ART (in der Zone und Klasse durch den Zone-Teil vorgeschrieben) muß existieren. (2) RRset existiert (Wert abhängig). Ein Satz von RRs mit ein vorgeschrieben NAME und TYPE existiert und hat die gleichen Mitglieder mit dem gleichen RDATAs als der RRset schrieb hier in diesem vor Teil. (3) RRset existiert nicht. Keine RRs mit vorgeschrieben NAMEN und TYPE (in der Zone und Klasse beschrieben im Zone-Teil) kann existieren. (4) Name ist im Gebrauch. Wenigstens ein RR mit einem vorgeschrieben NAMEN (in ZONE und CLASS des Zone-Teil beschrieben ) muß existieren. Bedenken Sie, daß diese Vorbedingung durch leere Inhalte nicht zufriedengestellt wird. (5) Name ist nicht im Gebrauch. Es wird kein RR irgendeiner Art wird durch NAME beschrieben. Bedenken Sie, daß diese Vorbedingung durch leere Inhalte zufriedengestellt wird. Folie 11 Das DNS-Format (5) • Update Section 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 NAME TYPE CLASS TTL RDLENGTH RDATA Diese Sektion beihaltet die RRs, welche einer Zone hinzugefügt oder gelöscht werden sollen. Man unterscheidet 4Möglichkeiten bei der Aktualisierung: 1) Hinzufügen in einen RRset 2) Löschen eines RRsets 3) Löschen aller RRsets eines Namens 4) Löschen eines einzelnen RRs aus einem RRset Folie 12 Interessantes • RFC‘s – – – – RFC1035 - „Domain Names - Implementation and Specification“ RFC2065 - „Domain Name System Protocol Security Extension“ RFC2136 - „Dynamic Update in the Domain Name System“ RFC2137 - „Secure Domain Name System Dynamic Update“ • weitere Quellen – Rumen Stainov - TCP/IP-Tutorial im Lexikon TCP/IP Internetworking - Datacom – Mark R. Brown - Internet - QUE (Markt und Technik) – Internet - RRZN – - LANLINE 12/97 - AWI • bei Fragen oder Anregungen – Peter Kühne - Fulda, den 28.06.1998 RFC‘s RFC1035 - „Domain Names - Implementation and Specification“ RFC2065 - „Domain Name System Protocol Security Extension“ RFC2136 - „Dynamic Update in the Domain Name System“ RFC2137 - „Secure Domain Name System Dynamic Update“ weitere Quellen Rumen Stainov TCP/IP-Tutorial im Lexikon TCP/IP Internetworking - Datacom Mark R. Brown Internet - QUE (Markt und Technik) Internet - RRZN - LANLINE 12/97 - AWI bei Fragen oder Anregungen Peter Kühne - Fulda, den 28.06.1998
