DNS-Management Leitfaden
Einführung
DNS ist einer der grundlegenden Bausteine des Internets.
Immer wenn eine Website aufgerufen, eine E-Mail gesendet oder eine API angesprochen wird, ist DNS im Hintergrund beteiligt.
Um DNS-Verwaltung wirklich zu verstehen, ist es wichtig, die folgenden Konzepte zu kennen:
- Domain
- Nameserver
- DNS
- Zone
- DNS-Records
- TTL (Time to Live)
- Caching
Dieser Leitfaden erklärt die Grundlagen verständlich, zeigt einfache Beispiele und beschreibt typische Verhaltensweisen sowie deren Auswirkungen im täglichen Betrieb.
1. Was ist DNS?
DNS steht für Domain Name System.
DNS funktioniert wie das Telefonbuch des Internets.
Menschen verwenden leicht zu merkende Namen wie:
example.com
google.com
shop.example.com
142.250.185.14 (IPv4)
2a00:1450:4001:82b::200e (IPv6)
Beispiel:
example.com -> 93.184.216.34
Ohne DNS müssten sich Nutzer die IP-Adresse jedes einzelnen Dienstes merken, den sie verwenden.
2. Grundbegriffe und Terminologie
2.1 Domain
Eine Domain ist der für Menschen lesbare Name einer Internetadresse.
Beispiele:
example.com
company.org
shop.mycompany.com
Struktur:
shop.mycompany.com
│ │ │
│ │ └── Top-Level-Domain (TLD)
│ └──────────── Hauptdomain
└───────────────── Subdomain
2.2 Nameserver
Ein Nameserver beantwortet DNS-Anfragen für eine Domain.
Wenn jemand wissen möchte:
„Welche IP-Adresse gehört zu example.com?“
wird der zuständige Nameserver abgefragt.
Beispiel:
example.com
Nameserver:
- ns1.provider.net
- ns2.provider.net
Diese Nameserver enthalten die DNS-Konfiguration der Domain.
2.3 DNS-Zone
Eine DNS-Zone ist die eigentliche Konfiguration einer Domain.
Sie enthält alle DNS-Einträge, zum Beispiel:
- Websites
- Mailserver
- Subdomains
- Sicherheits-Einträge
- Verifizierungs-Einträge
Beispiel:
example.com. A 203.0.113.10
www CNAME example.com.
mail A 203.0.113.20
2.4 Subdomain
Eine Subdomain ist ein Präfix vor einer Hauptdomain, das verwendet wird, um verschiedene Dienste, Systeme oder Umgebungen innerhalb derselben Domain zu trennen.
Damit lässt sich eine Domain in logische Bereiche strukturieren, ohne neue Domains registrieren zu müssen.
Beispiele:
www.example.com
shop.example.com
api.example.com
dev.example.com
Struktur:
api.shop.example.com
│ │ │ │
│ │ │ └── Top-Level-Domain (TLD)
│ │ └────────── Hauptdomain
│ └─────────────── Subdomain (shop)
└─────────────────── Subdomain (api)
Wie Subdomains im DNS funktionieren
Eine Subdomain ist einfach ein weiterer DNS-Eintrag innerhalb derselben Zone.
Beispiel-Zonen-Einträge:
example.com. A 203.0.113.10
www CNAME example.com.
shop A 203.0.113.20
api A 203.0.113.30
Ein A-Record ordnet eine Domain oder Subdomain direkt einer IPv4-Adresse zu (z. B. example.com → 203.0.113.10).
Ein CNAME-Record erstellt einen Alias, der einen Domainnamen auf einen anderen Hostnamen verweist statt auf eine IP-Adresse (z. B. www.example.com → example.com).
Eigenschaften von Subdomains
Jede Subdomain kann:
- auf einen eigenen Server zeigen
- einen anderen Dienst bereitstellen
- eigene TTL-Werte haben
- unterschiedliche Record-Typen nutzen
2.5 Häufige Anwendungsfälle
| Subdomain | Anwendung |
|---|---|
| www.example.com | Website |
| api.example.com | Backend / API |
| shop.example.com | E-commerce system |
| dev.example.com | Development environment |
| mail.example.com | Mail services |
3. DNS-Zonen im Detail
Die Zone ist die zentrale Komponente jeder DNS-Konfiguration.
Man kann sie sich wie eine technische Konfigurationsdatei vorstellen.
3.1 Aufbau einer Zone
Eine Zone besteht aus mehreren DNS-Einträgen.
Beispiel:
example.com
├── @
├── www
├── shop
├── api
└── _dmarc
Jeder Eintrag kann:
- auf unterschiedliche Systeme zeigen
- eigene TTL-Werte haben
- verschiedene Record-Typen verwenden
3.2 Zentrale DNS-Konzepte & Benennung
| Begriff | Bedeutung |
|---|---|
| Zone | Gesamte DNS-Konfiguration einer Domain |
| Resource Record (RR) | Einzelner DNS-Eintrag |
| RRset | Gruppe von Records mit gleichem Namen und Typ |
| Record Type (RR Type) | Art des DNS-Records (z. B. A, MX, TXT usw.) |
| Owner Name | Domain oder Subdomain, zu der der Record gehört |
| TTL | Cache-Dauer eines DNS-Records |
Beispiel 1 (Web)
Zone:
example.com
RR: www.example.com. 300 IN A 203.0.113.10
RRset:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN A 203.0.113.11
Record Type:
A
Owner Name:
www.example.com
TTL:
300
Beispiel 2 (Web + Mail)
Zone:
company.io
RR: company.io. 3600 IN A 198.51.100.10
RRset (MX):
company.io. 3600 IN MX 10 mail.company.io.
company.io. 3600 IN MX 20 backup.company.io.
Record Types:
A, MX
Owner Names:
company.io, mail.company.io
TTL:
3600
3.3 Alternative Begriffe in der Praxis
| Kontext / Branche | Verwendeter Begriff | Bedeutung |
|---|---|---|
| RFC / DNS-Standards | Resource Record (RR) | Formeller DNS-Standardbegriff |
| Zone Files (BIND-Style) | DNS Record | Häufig verwendeter Konfigurationsbegriff |
| Cloud Provider (AWS, GCP, Azure) | DNS Entry / Record Set | API-orientierte Abstraktion |
| Load-Balancing-Systeme | RRset | Gruppe identischer Records zur Verteilung |
| DNS Engineering / Operations | RR / RRset | Technische Implementierungsbegriffe |
| DNS Management UI Panels | Record | Vereinfachter Begriff für Endnutzer |
3.4 TTL (Time To Live)
Der TTL (Time To Live) definiert, wie lange ein DNS-Record von Resolvern zwischengespeichert werden darf, bevor er erneut vom autoritativen Nameserver abgefragt werden muss (siehe später, was ein authoritative nameserver ist).
Ein Resolver ist das System (meist betrieben vom ISP, Unternehmensnetzwerk oder öffentlichen DNS-Diensten wie 1.1.1.1 oder 8.8.8.8), das DNS-Anfragen im Namen von Clients auflöst. Er prüft zuerst seinen lokalen Cache. Wenn der TTL-Wert noch gültig ist, liefert er die gespeicherte Antwort direkt zurück. Ist der TTL abgelaufen, wird der Record erneut vom autoritativen Nameserver abgefragt.
Praktische Empfehlungen (Faustregeln)
Häufig wechselnde Websites (Deployments, Migrationen, A/B-Tests)
→ 60–300 Sekunden
Ermöglicht schnelle Änderungen, führt aber zu mehr DNS-Abfragen.
Neue Website / Initiale Einrichtung / Go-Live-Phase
→ 300–600 Sekunden
Flexibel während der ersten Anpassungen, später meist erhöhen.
Stabile Produktionswebsite (seltene Änderungen)
→ 3600–14400 Sekunden (1–4 Stunden)
Guter Kompromiss zwischen Performance und Änderbarkeit.
Sehr stabile Systeme (keine erwarteten Änderungen, z. B. Landing Pages)
→ 86400 Sekunden (24 Stunden)
Maximales Caching, minimale DNS-Last.
APIs / Apps mit dynamischer Infrastruktur (Autoscaling, Failover)
→ 60–300 Sekunden
Wichtig für schnelle Reaktion bei Infrastrukturänderungen.
Mail-Records (MX, SPF, DKIM)
→ 3600–86400 Sekunden
In der Regel stabil, daher höherer TTL sinnvoll, um Propagationsverzögerungen zu vermeiden.
3.5 Übersicht der DNS Resource Record Typen (RRTypes)
| RR-Typ | Vollständiger Name | Zweck | Häufige alternative Bezeichnungen |
|---|---|---|---|
| A | Address Record | Ordnet Hostnamen einer IPv4-Adresse zu | IPv4 Record |
| AAAA | IPv6 Address Record | Ordnet Hostnamen einer IPv6-Adresse zu | IPv6 Record |
| CNAME | Canonical Name Record | Alias auf einen anderen Hostnamen | Alias Record |
| MX | Mail Exchange Record | Definiert Mailserver für eine Domain | Mail Routing Record |
| TXT | Text Record | Freitext für SPF, DKIM, Verifizierung usw. | Verification / Policy Record |
| NS | Name Server Record | Delegiert DNS-Zuständigkeit an Nameserver | Delegation Record |
| SOA | Start of Authority | Metadaten und Steuerinformationen einer Zone | Zone Authority Record |
| PTR | Pointer Record | Reverse DNS (IP → Hostname) | Reverse Lookup Record |
| SRV | Service Record | Service-Discovery (Port + Zielhost) | Service Discovery Record |
| CAA | Certification Authority Authorization | Steuert SSL-Zertifikatsausstellung | Certificate Policy Record |
| DS | Delegation Signer | DNSSEC-Delegationsabsicherung | DNSSEC Chain Record |
| DNSKEY | DNS Public Key Record | Öffentlicher Schlüssel für DNSSEC | Security Key Record |
| NAPTR | Naming Authority Pointer | Erweiterte Service- und Routing-Logik | Rewrite / Routing Record |
3.6 Vollständiges Beispiel einer Zone
$ORIGIN example.com.
@ 3600 IN SOA ns1.provider.net. hostmaster.example.com. (
2026050701 ; Serial
3600 ; Refresh
900 ; Retry
1209600 ; Expire
300 ; Negative Cache TTL
)
@ 86400 IN NS ns1.provider.net.
@ 86400 IN NS ns2.provider.net.
@ 300 IN A 203.0.113.10
www 300 IN CNAME example.com.
mail 300 IN A 203.0.113.20
@ 300 IN MX 10 mail.example.com.
@ 300 IN TXT "v=spf1 include:_spf.google.com ~all"
_dmarc 300 IN TXT "v=DMARC1; p=reject"
4. Abfragen von DNS-Records und Zonen mit dig
dig („Domain Information Groper“) ist ein Standard-Kommandozeilen-Tool, das verwendet wird, um DNS-Informationen direkt von DNS-Servern abzufragen. Es wird häufig für Troubleshooting, Debugging und die Validierung von DNS-Konfigurationen genutzt.
Eine einfache Abfrage eines A-Records sieht so aus:
dig opusdns.com
Dies gibt die DNS-Antwort für die Domain zurück, einschließlich der aufgelösten IP-Adresse, TTL und des Record-Typs:
opusdns.com. 587 IN A 198.202.211.1
Spezifische Record-Typen können ebenfalls explizit abgefragt werden:
dig example.com A
dig example.com AAAA
dig example.com MX
dig example.com TXT
dig example.com NS
...
Authoritative Nameserver sind die DNS-Server, die die offizielle, endgültige Version der DNS-Daten einer Domain (der Zone) enthalten. Sie sind die „Source of Truth“ für eine Domain und verlassen sich nicht auf zwischengespeicherte Antworten anderer Server.
Wenn man sie direkt abfragt, umgeht man Zwischen-Resolver und Caches. Das ist besonders hilfreich, um zu prüfen, ob eine DNS-Änderung tatsächlich an der Quelle übernommen wurde.
Es ist außerdem möglich, einen bestimmten autoritativen Nameserver direkt abzufragen. Das ist besonders nützlich, um aktuelle DNS-Änderungen zu validieren oder Propagationsprobleme zu debuggen.
dig @ns1.opusdns.com example.com
dig @ns2.opusdns.net example.com