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!