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
Herunterladen
Explore flashcards