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.

Funktionen

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

RRset-Semantik

Dynamische Updates (DDNS, RFC 2136)

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

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

Negative Caching (RFC 2308)

DNSSEC

KSK,ZSK

CSK

NSEC, NSEC3

NODATA

SOA.MINIMUM

TTL

---