Die in [RFC4033],  [RFC4034] und [RFC4035] spezifizierten DNS Security Extensions zielen im  Gegensatz zum TSIG Mechanismus, bei dem die Sicherung des  Transaktionskanals im Mittelpunkt steht, auf die Sicherung von  Datenobjekten einer Zone ab.

Die Authentizität und Integrität besagter  Zonendatenobjekte, der sog. Resource Record Sets (RRset ), wird durch  Bildung einer digitalen Signatur über das jeweilige RRset  sichergestellt. Bei der Generierung der RRset-Signaturen kommen  asymmetrische, zonen-eigene Schlüsselpaare zum Einsatz.

DNSSec Extention Zweck
DNSSEC RR  (RRSIG) Beinhaltet die   Signatur über ein RRset;  neben Signaturen über die üblichen DNS RRsets werden   auch Signaturen  über DNSSEC RRsets (DNSKEY, DS, NSEC) gebildet und in   entsprechenden  RRSIG Records abgelegt. RRSIG RRs tragen   einen Zeitstempel (“Signature  Expiration   Date”), der die Gültigkeitsdauer der Signatur festlegt.
DNSKEY

Beinhaltet einen   publizierten  base64-kodierten Public Key, mit dessen Hilfe die Signatur in   einem  RRSIG RR im Rahmen des Authentisierungsprozesses verifiziert werden    kann. Findet sich am   Zonen-Delegationspunkt  einer Parent Zone und beinhaltet einen Verweis auf den   DNSKEY RR  (Public Key) einer Child Zone, mit dessen korrespondierenden   Private  Key entweder das DNSKEY RRset im Zonen-Apex der Child Zone oder die    anderen RRsets der Child Zone signiert wurden.

DS RRs sind   essentiell für den Aufbau von  sog. “Authentisierungsketten” zur Verifikation signierter  Datenobjekte über Domaingrenzen hinweg.

NSEC Beinhaltet zwei   Arten von Informationen:
Den nächsten kanonischen   (Owner) Namen,  der autoritative Daten oder ein NS RRset an einem   Delegationspunkt  enthält.
Die RRset Typen,   die mit dem aktuellen  kanonischen (Owner) Namen assoziiert sind Ketten von   (signierten) NSEC RRs  ermöglichen die Authentisierung negativer Antworten   (Nicht-Existenz  von kanonischen (Owner) Namen oder RR Typen).

Jegliche Kommunikation innerhalb des DNS Protokolls basiert auf  sog. DNS Messages.

Speziell die DNS Nachrichten, die zwischen zwei Nameservers im  Rahmen von Zonen-transfers ausgetauscht werden, nämlich DNS  NOTIFY Message(s) vom Master (oder auch Slave) an den Slave und DNS  AXFR/IXFR Request/Response Messages zwischen Slave und Master (oder  zwischen Slaves), können durch Einsatz eines symmetrischen Kryptographieverfahrens  auf Transaktionsebene geschützt werden.


Dieser als Transaction Signatures bezeichnete Mechanismus ist in  [RFC2845] spezifiziert und nutzt ein "Shared Secret" – d.h. einen  gemeinsamen symmetrischen Schlüssel –, um die zwischen zwei Parteien  ausgetauschten DNS Messages zu signieren.

Über entsprechende "Access Control Lists" (ACL) (auf Basis  dieses Shared Secret) wird zudem gesteuert, ob die genannten DNS  Nachrichten von der Gegenseite überhaupt akzeptiert werden.

Hat einer der beteiligten Nameserver eine entsprechende  ausgehende Nachricht generiert, so wird auf diese vor dem tatsächlichen  Versand eine "Keyed One-Way Hash Function" zur Erzeugung eines  128-bit großen "Message Digest" angewendet. Als Key kommt dabei der  gemeinsame symmetrische Schlüssel von sendender und empfangender Partei  zum Einsatz.

Nameserver  beantworten prinzipiell zwei Arten von Anfragen: iterative und  rekursive.

Dieses Verhalten gilt es aus Sicherheitsgründen auf  das absolut erforderliche Maß einzuschränken, ohne dabei die Nutzbarkeit  des Dienstes selbst in Frage zu stellen. Hierarchisch  gegliederte Namensräume und die physische Segmentierung von  Netzwerk-Topologien machen es möglich, Klassen von Nameservers zu  definieren, bei denen die genannten Anfragetypen entweder vollständig  voneinander getrennt sind oder hinsichtlich ihrer Verfügbarkeit lokal  beschränkt werden können.

In komplexeren DNS Topologien ist meist die Trennung zwischen  allgemein und eingeschränkt sichtbaren Zoneninformationen erforderlich. Diese Art der NS Konfiguration, die als "Split Namespace" bezeichnet wird, kommt üblicherweise auf speziell gesicherten Systemen  einer "De-Militarisierten Zone" (DMZ), dem sogenannten "Bastion Hosts" zum Einsatz. Die Split Namespace Konfiguration einer DMZ Nameserver-Instanz  verfügt i.d.R. über folgende Eigenschaften:

  • Bereitstellung  einer bewusst kleingehaltenen Menge offizieller und öffentlich  verfügbarer Resource Records (sog. "External View" oder auch "Shadow  Namespace") einer Domain zur Auflösung von Anfragen externer DNS  Clients. Typische Beispiele hierfür sind der SOA Record der Domain, NS  Records, MX Records für den Email-Exchange, sowie einige wenige A  Records und ihre jeweiligen PTR Records.
  • Fähigkeit,  interne Namen und IP-Adressen parallel zum externen Resolving  aufzulösen, wobei die Nutzung dieser Fähigkeit jedoch i. d. R. auf  Anfragen aus der DMZ (und ggfs. aus dem Intranet) beschränkt ist.

Ein  Nameserver, der grundsätzlich keine rekursiven Queries beantwortet und  keinen entsprechenden Daten-Cache aufbaut. Beispiele hierfür sind die NS  der (Internet) Root Domain und (üblicherweise) Hidden Primary Master  Nameserver

Zum Seitenanfang