InhaltIn diesem Text geht es um grundsätzliche DNS-Konzepte und Best Practice-Techniken für DNS, die am konkreten Beispiel erläutert werden.
Optimale Vorgehensweise bei DNSWhite Paper
2 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Nutzungsrechte dieses Dokuments
CopyrightDieses Dokument und die darin enthaltenen Informationen (in Form von Text, grafischen Benutzeroberflächen ("GUI"), Video und Audio, Bildern, Symbolen, Software, Entwürfen, Applikationen, Berechnungen, Modellen, Vorhersagen oder anderen Elementen, mittels dieses Dokuments zur Verfügung gestellt werden, sind Eigentum von BlueCat Networks oder Zulieferern, und sind durch kanadische und internationale Urheberrechte, Warenzeichen und Gesetze geschützt. Durch die Nutzung dieses Dokuments werden keinerlei Besitz- oder weitere Rechte oder Inhalte an Sie übertragen. BlueCat Networks behält sich alle Rechte vor, die nicht ausdrücklich gewährt wurden.
Dieses Dokument und die darin enthaltenen Informationen sind das ausschließliche geistige Eigentum von BlueCat Networks. Es ist untersagt, dieses Material in jeglicher Form zu reproduzieren, nachzubilden oder auf andere Weise zu verwenden, ohne die vorherige schriftliche Genehmigung von BlueCat Networks.
Copyright © October 23, 2006 5:31 PM BlueCat Networks (USA), Inc. Alle Rechte vorbehalten.
Information des HerausgebersVeröffentlicht in Kanada - Kein Teil dieses Dokumentes darf in irgendeiner Form reproduziert, übertragen, kopiert oder in einem Retrieval-System gespeichert, oder in irgendeiner Form oder mit irgendeiner Methode in eine andere menschliche Sprache oder eine Computersprache übersetzt werden, ohne die zuvorige ausdrückliche Genehmigung von:
Diese Publikation schließt Haftungsansprüche jeglicher Art aus, sowohl ausdrücklich als auch stillschweigend, einschließlich - aber nicht beschränkt auf - Gewährleistung, Tauglichkeit für einen bestimmten Zweck oder Rechtsverletzungen.
Alle in dieser Publikation aufgeführten Warenzeichen oder Handelsmarken sind als solche gekennzeichnet. BlueCat Networks übernimmt keinerlei Haftung für die Richtigkeit der hierin enthalten Informationen. Die Nutzung eines Warenzeichens in dieser Publikation deutet nicht darauf hin, dass die Gültigkeit dieses Warenzeichens oder Handelsnamens dadurch beeinträchtigt ist. Alle aufgeführten Warenzeichen, Handelsnamen und Logos (die "Warenzeichen") sind registrierte und nicht registrierte Warenzeichen der BlueCat Networks, Inc. und Anderer. Jegliche Nutzung dieser Warenzeichen ist untersagt, ohne die zuvorige schriftliche Genehmigung von BlueCat Networks oder des Dritten, der rechtmäßiger Eigentümer des Warenzeichens ist.
Keine fachmännische EmpfehlungDieses Dokument dient ausschließlich zu Nachschlage- und Informationszwecken. Dieses Dokument erhebt nicht den Anspruch, eine umfassende oder vollständige Exploration des angegebenen Themas zu sein, noch einen Ratschlag oder eine Empfehlung hinsichtlich wissenschaftlicher, technischer oder jeglicher anderer Natur darzustellen; noch ein Angebot für den Verkauf oder Kauf eines bestimmten Produktes oder einer Dienstleistung zu sein. BlueCat Networks übernimmt keine Haftung oder Veranwortung hinsichtlich der Nutzung, der Gültigkeit, Richtigkeit oder Zuverlässigkeit, oder die sich aus der Nutzung der Internetseite oder der Materialien dieses Dokuments oder für jegliche Internetseite, auf die verwiesen wird, ergibt. Dieses Dokument ist ausschließlich für die Nutzung durch den Empfänger bestimmt. Es stellt kein vollständiges Angebot dar und darf durch keine weitere Person reproduziert oder weitergegeben werden.
BlueCat Networks, Inc.4101 Yonge Street, Suite 502Toronto, OntarioKanada M2P 2C9
Zu Händen von: ProduktmanagerTelefon: 416-646-8400Fax: 416-225-4728E-mail: [email protected]: www.bluecatnetworks.com
Optimale Vorgehensweise bei DNS
Kurzfassung
Bei der Implementierung von DNS muss eine Vielzahl möglichst optimaler Verfahrensweisen in Betracht
gezogen werden. Dabei handelt es sich um in der Praxis erprobte und von Experten geprüfte Empfehlungen,
wie ein robuster und sicherer DNS-Service aufgebaut sein sollte.
Zunächst beschäftigen wir uns mit Best Practices für DNS selbst und für den jeweiligen Server, auf dem der
Dienst liegt. Die folgenden Informationen sind hilfreich für jede Art von Unternehmen, die den Aufbau eines
DNS planen, sei es ein kleinerer Betrieb, seien es mittelständische und große Unternehmen oder auch
Hosting-Dienstanbieter. Des Weiteren geht es im Detail um DNS auf Netzwerkebene, und abschließend
werden die möglichen Sicherheitsmaßnahmen thematisiert. Diese Informationen haben besonders für
Großunternehmen einen hohen Stellenwert, wenn diese mehrere DNS-Server einsetzen müssen. Im hier
vorliegenden White Paper beschränken wir uns allerdings auf Sicherheitsthemen, die Unternehmen mit nur
einem Server betreffen.
Inhaltsverzeichnis
Einführung ................................................................................................. 4DNS-Server ................................................................................................ 5Der DNS-Dienst ......................................................................................... 6
Erhöhte Redundanz ............................................................................................. 6Handhabung ...................................................................................................... 8IPAM ................................................................................................................. 9Sicherheit für den DNS-Service ............................................................................. 9
DNS-Netzwerkarchitektur ........................................................................ 10Iterative vs rekursive Abfragen ........................................................................... 10Autoritative Server ............................................................................................ 10Caching-Server ................................................................................................. 11Trennung von Funktionen .................................................................................. 12Bedingte Weiterleitung ...................................................................................... 13BIND Views ...................................................................................................... 14
Externe DNS und Sicherheit ..................................................................... 14Firewalls .......................................................................................................... 15Verborgener Master .......................................................................................... 15Zonentransfers und TSIG ................................................................................... 16Versionsmaskierung .......................................................................................... 17Interne DNS ..................................................................................................... 18Dynamische Updates ......................................................................................... 18
Ein vollständiges Netzwerk ...................................................................... 19Schlussfolgerung ..................................................................................... 20
3© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Einführung
Für Unternehmen ist ein DNS-Service unentbehrlich, er wird jedoch größtenteils vernachlässigt oder sogar
missverstanden. Die Verwaltung der DNS ist traditionell ein technisches Unterfangen. Die DNS-Dienste
selbst fallen allerdings ihrer eigenen Zuverlässigkeit und Leistungsfähigkeit zum Opfer, und werden schlicht
als gegeben hingenommen. Die Eigenschaften eines herkömmlichen Computernetzwerks verändern sich
jedoch, vor allem durch die Einführung neuer Anwendungsbereiche und Applikationen, wie beispielsweise
drahtlose Geräte und VoIP-Telefone. Zudem sind Netzwerke heute deutlich höher ausgelastet als noch in der
jüngeren Vergangenheit. Auf der anderen Seite spiegelt sich darin ein stark gewachsenes Vertrauen in die
datenpaketbasierten Netzwerke wider. Und diese sind es ja, die die neuen Kommunikationsformen erst
ermöglichen. Der DNS-Dienst ist für diese Art von Netzwerken unerlässlich. Ohne DNS würden die meisten
Ressourcen in einem Netzwerk sehr schnell nicht mehr erreichbar sein. Viele Netzwerke sind in punkto DNS-
Verwaltung und Dienste für ein solches Wachstum aber gar nicht ausgelegt. Dadurch entsteht eine Situation,
in der die Funktionalität eines Netzwerks durch einen menschlichen Fehler oder eine Anzahl einfach zu
implementierter Angriffe kompromittiert werden kann. Dazu gehören u. a. Denial of Service (DoS) Angriffe,
die den DNS-Dienst schlichtweg stilllegen und wesentlich raffiniertere Angriffe wie Cache-Poisoning, die
Benutzer auf betrügerische Internetseiten führen, die sich als legitim ausgeben.
Der Ansatz von BlueCat Networks für einen sicheren und gut verwalteten DNS umfasst die Überprüfung
sämtlicher beteiligter Komponenten, die an der Bereitstellung der DNS-Dienste beteiligt sind. Jede
Komponente muss so einfach wie möglich aufgebaut sein, um effizient, leicht zu administrieren und sicher zu
sein, aber auch komplex genug, um die erforderliche Funktionalität zu bieten. Zunächst legen wir unser
Augenmerk auf den Server, der den DNS-Dienst bereitstellt. BlueCat Networks empfiehlt hier ein Appliance-
Modell, zusätzlich erhalten Sie ergänzende Informationen für diese Vorstufe der Netzwerkplanung. Der DNS-
Dienst wird auf Schwachstellen hin überprüft, die sich direkt auf den DNS-Dienst selbst und die BIND
Implementierung des DNS zurückführen lassen. Im Folgenden wird die DNS-Netzwerkarchitektur erörtert, da
sie erhebliche Auswirkungen auf Sicherheit und Funktionalität haben kann. Im Anschluss geht es um die
Implementierung und Sicherheitsaspekte der externen DNS. Der letzte Abschnitt, "Ein vollständiges
Netzwerk", beschäftigt sich mit den unterschiedlichen Perspektiven zu DNS in einer typischen
Netzwerkimplementierung und wie sie zusammengeführt werden können.
4 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen möglich.
Optimale Vorgehensweise bei DNS
DNS-Server
Zunächst sehen wir uns den Server genauer an, auf dem der DNS-Dienst ausgeführt wird. Ohne einen
zuverlässigen, sicheren und optimierten Server, kann der DNS-Dienst ausfallen oder erhebliche
Sicherheitslücken aufweisen. Sicherheitsexperten empfehlen Unternehmen einen dedizierten DNS-Server
zu betreiben, der nichts anderes tut als genau diese DNS-Aufgaben wahrzunehmen. Je einfacher ein Server
aufgebaut werden kann, desto einfacher ist es, ihn abzusichern und ausfallsicher zu machen.
Die Hardware, die für den DNS-Server zum Einsatz kommen soll, sollte eine handelsübliche, empfohlene
Hardware sein, die vollständig über das ausgewählte Betriebssystem verwaltet werden kann.
Schwachstellen in der Hardware können zu Ausfällen des gesamten Servers führen.
Das Betriebssystem des Servers sollte nicht nur in der Lage sein die Hardware sicher zu verwalten, sondern
auch selbst keine Sicherheitslücken haben. Dies bedeutet, dass das Betriebssystem selbst auf
Sicherheitslücken überprüft ist und alle Sicherheits-Patches installiert sein müssen. Tatsächlich werden
automatisierte Patch- und Updatemanagementsysteme aufgrund ihrer Reaktionszeit und Konsistenz immer
beliebter. Sicherheitslücken des Betriebssystems können ebenfalls geschlossen werden, indem alle
Komponenten entfernt werden, die nicht ursächlich für den Betrieb des DNS erforderlich sind. BIND kann in
einer "abgeschlossenen" CHroot Umgebung betrieben werden, was es Hackern unmöglich macht, den DNS-
Dienst anzugreifen und Zugang zum Server über eine Privilegien-Eskalation zu erhalten. Diese Kombination
aus Hardware- und Betriebssystemintegration ist normalerweise nur auf Applikationsservern zu finden.
Auf einem DNS-Server sollte kein weiterer Service laufen, insbesondere keiner mit Internetzugang. Oft wird
allerdings für den DHCP-Dienst (Dynamic Host Control Protocol), der auf dem gleichen Server ausgeführt
werden soll, eine Ausnahme gemacht. Man sollte stets die aktuellste BIND-Software verwenden, um den
Sicherheitslevel zu erhöhen und die aktuellsten Funktionen, wie beispielsweise BIND 9 Views, einsetzen
zu können.
Der für den DNS-Dienst verwendete Server sollte über eine Firewall verfügen, die auf dem neusten Stand
der Paket-Filterung ist und so wenig offene Ports wie möglich aufweist. Hacker verwenden meist offene
Ports, um Angriffe auf DNS-Server auszuführen. Je besser die Firewall und je weniger offene Ports
vorhanden sind, desto sicherer der Server.
Wie ein Server sich administrieren lässt, ist nicht zuletzt dafür verantwortlich, wie effizient und sicher er
arbeitet. Da DNS-Sicherheitsprobleme sehr häufig aufgrund von Konfigurationsfehlern auftreten, ist der
Wechsel von textbasierenden Eingabekonsolen zu menügeführten grafischen Bedienoberflächen sinnvoll
und nützlich. Unter anderem sollten Funktionen wie die Administration von Protokollen und Zertifikaten
intuitiv bedienbar sein und sich einfach konfigurieren lassen.
5© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Figure 1: Server ohne Sicherheitslücken
Der DNS-Dienst
Erhöhte Redundanz
Der DNS-Dienst ist ein entscheidender Netzwerkservice. Die Kosten, die durch einen Ausfall entstehen, sei
es auch nur über einen Zeitraum von einer Stunde, übersteigen die Kosten für die Implementierung einer
korrekt konfigurierten, hoch verfügbaren DNS-Infrastruktur um ein Vielfaches. DNS ist vom zugrunde
liegenden Aufbau her ein skalierbarer und verteilter Dienst, der Fehler und stellenweise Ausfälle toleriert.
Setzt man eine DNS-Architektur ein, die einen primären (Master) Server und einen oder mehrere
sekundäre(n) (Slave) Server verwendet, kann ein Server ausfallen, ohne dass der DNS-Dienst als solcher
ausfällt. Dieser Aufbau hat jedoch auch gewisse Nachteile. Zum einen, wenn der Master Name-Server
ausfallen sollte und nicht innerhalb einer gewissen Zeit wieder in Betrieb genommen wird, können die
sekundären Name-Server letztendlich nicht mehr auf die verbindlichen Anfragen reagieren. Zum anderen ist
die Anmeldung für alle Arbeitsstationen in der Regel so konfiguriert, dass sie den Master-Name-Server zur
Namensauflösung nutzen. Daher kann die Anmeldung sehr viel Zeit in Anspruch nehmen, bis sie schließlich
an den sekundären Name-Server weiter geleitet wird.
6 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Figure 2: Eine Master/Slave Architektur
Cluster und hoch verfügbare Services erlauben es, mit dem DNS-Server auch mehrere Server zu betreiben,
aber mit nur einem Kontaktpunkt. Die Server, die in einem aktiv/passiv Cluster betrieben werden,
überwachen ihre Funktionsfähigkeit gegenseitig mit einem so genannten "Herzschlag"-Mechanismus. Falls
ein aktiver Server ausfallen sollte, kann der passive Server innerhalb weniger Sekunden dessen Platz
übernehmen. Ausfälle auf Serverebene müssen somit nicht mehr mit Ausfällen des DNS-Service
einhergehen.
7© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Figure 3: Eine hoch verfügbare Master/Slave Architektur
Es gibt etliche Firmen, die DNS-Software entwickeln und vertreiben. Der Industriestandard ist die Software
des Internet Software Consortiums (ISC) BIND (Berkeley Internet Name Domain). Übertragen durch das
IETF (Internet Engineering Task Force), ist diese Software standardisiert und weit reichend genug
implementiert, dass sie als Diskussionsgrundlage für bezüglich DNS-Services oder Dämon bildet.
Handhabung
Probleme mit dem DNS fallen in der Regel in den Bereich der Konfiguration oder der Sicherheit. Die am
häufigsten auftretenden Probleme mit dem DNS-Dienst selbst sind auf Konfigurationsfehler zurückzuführen.
DNS ist von Natur aus ein kompliziertes System. In der Regel überließ man die Konfiguration einem
fachkundigen Administrator, der das System aufsetzte und pflegte. Fehler treten oft aufgrund der Art und
Weise auf, wie DNS verwaltet wird und/oder aufgrund von unzulänglichen Werkzeugen, die üblicherweise für
die Verwaltung zur Verfügung stehen. Administratoren verwalten die DNS üblicherweise über eine Konsole
und verwenden dabei einen Texteditor (wie beispielsweise vi), um die DNS- Zonendateien einzurichten und
zu pflegen. Dies führt aufgrund von Syntaxfehlern, logischen Fehlern und Datensätzen, die auf nicht
vorhandene Ressourcen verweisen, zu Problemen in den Datensätzen selbst. Heute sind Werkzeuge
verfügbar, die sich aller drei dieser Datensatz-basierenden Probleme annehmen. Neuere Werkzeuge mit
grafischen Benutzeroberflächen bieten die Möglichkeit, Zonendateien ohne Texteditor bearbeiten zu können.
So ermöglichen moderne Managementwerkzeuge beispielsweise passend erzeugte Datensätze in
8 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
zurückliegenden Zonen vorzuhalten. Je mehr DNS-Datensätze mit einer leistungsfähigen
Benutzeroberfläche erstellt und gepflegt werden können, umso weniger benötigt man dazu einen DNS-
Experten. Ein gutes DNS-Managementwerkzeug schont personelle Ressourcen, gestattet es, sich auf
andere kritische Netzwerkbereiche zu konzentrieren und erlaubt es auch Neulingen unter den
Administratoren sich um die Wartung des Netzwerks zu kümmern.
Innerhalb der Konfiguration sollte auch berücksichtigt werden, dass Zonendateien, alle aktuellen
Kontaktinformationen der jeweils verantwortlichen Person enthalten. Bei DNS-Notfällen kommt im Regelfall
das gesamte Netzwerk zum Erliegen. Zu wissen, an wen man sich wenden muss, ist entscheidend.
IPAM
In größeren Netzwerken kann selbst ein gut geführter DNS-Service nicht ausreichend sein, um der
Komplexität und den steigenden Sicherheitsherausforderungen gerecht zu werden. In solchen Netzwerken
erlaubt ein IP-Adressen-Management (IPAM) -System eine wesentlich umfassendere Kontrolle über die
DNS-Services. Ordnungsgemäß konfigurierte IPAM-Systeme integrieren den DNS in ein größeres
Verwaltungssystem, das Entwicklungswerkzeuge für die Bereitstellung von IP-Bereichen und DHCP-
Managementwerkzeuge enthält. Dadurch sind die DNS-Konzepte immer auf dem aktuellen Stand und man
kann mit der zeitgemäßen Dynamic DNS (DDNS)-Funktionalität arbeiten. Netzwerkstrategien dieser Art,
inklusive der Network Access Control (NAC), können durch die enge Integration von DNS und DHCP bereits
wesentlich moderner ablaufen.
Sicherheit für den DNS-Service
Im Bereich Sicherheit für DNS-Services gilt es eine Reihe von Komponenten zu berücksichtigen. Der BIND-
Dienst sollte auf dem aktuellsten Build aktualisiert sein. Ebenso müssen immer die neuesten Patches
installiert sein, was Schutz vor Sicherheitslücken wie Buffer Overflows bietet. BIND kann auch in einer
"geschlossenen" CHroot Umgebung betrieben werden. Dies bedeutet, dass der Service ohne
Administratorrechte abläuft und in einem besonderen Verzeichnis liegt. So ist der Server keinem Risiko
ausgesetzt, selbst wenn es einem Hacker gelingen sollte auf den BIND-Service zuzugreifen.
Um DNS-Services sicherer und zuverlässiger zu machen, wechseln viele Unternehmen zu dedizierten
Appliances für diesen Bereich. Sie sind in der Lage die beschriebenen Best-Practice-Empfehlungen für
DNS-Server umzusetzen. Zusätzlich bieten sie Managementwerkzeuge und weitere Schnittstellen. Es ist
problemlos möglich, einen anwenderspezifischen DNS-Server zu erstellen, der all diese Faktoren
berücksichtigt. Rechnet man zusätzlich die Personalkosten mit ein, erschließt sich der Vorteil einer
dedizierten Appliance sofort. Diese Tendenz ist eine natürliche Entwicklung, die bereits bei vielen anderen
Geräten im Bereich des Netzwerkbetriebs Einzug gehalten hat, nicht zuletzt bei Routern und Firewalls.
9© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
DNS-Netzwerkarchitektur
Eine der wohl wichtigsten Vorgehensweisen im Bereich der DNS-Services ist es, den DNS-Dienst zwischen
Cache-Servern und autoritativen Servern aufzuteilen. Ein einzelner DNS-Server ist zwar in der Lage beide
Funktionen zu übernehmen, es gibt jedoch gute Gründe für eine Aufteilung.
Iterative vs rekursive Abfragen
Es gibt zwei Arten von DNS-Abfragen, die ausgegeben werden können: Iterative und rekursive. Wenn ein
DNS-Client, die IP-Adresse eines anderen Computers ermitteln muss, so erstellt er eine rekursive Abfrage
an den lokalen DNS-Server. Ein Beispiel für eine rekursive Abfrage wäre: "Ich möchte die IP-Adresse des
Web-Servers mit dem Namen www.example.com wissen". Die Namensumwandlung erstellt die Abfrage und
wartet auf eine Antwort. Aufgrund der eingeschränkten Funktionalität des Namensumwandlers ist dieser nur
in der Lage eine positive oder negative Antwort auf die rekursive Abfrage zu empfangen, mit anderen
Worten: nur ein Ja oder Nein. Während der Client auf die Antwort wartet, führt der lokale DNS-Server seine
Aufgabe fort, indem er eine weitere Abfrage ausführt, auch bekannt als iterative Abfrage an andere DNS-
Server (in der Regel an Server im Internet). Während einer normalen iterativen Abfrage, empfängt der lokale
DNS-Server eine Abfrage für den Web-Server einer Domain, für die er nicht maßgeblich ist, in diesem Fall
www.example.com. Dieser erstellt eine iterative Abfrage an einen der dreizehn Root-DNS-Server, um die IP-
Adresse von www.example.com abzufragen (optimal ist hier die erzwungene Weiterleitung dieser Abfrage
an einen Caching-DNS-Server, aus Gründen der Lesbarkeit verwenden wir hier nur den Begriff DNS-Server).
Aufgrund der hierarchischen und verteilten Struktur des DNS-Namensbereichs (Namespace), können die
DNS-Root-Server nur einen Bruchteil der Antwort liefern, welche in diesem Fall die IP-Adresse des .com
DNS-Servers ist. Der lokale DNS-Server übernimmt diese Information und erstellt eine zweite, iterative
Abfrage an den .com DNS-Server. Der .com Server antwortet mit der IP-Adresse des example.com DNS-
Servers. Der lokale Server erstellt nun eine dritte und letzte iterative Abfrage an die DNS-Server, die für die
www.example.com Domain maßgeblich sind. Der maßgebliche DNS-Server der www.example.com gibt nun
die IP-Adresse des www.example.com Computers zurück und der lokale DNS-Server kann nun auf die
ursprüngliche, rekursive Abfrage des Namenswandlers oder des Clients antworten.
Autoritative Server
Autoritative DNS-Server beantworten Abfragen im Hinblick auf die Zonen, für die sie maßgeblich
verantwortlich sind. In unserem Fall sind die autoritativen DNS-Server der example.com die einzigen Server,
die Abfragen über die example.com Domain verbindlich beantworten können. Indem man einen solchen
DNS-Server an der Beantwortung rekursiver Abfragen hindert, kann man gleichzeitig die Leistungsfähigkeit
steigern und den Sicherheitslevel erhöhen. Die Beantwortung rekursiver Abfragen ist ein
ressourcenintensiver Vorgang. Fällt die Notwendigkeit weg, rekursive Abfragen beantworten zu müssen,
ermöglichen wir dem autoritativen Server, seine Ressourcen auf die Beantwortung der Abfragen seiner
10 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Domain zu konzentrieren. Die Deaktivierung der Rekursion bedeutet sicherheitstechnisch, dass dieser DNS-
Server nicht mehr mit dem Root- oder einem anderen DNS-Nameservers im Internet kommuniziert. Je
weniger ein autoritativer Nameserver nach außen exponiert ist, desto geringer ist die Wahrscheinlichkeit,
dass er einem bekannten Angriff zum Opfer fällt.
Figure 4: Autoritative DNS
Caching-Server
Caching-Server sind demgegenüber so konfiguriert, dass sie rekursive Abfragen von Namensumwandlern
annehmen oder, im Falle der Weiterleitung, von anderen Nameservern annehmen. Auf Caching-Servern
sollten keine Zonen abgelegt sein. Ihre Funktion besteht nur darin, die rekursiven Abfragen im Interesse der
Clients zu beantworten und die iterativen Abfragen, wie oben beschrieben, auszustellen. Dies ist die einzige
Aufgabe, die sie zu erfüllen haben. Wenn Sie mit Caching-Servern arbeiten, ist es unerlässlich ACL (Access
Control List) zu verwenden; so ist gewährleistet, dass die Cache-Server nur auf Abfragen reagieren, die von
internen Clients gesendet wurden. Ansonsten ist es durchaus möglich, dass der DNS-Caching-Server durch
einen DDoS (Distributed Denial-of-Service) Angriff außer Betrieb gesetzt wird. Ein DDoS-Angriff wird durch
das Senden einer Vielzahl von Anfragen an den Server ausgelöst. Durch die Einschränkung des DNS-
Caching-Servers, nur rekursive Abfragen von internen Clients zu beantworten, wird das Risiko eines solchen
Angriffs nahezu beseitigt. Server, die rekursiven Abfragen gegenüber offen sind, können auch für DNS-
Cache-Poisoning anfällig sein. Cache-Poisoning Angriffe platzieren falsche Datensätze in einen DNS-
Server. In der Regel geschieht dies durch Manipulation des rekursiven Abfragemechanismus. Alle DNS-
Server sollten mit der aktuell verfügbaren Version von BIND aktualisiert werden, um das Risiko eines DNS-
Cache-Poisoning zu minimieren, da die neueren Versionen in der Lage sind, sicherere Transaktionen
durchzuführen.
DNS-Services, wie sie heute noch implementiert werden, wurden bereits zu einem Zeitpunkt verwendet, als
Sicherheitsbelange noch längst nicht eine so entscheidende Rolle spielten. Aufgrund der umfassenden
Sicherheitsproblematik des DNS-Caching wurde allgemein festgelegt, dass DNS-Caching-Server nur die
Abfragen interner Clients bearbeiten sollen. Autoritative Server dagegen sollten vollständig von Caching-
Servern getrennt sein, damit diese nicht den gleichen Sicherheitslücken unterliegen.
11© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Figure 5: Ein Caching-Server der eine Abfrage bearbeitet
Trennung von Funktionen
Um die Trennung der DNS-Server-Funktionen zu erreichen, ist es ratsam, das so genannte DNS-Forwarder
(DNS-Weiterleitung) -Konzept anzuwenden. Häufig sind DNS-Clients so konfiguriert, dass sie ihre Anfragen
an einen verbindlichen DNS-Server des Unternehmens senden. Erinnern wir uns daran, dass wir hinsichtlich
der Rekursion unserer verbindlichen Server sehr vorsichtig sein wollen. Gibt ein Client eine Abfrage über
einen internen Datensatz aus, für welche der DNS-Server verbindlich zuständig ist, so kann und soll dieser
Server die Abfrage aus seiner Zoneninformation heraus beantworten. Ist die Abfrage jedoch an eine Zone
gerichtet, für die der Server nicht zuständig ist, konfigurieren wir den lokalen DNS-Server so, dass er die
rekursive Abfrage an den DNS-Caching-Server weiterleitet, anstatt die Rekursion zu deaktivieren. Der
Caching-Server "durchläuft" dann den DNS-Namensbereich, indem er iterative Abfragen ausgibt, die bei den
Root-Servern beginnen, und die Antwort dann an den abfragenden DNS-Server weitergeben. Dieser
antwortet dann auf die ursprüngliche Abfrage des Clients. Durch die Verwendung von Forwardern
(Weiterleitung), können DNS-Administratoren den DNS-Server auf entsprechende Funktionen beschränken.
Figure 6: Weiterleitung an einen Caching-Server
12 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Bedingte Weiterleitung
Man kann den Einsatz der Forwarder noch ausweiten, indem man Forwarding-Zones verwendet (auch als
‚bedingte Weiterleitung' bekannt). Anstatt alle Abfragen, für die der DNS-Server nicht zuständig ist, an einen
Forwarder weiterzuleiten, kann ein DNS-Server so konfiguriert werden, dass er bestimmte Abfragen direkt
an spezifische DNS-Server versendet, die für diese Zonen zuständig sind. In der Regel sind diese
Forwarding-Zonen auf anderen, unternehmensinternen DNS-Servern abgelegt. Nehmen wir zu
Anschauungszwecken an, dass ein Unternehmen mehr als eine DNS-Zone verwaltet. Die Domain
example.com wird von einer Gruppe von einem DNS-Server aus verwaltet, während die Domain
example2.com von DNS-Servern aus einer anderen Abteilung verwaltet wird. Erhält nun der DNS-Server der
example.com eine Anfrage über die example2.com Domain, so kann diese Anfrage direkt an den DNS-
Server der example2.com Domain weitergegeben werden, ohne zuerst die Anfrage an den Caching-Server
weiterzuleiten, der dann die Anfrage an die Root-Server weitergibt usw. Diese Funktion gewährleistet, dass
Anfragen nach Ressourcen, die in den Zuständigkeitsbereich des jeweiligen DNS-Servers fallen, das
Netzwerk nicht verlassen. Rekursive, internetweite Anfragen würden in diesem Szenario nur für nicht-lokale
Ressourcen verwendet werden. Dadurch wird der Caching-Server weniger belastet. Ein Hacker, der den
Datenverkehr zwischen dem Unternehmen und dem Internet abhören will, wird niemals auf Abfragen nach
internen Ressourcen zugreifen können. Auch diese Funktion macht DNS erheblich sicherer.
Figure 7: Bedingte Weiterleitung
13© 2006 BlueCat Networks (USA), Inc. Alle Recht vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
BIND Views
Es gibt weitere Funktionen, die DNS-Administratoren anwenden können, um die DNS-Infrastruktur sicherer
und zugleich ausfallsicherer zu machen. Durch die BIND Views- Funktion kann ein DNS-Server die Clients,
die ihn nutzen, "erkennen" und ist somit in der Lage entsprechend zu reagieren. Falls ein DNS-Server nur für
eine bestimmte Benutzergruppe zuständig ist, können die Anfragen an den Server mit einer ACL (Access
Control List) verglichen werden. Verwendet man BIND Views, werden die Abfragen erst dann ausgeführt,
wenn die IP-Adresse in der ACL-Liste aufgeführt ist, von der die ursprüngliche Abfrage stammt. Ein View
kann die Anfrage eines Clients erst dann beantworten, wenn dieser in einer der jeweiligen ACL-Listen
aufgeführt ist. Mit der View-Funktion kann ein Server vielseitiger gestaltet werden. Er kann beispielsweise
unterschiedliche Daten für unterschiedliche Benutzergruppen anzeigen oder die Anfragen einer
Benutzergruppe bearbeiten und dabei alle anderen ignorieren. Das minimiert jedoch keineswegs das
Sicherheitsrisiko, wenn der Caching-Server und der DNS-Server nicht getrennt sind.
Figure 8: BIND-Ansichten
Externe DNS und Sicherheit
Auch hinsichtlich des externen DNS gibt es optimale Vorgehensweisen. Auf externen DNS-Servern werden
Ressourcen-Datensätze abgelegt, auf die über das Internet (Web, E-Mail, ftp usw.) zugegriffen werden kann.
Diese Server beantworten Abfragen über Ressourcen von externen Clients, für die sie zuständig sind. Diese
Ressourcen sind für Benutzer zugänglich, die sich außerhalb des Unternehmens befinden und über
Protokolle, wie beispielsweise Web-Server, Mail-Server usw. darauf zugreifen.
14 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Firewalls
Das Erste, an das wir uns bei externen DNS erinnern sollten ist, dass Firewalls ein unverzichtbarer
Bestandteil sind. Sie gewährleisten bei der Einrichtung einer DMZ zwischen internem Netzwerk und dem
Internet, dass der Netzwerkverkehr nur dann sichtbar wird, wenn beispielsweise Daten über das Internet
übertragen werden. Der Einsatz einer Firewall auf der öffentlichen Seite des DMZ gewährleistet, dass die
Server vor ungewollten Zugriffen aus dem Internet geschützt sind. Die Firewall im internen Bereich der DMZ
gewährleistet, dass die Ressourcen im internen Netzwerk durch Beschränkungen und Richtlinien zusätzlich
abgesichert werden. Durch Firewalls entsteht im Netzwerk eine Zone, in der nur eine bestimmte Form des
Datenverkehrs regulär und zulässig ist.
Figure 9: Eine DNS-Topologie mit einer Firewall
Verborgener Master
Eine der Möglichkeiten, einen externen Master-Nameserver abzusichern ist eine Konfiguration, die als
"Verborgener Master" bekannt ist. Mit dem Konzept des "verborgenen Masters" können Sie einen Master-
Nameserver hinter einer Firewall auf der internen Seite eines Netzwerks verbergen. Es sind keine weiteren
Sicherheitsmaßnahmen erforderlich. Der "verborgene Master" wird nie in einem NS-Datensatz einer DNS-
Zone aufgeführt, daher ist er für alle öffentlichen Ansichten (Views) dieser Zone unsichtbar. Dieser
"verborgene Master" Server wird für Modifikationen an Zonendateien und zur Übertragung der Zonendateien
an die "Slave" Server in der DMZ verwendet. Damit ist die wichtigste DNS-Information nie öffentlich
zugänglich.
15© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Figure 10: Die Topologie eines verborgenen Masters
Zonentransfers und TSIG
Beim Entwurf einer externen DNS-Infrastruktur ist es äußerst wichtig, auch die Sicherheit der Zonentransfers
zu berücksichtigen. Beachten Sie stets, wer oder "was" Zonen von Ihrem primären Server übertragen kann
und darf. Ein offener Server, der jedem Host Zonentransfers ermöglich, ist in zweierlei Hinsicht ein Problem.
Der Server ist für Denial-of-Service Angriffe (DoS) offen. Ein Angreifer kann ein einfaches Skript erstellen,
welches ständig Zonentransfers im Ziel-Server auslöst. Das schränkt die Ressourcen und die Bandbreite
eines Servers erheblich ein. Zudem geben Zonentransfers jedem Angreifer einen "Lageplan" des
Zielnetzwerks an die Hand. Das ist besonders dann kritisch, wenn das interne System in externen Zonen
angezeigt ist (was allerdings nie der Fall sein sollte). Zonentransfers sollten ausschließlich auf berechtigte
Hosts eingeschränkt werden, wie über ACL (Access Control Lists) möglich. Zonentransfers können
zusätzlich über digitale Unterschriften authentifiziert werden, um sie noch weiter abzusichern. Neuere BIND-
Versionen verwenden TSIG (Transaction Signatures (Transaktionssignaturen)), um Nameserver zu
authentifizieren, die Zonentransfers durchführen. Dies geschieht durch einen Kryptografieservice, der auf
zuvor ausgegebenen Schlüsseln basiert. Damit dieses System funktionieren kann, benötigt der berechtigte
Sekundär-Server einen TSIG-Schlüssel. Für einen Eindringling ist es dann wesentlich schwieriger einen
Zonentransfer von einem geschützten Master-Server anzufordern. TSIGs können dazu verwendet werden,
Daten so zu zergliedern, dass nur die ausgegebenen Daten gültig sind und nicht modifiziert wurden.
16 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Figure 11: Geschützte TSIG Zonentransfers
Versionsmaskierung
Best Practice ist ebenfalls das Verbergen der BIND-Version auf dem Server, auf dem sie gerade ausgeführt
wird. BIND (und andere Nameserver) beantworten per Voreinstellung alle Versionsabfragen. Dies ist eine
durchaus nützliche Funktion für Administratoren, öffnet aber zugleich eine Hintertür für potenzielle Angreifer
(indem sie bekannte Exploits für die jeweilige Version des BIND-Dienstes verwenden). Das Verbergen der
BIND-Version ist keine Wunderwaffe, bietet aber einen zusätzlichen Sicherheitslevel. Dieses Szenario
beinhaltet ein hoch verfügbares Cluster für den Master-Server. Auch bei einem Hardwarefehler würde der
DNS-Service weiterhin in Bereitschaft und verfügbar sein. In diesem Szenario kommt mehr als nur ein
Slave-Server zum Einsatz, was eine maximale Verfügbarkeit der externen DNS gewährleistet. Dabei wird
selbstverständlich ein autoritativer Server zur Namensauflösung externer DNS rekursive Anfragen
annehmen.
Figure 12: Beispiel eines externen DNS
17© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen
Optimale Vorgehensweise bei DNS
Figure 10: Die Topologie eines verborgenen Masters
Zonentransfers und TSIG
Beim Entwurf einer externen DNS-Infrastruktur ist es äußerst wichtig, auch die Sicherheit der Zonentransfers
zu berücksichtigen. Beachten Sie stets, wer oder "was" Zonen von Ihrem primären Server übertragen kann
und darf. Ein offener Server, der jedem Host Zonentransfers ermöglich, ist in zweierlei Hinsicht ein Problem.
Der Server ist für Denial-of-Service Angriffe (DoS) offen. Ein Angreifer kann ein einfaches Skript erstellen,
welches ständig Zonentransfers im Ziel-Server auslöst. Das schränkt die Ressourcen und die Bandbreite
eines Servers erheblich ein. Zudem geben Zonentransfers jedem Angreifer einen "Lageplan" des
Zielnetzwerks an die Hand. Das ist besonders dann kritisch, wenn das interne System in externen Zonen
angezeigt ist (was allerdings nie der Fall sein sollte). Zonentransfers sollten ausschließlich auf berechtigte
Hosts eingeschränkt werden, wie über ACL (Access Control Lists) möglich. Zonentransfers können
zusätzlich über digitale Unterschriften authentifiziert werden, um sie noch weiter abzusichern. Neuere BIND-
Versionen verwenden TSIG (Transaction Signatures (Transaktionssignaturen)), um Nameserver zu
authentifizieren, die Zonentransfers durchführen. Dies geschieht durch einen Kryptografieservice, der auf
zuvor ausgegebenen Schlüsseln basiert. Damit dieses System funktionieren kann, benötigt der berechtigte
Sekundär-Server einen TSIG-Schlüssel. Für einen Eindringling ist es dann wesentlich schwieriger einen
Zonentransfer von einem geschützten Master-Server anzufordern. TSIGs können dazu verwendet werden,
Daten so zu zergliedern, dass nur die ausgegebenen Daten gültig sind und nicht modifiziert wurden.
16 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Figure 13: DHCP und DDNS mit TSIG
Ein vollständiges Netzwerk
Viele, wenn nicht die meisten Unternehmen betreiben eine Kombination aus internen und externen DNS. Für
die Clients des internen Netzwerks ist in der Regel ein Zugriff auf interne und externe Ressourcen
erforderlich, während für Clients außerhalb des Unternehmens der Zugriff im Normalfall auf die extern
verfügbaren Ressourcen eingeschränkt wird, wie beispielsweise auf Web-Server, Mail-Server usw.
Die internen DNS-Clients sind so konfiguriert, dass sie einen internen DNS-Server zur Namensauflösung
verwenden. Ist eine angefragte Ressource intern, so gibt der DNS-Server die Adresse der Ressource
zurück. Betrifft die angefragte Information eine externe Ressource, so ist der interne DNS-Server so
konfiguriert, dass er die Anfrage an den Caching-Server weiterleitet. Ein Caching-Server kann in einem
internen Netzwerk oder in der DMZ platziert werden, je nach dem, ob andere Geräte in der DMZ darauf
zugreifen müssen. Nachdem der Caching-Server die Abfrage aufgelöst hat, gibt er die Antwort an den
internen DNS-Server weiter. Dieser antwortet dann auf die ursprüngliche Abfrage des Clients. So bleibt der
autoritative Server von dem oder den Caching-Server/n getrennt. Die Abbildung illustriert die Integration der
hier angesprochenen Best Practice Empfehlungen auf Netzwerkebene.
19© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
Figure 14: Ein vollständiges Netzwerk
Die externen und internen DNS-Daten werden auf physikalisch getrennten Servern abgelegt. Durch die
Platzierung des Master-Servers im internen Netzwerk, wird dieser vor äußeren Angriffen geschützt und als
“verborgener” Master konfiguriert und die DNS noch zusätzlich abgesichert. Falls gewünscht, kann eine
hoch verfügbare Konfiguration eingesetzt werden, um sich gegen Hardwarefehler auf dem Master-Server
abzusichern. Die externen DNS-Slave-Server werden in der DMZ des Unternehmens platziert und durch
Zonentransfers durch den externen View auf den DNS-Master-Server aktualisiert. Es ist äußerst wichtig,
dass sich auf den externen DNS-Servern keine Datensätze der internen DNS befinden, da diese von
externen Clients abgefragt werden können.
Schlussfolgerung
Die geschilderten DNS-Verfahrensweisen, werden sich mit der Zeit immer mehr zum Standard entwickeln.
Grundsätzlich wird dem DNS-Service oft zu wenig Beachtung geschenkt, was zu schlecht konfigurierten
Services führen kann. Sie sind dann entweder nicht vollständig verfügbar, funktionieren nicht richtig oder
können sehr leicht kompromittiert werden. Durch die zunehmende Anzahl der implementierten
Applikationen, mit einer Vielzahl an zusätzlichen Werkzeugen, wird dieses Problem etwas minimiert. Um
sicherzustellen, dass das Internet auch bei weiterer Expansion ein verlässliches Medium für
Informationsvermittlung und geschäftliche Transaktionen bleibt, ist die Implementierung von sicheren und
20 © 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
effizienten DNS zwingend erforderlich. Zudem wird DNS immer besser organisiert und verstanden. Eine
zusätzliche Integration des DNS-Dienstes in IPAM Systeme ist eine natürliche Reaktion auf die neu
entstehenden Komplexitätsebenen, wenn sich Netzwerke weiterentwickeln. Best Practice für DNS auf einen
Nenner gebracht: Komplexe Netzwerke sicher verwalten!
21© 2006 BlueCat Networks (USA), Inc. Alle Rechte vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind möglich.
Optimale Vorgehensweise bei DNS
22 © 2006 BlueCat Networks (USA), Inc. Alle Recht vorbehalten. Alle aufgeführten Markennamen und Warenzeichen sind Eigentum der rechtmäßigen Besitzer. Die tatsächliche Form der Implementation und
Konfiguration kann Abweichungen unterliegen. Fehler und Auslassungen sind zu erwarten.
Top Related