Domain Name System/Server/Autoritative

Domain Name System/Server/Autoritative - Autoritativer Server

Beschreibung

Die Hauptaufgabe eines autoritativen Servers

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

Abgrenzung zum Rekursiven 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

NODATA

NODATA bedeutet, dass der Name existiert, aber kein RRset des angefragten Typs vorhanden ist

• Response-Code NOERROR mit leerer Answer-Section für den angefragten Typ
• Negative Caching wird wie bei NXDOMAIN über SOA-bezogene Werte gesteuert

---