Zum Hauptinhalt springen

2. Einführung (Introduction)

Dieses RFC führt Domänen-Stil-Namen (Domain Style Names), ihre Verwendung für Internet-Mail und Host-Adressunterstützung sowie die Protokolle und Server ein, die zur Implementierung von Domänennamen-Funktionen verwendet werden.

2.1. Die Geschichte der Domänennamen (The history of domain names)​

Der Anstoß für die Entwicklung des Domänensystems war das Wachstum des Internets:

Probleme des frühen HOSTS.TXT-Systems​

1. Skalierbarkeitsprobleme (Scalability Issues)​

Host-Namen-zu-Adress-Zuordnungen (Host name to address mappings) wurden vom Network Information Center (NIC) in einer einzigen Datei (HOSTS.TXT) gepflegt, die von allen Hosts per FTP abgerufen wurde [RFC-952, RFC-953].

Probleme:

  • Die Gesamtnetzwerkbandbreite, die für die Verteilung einer neuen Version durch dieses Schema verbraucht wird, ist proportional zum Quadrat der Anzahl der Hosts im Netzwerk
  • Selbst wenn mehrere FTP-Ebenen verwendet werden, ist die ausgehende FTP-Last auf dem NIC-Host beträchtlich
  • Das explosive Wachstum der Anzahl von Hosts verhieß nichts Gutes für die Zukunft

Mathematisches Modell:

N Hosts → N Downloads × Dateigröße = O(N²) Bandbreitenverbrauch

Beispiel:
100 Hosts: 10.000 Übertragungsoperationen
1.000 Hosts: 1.000.000 Übertragungsoperationen
10.000 Hosts: 100.000.000 Übertragungsoperationen

2. Zentralisierungsprobleme (Centralized Administration)​

Die Netzwerkpopulation änderte sich auch in ihrem Charakter:

  • Die Timesharing-Hosts, die das ursprüngliche ARPANET bildeten, wurden durch lokale Netzwerke von Workstations ersetzt
  • Lokale Organisationen verwalteten ihre eigenen Namen und Adressen
  • Mussten jedoch warten, bis das NIC HOSTS.TXT änderte, um Änderungen für das gesamte Internet sichtbar zu machen
  • Organisationen wünschten sich auch eine lokale Struktur im Namensraum (Name Space)

Problemzusammenfassung:

  • ❌ Einzelner Ausfallpunkt
  • ❌ Aktualisierungsverzögerung
  • ❌ Fehlende Hierarchie
  • ❌ Keine delegierte Verwaltung

3. Funktionsbeschränkungen (Functional Limitations)​

Die Anwendungen im Internet wurden ausgefeilter und erzeugten einen Bedarf an einem allgemeinen Namensdienst.

Die Geburt von DNS​

Das Ergebnis waren mehrere Ideen über Namensräume und deren Verwaltung [IEN-116, RFC-799, RFC-819, RFC-830].

Gemeinsame Merkmale:

  • Konzept eines hierarchischen Namensraums (hierarchical name space)
  • Hierarchie entspricht grob der Organisationsstruktur
  • Verwendung von . als Zeichen zur Markierung der Hierarchieebenen

Evolutionsprozess:

1983: Hierarchisches DNS-Konzept vorgeschlagen
  ↓
1984: RFC 882/883 - Initiales Design
  ↓
1987: RFC 1034/1035 - Standardisiertes DNS
  ↓
Kontinuierliche Evolution: DNSSEC, EDNS0 usw.

Ein Design mit einer verteilten Datenbank und generalisierten Ressourcen wurde in [RFC-882, RFC-883] beschrieben. Basierend auf Erfahrungen mit mehreren Implementierungen entwickelte sich das System zu dem in diesem Memo beschriebenen Schema.

Begriffsklärung​

Die Begriffe "Domäne (Domain)" oder "Domänenname (Domain Name)" werden in vielen Kontexten verwendet, die über das hier beschriebene DNS hinausgehen. Sehr oft wird der Begriff Domänenname verwendet, um einen Namen mit durch Punkte angezeigter Struktur zu bezeichnen, aber ohne Bezug zum DNS. Dies gilt insbesondere für Mail-Adressierung [Quarterman 86].

2.2. DNS-Designziele (DNS design goals)​

Die Designziele des DNS beeinflussen seine Struktur.

Ziel 1: Konsistenter Namensraum (Consistent Name Space)​

Primäres Ziel ist ein konsistenter Namensraum, der zur Referenzierung von Ressourcen verwendet wird.

Anforderungen:

  • Um die durch Ad-hoc-Kodierungen verursachten Probleme zu vermeiden
  • Namen sollten nicht erforderlich sein, Netzwerk-Identifikatoren, Adressen, Routen oder ähnliche Informationen als Teil des Namens zu enthalten
  • Namen sollten menschenlesbar und merkbar sein

Gegenbeispiele (schlechtes Design):

❌ host-192-168-1-1.network.com  (enthält IP-Adresse)
❌ router-path-a-b-c.network.com (enthält Routing-Informationen)
✅ www.example.com               (klarer semantischer Name)

Ziel 2: Verteilte Wartung (Distributed Maintenance)​

Die schiere Größe der Datenbank und die Häufigkeit von Aktualisierungen deuten darauf hin, dass sie in verteilter Weise gepflegt werden muss, mit lokalem Caching zur Leistungsverbesserung.

Prinzipien:

  • Ansätze, die versuchen, eine konsistente Kopie der gesamten Datenbank zu sammeln, werden immer teurer und schwieriger und sollten daher vermieden werden
  • Das gleiche Prinzip gilt für die Struktur des Namensraums, insbesondere für Mechanismen zum Erstellen und Löschen von Namen; diese sollten ebenfalls verteilt sein

Verteiltes Design:

Zentralisiert (HOSTS.TXT)           Verteilt (DNS)
      [NIC]                    [Wurzelserver]
       |                      /     |     \
    Alle Hosts               [.com] [.org] [.net]
                           /  |    |  \
                          mehr Hierarchie...

Ziel 3: Datenquellenkontrolle von Kompromissen (Data Source Controls Tradeoffs)​

Wo es Kompromisse zwischen den Kosten für den Erwerb von Daten, der Geschwindigkeit von Updates und der Genauigkeit von Caches gibt, sollte die Quelle der Daten den Kompromiss kontrollieren.

Implementierungsmechanismus:

  • TTL (Time To Live) Werte werden vom autoritativen Server gesetzt
  • Datenbesitzer entscheidet über Cache-Strategie
  • Flexibilität: von Sekunden bis Tagen

Beispiel:

; Statische Daten - lange TTL
www  3600  IN  A  93.184.216.34  ; 1 Stunde

; Dynamische Daten - kurze TTL  
api  60    IN  A  93.184.216.35  ; 1 Minute

Ziel 4: Allgemeine Nützlichkeit (General Usefulness)​

Die Kosten für die Implementierung einer solchen Einrichtung diktieren, dass sie allgemein nützlich sein sollte und nicht auf eine einzelne Anwendung beschränkt.

Mehrzweck-Unterstützung:

  • Host-Adressen (A, AAAA-Einträge)
  • Mailbox-Daten (MX-Einträge)
  • Andere noch unbestimmte Informationen (TXT, SRV usw.)

Typ-Markierung:

  • Alle mit einem Namen verbundenen Daten werden mit einem Typ markiert
  • Abfragen können auf einen einzelnen Typ beschränkt werden
  • Erweiterbarkeit: neue Typen können definiert werden

Ziel 5: Protokollfamilien-Unabhängigkeit (Protocol Family Independence)​

Da wir möchten, dass der Namensraum in unterschiedlichen Netzwerken und Anwendungen nützlich ist, bieten wir die Fähigkeit, denselben Namensraum mit verschiedenen Protokollfamilien oder Verwaltung zu verwenden.

Klassen- und Typsystem:

  • DNS markiert alle Daten mit Klasse (class) und Typ (type)
  • Ermöglicht parallele Verwendung verschiedener Formate für Daten

Beispiel:

Klasse (Class):
- IN (Internet) - Internet
- CH (Chaos) - Chaos-Netzwerk
- HS (Hesiod) - Hesiod-System

Typ (Type):
- A - IPv4-Adresse
- AAAA - IPv6-Adresse
- Für verschiedene Protokolle können verschiedene Formate definiert werden

Ziel 6: Transportunabhängigkeit (Transport Independence)​

Wir möchten, dass Nameserver-Transaktionen unabhängig vom Kommunikationssystem sind, das sie trägt.

Flexibilität:

  • Einige Systeme möchten möglicherweise Datagramme (UDP) für Abfragen und Antworten verwenden
  • Nur für Transaktionen, die Zuverlässigkeit benötigen (z. B. Datenbankaktualisierungen, lange Transaktionen), virtuelle Verbindungen (TCP) einrichten
  • Andere Systeme werden ausschließlich virtuelle Verbindungen verwenden

Praktische Implementierung:

UDP (Standard):
- Schnelle Abfragen/Antworten
- 512-Byte-Begrenzung (traditionell)
- Geeignet für die meisten Abfragen

TCP (Backup):
- Zonenübertragungen (AXFR, IXFR)
- Antworten > 512 Bytes
- Szenarien, die Zuverlässigkeit benötigen

Ziel 7: Breite Host-Fähigkeitsspanne (Wide Host Capability Spectrum)​

Das System sollte über ein breites Spektrum von Host-Fähigkeiten hinweg nützlich sein.

Anpassungsfähigkeit:

  • Sowohl Personal Computer als auch große Timesharing-Hosts sollten das System nutzen können
  • Möglicherweise auf unterschiedliche Weise

Implementierungsebenen:

Minimale Implementierung:
- Stub-Resolver (Stub Resolver)
- Abhängig von rekursivem Server

Standard-Implementierung:
- Vollständiger Resolver
- Lokaler Cache

Erweiterte Implementierung:
- Autoritativer Nameserver
- Zonenverwaltung
- Master/Slave-Synchronisation

2.3. Annahmen zur Nutzung (Assumptions about usage)​

Die Organisation des Domänensystems leitet sich aus einigen Annahmen über die Bedürfnisse und Nutzungsmuster seiner Benutzergemeinschaft ab und ist so konzipiert, dass viele der komplizierten Probleme vermieden werden, die in allgemeinen Datenbanksystemen zu finden sind.

Annahme 1: Datenbankgrößen-Wachstumsmuster​

Die Größe der Gesamtdatenbank wird zunächst proportional zur Anzahl der das System verwendenden Hosts sein, wird aber schließlich proportional zur Anzahl der Benutzer auf diesen Hosts wachsen, wenn Mailboxen und andere Informationen zum Domänensystem hinzugefügt werden.

Wachstumsphasen:

Phase 1: Host-Einträge dominieren
- 1-2 Einträge pro Host
- O(hosts)

Phase 2: Benutzer-Einträge nehmen zu
- Mehrere Einträge pro Benutzer möglich
- O(users) >> O(hosts)

Phase 3: IoT-Zeitalter
- Jedes Gerät kann Einträge haben
- O(devices) >>> O(users)

Annahme 2: Datenänderungsrate​

Die meisten Daten im System werden sich sehr langsam ändern (z. B. Mailbox-Bindungen, Host-Adressen), aber das System sollte in der Lage sein, mit Teilmengen umzugehen, die sich schneller ändern (in der Größenordnung von Sekunden oder Minuten).

Datenkategorien:

KategorieÄnderungshäufigkeitTTL-EmpfehlungBeispiel
StatischSeltenTageNS-Einträge
Semi-statischGelegentlichStundenA-Einträge
DynamischHäufigMinutenLoad-Balancing-Einträge
EchtzeitKontinuierlichSekundenCDN-Edge-Knoten

Annahme 3: Administrative Grenzen entsprechen Organisationen​

Die zur Verteilung der Verantwortung für die Datenbank verwendeten administrativen Grenzen werden normalerweise Organisationen entsprechen, die einen oder mehrere Hosts haben.

Verantwortungszuweisung:

  • Jede Organisation, die Verantwortung für eine bestimmte Gruppe von Domänen hat, wird redundante Nameserver bereitstellen
  • Kann auf den eigenen Hosts der Organisation sein
  • Oder auf anderen Hosts, deren Nutzung die Organisation vereinbart

Beispielarchitektur:

example.com (Organisation A verantwortlich)
├── ns1.example.com (Primärserver)
└── ns2.example.com (Sekundärserver)

Oder mit Hosting-Service:
├── ns1.provider.net (gehostet)
└── ns2.provider.net (gehostet)

Annahme 4: Vertrauenswürdige Nameserver​

Clients des Domänensystems sollten in der Lage sein, vertrauenswürdige Nameserver zu identifizieren, die sie bevorzugt verwenden möchten, bevor sie Verweise auf Nameserver außerhalb dieser "vertrauenswürdigen" Menge akzeptieren.

Sicherheitsüberlegungen:

  • Lokale Konfiguration bevorzugter DNS-Server
  • DNSSEC-Validierung
  • Vermeidung von DNS-Hijacking

Annahme 5: Verfügbarkeit vor Konsistenz (Availability > Consistency)​

Der Zugriff auf Informationen ist wichtiger als sofortige Updates oder Konsistenzgarantien.

Eventual-Consistency-Modell:

  • Der Aktualisierungsprozess ermöglicht, dass Updates durch die Benutzer des Domänensystems durchsickern
  • Statt zu garantieren, dass alle Kopien gleichzeitig aktualisiert werden
  • Wenn Updates aufgrund von Netzwerk- oder Host-Ausfällen nicht verfügbar sind, besteht der übliche Kurs darin, alten Informationen zu glauben, während die Bemühungen zur Aktualisierung fortgesetzt werden

Verteilungsmodell:

Primärserver
   ↓ (TTL setzen)
Kopie 1 (verantwortlich für Auffrischung)
Kopie 2 (verantwortlich für Auffrischung)
Kopie 3 (verantwortlich für Auffrischung)

Besondere Situationen:
- Sehr kurze Intervalle
- Kopien verbieten (TTL=0)

Annahme 6: Rekursiv vs. Iterativ​

In jedem System mit einer verteilten Datenbank kann einem bestimmten Nameserver eine Abfrage vorgelegt werden, die nur von einem anderen Server beantwortet werden kann.

Zwei Ansätze:

Rekursiv (Recursive)​

Der erste Server verfolgt die Abfrage für den Client bei einem anderen Server.

Client → DNS1 → DNS2 → DNS3 → Antwort
           ← ← ← ← ← ← ← ← ← ← ← 
Client ← DNS1 (gibt endgültige Antwort zurück)

Vorteile:

  • Client einfach
  • Reduziert Client-Netzwerkverkehr

Nachteile:

  • Hohe Serverlast
  • Kann für DDoS ausgenutzt werden

Iterativ (Iterative)​

Der Server verweist den Client an einen anderen Server und lässt den Client die Abfrage verfolgen.

Client → DNS1 → Verweis auf DNS2
Client → DNS2 → Verweis auf DNS3
Client → DNS3 → Endgültige Antwort

Vorteile:

  • Niedrige Serverlast
  • Bessere Fehlerisolierung

Nachteile:

  • Client komplexer
  • Mehr Netzwerk-Roundtrips

DNS-Anforderungen:

  • ✅ Muss iterative Methode implementieren
  • ✅ Erlaubt rekursive Methode als Option
  • ⭐ Iterative Methode ist für Datagramm-Zugriffsstil bevorzugt

2.4. Elemente des DNS (Elements of the DNS)​

Das DNS hat drei Hauptkomponenten:

Komponente 1: Domänennamen-Raum und Ressourceneinträge (DOMAIN NAME SPACE and RESOURCE RECORDS)​

Spezifikationen für einen baumstrukturierten Namensraum und mit den Namen verbundene Daten.

Konzept:

  • Jeder Knoten und jedes Blatt des Domänennamensraum-Baums benennt einen Satz von Informationen
  • Abfrageoperationen sind Versuche, bestimmte Arten von Informationen aus einem bestimmten Satz zu extrahieren
  • Eine Abfrage benennt den interessierenden Domänennamen und beschreibt die Art der gewünschten Ressourceninformation

Beispiel:

Abfrage: A-Eintrag für www.example.com
→ Extrahiert Adressressourceninformationen dieses Knotens
→ Gibt Internet-Host-Adresse zurück

Komponente 2: Nameserver (NAME SERVERS)​

Serverprogramme, die Informationen über die Struktur des Domänenbaums und Set-Informationen enthalten.

Merkmale:

  • Kann Struktur- oder Set-Informationen über jeden Teil des Domänenbaums zwischenspeichern
  • Im Allgemeinen hat ein bestimmter Nameserver vollständige Informationen über eine Teilmenge des Domänenraums
  • Hat Zeiger auf andere Nameserver, die verwendet werden können, um zu Informationen aus jedem Teil des Domänenbaums zu führen

Autorität (AUTHORITY):

  • Nameserver kennen die Teile des Domänenbaums, für die sie vollständige Informationen haben
  • Für diese Namensraum-Teile wird der Nameserver als AUTORITÄT (AUTHORITY) bezeichnet
  • Autoritative Informationen sind in Einheiten organisiert, die ZONEN (ZONES) genannt werden
  • Diese Zonen können automatisch an die Nameserver verteilt werden, die redundanten Service für die Daten in einer Zone bereitstellen

Zonenarchitektur:

example.com Zone
├── SOA-Eintrag (Autoritätsbeginn)
├── NS-Einträge (Nameserver)
├── Host-Einträge (www, mail usw.)
└── Subdomänen-Delegierung (sub.example.com)

Komponente 3: Resolver (RESOLVERS)​

Programme, die Informationen von Nameservern als Antwort auf Client-Anfragen extrahieren.

Anforderungen:

  • Muss in der Lage sein, auf mindestens einen Nameserver zuzugreifen
  • Verwendet die Informationen dieses Nameservers, um eine Abfrage direkt zu beantworten
  • Oder verfolgt die Abfrage unter Verwendung von Verweisen auf andere Nameserver

Implementierungsformen:

  • Wird typischerweise eine Systemroutine sein, die für Benutzerprogramme direkt zugänglich ist
  • Daher ist kein Protokoll zwischen dem Resolver und dem Benutzerprogramm erforderlich

Resolver-Typen:

Stub-Resolver (Stub Resolver):
- Minimale Implementierung
- Abhängig von rekursivem Server
- Üblich bei Clients

Vollständiger Resolver (Full Resolver):
- Kann iterative Abfragen ausführen
- Lokale Cache-Verwaltung
- Üblich bei DNS-Servern

Drei Ansichten des Domänensystems​

Ansicht 1: Benutzersicht (User's Point of View)​

Aus Sicht des Benutzers:

  • Das Domänensystem wird über eine einfache Prozedur oder einen OS-Aufruf an einen lokalen Resolver zugegriffen
  • Der Domänenraum besteht aus einem einzigen Baum
  • Der Benutzer kann Informationen aus jedem Abschnitt des Baums anfordern

Benutzererfahrung:

# Einfache Schnittstelle
import socket
ip = socket.gethostbyname('www.example.com')
# Benutzer kümmert sich nicht um interne Auflösung

Ansicht 2: Resolver-Sicht (Resolver's Point of View)​

Aus Sicht des Resolvers:

  • Das Domänensystem besteht aus einer unbekannten Anzahl von Nameservern
  • Jeder Nameserver hat ein oder mehrere Teile der Daten des gesamten Domänenbaums
  • Der Resolver betrachtet jede dieser Datenbanken als im Wesentlichen statisch

Resolver-Verantwortlichkeiten:

  • Abfragen des angemessenen Nameservers
  • Behandlung von Verweisen
  • Cache-Verwaltung
  • Behandlung von Timeouts und Wiederholungen

Ansicht 3: Nameserver-Sicht (Name Server's Point of View)​

Aus Sicht eines Nameservers:

  • Das Domänensystem besteht aus separaten Sätzen lokaler Informationen, die Zonen (zones) genannt werden
  • Der Nameserver hat lokale Kopien einiger der Zonen
  • Muss seine Zonen periodisch von Masterkopien in lokalen Dateien oder fremden Nameservern auffrischen
  • Muss gleichzeitig Abfragen verarbeiten, die von Resolvern ankommen

Nameserver-Verantwortlichkeiten:

  • Zonendaten laden
  • Auf Abfragen antworten
  • Zonenübertragungen (AXFR/IXFR)
  • Cache warten
  • Updates verarbeiten

Funktionskopplung (Function Coupling)​

Im Interesse der Leistung können Implementierungen diese Funktionen koppeln.

Beispiel:

  • Ein Resolver auf demselben Rechner wie ein Nameserver könnte eine Datenbank teilen
  • Die Datenbank besteht aus den vom Nameserver verwalteten Zonen und dem vom Resolver verwalteten Cache

Gemeinsame Konfiguration:

Kombinierter Server:
- Autoritativer Nameserver (Zonendaten)
+ Rekursiver Resolver (Cache-Daten)
= Vollständiger DNS-Server (BIND, Unbound usw.)

Verantwortlichkeiten von Systemadministratoren und Domänensystem​

Systemadministratoren stellen bereit:​

  1. ✅ Definition von Zonengrenzen
  2. ✅ Masterdateien mit Daten
  3. ✅ Aktualisierungen der Masterdateien
  4. ✅ Aussagen über die gewünschten Auffrischungsrichtlinien

Das Domänensystem stellt bereit:​

  1. ✅ Standardformate für Ressourcendaten
  2. ✅ Standardmethoden zur Abfrage der Datenbank
  3. ✅ Standardmethoden für Nameserver, um lokale Daten von fremden Nameservern aufzufrischen

Kooperationsbeziehung:

Administrator → Erstellt/Aktualisiert Zonendateien
   ↓
DNS-System → Lädt/Verteilt/Abfragt
   ↓
Benutzer/Anwendung ← Erhält Informationen

Zusammenfassung der Schlüsselkonzepte​

Kernprobleme, die DNS löst​

  1. ✅ Skalierbarkeit: Von O(N²) zu O(log N)
  2. ✅ Verteilte Verwaltung: Jede Organisation verwaltet ihre eigene Domäne
  3. ✅ Hohe Verfügbarkeit: Redundante Server, Cache-Mechanismus
  4. ✅ Flexibilität: Erweiterbares Typ- und Klassensystem
  5. ✅ Leistung: Lokaler Cache, hierarchische Abfragen

Design-Kompromisse von DNS​

EigenschaftWahlGrund
Konsistenz vs. VerfügbarkeitVerfügbarkeit bevorzugtEventual-Consistency-Modell
Rekursiv vs. IterativBeide unterstütztAnpassung an verschiedene Szenarien
Zentral vs. VerteiltVerteiltSkalierbarkeit und Fehlertoleranz
Sofort vs. CacheCache bevorzugtLeistungsüberlegungen

Nächstes Kapitel: 3. Domain Name Space and Resource Records - Vertiefung in die Domänennamen-Raum-Struktur und Ressourceneintragsformate

Letztes Update am