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 seine eigenen Zonen und delegierten Subzonen zurück. Für fremde Namen antwortet 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.

• RD in der Anfrage wird ignoriert.
• 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.

Verarbeitung von DNS-Anfragen

Flags

Flags – Bits im DNS-Header, beschreiben die Art der Anfrageverarbeitung

Bedeutung	Beschreibung	Anmerkungen
QR — Query/Response
0	Query	—
1	Response	—
AA — Authoritative Answer
0	Die Antwort ist für den Namen nicht maßgeblich	Auf einem autoritativen Server außerhalb seiner Zonen
1	Die Antwort ist für den Namen maßgeblich	Auf dem autoritativen Server für seine Zone
TC — Truncated
0	Die Antwort ist nicht abgeschnitten.	—
1	Antwort abgeschnitten (fragmentiert), Antwort über TCP wiederholen	Der Client wechselt zu TCP 53
RD — Recursion Desired
0	Der Client fordert keine Rekursion an	Standardmäßig für direkte Anfragen an den autoritativen Server
1	Der Kunde fordert eine Rekursion an.	Ein autoritativer Server führt keine Rekursion durch. In seiner Antwort ist RA=0, auch wenn RD=1 in der Anfrage stand
RA — Recursion Available
0	Rekursion ist auf diesem Server nicht verfügbar	Standardmäßig für autoritative-only
1	Der Server unterstützt Rekursion	Standardmäßig bei rekursiven Resolvern
Z — Reserviert
0	Korrekte Bedeutung	—
1	Unzulässig gemäß Norm	Ignoriert. Reserve für zukünftige Protokollerweiterungen
AD — Authenticated Data (DNSSEC)
0	Daten sind nicht als DNSSEC validiert gekennzeichnet	Standardmäßig
1	Die Daten wurden durch DNSSEC validiert	Wird nur von einem rekursiven Resolver mit aktiviertem DNSSEC gesetzt
CD — Checking Disabled (DNSSEC)
0	Der Kunde deaktiviert die DNSSEC-Überprüfung nicht.	Standardmäßig
1	Der Kunde bittet darum, DNSSEC nicht zu überprüfen.	Einstellbar

EDNS(0) — DO (DNSSEC OK) — Flag in OPT

• 0 - Der Client fordert keine DNSSEC-Daten an
• 1 - Der Server fügt die entsprechenden RRSIG/DNSKEY hinzu

RCODE

Antwortcodes, RCODE – Ergebnis der Bearbeitung einer Anfrage

Code	Name	Beschreibung	Anmerkung
0	NOERROR	Keine Fehler aufgetreten. Die Anfrage konnte erfolgreich verarbeitet werden.	Leere Answer-Sektion mit NOERROR entspricht NODATA (Name existiert, der abgefragte Typ jedoch nicht).
1	FORMERR	Fehlerhaftes DNS-Nachrichtenformat. Der Server konnte die Anfrage nicht interpretieren.	Kann auf defekte Pakete oder auf Probleme in Zwischenkomponenten (z.B. NAT, Firewall) hinweisen.
2	SERVFAIL	Interner Serverfehler oder temporäres Problem bei der Verarbeitung der Anfrage.	Für Clients oft kaum von Netzwerkstörungen unterscheidbar. Tritt u.a. bei DNSSEC-Validierungsfehlern auf.
3	NXDOMAIN	Der abgefragte Name existiert in der zuständigen Zone nicht.	Wird für negative Antworten mit AA=1 und SOA im Authority-Bereich verwendet (negatives Caching nach RFC 2308).
4	NOTIMP	Die angeforderte Operation oder der verwendete OpCode wird vom Server nicht unterstützt.	Kommt selten vor. Deutet meist auf sehr alte oder stark eingeschränkte Implementierungen hin.
5	REFUSED	Der Server verweigert die Ausführung der Operation aus administrativen oder sicherheitsbedingten Gründen.	Typisch bei Policy-Blockaden, z.B. geschlossener Rekursion oder gezielt gefilterten Zonen/Operationen.
6	YXDOMAIN	Der Name existiert, obwohl er gemäß der angeforderten Operation nicht existieren dürfte.	Wird fast ausschließlich im Kontext von Dynamic DNS Updates (RFC 2136) verwendet.
7	YXRRSET	Das RR-Set existiert, obwohl es gemäß der Operation nicht existieren dürfte.	Ebenfalls hauptsächlich bei DNS-Updates. Signalisiert fehlerhafte oder widersprüchliche Update-Anfragen.
8	NXRRSET	Das angeforderte RR-Set existiert nicht, obwohl es gemäß der Operation existieren müsste.	Wird bei fehlgeschlagenen Update-Operationen genutzt, wenn zu ändernde Datensätze nicht vorhanden sind.
9	NOTAUTH	Der Server ist für die angefragte Zone nicht zuständig oder lehnt die Autorisierung ab.	Häufig in Antworten auf AXFR/UPDATE, wenn der Server nicht autoritativ für die Zone ist oder Updates nicht erlaubt.
10	NOTZONE	Der angegebene Name gehört nicht zur im Update referenzierten Zone.	Hilft Clients, fehlerhafte oder falsch konstruierte Update-Requests zu erkennen.
16	BADVERS	Nicht unterstützte oder falsche EDNS-Version (im OPT-Record angegeben).	Erweitertes RCODE in EDNS. Erscheint im Zusammenhang mit dem OPT-Record, nicht als klassischer Header-Rückgabecode.

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
• Funktioniert über TCP oder UDP
• 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

---