Zum Hauptinhalt springen

6. SUPPORT SERVICES (Unterstützungsdienste)

Dieser Abschnitt behandelt drei Kategorien von Unterstützungsdiensten: Domänennamen-Übersetzung, Host-Initialisierung und Remote-Management.

6.1 DOMAIN NAME TRANSLATION (Domänennamen-Übersetzung)​

6.1.1 Einführung​

Das Domain Name System (DNS) ist ein verteiltes Datenbanksystem zur Übersetzung von Hostnamen in IP-Adressen und umgekehrt. DNS ist wesentlich für den Betrieb des Internets.

Jeder Internet-Host muss (MUST) einen DNS-Resolver implementieren, um DNS-Server für die Namensauflösung abzufragen.

6.1.2 Protokoll-Durchgang​

DNS arbeitet nach einem Client-Server-Modell:

  • Resolver: Client, der DNS-Server abfragt
  • Nameserver: Server, der auf DNS-Anfragen antwortet

DNS-Nachrichtenformat​

DNS-Nachrichten bestehen aus:

  • Header: Enthält Anfrage-/Antwort-Flags und Zähler
  • Fragebereich: Enthält die Anfrage
  • Antwortbereich: Enthält Ressourceneinträge, die die Anfrage beantworten
  • Autoritätsbereich: Enthält NS-Einträge für autoritative Server
  • Zusatzbereich: Enthält zusätzliche hilfreiche Einträge

Ressourceneintrag-Typen​

Gängige DNS-Ressourceneintrag (RR) -Typen umfassen:

  • A: IPv4-Adresse
  • AAAA: IPv6-Adresse
  • CNAME: Kanonischer Name (Alias)
  • MX: Mail-Exchanger
  • NS: Nameserver
  • PTR: Zeiger (Rückwärtssuche)
  • SOA: Start of Authority
  • TXT: Textzeichenfolgen

6.1.3 Spezifische Probleme​

6.1.3.1 Ressourceneintrag-Caching​

Ein DNS-Resolver sollte (SHOULD) Ressourceneinträge gemäß ihren Time-To-Live (TTL) -Werten zwischenspeichern. Der Resolver muss (MUST) die TTL-Werte respektieren.

6.1.3.2 Negatives Caching​

Ein Resolver sollte (SHOULD) negatives Caching implementieren, um Informationen über nicht existierende Domänennamen oder Ressourceneinträge zwischenzuspeichern.

6.1.3.3 Mehrere Adressen​

Wenn eine DNS-Anfrage mehrere Adressen zurückgibt, sollte (SHOULD) der Resolver alle Adressen versuchen, wenn die erste Verbindung fehlschlägt.

6.1.3.4 CNAME-Einträge​

Ein Resolver muss (MUST) CNAME-Einträge korrekt handhaben, indem er der CNAME-Kette folgt, um die tatsächliche Adresse zu erhalten.

6.1.4 Zusammenfassung der DNS-Anforderungen​

FunktionalitätAbschnittMUSTSHOULDMAYBemerkungen
DNS-Resolver implementieren6.1.1✓
Ressourceneinträge cachen6.1.3.1✓
TTL-Werte respektieren6.1.3.1✓
Negatives Caching implementieren6.1.3.2✓
CNAME-Einträge handhaben6.1.3.4✓
Mehrere Adressen versuchen6.1.3.3✓

6.2 HOST INITIALIZATION (Host-Initialisierung)​

6.2.1 Einführung​

Host-Initialisierung bezieht sich auf den Prozess, bei dem ein Host beim Start seine Konfigurationsparameter erhält. Gängige Protokolle für die Host-Initialisierung umfassen:

  • BOOTP: Bootstrap-Protokoll
  • DHCP: Dynamic Host Configuration Protocol
  • RARP: Reverse ARP

6.2.2 Protokoll-Durchgang​

BOOTP/DHCP​

BOOTP und DHCP ermöglichen es einem Host, seine IP-Adresse, Subnetzmaske, Standard-Gateway und andere Konfigurationsparameter von einem Server zu ermitteln.

Der Prozess umfasst typischerweise:

  1. Entdeckung: Client sendet eine Entdeckungsnachricht als Broadcast
  2. Angebot: Server bietet Konfigurationsparameter an
  3. Anfrage: Client fordert spezifische Parameter an
  4. Bestätigung: Server bestätigt die Konfiguration

6.2.3 Spezifische Probleme​

6.2.3.1 Konfigurationsparameter​

Ein Host-Initialisierungsprotokoll sollte (SHOULD) mindestens die folgenden Parameter bereitstellen:

  • IP-Adresse
  • Subnetzmaske
  • Standard-Gateway
  • DNS-Server-Adressen

6.2.3.2 Lease-Zeit​

Für Protokolle wie DHCP, die gemietete Adressen verwenden, muss (MUST) der Client die Lease-Zeit einhalten und das Lease vor Ablauf erneuern.

6.2.4 Zusammenfassung der Initialisierungsanforderungen​

FunktionalitätAbschnittMUSTSHOULDMAYBemerkungen
BOOTP/DHCP unterstützen6.2.1✓
Basis-Konfigurationsparameter bereitstellen6.2.3.1✓
Lease-Zeit einhalten6.2.3.2✓

6.3 REMOTE MANAGEMENT (Fernverwaltung)​

6.3.1 Einführung​

Remote-Management-Protokolle ermöglichen es Netzwerkadministratoren, Internet-Hosts aus der Ferne zu überwachen und zu verwalten. Das Hauptprotokoll für Remote-Management ist:

  • SNMP: Simple Network Management Protocol

6.3.2 Protokoll-Durchgang​

SNMP verwendet ein Manager-Agent-Modell:

  • Manager: Verwaltungsstation, die Agents abfragt
  • Agent: Software, die auf verwalteten Geräten läuft und auf Anfragen antwortet

SNMP-Operationen​

  • GET: Eine Verwaltungsvariable abrufen
  • GET-NEXT: Die nächste Verwaltungsvariable abrufen
  • SET: Eine Verwaltungsvariable ändern
  • TRAP: Asynchrone Benachrichtigung vom Agent an den Manager

Management Information Base (MIB)​

Die MIB definiert die Struktur und Semantik von Verwaltungsinformationen. Jedes verwaltbare Objekt wird durch einen Object Identifier (OID) identifiziert.

6.3.3 Spezifische Probleme​

6.3.3.1 SNMP-Implementierung​

Ein Host kann (MAY) einen SNMP-Agent implementieren. Falls implementiert, sollte (SHOULD) der Agent mindestens MIB-II unterstützen.

6.3.3.2 Sicherheit​

SNMP-Implementierungen sollten (SHOULD) community-basierte Zugriffskontrolle implementieren. Für SNMPv3 sollten (SHOULD) Implementierungen Authentifizierung und Verschlüsselung unterstützen.

6.3.4 Zusammenfassung der Verwaltungsanforderungen​

FunktionalitätAbschnittMUSTSHOULDMAYBemerkungen
SNMP-Agent implementieren6.3.3.1✓
MIB-II unterstützen6.3.3.1✓
Zugriffskontrolle implementieren6.3.3.2✓
Letztes Update am