Domain Name Service

DNS-Server werden nicht nur beim klassischen Surfen im Internet verwendet. Denn eigentlich nutzen alle Dienste das DNS-System, um die IP-Adressen zu einen FQDN zu ermitteln. Die meisten Benutzer schenken dem Domain Name System (DNS) nicht viel Aufmerksamkeit und machen sich keine Gedanken über Investitionen in die Sicherheit der DNS-Ebene. Schließlich ist das Markenzeichen eines gut funktionierenden DNS-Services dessen Unsichtbarkeit und die Fähigkeit, Benutzer korrekt und ohne Verzögerung mit Websites oder Web-Anwendungen zu verbinden.

Das DNS-Protokoll enthält keine Authentifizierung die sicherstellt, dass man wirklich mit dem gewünschten DNS-Server verbunden ist. DNS-Anfragen können vom Provider auf eigene, zensierende Server umgeleitet werden.

Die Sicherung der DNS-Ebene bedeutet für den Benutzer, dass bösartige Domains, IP-Adressen und Cloud-Anwendungen blockiert werden, bevor eine Verbindung überhaupt hergestellt wird. Hingegen für den Administrator des DNS-Servers bedeutet dies, dass dieser Mechanismen die einen Missbrauch/Umleitung idealerweise verhindern, mindestens jedoch validierte DNS-Antworten ausliefern.

letzte Beiträge Blog Seite

Blogeinträge

DNS Tunnel

Die Idee hinter der Nutzung eines Tunnels auf Basis von DNS ist es, den gesamten ausgehenden Datenverkehr vor anderen zu verstecken. Dies bedeutet, den von Menschen lesbare Hostnamen in numerische IP-Adressen durch DNS zu übersetzen und auch umgekehrt.

DNS DDoS Vorsorge

Vorsorge gegen DNS Amplification Attacks

Die DNS Amplification Attack zählt zu den DDoS-Angriffen. Denn der Angreifer nutzt falsch konfigurierte Name-Server aus und leitet riesige Datenströme auf den Internetanschluss des Opfers mit den falsch konfigurierten Name-Server weiter. Als Ergebnis der Umleitung ist der Internetanschluss des Opfers überlastet und kann nicht mehr verwendet werden. Dies ist um so fataler in Zeiten von Cloud-basierten Rechenzentren. Dieser Artikel benennt RFCs zur Vorsorge gegen einen solchen Angriff.

DNS CADR

CADR - DNSSEC Authentifizierte DNS Registry

CADR (ein etwas abgewandeltes Akronym für "DNSSEC authentifizierte DNS Registry") ist eine Registrierungsstelle für DNS-Daten. Das heißt, CADR ist ein System, das mit den Registries vergleichbar ist, die von TLDs betrieben werden, um Delegationsinformationen zu verwalten, oder in manchen Umgebungen von Registraren betrieben wird, um Delegationsinformationen für Kunden zu verwalten, die dann an eine Registry (typischerweise für eine TLD) weitergegeben werden.

Ein paar grundsätzliche Dinge zu DNS?

Was sind DNS Security Extensions und welche Resource Records kommen hinzu?

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-eigne Schlüsselpaare zum Einsatz.

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).

Wofür steht Transactional Signatures (TSIG) und was beinhaltet es?

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

Speziell die DNS Nachrichten, die zwischen zwei Name-Servers im Rahmen von Zonentransfers 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 Name-Server 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.

Was bedeutet Split Namespace?

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 Name-Server-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.

Was bedeutet Split Function Name-Server?

Name-Server 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 Name-Servers zu definieren, bei denen die genannten Anfragetypen entweder vollständig voneinander getrennt sind oder hinsichtlich ihrer Verfügbarkeit lokal beschränkt werden können.

Wofür steht Nonrecursive Name-Server?

Ein Name-Server, 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 Name-Server.

Was ist ein Forwarder?

Ein Name-Server, der Empfänger von rekursiven Queries ist, die von entfernten Name-Servers an ihn weitergeleitet wurden. Besagte entfernte NS nutzen eine Forwarding-Konfiguration, mittels der ausgewählte oder auch alle bei ihnen eingehenden rekursiven Queries als solche an einen oder mehrere Forwarders durchgereicht werden.

Was ist ein Caching-Only Name-Server?

Ein Name-Server, der für keine Zone autoritativ zuständig ist. Die einzigste Funktion dieses NS-Typs besteht darin, angefragte RRs bei anderen Name-Servers zu ermitteln und in seinem Cache (zur Beantwortung entsprechender Anfragen) vorzuhalten.

Was ist ein hidden Slave Name-Server?

Ein Slave Name-Server, der nicht in den NS Records der Zonen gelistet ist, für die er autoritativ ist. Hierdurch ist sichergestellt, dass sich dieser (zusätzliche) Name-Server nicht negativ auf die Größenlimitierung UDP-basierter DNS Response Messages auswirkt und entfernte Name-Server keiner Delegation zu diesem Slave folgen können.

Was ist ein Stealth Slave Name-Server?

Ein Slave Name-Server, welche anstelle des Hidden Primary Master Name-Server nach außen hin in der Rolle des Primary Master Name-Server auftritt. Um diese Rolle ausfüllen zu können, ist dieser Server nicht nur – wie üblich – in den NS Records der Zone gelistet, für die er autoritativ ist, sondern auch in den SOA Records (MNAME Feld) der besagten Zone mit eingetragen.

Was ist ein Hidden Primary Master Name-Server?

Ein Hidden Primary Master Name-Server wird nicht in den Name-Server Records der Zone (im Zonenfile) gelistet, für die er eigentlich autoritativ zuständig ist. Hierdurch wird sichergestellt, dass entfernte Name-Server keiner Delegation zu diesem wirklichen Master Name-Server folgen können. Somit ist dieser „versteckt“. Diese Art des DNS-Designs findet Verwendung meist in Sicherheitsarchitekturen oder bei kleinen Firmen.

Was ist ein secondary Name-Server?

Das Synonym für einen secondary Names-Server lautet Slave Name-Server. Ein Secondary Name-Servers ist ein redundanter Autoritativer Name-Server für eine bestimmte Zone. Die Name-Server-Instanz erhält ihre Zonendaten vom Primary Master Name-Server oder einem anderen Slave Name-Server.

Was ist ein primary Master Name-Server?

Ein primary Master Name-Server ist ein autoritativer Name-Server für eine bestimmte Zone (bspw. www.je-ru.de), innerhalb der Name-Server-Instanz erfolgt die Pflege der eigentlichen Zonendaten.

Was ist eine iterative Anfrage?

Dieser Query-Typ findet in der Kommunikation zwischen Name-Servers Verwendung, und zwar dann, wenn diese (quasi in Kooperation) eine rekursive Anfrage weiterbearbeiten.

Wird z. B. rekursiv nach der IP-Adresse von www.je-ru.de gefragt, so überprüft der angefragte Name-Server zunächst, ob ihm die autoritativen Name-Servers für die Domain je-ru.de bekannt sind. Ist dies der Fall, so sendet der Name-Server eine entsprechende iterative Anfrage an einen dieser Servers; andernfalls wird einer der autoritativen de Name-Servers (falls bekannt) und in letzter Instanz einer der (Internet) Root Name-Servers befragt. Der Name-Server, der eine iterative Anfrage erhält, liefert als Resultat die bestmögliche Antwort, die in seinem lokalen Datenbestand (inklusive Cache) gefunden wird. Dies ist entweder die tatsächlich nachgefragte IP-Adresse (oder der nachgefragte Name) oder eine Referral-Liste, die alle „näher“ am Ziel der Anfrage liegenden autoritativen Name-Servers enthält. Verwaltet der anfragende Name-Server aufgrund früherer Anfragen sog. Round Trip Times (RTT) für die in der Referral-Liste genannten Servers, so wählt er denjenigen mit der niedrigsten RTT aus und wiederholt dort die iterative Anfrage. Dieser Prozess setzt sich solange fort, bis eine tatsächliche Antwort vorliegt.

Was ist eine rekrusive Anfrage?

Diese Art von Queries wird von (Stub) Resolver Hosts oder von Name-Servern, die Forwarder benutzen, initiiert.

Rekursive Anfragen zur Namensauflösung weisen dem angefragten NS-System die exklusive Aufgabe zu, alle notwendigen Schritte zur Erfüllung der Anfrage durchzuführen. Eine Delegation der Arbeitsschritte an andere Name-Server oder die Rückgabe von Referrals an den anfragenden Client sind nicht vorgesehen bzw. nicht erlaubt.

Der adressierte Name-Server kann die Anfrage entweder direkt beantworten oder andere Name-Servers iterativ anfragen, bis eine Antwort vorliegt.