Domain Name System/Server/Autoritative: Unterschied zwischen den Versionen

Aktuelle Version vom 15. Dezember 2025, 19:23 Uhr

Domain Name System/Server/Autoritative - Autoritativer Server

Beschreibung

Autoritative Server

Speicherung und Veröffentlichung autoritativer Daten
Speichert eine oder mehrere DNS-Zonen
Quelle der autoritativen Daten für diese Zonen

Rekursive Server

Der autoritative Server speichert keine Cache-Daten fremder Domains und greift nicht nach außen
Gibt nur Antworten für eigene Zonen und Delegationen zurück. Für Namen außerhalb der Zuständigkeit erfolgt typischerweise REFUSED. Negative Antworten innerhalb der autoritativen Zone sind NXDOMAIN oder NODATA
Der ausgehende Datenverkehr ist auf den Dienstverkehr beschränkt. AXFR/IXFR zum Master. NOTIFY zu den Slaves
Führt keine Rekursion durch

Rekursion wird nicht durchgeführt, auch wenn RD=1 gesetzt ist
RD wird in der Antwort gespiegelt
RA in der Antwort = 0

Rollen

Primary (Master)

Einzige Quelle für Zonenänderungen
Verwaltet den beschreibbaren Speicher/das Repository
Kann „versteckt” (hidden primary) sein und nicht im NS veröffentlicht werden
Erhöht die SOA-Serial bei jeder Änderung. Hält Journale für IXFR. Fällt bei Bedarf auf AXFR zurück
Versendet NOTIFY an Secondaries. Pflegt die Empfängerliste
Kein Rekursivmodus
In BIND kann derselbe Server zwar auch rekursiv agieren, jedoch gilt dies als getrennte Funktionsebene

Hidden Primary

Der primäre Server ist innerhalb der Infrastruktur versteckt, z. B. hinter einer Firewall
Der Secondary-DNS-Server bedient alle DNS-Anfragen wie der Primary-Server und erhält weiterhin alle DNS-Eintrag-Updates vom primären DNS-Server
Diese Konfiguration wird ausschließlich zur Erhöhung der Sicherheit verwendet

Secondary (Slave)

Nur lesbare Replikate
Erhalten Änderungen über AXFR/IXFR. Initiierung über NOTIFY
Authentifizierung über TSIG

Multi-Primary

Mehrere Primäre für hohe Verfügbarkeit
Synchronisierung von Serien und Schlüsseln erforderlich

Nur autoritativ

Server, bei dem die Rekursion deaktiviert ist

Speicherung von DNS-Einträgen

Ablageformen

Zonendatei als textbasierte Quelle. Änderungen erhöhen die SOA-Serial und werden an Secondaries repliziert
Journalbasierte Speicherung für inkrementelle Transfers. Deltas ermöglichen IXFR, bei fehlendem oder unpassendem Journal erfolgt AXFR
Backend-Storage bei datenbankgestützten Authoritative-Servern. Zonendaten werden aus einem Persistenz-Backend erzeugt oder online aktualisiert

RRset-Semantik

Ein RRset ist die Menge aller Resource Records mit identischem Owner-Name, Typ und Klasse. Die Antwort enthält RRsets, nicht einzelne Records

TTL gilt auf RRset-Ebene und muss für alle Records eines RRsets konsistent sein
DNSSEC signiert RRsets. Eine inhaltliche Änderung am RRset erfordert neue Signaturen für das gesamte RRset
Bei dynamischen Updates wird logisch ein RRset ersetzt oder verändert, nicht nur ein einzelner Record

Dynamische Updates (DDNS, RFC 2136)

Dynamische Updates verwenden den DNS-Opcode UPDATE zur Änderung von Zonendaten auf dem Primary

Zugriff wird typischerweise über ACLs und Authentifizierung abgesichert. Häufig erfolgt dies über TSIG
Updates werden journalisiert, erhöhen die SOA-Serial und lösen NOTIFY an Secondaries aus
Typische Anwendungsfälle sind DHCP-Integration und automatische Pflege von A/AAAA- und PTR-Records

Verarbeitung von DNS-Anfragen

Ein autoritativer Server verarbeitet Anfragen anhand seiner Zonen und Delegationen

Zonenwahl erfolgt per Longest-Match-Regel. Die Zone mit dem längsten passenden Suffix ist zuständig
An einer Delegation wird ein Referral geliefert. Enthalten sind NS-Records der Child-Zone und bei Bedarf Glue (A/AAAA) für in-bailiwick Nameserver
Für Namen innerhalb der Zone erfolgt eine autoritative Antwort mit AA=1. Negative Antworten sind NXDOMAIN oder NODATA und enthalten typischerweise SOA in der Authority-Section
Für Namen außerhalb der Zuständigkeit erfolgt typischerweise REFUSED
Bei CNAME wird die Alias-Beziehung geliefert. Der Zielname wird ohne Rekursion nicht aufgelöst
Bei großer Antwort über UDP kann TC=1 gesetzt werden. Wiederholung über TCP ist erforderlich. EDNS0 erhöht die UDP-Nutzlast, ersetzt aber TCP nicht bei sehr großen Antworten

Aktualisierung von Informationen

Replikation von Zonen

Abgestimmtes Kopieren (Replikation) der Zone vom Primärserver auf die Sekundärserver

Änderungen an der Zone werden auf dem Primary persistiert. Die SOA-Serial wird erhöht
Der Primary informiert autorisierte Secondaries per NOTIFY (optional TSIG)
Secondaries prüfen Absender/TSIG, holen die SOA vom Primary und vergleichen die Serial
Bei älterer Kopie fordert der Secondary eine Übertragung an:

IXFR, wenn Journale/Deltas verfügbar sind. Der Secondary übermittelt seine bekannte Serial
AXFR als Fallback, wenn kein passendes Journal vorhanden ist, das Delta zu groß ist oder IXFR nicht unterstützt wird

Ohne NOTIFY erfolgt die Aktualitätsprüfung nach den SOA-Timern:

refresh: Zeitpunkt der nächsten planmäßigen Prüfung beim Primary
retry: Intervall für Wiederholungen, falls die Prüfung fehlschlägt
expire: maximale Gültigkeitsdauer. Nach Ablauf wird die Zone nicht mehr ausgeliefert

SOA serial number

Eindeutige Versionsnummer der DNS-Zone
Erhöht sich bei jeder Änderung der DNS-Zone

AXFR (RFC 5936)

Vollständige Replikation der Zone
Funktioniert über TCP
Wird für die Erstbefüllung verwendet oder wenn IXFR nicht möglich ist
Enthält alle Ressourcensätze der Zone

IXFR (RFC 1995)

Inkrementeller Transfer
Erfolgt typischerweise über TCP. UDP ist nur praktikabel, wenn die Antwort in eine einzelne UDP-Nachricht passt. Bei zu großer Antwort wird auf TCP gewechselt
Voraussetzung: Primary führt Journale. Secondary meldet seine letzte Serial

NOTIFY (RFC 1996)

Aktiv-Signal vom Primary an Secondaries
Funktioniert über UDP
Meldet, dass sich die Zone geändert hat
Empfänger prüft per SOA-Query die Serial
Verhindert lange Refresh-Intervalle

TSIG (Transaction SIGnature)

Protokoll zur Gewährleistung der Sicherheit und Authentifizierung von Daten im DNS
Fügt Nachrichten eine digitale Signatur hinzu
Verwendet eine kryptografische Signatur auf Basis eines geheimen Schlüssels, der sowohl dem sendenden als auch dem empfangenden Server bekannt ist
Das TSIG-Protokoll wird von allen gängigen DNS-Servern unterstützt:

NSD, PowerDNS, Knot und BIND

Protokollierung

Protokollierung dient der Nachvollziehbarkeit und Fehleranalyse im autoritativen Betrieb

Zonenlade- und Signaturereignisse. Parserfehler, DNSSEC-Signing-Status, Key-Rollover-Status
Zonentransfers. AXFR/IXFR-Anfragen, Transfer-Erfolg oder Fehler, Quellen, TSIG-Fehler
NOTIFY und SOA-Checks. Versand, Empfang, abgewiesene Empfänger
Dynamische Updates. Update-Quelle, geänderte Owner/Typen, Authentifizierungsstatus
Query-Logging ist optional und kann volumetrisch hoch sein. Für Betrieb und Forensik werden häufig Sampling oder gezielte Kategorien genutzt

DNS-Zone

Namensraum und Delegation

Eine DNS-Zone ist die Verwaltungseinheit für einen zusammenhängenden Teil des DNS-Namensraums. Sie definiert, für welche Namen ein autoritativer Server zuständig ist und autoritative Antworten liefern kann

Eine Zone wird durch eine eigene SOA- und NS-Ressourcensatzgruppe beschrieben
Die Grenze einer Zone wird durch Delegationen markiert:
- In der übergeordneten Zone existieren nur die NS-Records der Child-Zone sowie ggf. Glue-Records (A/AAAA) für deren Nameserver
- Die eigentlichen Daten der Child-Zone werden ausschließlich in der Zone der Child-Zone geführt
Für alle Namen innerhalb der Zone, die nicht in eine Subzone delegiert sind, liefert der autoritative Server Daten oder negative Antworten (NXDOMAIN/NODATA) mit gesetztem AA-Flag
Ein Nameserver kann mehrere Zonen bedienen. Bei der Anfrageverarbeitung wird immer die Zone mit dem längsten passenden Suffix ausgewählt (Longest-Match-Regel), z.B. für www.sub.example.com.:
- existieren die Zonen example.com. und sub.example.com., ist sub.example.com. zuständig
- existiert nur example.com., beantwortet diese Zone die Anfrage oder liefert NXDOMAIN/NODATA

Begrifflich ist zu unterscheiden:

Domain: Knoten oder Teilbaum im hierarchischen Namensraum
Zone: tatsächlich verwalteter Ausschnitt mit eigener SOA und NS-Satz. Eine Zone kann eine oder mehrere Domains umfassen

SOA

Der SOA-Record markiert den Beginn der Zone (Zonenapex) und enthält Verwaltungsinformationen für Zonentransfers und Caching

Es gibt genau einen SOA-Record pro Zone. Sein Name entspricht dem Zonenapex (z. B. example.com.)

Typischer Aufbau (bind9)

 example.com. 3600 IN SOA ns1.example.com. hostmaster.example.com. (
   2025112101 ; Serial
   7200       ; Refresh
   3600       ; Retry
   1209600    ; Expire
   3600       ; Minimum / Negative TTL
 )

Feld	Wert	Beschreibung
Name (Owner)	example.com.	Zonenapex (Wurzel) der Zone, zu der der SOA-Eintrag gehört
TTL	3600	Lebensdauer des SOA-Eintrags im Cache in Sekunden
Klasse	IN	Protokollklasse. Für das Internet immer IN
Typ	SOA	Record-Typ. Start of Authority, Beginn der Zone und ihre Metadaten
MNAME	ns1.example.com.	Name des primären autoritativen Nameservers für die Zone
RNAME	hostmaster.example.com.	Kontaktadresse des Zonenadministrators als Mailadresse mit Punkt statt @
Serial	2025112101	Seriennummer der Zone. Wird bei jeder inhaltlichen Änderung erhöht und von Secondary-Servern zum Versionsvergleich verwendet. Häufig wird das Format YYYYMMDDNN verwendet, wobei NN die Änderungsnummer für den heutigen Tag ist
Refresh	7200	Intervall in Sekunden, nach dem ein Secondary den SOA des Masters erneut abfragen soll
Retry	3600	Wartezeit in Sekunden, bevor ein fehlgeschlagener Refresh zum Master erneut versucht wird
Expire	1209600	Maximale Zeit in Sekunden, während der ein Secondary alte Zonendaten verwenden darf, wenn der Master nicht erreichbar ist. Nach Ablauf gilt die Zone als ungültig
Negative TTL	3600	Maximale Dauer in Sekunden, für die negative Antworten NXDOMAIN/NODATA gecacht werden dürfen gemäß RFC 2308. Wird als Minimum aus diesem Wert und der TTL des SOA-Records verwendet

Hinweis

In der Zonendatei werden die Zeitwerte intern immer in Sekunden gespeichert und im Protokoll auch so übertragen

Für die Lesbarkeit können die Felder wie Refresh, Retry, Expire, Minimum/Negative TTL sowie die allgemeine $TTL aber mit Zeiteinheiten angegeben werden, z. B. 3600, 1h, 60m, 1d oder 2w
Der Nameserver rechnet diese Angaben beim Einlesen der Zone automatisch in Sekunden um

NS

NS-Records definieren die autoritativen Nameserver einer Zone und bilden die Grundlage für Delegationen

Am Zonenapex enthält das RRset die autoritativen Nameserver für die Zone
Bei Delegation enthält die Parent-Zone nur das NS-RRset der Child-Zone. Die eigentlichen Daten der Child-Zone liegen ausschließlich in der Child-Zone
Glue (A/AAAA) wird in der Parent-Zone nur für Nameserver-Namen innerhalb der delegierten Zone benötigt, um zirkuläre Abhängigkeiten zu vermeiden
Mehrere NS-Records im RRset erhöhen Verfügbarkeit. Konsistenz zwischen den autoritativen Servern ist für korrekte Antworten und DNSSEC-Validierung relevant

Negative Caching (RFC 2308)

Negative Antworten können gecacht werden, um wiederholte Anfragen an autoritative Server zu reduzieren

NXDOMAIN und NODATA werden mit einer negativen TTL zwischengespeichert
Die negative TTL wird aus dem SOA abgeleitet. Üblich ist eine Begrenzung durch SOA.MINIMUM und die TTL des SOA-Records
Autoritative Antworten enthalten für negatives Caching typischerweise den SOA in der Authority-Section

Transport

DNS verwendet UDP und TCP. Die Wahl hängt vom Nachrichtentyp und der Größe der Antwort ab

UDP

UDP ist der Standardtransport für klassische DNS-Queries und NOTIFY

Geringer Overhead und niedrige Latenz
Größenlimit führt bei zu großen Antworten zur Trunkierung. TC=1 signalisiert Wiederholung über TCP
EDNS0 kann die UDP-Nutzlast erhöhen. Große Antworten, DNSSEC und lange RRsets können trotzdem TCP erfordern

TCP

TCP wird für zuverlässige Übertragung und große Nachrichten genutzt

Zonentransfers (AXFR/IXFR) erfolgen über TCP
Query-Antworten mit TC=1 über UDP werden über TCP wiederholt
TCP reduziert Fragmentierungsrisiken bei großen Antworten, erhöht aber Verbindungs-Overhead

DNSSEC

DNSSEC schützt Zonendaten gegen Manipulation durch kryptografische Signaturen. Der autoritative Server liefert signierte RRsets und die zugehörigen Schlüsselmaterialien aus

Zentrale Record-Typen sind DNSKEY (öffentliche Schlüssel) und RRSIG (Signaturen über RRsets)
Validierende Resolver prüfen die Signaturen anhand einer Vertrauenskette. In der Parent-Zone wird dazu ein DS-Record für die Child-Zone publiziert

DNSSEC nutzt kryptografische Schlüssel und Signaturen, um die Authentizität und Integrität von DNS-Antworten nachprüfbar zu machen

Termin	Beschreibung
DNSKEY	Publiziert die öffentlichen kryptografischen Schlüssel einer Zone. Das DNSKEY-RRset enthält KSK und ZSK oder einen kombinierten CSK und bildet die Grundlage für die Signaturprüfung
KSK (Key Signing Key)	Signiert das DNSKEY-RRset der Zone. Der übergeordnete Parent publiziert einen DS-Record, der auf diesen Schlüssel verweist und so die Vertrauenskette herstellt
ZSK (Zone Signing Key)	Signiert die übrigen RRsets der Zone und erzeugt dafür RRSIG-Records. Wird häufiger gewechselt als der KSK
CSK (Combined Signing Key)	Kombiniert die Funktion von KSK und ZSK in einem einzigen Schlüssel. Vereinfacht die Schlüsselverwaltung, beeinflusst jedoch Rollover-Strategien
DS (Delegation Signer)	Record in der Parent-Zone. Enthält einen Hash eines DNSKEY und verankert die DNSSEC-Vertrauenskette zwischen Parent- und Child-Zone
RRSIG	Kryptografische Signatur über ein RRset. Ermöglicht dem validierenden Resolver die Prüfung von Authentizität und Integrität der Zonendaten
NSEC	Belegt die Nicht-Existenz von Namen oder RRsets durch Verweis auf den nächsten existierenden Namen in der Zone. Ermöglicht Zone Walking
NSEC3	Variante von NSEC mit gehashten Namen. Erschwert Zone Walking, erhöht jedoch Rechenaufwand und Komplexität

KSK,ZSK

ZSK signiert die RRsets der Zone und erzeugt RRSIG-Records
KSK signiert das DNSKEY-RRset. Der DS-Record im Parent referenziert typischerweise den KSK
Rollovers erfordern abgestimmtes Vorgehen, damit die Vertrauenskette erhalten bleibt

CSK

Ein CSK kombiniert die Funktion von KSK und ZSK in einem Schlüssel. Dies vereinfacht Schlüsselmanagement, kann aber Rollover-Strategien beeinflussen

NSEC, NSEC3

Proof-of-Non-Existence wird über NSEC oder NSEC3 abgebildet

NSEC zeigt den nächsten existierenden Namen im Kanon der Zone und belegt Nicht-Existenz, ermöglicht aber Zone Walking
NSEC3 nutzt gehashte Namen und erschwert Zone Walking, erhöht jedoch Komplexität und Rechenaufwand

Negative Antworten

Negative Antworten sind Antworten ohne nutzbares RRset für den abgefragten Typ oder Namen. Innerhalb einer autoritativen Zone erfolgt die Antwort mit AA=1 und typischerweise SOA in der Authority-Section

SOA.MINIMUM

SOA.MINIMUM wird als Negative TTL für negative Antworten verwendet

Die Semantik ist nicht ein generelles Minimum für alle TTLs, sondern steuert Caching negativer Antworten gemäß RFC 2308

TTL

TTL definiert die Cache-Lebensdauer eines Resource Records in Sekunden

TTL kann pro Record angegeben werden. In Zonendateien kann $TTL als Standardwert für nachfolgende Records gesetzt werden
Kürzere TTLs erhöhen Änderungsagilität, erhöhen aber Query-Last. Längere TTLs reduzieren Query-Last, verzögern aber die Wirksamkeit von Änderungen

NXDOMAIN

NXDOMAIN bedeutet, dass der abgefragte Name in der Zone nicht existiert

Response-Code NXDOMAIN
Negative Caching erfolgt gemäß SOA-Parametern

NOERROR

NOERROR bedeutet, dass die Anfrage formal erfolgreich verarbeitet wurde. Inhaltlich kann die Answer-Section leer sein

Bei NODATA ist NOERROR gesetzt, aber das angefragte RRset fehlt
Ein leeres Ergebnis kann auch durch Delegation oder CNAME-Only-Antworten entstehen, abhängig vom Query und Zoneninhalt