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	Bezeichnung	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

Protokollierung

DNS-Zone

NS

Negative Caching (RFC 2308)

DNSSEC

KSK,ZSK

CSK

NSEC, NSEC3

NODATA

SOA.MINIMUM

TTL

---