Zum Hauptinhalt springen

DNS-Protokoll Technischer Leitfaden (RFC 1035)

Dieses Dokument ist ein detaillierter technischer Leitfaden zu RFC 1035, einschließlich Nachrichtenformat, Ressourceneintragtypen, praktischen Beispielen und Werkzeuganleitungen. Für offizielle RFC-Kapitelübersetzungen siehe die einzelnen Kapiteldokumente.

Dokumentinformationen

  • RFC-Nummer: 1035
  • Titel: Domain Names - Implementation and Specification
  • Titel (Deutsch): Domainnamen - Implementierung und Spezifikation
  • Veröffentlichungsdatum: November 1987
  • Autor: P. Mockapetris (USC/Information Sciences Institute)
  • Status: INTERNET STANDARD (STD 13)

Zusammenfassung

Dieses RFC definiert die Implementierungsdetails von DNS (Domain Name System), einschließlich Nachrichtenformat, Ressourceneintragformat und Verhaltensspezifikationen für Nameserver und Resolver. Dieses Dokument ist das Gegenstück zu RFC 1034 (DNS-Konzepte und -Einrichtungen), wobei RFC 1034 die Konzepte und dieses Dokument die spezifische Implementierung definiert.

Kernkonzept: RFC 1035 ist die Implementierungsspezifikation von DNS und definiert Nachrichtenformat, Eintragstypen und Implementierungsdetails.

Beziehung zu RFC 1034

RFC 1034 (Konzepte)         RFC 1035 (Implementierung)
───────────────── ─────────────────
✓ Was ist DNS → ✓ Nachrichtenformat
✓ Domainnamen-Struktur → ✓ Ressourceneintragformat
✓ Nameserver-Architektur → ✓ Auflösungsalgorithmen
✓ Cache-Strategie → ✓ Kompressionsmechanismus
✓ Abfragetypen → ✓ Protokolldetails

Empfehlung:
Zuerst RFC 1034 für Konzepte lesen
Dann RFC 1035 für Implementierung verstehen

DNS-Nachrichtenformat

Nachrichtenstruktur

Alle DNS-Nachrichten verwenden dasselbe Format:

+---------------------+
| Header | 12 Bytes, fest
+---------------------+
| Question | Frageabschnitt (variable Länge)
+---------------------+
| Answer | Antwortabschnitt (variable Länge)
+---------------------+
| Authority | Autoritätsabschnitt (variable Länge)
+---------------------+
| Additional | Zusätzlicher Abschnitt (variable Länge)
+---------------------+

Header-Format

                                    1  1  1  1  1  1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Gesamtlänge: 12 Bytes

Felddetails

ID (16 Bits): Abgleich Abfrage/Antwort. Bereich: 0-65535

QR (1 Bit): 0 = Query (Abfrage), 1 = Response (Antwort)

Opcode (4 Bits): 0 = QUERY (Standardabfrage), 1 = IQUERY (veraltet), 2 = STATUS

AA (1 Bit): Authoritative Answer - Autoritative Antwort-Flag

TC (1 Bit): Truncation - Abschneidungs-Flag (UDP 512-Byte-Überschreitung)

RD (1 Bit): Recursion Desired - Rekursion gewünscht

RA (1 Bit): Recursion Available - Rekursion verfügbar

Z (3 Bits): Reserviert (muss 0 sein)

RCODE (4 Bits): Response Code

RCODEBedeutungBeschreibung
0NOERRORErfolg
1FORMERRFormatfehler
2SERVFAILServerfehler
3NXDOMAINDomainname existiert nicht
4NOTIMPNicht unterstützt
5REFUSEDAbfrage abgelehnt

Question-Section-Format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

QNAME: Abzufragender Domainname (variable Länge)
QTYPE: Abfragetyp (16 Bits)
QCLASS: Abfrageklasse (16 Bits, normalerweise 1=IN)

QNAME-Kodierung

Domainname: www.example.com

Kodierung:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|03| w w w |07| e x a m p l e |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|02| c o m |00|
+--+--+--+--+--+

Format:
- Länge vor jedem Label (1 Byte)
- Label-Inhalt (ASCII-Zeichen)
- Endet mit 0

Beispiel: "www.example.com" = 3 "www" 7 "example" 3 "com" 0
Wurzel-Domainname: 0 (einzelnes 0-Byte)

QTYPE (Abfragetyp)

WertTypBeschreibung
1AIPv4-Adresse
2NSNameserver
5CNAMEKanonischer Name (Alias)
6SOAAutoritätsbeginn
12PTRZeiger (Rückwärtsauflösung)
15MXMail-Exchange
16TXTTexteintrag
28AAAAIPv6-Adresse
255ANYAlle Einträge (nicht empfohlen)

Details zu Ressourceneintragtypen

A-Eintrag - IPv4-Adresse

TYPE = 1
RDLENGTH = 4 (Bytes)
RDATA = 32-Bit-IPv4-Adresse

Beispiel:
NAME: example.com
TYPE: A (1)
CLASS: IN (1)
TTL: 3600
RDLENGTH: 4
RDATA: 93.184.216.34

Kodierung (RDATA):
93.184.216.34 → 0x5DB8D822

NS-Eintrag - Nameserver

TYPE = 2
RDATA = Domainname des Nameservers

Beispiel:
NAME: example.com
TYPE: NS (2)
TTL: 86400
RDATA: ns1.example.com

Bedeutung: Der autoritative Server für example.com ist ns1.example.com

CNAME-Eintrag - Alias

TYPE = 5
RDATA = Kanonischer Name

Beispiel:
NAME: www.example.com
TYPE: CNAME (5)
TTL: 3600
RDATA: example.com

Bedeutung: www.example.com ist ein Alias für example.com

Abfragefluss:
Abfrage www.example.com A
→ Gibt CNAME example.com zurück
→ Setzt Abfrage für example.com A fort
→ Gibt 93.184.216.34 zurück

SOA-Eintrag - Autoritätsbeginn

TYPE = 6
RDATA-Format:
MNAME: Primärer Nameserver
RNAME: Verantwortliches Postfach
SERIAL: Seriennummer
REFRESH: Aktualisierungsintervall
RETRY: Wiederholungsintervall
EXPIRE: Ablaufzeit
MINIMUM: Minimales TTL

Beispiel:
NAME: example.com
TYPE: SOA (6)
TTL: 86400
RDATA:
MNAME: ns1.example.com
RNAME: admin.example.com ([email protected])
SERIAL: 2024010101
REFRESH: 3600
RETRY: 600
EXPIRE: 604800
MINIMUM: 86400

Zweck:
- Zonen-Autoritätsinformationen identifizieren
- Zonentransfers steuern
- Cache-Richtlinien festlegen

MX-Eintrag - Mail-Exchange

TYPE = 15
RDATA-Format:
PREFERENCE: Priorität (16 Bits)
EXCHANGE: Mailserver-Domainname

Beispiel:
NAME: example.com
TYPE: MX (15)
TTL: 3600
RDATA:
PREFERENCE: 10
EXCHANGE: mail1.example.com

Mehrere MX-Einträge:
example.com MX 10 mail1.example.com
example.com MX 20 mail2.example.com
example.com MX 30 mail3.example.com

Verarbeitung:
- Niedrigere numerische Werte bevorzugen
- Zufällige Auswahl bei gleicher Priorität
- Bei Fehler nächsten versuchen

DNS-Nachrichtenkompression

Um doppelte Domainnamen zu komprimieren, verwendet DNS Zeiger:

Kompressionsformat:

Domainnamen-Label-Länge:
- 00-3F: Normale Label-Länge (0-63)
- C0-FF: Zeiger (11xxxxxx xxxxxxxx)

Zeiger-Format:
11 <14-Bit-Offset>

Beispiel:
Ursprüngliche Nachricht:
Offset 12: 3 "www" 7 "example" 3 "com" 0
Offset 30: 7 "example" 3 "com" 0

Nach Kompression:
Offset 12: 3 "www" 7 "example" 3 "com" 0
Offset 30: C0 0x11 (zeigt auf Offset 12+4="example")

Ersparnis:
30: "example.com" (12 Bytes)
Komprimiert: C0 0x11 (2 Bytes)
Ersparnis: 10 Bytes

Praktische Werkzeuge

dig-Befehl detailliert

# Grundlegende Abfrage
dig example.com

# Eintragstyp angeben
dig example.com A # IPv4
dig example.com AAAA # IPv6
dig example.com MX # Mailserver
dig example.com NS # Nameserver
dig example.com TXT # Texteinträge

# DNS-Server angeben
dig @8.8.8.8 example.com

# Abfragepfad verfolgen
dig +trace example.com

# Kurze Ausgabe
dig +short example.com

# Rückwärtsauflösung
dig -x 93.184.216.34

# TCP-Abfrage
dig +tcp example.com

nslookup-Verwendung

# Interaktiver Modus
nslookup
> example.com
> set type=MX
> example.com
> exit

# Kommandozeilenmodus
nslookup example.com
nslookup -type=MX example.com
nslookup -type=NS example.com

host-Befehl

# Einfache Abfrage
host example.com

# Detaillierte Ausgabe
host -v example.com

# Eintragstyp angeben
host -t MX example.com
host -t NS example.com

Referenzen

Kern-RFCs:

  • [RFC 1034] Domain Names - Concepts and Facilities
  • [RFC 1035] Domain Names - Implementation and Specification ← Dieses Dokument

Erweiterungen und Updates:

  • [RFC 2181] Clarifications to the DNS Specification
  • [RFC 2308] Negative Caching of DNS Queries (DNS NCACHE)
  • [RFC 4033-4035] DNSSEC
  • [RFC 6891] Extension Mechanisms for DNS (EDNS(0))

Verwandte Protokolle:

  • [RFC 8484] DNS Queries over HTTPS (DoH)
  • [RFC 7858] DNS over TLS

Zusammenfassung: RFC 1035 definiert die Implementierungsdetails von DNS und ist ein Schlüsseldokument zum Verständnis der Funktionsweise des DNS-Protokolls. Vom Nachrichtenformat bis zu Ressourceneinträgen, vom Abfragefluss bis zum Kompressionsmechanismus bietet dieses RFC detaillierte Spezifikationen für alle DNS-Implementierungen. Zusammen mit RFC 1034 werden Sie das DNS-System vollständig verstehen!