|
|
| Zeile 231: |
Zeile 231: |
|
| |
|
| [[Kategorie:Entwurf]] | | [[Kategorie:Entwurf]] |
|
| |
| = Wikipedia =
| |
| == Komponenten ==
| |
| === Domain-Namensraum ===
| |
| [[Datei:Dns-raum.svg|mini|Schematische Darstellung der DNS-Hierarchie]]
| |
| Der Domain-Namensraum hat eine baumförmige Struktur.
| |
| * Die [[Blatt (Graphentheorie)|Blätter]] und [[Knoten (Graphentheorie)|Knoten]] des Baumes werden als Labels bezeichnet.
| |
| * Ein kompletter Domainname eines Objektes besteht aus der Verkettung aller Labels eines Pfades.
| |
|
| |
| Labels sind Zeichenketten, die jeweils mindestens ein [[Oktett (Informatik)|Byte]] und maximal 63 Bytes lang sind (RFC 2181, Abschnitt „11. Name syntax“).
| |
| * Einzelne Labels werden durch Punkte voneinander getrennt.
| |
| * Ein Domainname wird mit einem Punkt abgeschlossen (der letzte Punkt wird normalerweise weggelassen, gehört rein formal aber zu einem vollständigen Domainnamen dazu).
| |
| * Somit lautet ein korrekter, vollständiger Domainname (auch [[Fully Qualified Domain Name|{{lang|en|Fully Qualified Domain-Name}} (FQDN)]] genannt) zum Beispiel <code>www.example.com.</code> <!-- sic! siehe [[Fully Qualified Domain-Name]] --> und darf inklusive aller Punkte maximal 255 Bytes lang sein.
| |
|
| |
| Ein Domainname wird immer von rechts nach links delegiert und aufgelöst, das heißt je weiter rechts ein Label steht, umso höher steht es im Baum.
| |
| * Der Punkt am rechten Ende eines Domainnamens trennt das Label für die erste Hierarchieebene von der Wurzel (englisch ''{{lang|en|root}}'').
| |
| Diese erste Ebene wird auch als [[Top-Level-Domain]] (TLD) bezeichnet.
| |
| Die DNS-Objekte einer Domäne (zum Beispiel die Rechnernamen) werden als Satz von [[Resource Record]]s meist in einer [[Zonendatei]] gehalten, die auf einem oder mehreren autoritativen Nameservern vorhanden ist.
| |
| * Anstelle von ''Zonendatei'' wird meist der etwas allgemeinere Ausdruck [[Zone (DNS)|Zone]] verwendet.
| |
|
| |
| {{Siehe auch|Liste länderspezifischer Top-Level-Domains}}
| |
|
| |
| === Nameserver ===
| |
| Ein '''Nameserver''' ist ein [[Server (Software)|Server]], der [[Namensauflösung]] anbietet.
| |
| * Namensauflösung ist das Verfahren, das es ermöglicht, Namen von Rechnern bzw.
| |
| * Diensten in eine vom Computer bearbeitbare Adresse aufzulösen (z. B. ''www.wikipedia.org'' in ''91.198.174.192'').
| |
|
| |
| Die meisten Nameserver sind Teil des Domain Systems, das auch im [[Internet]] benutzt wird.
| |
|
| |
| Nameserver sind zum einen Programme, die auf Basis einer DNS-[[Datenbank]] Anfragen zum Domain-Namensraum beantworten.
| |
| * Im Sprachgebrauch werden allerdings auch die Rechner, auf denen diese Programme zum Einsatz kommen, als Nameserver bezeichnet.
| |
| * Man unterscheidet zwischen autoritativen und nicht-autoritativen Nameservern.
| |
|
| |
| Ein autoritativer Nameserver ist verantwortlich für eine Zone.
| |
| * Seine Informationen über diese Zone werden deshalb als ''gesichert'' angesehen.
| |
| * Für jede Zone existiert mindestens ein autoritativer Server, der Primary Nameserver.
| |
| * Dieser wird im [[SOA Resource Record]] einer [[Zonendatei]] aufgeführt.
| |
| * Aus Redundanz- und Lastverteilungsgründen werden autoritative Nameserver fast immer als [[Server]]-[[Computercluster|Cluster]] realisiert, wobei die Zonendaten identisch auf einem oder mehreren Secondary Nameservern liegen.
| |
| * Die Synchronisation zwischen Primary und Secondary Nameservern erfolgt per [[Zonentransfer]].
| |
|
| |
| Ein nicht-autoritativer Nameserver bezieht seine Informationen über eine Zone von anderen Nameservern sozusagen aus zweiter oder dritter Hand.
| |
| * Seine Informationen werden als ''nicht gesichert'' angesehen.
| |
| * Da sich DNS-Daten normalerweise nur sehr selten ändern, speichern nicht-autoritative Nameserver die einmal von einem Resolver angefragten Informationen im lokalen [[Halbleiterspeicher#Wahlfreier Zugriff|RAM]] ab, damit diese bei einer erneuten Anfrage schneller vorliegen.
| |
| * Diese Technik wird als [[DNS-Caching|Caching]] bezeichnet.
| |
| * Jeder dieser Einträge besitzt ein eigenes Verfallsdatum ([[Time to live|TTL]] ''time to live''), nach dessen Ablauf der Eintrag aus dem Cache gelöscht wird.
| |
| * Die TTL wird dabei durch einen autoritativen Nameserver für diesen Eintrag festgelegt und wird nach der Änderungswahrscheinlichkeit des Eintrages bestimmt (sich häufig ändernde DNS-Daten erhalten eine niedrige TTL).
| |
| * Das kann unter Umständen bedeuten, dass der Nameserver in dieser Zeit falsche Informationen liefert, wenn sich die Daten zwischenzeitlich geändert haben.
| |
|
| |
| Ein Spezialfall ist der Caching Only Nameserver.
| |
| * In diesem Fall ist der Nameserver für keine Zone verantwortlich und muss alle eintreffenden Anfragen über weitere Nameserver (Forwarder) auflösen.
| |
| * Dafür stehen verschiedene Strategien zur Verfügung:
| |
|
| |
| ;Zusammenarbeit der einzelnen Nameserver
| |
| Damit ein nicht-autoritativer Nameserver Informationen über andere Teile des Namensraumes finden kann, bedient er sich folgender Strategien:
| |
|
| |
| ;Delegierung
| |
| :Teile des Namensraumes einer Domain werden oft an [[Domain (Internet)#Subdomain|Subdomains]] mit dann eigens zuständigen Nameservern ausgelagert.
| |
| * Ein Nameserver einer Domäne kennt die zuständigen Nameserver für diese Subdomains aus seiner Zonendatei und delegiert Anfragen zu diesem untergeordneten Namensraum an einen dieser Nameserver.
| |
| ;Weiterleitung (forwarding)
| |
| :Falls der angefragte Namensraum außerhalb der eigenen Domäne liegt, wird die Anfrage an einen fest konfigurierten Nameserver weitergeleitet.
| |
| ;Auflösung über die Root-Nameserver
| |
| :Falls kein Weiterleitungsserver konfiguriert wurde oder dieser nicht antwortet, werden die [[Root-Nameserver]] befragt.
| |
| * Dazu werden in Form einer statischen Datei die Namen und IP-Adressen der Root-Server hinterlegt.
| |
| * Es gibt 13 Root-Server (Server A bis M).
| |
| * Die Root-Server beantworten ausschließlich [[Rekursive und iterative Namensauflösung|iterative]] Anfragen.
| |
| * Sie wären sonst mit der Anzahl der Anfragen schlicht überlastet.
| |
|
| |
| Anders konzipierte Namensauflösungen durch Server, wie der [[Netware|NetWare Name Service]] oder der [[Windows Internet Naming Service]], sind meistens auf [[Local Area Network]]s beschränkt und werden zunehmend von der [[Internetprotokollfamilie]] verdrängt.
| |
|
| |
| === Protokoll ===
| |
| DNS-Anfragen werden normalerweise per [[User Datagram Protocol|UDP]] [[Port (Protokoll)|Port]] 53 zum Namensserver gesendet.
| |
| * Der DNS-Standard fordert aber auch die Unterstützung von [[Transmission Control Protocol|TCP]] für Fragen, deren Antworten zu groß für UDP-Übertragungen sind.<ref>[[RFC:7766#section-1|RFC 7766]] – ''DNS Transport over TCP – Implementation Requirements.'' [[Internet Engineering Task Force]] (IETF), S. 3 (Stand: März 2010) {{" |lang=en |Text=This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. […] It should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) will probably result in resolution failure and/or application-level timeouts.}}</ref> Falls kein [[Extended DNS]] verwendet wird (EDNS), beträgt die maximal zulässige Länge des DNS-UDP-Pakets 512 [[Byte]]s. Überlange Antworten werden daher abgeschnitten übertragen.
| |
| * Durch Setzen des Truncated-Flags wird der anfragende Client über diesen Sachverhalt informiert.
| |
| * Er muss dann entscheiden, ob ihm die Antwort reicht oder nicht.
| |
| * Gegebenenfalls wird er die Anfrage per TCP Port 53 wiederholen.
| |
|
| |
| Zonentransfers werden stets über Port 53 TCP durchgeführt.
| |
| * Die Auslösung von Zonentransfers erfolgt aber gewöhnlich per UDP.
| |
|
| |
| == Erweiterungen ==
| |
| Da sich das DNS als zuverlässig und flexibel erwiesen hat, wurden im Laufe der Jahre mehrere größere Erweiterungen eingeführt.
| |
| * Ein Ende dieses Trends ist nicht absehbar.
| |
|
| |
| === Dynamisches DNS ===
| |
| Im klassischen DNS ist es aufwendig, einem Namen eine neue IP-Adresse zuzuordnen.
| |
| * Das zugehörige Zonenfile muss (meist manuell) geändert und der Nameserver neu geladen werden.
| |
| * Zeitliche Verzögerungen bis hin zu mehreren Tagen sind üblich.
| |
| * Mit [[Dynamisches DNS|dynamischem DNS]] sind Änderungen durch Senden einer Aktualisierungsanfrage mit geringer Zeitverzögerung möglich.
| |
|
| |
| Das Dynamische DNS gilt als Sicherheitsrisiko, da ohne spezielle Vorkehrungen jedermann DNS-Einträge löschen oder verändern kann.
| |
| * Im Zusammenhang mit [[Dynamic Host Configuration Protocol|DHCP]] ist Dynamisches DNS nahezu zwingend erforderlich, da einem User häufig neue IP-Adressen zugewiesen werden.
| |
| * Der DHCP-Server sendet dazu bei jeder Adressänderung eine entsprechende Mitteilung an den Nameserver.
| |
|
| |
| === Internationalisierung ===
| |
| {{Hauptartikel|Internationalisierter Domainname}}
| |
|
| |
| Bisher waren die Labels auf [[alphanumerische Zeichen]] und das Zeichen ‚-‘ eingeschränkt.
| |
| * Möglich, aber nicht standardkonform, ist bei Subdomains zudem ‚_‘.
| |
| * Dieser begrenzte Zeichenvorrat hängt vor allem damit zusammen, dass das DNS (wie auch das Internet ursprünglich) in den [[Vereinigte Staaten|USA]] entwickelt wurde.
| |
| Damit waren in vielen Ländern gebräuchliche [[Schriftzeichen]] (im deutschen Sprachraum zum Beispiel die [[Umlaut]]e ä, ö und ü sowie ß) oder Zeichen aus komplett anderen Schriftsystemen (zum Beispiel Chinesisch) ursprünglich nicht in Domainnamen möglich.
| |
|
| |
| Ein mittlerweile etablierter Ansatz zur Vergrößerung des Zeichenvorrats ist die 2003 in RFC 3490 eingeführte und 2010 mit RFC 5890 aktualisierte Internationalisierung von Domainnamen (IDNA).
| |
| * Um das neue System mit dem bisherigen kompatibel zu halten, werden die erweiterten Zeichensätze mit den bislang zulässigen Zeichen kodiert.
| |
| * Die erweiterten Zeichensätze werden dabei zunächst normalisiert, um unter anderem Großbuchstaben auf Kleinbuchstaben abzubilden, und anschließend per [[Punycode]] auf einen ASCII-kompatiblen String abgebildet.
| |
| * IDNA erfordert eine Anpassung der Netzwerkanwendungen (zum Beispiel [[Webbrowser]]), die Nameserver-Infrastruktur (Server, Resolver) braucht jedoch nicht verändert zu werden.
| |
| * Im deutschsprachigen Raum können seit März 2004 deutsche, liechtensteinische, österreichische und schweizerische Domains (.de, .li, .at und .ch) mit Umlauten registriert und verwendet werden.
| |
| * Auch bei anderen [[Top-Level-Domain]]s, insbesondere im asiatischen Raum, ist die Verwendung von internationalisierten Domainnamen möglich.
| |
|
| |
| === Extended DNS ===
| |
| 1999 beschrieb [[Paul Vixie]] im RFC 2671 einige kleinere, abwärtskompatible Erweiterungen am Domain Name System, die als [[Extended DNS]] Version 0 bezeichnet werden.
| |
| * Durch Einsatz eines Pseudo-Records als Header-Erweiterung kann der Anfragende zusätzliche Optionen setzen.
| |
| * Insbesondere kann er übermitteln, dass er UDP-Antworten größer als 512 Bytes entgegennehmen kann. [[DNSSEC]]-fähige Server und Resolver müssen EDNS beherrschen.
| |
|
| |
| === Verwaltung von Telefonnummern ===
| |
| Eine weitere aktuelle Erweiterung des DNS stellt [[Telephone Number Mapping|ENUM]] (RFC 2916) dar.
| |
| * Diese Anwendung ermöglicht die Adressierung von [[Internet]]-Diensten über Telefonnummern, also das „Anwählen“ von per Internet erreichbaren Geräten mit dem aus dem Telefonnetz bekannten Nummerierungsschema.
| |
| Aus dem breiten Spektrum der Einsatzmöglichkeiten bietet sich insbesondere die Verwendung für [[Voice over IP]] Services an.
| |
|
| |
| === RFID-Unterstützung ===
| |
| Mit der [[RFID]] können auf speziellen RFID-Etiketten abgelegte [[Identifikator|IDs]] – so genannte [[Elektronischer Produktcode|elektronische Produktcodes]] oder EPCs – berührungslos gelesen werden.
| |
| * Das DNS kann dazu verwendet werden, zu einer ID den Server zu ermitteln, der Daten über das zugehörige Objekt enthält.
| |
| * Der [[Object Naming Service]] ONS wandelt dazu den EPC in einen DNS-Namen um und erfragt per Standard-DNS einen oder mehrere Naming Authority Pointer NAPTR.
| |
|
| |
| === Spam-Abwehr ===
| |
| Zur Filterung von [[Spam]]-Mails überprüfen viele [[Mailserver]] den DNS-Eintrag des sendenden Mailservers routinemäßig mit Hilfe des [[Reverse DNS]] Lookup.
| |
| * Dieser muss nicht nur auch vorwärts wieder korrekt auflösen und auf die IP-Adresse des sendenden Systems zeigen ([[Forward-confirmed reverse DNS]]), sondern muss auch dem im SMTP-Protokoll genannten HELO-Hostnamen des sendenden Systems entsprechen.
| |
|
| |
| Mittels [[Sender Policy Framework]] wird versucht, den Versand von gefälschten Absendern durch Dritte möglichst zu unterbinden.
| |
| * Zu jeder Mail-Domain wird dabei über einen speziellen [[SPF Resource Record]] explizit aufgelistet, von welchen Servern und IP-Netzen mit E-Mails dieser Domain zu rechnen ist.
| |
| * SPF steht jedoch wegen zahlreicher technischer Schwierigkeiten, beispielsweise bei Weiterleitungen, in der Kritik.
| |
|
| |
| Auch der Anti-Spam-Mechanismus [[DomainKeys]] (DKIM) greift auf Einträge im DNS zurück, indem sendende Mailserver in DNS-TXT-Records ihren Public-Key veröffentlichen, mit dem die Signatur ihrer ausgehenden E-Mails verifiziert werden kann.
| |
|
| |
| === Sonstiges ===
| |
| Neben den IP-Adressen können DNS-Namen auch [[Integrated Services Digital Network|ISDN]]-Nummern, [[X.25]]-Adressen, [[Asynchronous Transfer Mode|ATM]]-Adressen, [[Öffentlicher Schlüssel|öffentliche Schlüssel]], Text-Zeilen usw.
| |
| * zugeordnet werden.
| |
| * In der Praxis sind derartige Anwendungsfälle aber die Ausnahme.
| |
|
| |
| == DNS im lokalen Netz ==
| |
| DNS ist nicht auf das Internet beschränkt.
| |
| * Es ist ohne weiteres möglich und mit der Definition verträglich, für die Auflösung lokaler Namen eigene Zonen im Nameserver einzurichten und dort die entsprechenden Adressen einzutragen.
| |
| * Der einmalige Aufwand zur Installation lohnt sich auch bei relativ kleinen Netzen, da dann alle Adressen im Netz zentral verwaltet werden können.
| |
|
| |
| Bei größeren Firmen oder Organisationen ist häufig ein aus lokalem und Internet-DNS bestehendes Mischsystem (Split-DNS) anzutreffen.
| |
| * Die internen Nutzer greifen auf das lokale und die externen auf das Internet-DNS zu.
| |
| * In der Praxis können dadurch sehr komplizierte Konstellationen entstehen.
| |
|
| |
| Der DNS-Server [[BIND]] kann auch mit [[Dynamic Host Configuration Protocol|DHCP]] zusammenarbeiten und damit für jeden Client im Netz eine Namensauflösung ermöglichen.
| |
|
| |
| Unter Windows gibt es noch einen anderen Dienst zur Namensauflösung – [[Windows Internet Naming Service|WINS]], der eine ähnliche Funktion zur Verfügung stellt, allerdings ein anderes Protokoll verwendet.
| |
|
| |
| == DNS-Serververbund ==
| |
| Es ist möglich, mehrere DNS-Server zu verbinden.
| |
| * Die als Master bezeichneten Server sind für eine oder mehrere Domains verantwortlich.
| |
| * Die Slaves aktualisieren nach einer Änderung selbst die Daten, der Master verteilt diese Daten nicht automatisiert.
| |
| * Die Abholung der Daten wird über einen [[Zonentransfer]] realisiert.
| |
|
| |
| Beispielsweise kann eine Firma mit mehreren Standorten an einem Platz einen Master für ihr internes DNS betreiben, der die Server in den Außenstellen versorgt.
| |
| * Der Zonentransfer geht bei BIND über TCP (per Default Port 53) und erfordert empfohlenerweise Authentifizierung.
| |
| * Die Slaves aktualisieren sich, wenn sich die Seriennummer für eine Zonendatei ändert oder sie eine entsprechende Nachricht vom Master erhalten.
| |
| * Die Freigabe für den Transferport sollte man per Firewall an die IP-Adresse des Masters binden.
| |
| * Bei anderen Softwarepaketen werden die Daten unter Umständen auf anderen Wegen abgeglichen, beispielsweise durch LDAP-Replikation, rsync, oder noch andere Mechanismen.
| |
|
| |
| == Sicherheit ==
| |
| Das DNS ist ein zentraler Bestandteil einer vernetzten IT-Infrastruktur.
| |
| * Eine Störung kann erhebliche Kosten nach sich ziehen und eine Verfälschung von DNS-Daten Ausgangspunkt von Angriffen sein.
| |
|
| |
| === Angriffsformen ===
| |
| Hauptziel von DNS-Angriffen ist es, durch Manipulation DNS-Teilnehmer auf falsche Webseiten zu lenken, um anschließend Passwörter, PINs, Kreditkartennummern usw.
| |
| * zu erhalten.
| |
| * In seltenen Fällen wird versucht, den Internet-DNS durch [[Denial of Service|Denial-of-Service]]-Attacken komplett auszuschalten und so das Internet lahmzulegen.
| |
| * Außerdem kann das DNS dazu verwendet werden, gezielte Angriffe auf Einzelpersonen oder Unternehmen zu intensivieren.
| |
|
| |
| ==== DDoS-Angriff auf Nameserver ====
| |
| Bei einem [[Distributed Denial of Service|Distributed-Denial-of-Service]]-Angriff werden Nameserver durch einen hohen Datenstrom von DNS-Anfragen überlastet, so dass legitime Anfragen nicht mehr beantwortet werden können.
| |
| * Gegen DDoS-Angriffe auf Nameserver gibt es zur Zeit keine Abwehrmöglichkeit.
| |
| * Als vorbeugende Maßnahme kann lediglich versucht werden, die Nameserver entsprechend zu dimensionieren bzw.
| |
| * ein verteiltes Netz mit möglichst vielen Servern zu installieren.
| |
| * Um eine große Anzahl DNS-Anfragen zu erzeugen, werden bei solchen Angriffen [[Botnet]]ze eingesetzt.
| |
|
| |
| Ein DDoS-Angriff kann unbeabsichtigt einen DNS-Server betreffen und zum Ausfall bringen, wenn der Domainname des Angriffsziels wiederholt aufgelöst wird ohne zwischengespeichert zu werden.
| |
| * Der Effekt auf DNS-Server wird verhindert, wenn das DDoS-Schadprogramm [[DNS-Caching]] verwendet.
| |
|
| |
| ==== DNS-Amplification-Angriff ====
| |
| Die [[DNS Amplification Attack]] ist ein [[Denial of Service|Denial-of-Service]]-Angriff, bei der nicht der DNS-Server selbst das eigentliche Angriffsziel ist, sondern ein Dritter.
| |
| * Ausgenutzt wird, dass ein DNS-Server in manchen Fällen auf kurze Anfragen sehr lange Antworten zurücksendet.
| |
| * Durch eine gefälschte Absenderadresse werden diese an die IP-Adresse des Opfers gesendet.
| |
| * Ein Angreifer kann damit den von ihm ausgehenden Datenstrom substanziell verstärken und so den Internet-Zugang seines Angriffsziels stören.
| |
|
| |
| === DNS-Spoofing ===
| |
| Beim [[DNS-Spoofing]] handelt es sich um eine Angriffsklasse von Maskierungsangriffen, die das Ziel haben eine falsche Identität vorzugeben.
| |
| * Dafür wird die DNS-Antwort an einen Client verändert um ihn auf einen anderen, meist vom Angreifer kontrollierten Dienst fehlzuleiten.
| |
|
| |
| ==== Cache Poisoning ====
| |
| [[Cache Poisoning]] bezeichnet ein Angriffsszenario, welches in die Angriffsklasse des DNS-Spoofing fällt.
| |
| * Dabei werden einem anfragenden Client zusätzlich zu der korrekten Antwort, manipulierte Daten übermittelt, die dieser in seinen Cache übernimmt und später, möglicherweise ungeprüft, verwendet.
| |
|
| |
| ==== Offener DNS-Server ====
| |
| Wer einen autoritativen DNS-Server für seine eigenen Domains betreibt, muss natürlich für Anfragen von beliebigen IP-Adressen offen sein.
| |
| * Um zu verhindern, dass Internetteilnehmer diesen Server als allgemeinen Nameserver verwenden (z. B.
| |
| * für Angriffe auf Root-Server), erlaubt BIND es, die Antworten auf die eigenen Domains einzuschränken.
| |
| * Beispielsweise bewirkt die Option <code>allow-recursion {127.0.0.1; 172.16.1.4;};</code>, dass rekursive Anfragen, d. h.
| |
| * Anfragen auf andere Domains, ausschließlich für den lokalen Host (localhost) sowie 172.16.1.4 beantwortet werden.
| |
| * Alle anderen IP-Adressen bekommen nur auf Anfragen auf eigene Domains eine Antwort.
| |
|
| |
| Ein offener DNS-Server kann auch eine Falle sein, wenn er gefälschte IP-Adressen zurückgibt, siehe [[Pharming (Internet)|Pharming]].
| |
|
| |
| === Sicherheitserweiterungen ===
| |
| Mehr als zehn Jahre nach der ursprünglichen Spezifikation wurde DNS um Security-Funktionen ergänzt.
| |
| * Folgende Verfahren sind verfügbar:
| |
|
| |
| ==== TSIG ====
| |
| {{Hauptartikel|TSIG}}
| |
| Bei TSIG (Transaction Signatures) handelt es sich um ein einfaches, auf [[Symmetrisches Kryptosystem|symmetrischen Schlüsseln]] beruhendes Verfahren, mit dem der Datenverkehr zwischen DNS-Servern und Updates von [[Client]]s gesichert werden kann.
| |
|
| |
| ==== DNSSEC ====
| |
| {{Hauptartikel|Domain Name System Security Extensions}}
| |
| Bei DNSSEC (Domain Name System Security Extensions) wird von einem [[Asymmetrisches Kryptosystem|asymmetrischen Kryptosystem]] Gebrauch gemacht.
| |
| * Neben der Server-Server-Kommunikation kann auch die Client-Server-Kommunikation gesichert werden.
| |
| * Dies soll die Manipulation der Antworten erschweren.
| |
|
| |
| ==== DNS over TLS (DoT) ====
| |
| {{Hauptartikel|DNS over TLS}}
| |
|
| |
| Bei ''DNS over TLS'' sollen sowohl DDoS-Angriffe, die Manipulation der Antworten als auch das Ausspähen der gesendeten Daten verhindert werden.
| |
| * Dazu werden die DNS-Abfragen per [[Transport Layer Security]] (TLS) abgesichert.<ref name=":0">{{Internetquelle |autor=Carsten Strotmann, Jürgen Schmidt |url=https://www.heise.de/ct/ausgabe/2018-14-DNS-mit-Privacy-und-Security-vor-dem-Durchbruch-4079547.html |titel=DNS mit Privacy und Security vor dem Durchbruch |abruf=2018-07-25}}</ref>
| |
|
| |
| ==== DNS over HTTPS (DoH) ====
| |
| {{Hauptartikel|DNS over HTTPS}}
| |
|
| |
| DNS over HTTPS ändert das DNS-System grundlegend.
| |
| * Anfragen finden hier auf Anwendungsebene statt.
| |
| * Anwendungen wie beispielsweise der Webbrowser fragen direkt beim DNS-Server an, anstatt die Anfrage an das Betriebssystem weiterzuleiten.
| |
| * Dadurch sehen DNS-Anfragen aus wie normaler Internetverkehr und können somit nicht gezielt abgefangen bzw.
| |
| * blockiert werden.<ref name=":0" />
| |
|
| |
| [[Cloudflare]] und [[Google LLC|Google]] bieten öffentliche DoH-Webserver an. [[Mozilla Firefox]] unterstützt DoH seit Version 60 als experimentelle Funktion.
| |
| * Mozilla stellt in Zusammenarbeit mit Cloudflare einen DoH-Server bereit, der strenge Privatsphäre-Anforderungen erfüllen muss.<ref name=":0" /><ref>{{Internetquelle |autor=Patrick McManus |url=https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefox/ |titel=Improving DNS Privacy in Firefox |sprache=en |abruf=2018-07-26}}</ref>
| |
|
| |
| ==== DNS over QUIC (DoQ) ====
| |
| DNS over [[Quick UDP Internet Connections|QUIC]] soll die Vorteile von DoT und DoH kombinieren.
| |
| * DoQ soll gute Privatsphäre und Sicherheit bieten, eine geringe Latenz aufweisen und nicht blockierbar sein.<ref>{{Internetquelle |autor= |url=https://www.privacy-handbuch.de/handbuch_93.htm |titel=DoQ soll nicht manipulierbar sein, die gleiche Privatsphäre wie DoT bieten, eine geringe Latenz wie unverschlüsseltes DNS über UDP und nicht blockierbar sein wie DoH. |werk= |hrsg= |datum= |abruf=28.01.2021 |sprache=de}}</ref> RFC 9250 der [[Internet Engineering Task Force]] beschreibt DoQ.<ref>{{Internetquelle |autor=heise online |url=https://www.heise.de/news/Verbesserte-Namensaufloesung-IETF-veroeffentlicht-RFC-zum-Internetprotokoll-QUIC-7097921.html |titel=Verbesserte Namensauflösung: IETF veröffentlicht RFC zum Internetprotokoll QUIC |sprache=de |abruf=2022-07-20}}</ref>
| |
|
| |
| == Domain-Registrierung ==
| |
| {{Hauptartikel|1=Domain-Registrierung}}
| |
| Um DNS-Namen im Internet bekannt machen zu können, muss der Besitzer die Domain, die diesen Namen enthält, registrieren.
| |
| * Durch eine Registrierung wird sichergestellt, dass bestimmte formale Regeln eingehalten werden und dass Domain-Namen weltweit eindeutig sind.
| |
| * Domain-Registrierungen werden von Organisationen (Registries, z. B.
| |
| * Verisign oder Afilias) vorgenommen, die dazu von der [[Internet Assigned Numbers Authority|IANA]] bzw. [[Internet Corporation for Assigned Names and Numbers|ICANN]] autorisiert wurden.
| |
| * Registrierungen sind (von wenigen Ausnahmen abgesehen) gebührenpflichtig.
| |
| * Für Domains unter .de ist die [[DENIC]] zuständig.
| |
| * In den allermeisten Fällen können Domains bei den Registries nur über Zwischenhändler, sogenannte Registrare wie Godaddy oder 1&1 Internet SE registriert werden, die mit den Registries entsprechende Verträge abgeschlossen haben.
| |
|
| |
| == Bonjour bzw.
| |
| * Zeroconf ==
| |
| [[Apple]] hat bei der Entwicklung von [[macOS]] mehrere Erweiterungen am DNS vorgenommen, welche die umfassende Selbstkonfiguration von Diensten in LANs ermöglichen soll.
| |
| * Zum einen wurde [[Multicast DNS]] („mDNS“) eingeführt, das die Namensauflösungen in einem [[Local Area Network|LAN]] ohne einen dedizierten Namensserver erlaubt.
| |
| * Zusätzlich wurde noch [[DNS-SD]] (für „DNS Service Discovery“) eingeführt, die die Suche („Browsing“) nach Netzwerkdiensten in das DNS beziehungsweise mDNS ermöglicht.
| |
| * mDNS und DNS-SD sind bisher keine offiziellen [[Request for Comments|RFCs]] des [[Internet Engineering Task Force|IETF]], sind aber trotzdem bereits in verschiedenen (auch freien) Implementierungen verfügbar.
| |
| * Zusammen mit einer Reihe von anderen Techniken fasst Apple DNS-SD und mDNS unter dem Namen „[[Zeroconf]]“ zusammen, als Bestandteil von OS X auch als „Rendezvous“ bzw. „[[Bonjour (Apple)|Bonjour]]“.
| |
| * Die meisten Linux-Distributionen unterstützen diese Erweiterung z. B.
| |
| * mit der [[Avahi (Software)|avahi]]-Implementierung von Zeroconf.
| |
|
| |
| == Zensur und alternative DNS ==
| |
| Seit den Debatten um [[Sperrungen von Internetinhalten in Deutschland]] und [[Zensur im Internet]] im Allgemeinen gibt es eine Reihe von alternativen DNS-Anbietern, die Domains nach eigener Aussage nicht zensieren.
| |
| * Beispiele sind Projekte von Organisationen wie [[Digitalcourage]], Freifunk München<ref>[https://ffmuc.net/wiki/doku.php?id=knb:dohdot DNS-over-HTTPS und DNS-over-TLS Unterstützung], auf ffmuc.net</ref> oder [[Digitale Gesellschaft (Schweiz)|Digitale Gesellschaft]].
| |
| * Auch von Privatpersonen werden alternative DNS-Server bereitgestellt.<ref name=":1">{{Internetquelle |url=https://www.privacy-handbuch.de/handbuch_93d.htm |titel=Vertrauenswürdige DNS-Server |abruf=2021-02-19}}</ref><ref>{{Internetquelle |url=https://www.privacytools.io/providers/dns/ |titel=Encrypted DNS Resolvers |abruf=2021-05-03 |sprache=en}}</ref> Der alternative DNS-Server des [[Chaos Computer Club]] wird, aufgrund von fehlenden Sicherheitsaspekten, kritisiert.<ref name=":1" />
| |
|
| |
| === Namecoin ===
| |
| {{Hauptartikel|.bit}}
| |
| Namecoin ist der erste [[Abspaltung (Softwareentwicklung)|Fork]] von [[Bitcoin]] aus dem Jahr 2011 und findet Anwendung als [[Kryptowährung]] sowie als [[Schlüssel-Werte-Datenbank|Key-Value Store]] für Domainnamen und Identitäten.
| |
| * Als alternatives verteiltes Domain Name System (DNS) außerhalb des [[Internet Corporation for Assigned Names and Numbers|ICANN]]-Namensraumes werden Transaktionen zum Registrieren, Aktualisieren und Übertragen von Domains auf der [[Blockchain]] aufgezeichnet.
| |
| * Zur Auflösung der .bit Adressen werden ein Browserplugin oder ein lokaler Namecoin DNS-Server benötigt.
| |
| * Ebenso wie Bitcoin ist Namecoin ein dezentrales [[Peer-to-Peer]]-System, das keiner Zensur unterliegt.<ref>{{Internetquelle |url=https://news.bitcoin.com/obtain-use-bit-privacy-domains/ |titel=How to Obtain and Use .Bit Privacy Domains | autor=Kevin Helms |werk=Bitcoin News |datum=2017-03-07 |abruf=2020-03-19 |sprache=en}}</ref> Die Software ist [[Open Source]] und wird auf [[GitHub]] gehostet.<ref>{{Internetquelle |url=https://www.namecoin.org/ |titel=Namecoin |abruf=2020-03-06 |kommentar=Projektwebsite |sprache=en}}</ref>
| |
|
| |
| Einem Bericht von Trend Micro zufolge wurden .bit Domains seit 2013 vermehrt auch von [[Internetkriminalität|Cyberkriminellen]] genutzt.<ref>{{Internetquelle |url=https://abuse.ch/blog/dot-bit-the-next-generation-of-bulletproof-hosting/ |titel=.bit - The next Generation of Bulletproof Hosting |werk=abuse.ch |datum=2017-09-25 |abruf=2020-03-19 |sprache=en}}</ref> Vornehmlich aus diesem Grund hat das [[OpenNIC]]-Projekt im Sommer 2019 seine DNS-Auflösung von .bit Domains eingestellt.<ref>{{Internetquelle | autor=Catalin Cimpanu |url=https://www.zdnet.com/article/opennic-drops-support-for-bit-domain-names-after-rampant-malware-abuse/ |titel=OpenNIC drops support for .bit domain names after rampant malware abuse | datum=2019-07-17 |werk=ZDNet |abruf=2020-03-19 |sprache=en}}</ref>
| |
|
| |
| == Nameserversoftware ==
| |
| Auswahl bekannter Software für Namensauflösung.
| |
|
| |
| * [[BIND]] (Berkeley Internet Name Domain) ist die meistgebrauchte Nameserversoftware und gilt als Referenzimplementierung der meisten [[Request for Comments|RFCs]] zu DNS.
| |
| * Die erste Version von BIND war die erste öffentlich verfügbare Nameserver-Implementierung.
| |
| * [[CoreDNS]] ist ein in [[Go (Programmiersprache)|Go]] geschriebener DNS-Server der [[Cloud Native Computing Foundation]].
| |
| * Bei [[djbdns]] hat der Autor [[Daniel J.
| |
| * Bernstein]] eine Prämie für das Finden von Sicherheitsproblemen ausgeschrieben.
| |
| * Djbdns wird von Bernstein nicht mehr weiterentwickelt, weil er es als fertig ansieht.
| |
| * [[Dnsmasq]] ist ein Nameserver und DHCP-Server mit eingeschränkter Funktionalität.
| |
| * Es werden die Namen aus dem lokalen Netz entsprechend /etc/hosts aufgelöst.
| |
| * Dnsmasq verfügt über keinen vollständigen Resolver: unbekannte Namensanfragen werden weitergeleitet und im Cache gespeichert.
| |
| * [[Knot DNS]] ist ein autoritativer Nameserver, der von [[CZ.NIC]] entwickelt wird, dem Betreiber von [[.cz]].
| |
| * Microsoft Windows DNS ist eine der wenigen kommerziellen Nameserver-Implementierungen als Teil der Produktreihe [[Microsoft Windows Server]].
| |
| * Der Nameserver unterstützt dynamische Updates, Zonentransfers und Notification.
| |
| * Zonendaten können in den aktuellen Versionen im [[Active Directory Service|Active Directory]] oder in Zonendateien gespeichert und repliziert werden.
| |
| * [[Name Server Daemon]] ist ein autoritativer Nameserver, der zum Einsatz als Top-Level-Domain- und [[Root-Nameserver]] entwickelt wurde.
| |
| * NSD kompiliert Antworten statisch vor, um die Server-Performance zu optimieren.
| |
| * Dynamische Zoneninhalte oder [[Lastverteilung per DNS|Round Robin]] werden nicht unterstützt.
| |
| * [[PowerDNS]] ist ein Nameserver, der Zonen aus [[SQL]]-Datenbanken, [[Lightweight Directory Access Protocol|LDAP]]-Verzeichnissen und anderen Backends lesen kann.
| |
| * PowerDNS begann als kommerzielle Implementierung und ist seit 2002 unter der [[GNU General Public License|GPL]] lizenziert.
| |
| * [[Unbound]] ist ein DNS-Resolver, der DNSSEC-Validierung und Caching unterstützt.
| |
| * Unbound kann als Softwarebibliothek in Anwendungen eingebunden werden.
| |
