Domainnamensystem
Funktion | Translation Domain - Namen in IP - Adresse |
---|---|
Akronym | DNS |
Hafen | 53 |
RFC |
1983 : RFC 882 - RFC 883 1987 : RFC 1034 - RFC 1035 1994 : RFC 1591 2011 : RFC 6195 2013 : RFC 6895 2018 : RFC 8375 - RFC 8467 - RFC 8483 - RFC 8484 2019 : RFC 8499 |
Das Domain Name System , allgemein abgekürzt DNS , das als "Domain Name System" übersetzt werden kann, ist der verteilte Computerdienst , der verwendet wird, um Internet-Domain-Namen in IP-Adressen oder andere Datensätze zu übersetzen . Durch die Bereitstellung eines verteilten Namensauflösungsdienstes seit den frühen Jahren des Internets um 1985 war DNS ein wesentlicher Bestandteil bei der Entwicklung des Netzwerks.
Auf Antrag der US Defense Advanced Research Projects Agency ( DARPA ), Jon Postel und Paul Mockapetris entworfen , um die Domain Name System in 1983 und schrieb die erste Implementierung.
Geräte ( Hosts ), die mit einem IP-Netzwerk wie dem Internet verbunden sind , haben eine IP-Adresse , die sie im Netzwerk identifiziert. Diese Adressen sind numerisch, um ihre Verarbeitung durch die Maschinen zu erleichtern. In IPv4 werden sie als „---. - - -. - - -. - - - ”, wobei jede „Gruppe“ aus drei Bindestrichen durch eine Zahl zwischen 0 und 255 (in dezimaler Darstellung ) ersetzt werden kann. Bei IPv6 werden Adressen in der Form "....: ....: ....: ....: ....: ....: ....: .... " dargestellt. , wobei jede „Gruppe“ von vier Punkten durch einen hexadezimalen Wert von 0000 bis FFFF ersetzt werden kann.
Um den Zugriff auf Hosts in einem IP-Netzwerk zu erleichtern, wurde ein Mechanismus eingerichtet, um einen Namen mit einer IP-Adresse zu verknüpfen. Dieser leichter zu merkende Name wird als „ Domänenname “ bezeichnet. Um einen Domainnamen aufzulösen, muss die damit verbundene IP-Adresse gefunden werden.
Zusätzlich zu IP - Adressen, können zusätzliche Informationen mit Domainnamen wie Aufzeichnungen im Zusammenhang mit der anti- verbunden seinem Spam ( SPF ), RRSIG für DNS Informationssicherheit ( DNSSEC ) oder NAPTR zum Zuordnen von Zahlen. Telefon E-Mail - Adressen ( ENUM ).
Vor DNS musste die Auflösung eines Internetnamens über eine Textdatei namens HOSTS.TXT ( RFC 608) erfolgen, die von der NIC des Stanford Research Institute (SRI) verwaltet und bei der Netzwerkdateiübertragung auf jeden Computer kopiert wurde. 1982 stieß dieses zentralisierte System an seine Grenzen und es tauchten mehrere Ersatzvorschläge auf, darunter das verteilte System Grapevine von Xerox und IEN 116. Das erste ( Grapevine ) wurde als zu kompliziert erachtet, während das zweite (IEN 116) unzureichend war. Letztendlich wird das von Elizabeth Feinler bei NIC geleitete Team das Domain Name System definieren, um das Wachstum des Internets zu bewältigen, indem es die Verwaltung von Domainnamen an verteilte Nameserver delegiert. Paul Mockapetris veröffentlichte 1983 das Design des Systems in RFC 882 und RFC 883. Der entsprechende Standard wurde 1987 in RFC 1034 und RFC 1035 veröffentlicht. 1987 enthielt die Datei HOSTS.TXT 5.500 Einträge, während 20.000 Hosts in DNS definiert waren .
Das Domain Name System besteht aus einer Hierarchie, deren Spitze Root genannt wird . Letztere vertreten wir durch einen Punkt. In einer Domäne können eine oder mehrere Subdomänen angelegt werden sowie eine Delegation für diese, also ein Hinweis, dass die Informationen zu dieser Subdomäne auf einem anderen Server erfasst werden. Diese Subdomains können wiederum Subdomains an andere Server delegieren.
Nicht alle Subdomains werden unbedingt delegiert. Delegierungen erstellen Zonen , dh Gruppen von Domänen und ihren nicht delegierten Unterdomänen, die auf einem bestimmten Server konfiguriert sind. Zonen werden oft mit Domänen verwechselt.
Die unmittelbar unterhalb der Wurzel liegenden Bereiche werden als Top-Level-Domain (TLD: Top Level Domain) bezeichnet. Domainnamen, die keiner Ländererweiterung entsprechen, werden als generische Domains (gTLDs) bezeichnet, beispielsweise .org oder .com. Wenn sie Ländercodes (fr, be, ch…) entsprechen, handelt es sich um nationale Top-Level-Domains , auch ccTLD vom englischen Ländercode TLD genannt .
Ein Domänenname wird durch die Angabe aufeinanderfolgender Domänen dargestellt, die durch einen Punkt getrennt sind, wobei die höheren Domänennamen auf der rechten Seite stehen. Zum Beispiel die Domain org. ist eine TLD, Subdomain des Roots. Die Domäne wikipedia.org . ist eine Subdomain von .org . Diese Delegierung wird erreicht, indem die Liste der DNS-Server angegeben wird, die der Unterdomäne in der Top-Level-Domäne zugeordnet sind.
Die Domänennamen werden daher aufgelöst, indem die Hierarchie von oben durchsucht wird und den aufeinanderfolgenden Delegationen gefolgt wird, dh indem der Domänenname von rechts nach links durchsucht wird.
Damit es normal funktioniert, muss ein Domänenname ordnungsgemäß in der Top-Level-Domäne delegiert worden sein.
Hosts haben nur begrenzte Kenntnisse über das Domain Name System. Wenn sie einen Namen auflösen müssen, adressieren sie sich an einen oder mehrere sogenannte rekursive Nameserver , dh sie durchsuchen die DNS-Hierarchie und leiten die Anfrage an einen oder mehrere andere Nameserver zur Beantwortung weiter. Die IP - Adressen dieser rekursive Server werden häufig über erhalten DHCP oder Hart- konfiguriert auf dem Hostcomputer. Die Internet Service Provider stellen ihren Kunden diese rekursiven Server zur Verfügung. Es gibt auch öffentliche rekursive Server wie die von Cloudflare , Yandex.DNS , Google Public DNS oder OpenNIC .
Wenn ein rekursiver DNS-Server die IP-Adresse von fr.wikipedia.org finden muss , beginnt ein iterativer Prozess, die DNS-Hierarchie nachzuschlagen . Dieser Server fragt die DNS-Server, die Root- Server genannt werden, welche Server ihm für die Org- Zone antworten können . Unter diesen wählt der Server einen aus, um zu wissen, welche Server für die Zone wikipedia.org darauf antworten können . Einer von ihnen kann ihm die IP-Adresse von fr.wikipedia.org geben . Wenn festgestellt wird, dass ein Server nicht reagiert, wird ein anderer Server in der Liste konsultiert.
Um spätere Abfragen zu optimieren, fungieren rekursive DNS-Server auch als DNS-Cache : Sie halten die Antwort auf eine Namensauflösung im Speicher ( Cache ), damit dieser Vorgang später nicht noch einmal ausgeführt wird. Diese Informationen werden für einen Zeitraum namens Time to live aufbewahrt und mit jedem Domainnamen verknüpft.
Ein Domänenname kann mehrere DNS-Server verwenden. Normalerweise verwenden Domänennamen mindestens zwei: einen primären und einen sekundären. Es kann mehrere sekundäre Server geben.
Alle primären und sekundären Server sind für eine Domäne autorisierend, dh die Antwort ruft keinen anderen Server oder einen Cache auf. Rekursive Server liefern Antworten, die aufgrund des vorhandenen Caches nicht unbedingt aktuell sind. Dies wird als nicht autoritative Antwort bezeichnet .
Diese Architektur garantiert dem Internet-Netzwerk eine gewisse Kontinuität in der Namensauflösung. Wenn ein DNS-Server ausfällt, wird die ordnungsgemäße Funktion der Namensauflösung nicht beeinträchtigt, solange sekundäre Server verfügbar sind.
Um den einer IP-Adresse zugeordneten Domainnamen zu finden, wird ein ähnliches Prinzip verwendet. Bei einem Domainnamen befindet sich der allgemeinste Teil rechts: org in fr.wikipedia.org, der Auflösungsmechanismus scannt daher den Domainnamen von rechts nach links. Bei einer V4-IP-Adresse ist es umgekehrt: 213 ist der allgemeinste Teil von 213.228.0.42. Um eine kohärente Logik beizubehalten, kehren wir die Reihenfolge der vier Terme der Adresse um und verketten sie mit der Pseudodomäne in-addr.arpa . Um beispielsweise den Domainnamen der IP-Adresse 91.198.174.2 zu finden, lösen wir 2.174.198.91.in-addr.arpa auf.
Die umgekehrte Anweisung ist bei öffentlichen IP-Adressen im Internet wichtig, da das Fehlen einer umgekehrten Auflösung als Betriebsfehler ( RFC 1912) angesehen wird, der zur Verweigerung des Zugriffs auf einen Dienst führen kann. Beispielsweise wird ein E-Mail-Server, der sich als sendend mit einer IP-Adresse ohne Reverse-Resolution (PTR) präsentiert, vom entfernten Host mit hoher Wahrscheinlichkeit die Übertragung der E-Mail verweigert (Ablehnungsnachricht vom Typ: IP-Suche fehlgeschlagen). ).
Darüber hinaus ist diese Rückwärtsauflösung im Rahmen der Durchführung von Netzwerkdiagnosen wichtig, da sie es ermöglicht, die Ergebnisse des Traceroute- Befehls menschlich verwertbar zu machen. Die Namen von Reverse-Hostnamen setzen sich oft aus Lokalisierungs-Subdomains (Stadt, Region, Land) und expliziten Domains zusammen, die den gekreuzten Internet-Zugangsanbieter angeben, wie z .net (- - - -.Aubervilliers.opentransit.net) für France Telecom oder proxad.net (- - - -.intf.routers.proxad.net) kostenlos .
Eine IP-Adresse kann verschiedenen Domänennamen zugeordnet werden, indem mehrere PTR-Einträge in der .arpa- Subdomäne registriert werden , die dieser Adresse zugeordnet ist (in-addr.arpa. Für IPv4 und ip6.arpa. Für IPv6 ). Die Verwendung mehrerer PTR - Einträge für die gleiche IP - Adresse ist möglicherweise in Zusammenhang mit dem virtuellen Hosting von mehrer Web - Domains hinter der gleichen IP - Adresse , aber wird nicht empfohlen , da die Anzahl der PTR Felder zurückgegeben werden kann die Reaktion bewirken , dass die zu übertreffen Größe von UDP- Antwortpaketen und verursachen die Verwendung von TCP (kostspieliger in den Ressourcen), um die Antwort auf die DNS-Anfrage zu senden.
CIDR inverse AuflösungDie Delegationen von Reverse-Zonen befinden sich auf einer Byte-Grenze, was funktioniert, wenn Adressblöcke klassenmäßig verteilt sind, aber Probleme verursacht, wenn zugewiesene Blöcke beliebiger Größe sind.
Wenn beispielsweise zwei Clients A und B jeweils die Blöcke 192.168.0.0/25 und 192.168.0.128/25 haben, ist es nicht möglich, 0.168.192.in-addr.arpa zu delegieren. zum ersten, damit er die PTRs entsprechend seinen Hosts definieren kann, da dies den zweiten daran hindern würde, dasselbe zu tun.
Der RFC 2317 definiert einen Ansatz, um dieses Problem anzugehen, es ist die Verwendung von Zwischenbereichen und CNAME.
$ORIGIN 0.168.192.in-addr.arpa. 0/25 NS ns.clientA.fr. 128/25 NS ns.clientB.fr. 0 CNAME 0.0/25.0.168.192.in-addr.arpa. 1 CNAME 1.0/25.0.168.192.in-addr.arpa. ... 127 CNAME 127.0/25.0.168.192.in-addr.arpa. 128 CNAME 128.128/25.0.168.192.in-addr.arpa. ... 255 CNAME 255.128/25.0.168.192.in-addr.arpa.Client A definiert Zone 0 / 25.0.168.192.in-addr.arpa. :
$ORIGIN 0/25.0.168.192.in-addr.arpa. 1 PTR hote1.clientA.fr. ... 127 PTR hote127.clientA.fr.Client B macht dasselbe für 128 / 25.0.168.192.in-addr.arpa. und Adressen 128 bis 255.
Die Umkehrung von 192.168.0.1 führt zu folgenden Abfragen:
1.0.168.192.in-addr.arpa. CNAME 1.0/25.0.168.192.in-addr.arpa. 1.0/25.0.168.192.in-addr.arpa. PTR hote1.clientA.fr.Dies gewährleistet den Betrieb der umgekehrten Auflösung mit einer zusätzlichen Indirektionsebene.
Die Root-Server werden von zwölf verschiedenen Organisationen verwaltet: zwei sind europäische, eine japanische und die anderen neun sind amerikanisch. Sieben dieser Server sind im Anycast- Verfahren weltweit verteilt und neun haben eine IPv6- Adresse . Dank Anycast bieten mehr als 200 Server in 50 Ländern weltweit diesen Service an. Es gibt 13 Namensautoritäten, die von a bis m.root-servers.net aufgerufen werden. Der Server k empfängt beispielsweise in der Größenordnung von 70.000 bis 100.000 Anfragen pro Sekunde inApril 2019.
Das DNS bietet keinen Mechanismus, um die Liste der Root-Server zu erkennen , sodass jeder Server diese Liste dank einer expliziten Codierung beim Start kennen muss. Diese Liste wird dann aktualisiert, indem man einen der angegebenen Server konsultiert. Diese Liste wird selten aktualisiert, damit ältere Server weiterhin funktionieren.
Der Begriff Fully Qualified Domain Name (FQDN) oder vollqualifizierter Domainname ein in absoluten Zahlen geschriebener Domainname, einschließlich aller Bereiche bis zur Top-Level-Domain (TLD), wird durch einen Punkt unterbrochen, zum Beispiel fr.wikipedia.org.
Der Standard sieht vor, dass ein Element eines Domainnamens (als Label bezeichnet ) 63 Zeichen nicht überschreiten darf, ein FQDN darf 253 Zeichen nicht überschreiten.
Domain-Namen bestehen in ihrer ursprünglichen Definition aus Zeichen von A bis Z (ohne Groß-/Kleinschreibung: die Großbuchstaben werden nicht unterschieden), Zahlen und dem Bindestrich.
Der RFC 3490 definiert ein Format namens Punycode , das die Codierung eines größeren Zeichensatzes ermöglicht.
Wenn ein Dienst erheblichen Datenverkehr erzeugt, kann er auf die Round-Robin- DNS- Technik (auf Französisch Tourniquet-DNS) zurückgreifen, eine der Lastausgleichstechniken , die darin besteht, mehrere IP-Adressen einem FQDN zuzuordnen . Den verschiedenen Wikipedia-Versionen, wie beispielsweise fr.wikipedia.org , sind mehrere IP-Adressen zugeordnet: 207.142.131.235, 207.142.131.236, 207.142.131.245, 207.142.131.246, 207.142.131.247 und 207.142.131.248. Die Reihenfolge, in der diese Adressen zurückgegeben werden, ändert sich von einer Anfrage zur nächsten. Eine kreisförmige Rotation zwischen diesen verschiedenen Adressen ermöglicht es somit, die durch diesen erheblichen Verkehr erzeugte Last auf die verschiedenen Maschinen mit diesen IP-Adressen zu verteilen. Diese Verteilung muss jedoch qualifiziert werden, da sie nur bei der Auflösung des Hostnamens stattfindet und anschließend im Cache auf den verschiedenen Resolvern (DNS-Client) verbleibt .
Die Art des Resource Records (RR für Resource Record) ist auf 16 Bit kodiert, die IANA führt das Register der zugewiesenen Codes. Die wichtigsten definierten Datensätze sind:
Der NS-Eintrag erstellt eine Delegation von einer Subdomain an eine Liste von Servern.
In der org zone erstellen die folgenden NS-Records die Wikipedia- Subdomain und delegieren sie an die angegebenen Server.
Die Reihenfolge der Server ist beliebig. Alle aufgeführten Server müssen für die Domäne autorisierend sein.
wikipedia NS ns1.wikimedia.org. wikipedia NS ns2.wikimedia.org. wikipedia NS ns0.wikimedia.org.Im Gegensatz zu einem A- oder AAAA-Eintrag gibt ein PTR-Eintrag an, welchem Hostnamen eine IPv4- oder IPv6- Adresse entspricht . Falls angegeben, muss es den Reverse-Record eines DNS-A- oder AAAA-Eintrags enthalten.
Zum Beispiel (für eine IPv4- Adresse ) lautet dieser PTR-Eintrag:
232.174.198.91.in-addr.arpa. IN PTR text.esams.wikimedia.org.entspricht diesem Eintrag A:
text.esams.wikimedia.org. IN A 91.198.174.232Im Fall einer IPv6- Adresse werden Einträge vom Typ PTR in der Zone ip6.arpa gespeichert. (Anhänger aus der Zone in-addr.arpa von IPv4- Adressen ).
Die Regel zum Auffinden des Eintrags, der einer IPv6- Adresse entspricht, ist ähnlich wie bei IPv4- Adressen ( Adressumkehr und Suche in einer dedizierten Subdomain der arpa-Zone.), unterscheidet sich jedoch in der Anzahl der Bits der Adresse, die zum Schreiben des Namens verwendet wird der Domain, wo nach dem PTR-Feld gesucht wird: wobei bei IPv4 die Adressaufteilung nach Byte erfolgt, bei IPv6 wird eine Aufteilung nach Nibble verwendet.
Zum Beispiel an der IPv6-Adresse:
2001:610:240:22:::c100:68bstimmt mit dem Domainnamen überein:
b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. PTR www.ipv6.ripe.net.Ein DNS-MX-Eintrag gibt die SMTP- Server an, die kontaktiert werden müssen, um eine E-Mail an einen Benutzer in einer bestimmten Domäne zu senden. Beispielsweise :
wikimedia.org. IN MX 10 mchenry.wikimedia.org. wikimedia.org. IN MX 50 lists.wikimedia.org.Wir sehen, dass E-Mails, die an eine @ wikimedia.org-Adresse gesendet werden, an den Server mchenry.wikimedia.org gesendet werden. oder listen.wikimedia.org. Die Zahl vor dem Server steht für die Priorität. Der Server mit der niedrigsten numerischen Priorität wird zuerst verwendet. Hier ist es also mchenry.wikimedia.org. die zuerst verwendet werden sollte, mit einem Wert von 10.
Die angegebenen Server müssen so konfiguriert sein, dass sie die Weiterleitung von E-Mails für den angegebenen Domänennamen akzeptieren. Ein häufiger Fehler besteht darin, Server als sekundäre Server anzugeben, was dazu führt, dass E-Mails zurückgewiesen werden, wenn der primäre Server nicht mehr erreichbar ist. Es ist nicht unbedingt erforderlich, sekundäre Server zu haben, da die sendenden Server die Nachrichten für eine bestimmte Zeit (typischerweise mehrere Tage) aufbewahren, bis der primäre Server wieder verfügbar ist.
MX-Einträge werden durch SRV-Einträge verallgemeinert, die dasselbe ermöglichen, jedoch für alle Dienste, nicht nur für SMTP (E-Mail). Der Vorteil von SRV-Einträgen gegenüber MX-Einträgen besteht auch darin, dass sie die Wahl eines beliebigen Ports für jeden Dienst sowie einen effizienteren Lastausgleich ermöglichen . Der Nachteil ist, dass es noch wenige Client-Programme gibt, die SRV-Einträge verarbeiten. Mit der zunehmenden Nutzung von SIP- over- VoIP- Diensten werden jedoch seit 2009 SRV-Einträge in DNS-Zonen immer häufiger.
Der CNAME-Eintrag wird verwendet, um einen Alias zu erstellen .
Beispielsweise :
fr.wikipedia.org. IN CNAME text.wikimedia.org. text.wikimedia.org. IN CNAME text.esams.wikimedia.org. text.esams.wikimedia.org. IN A 91.198.174.232Dies schließt jede andere Registrierung aus ( RFC 1034 Abschnitt 3.6.2, RFC 1912 Abschnitt 2.4), d. h. Sie können nicht sowohl einen CNAME- als auch einen A-Record für denselben Domainnamen haben.
Dies ist beispielsweise verboten:
fr.wikipedia.org. IN CNAME text.wikimedia.org. fr.wikipedia.org. IN A 91.198.174.232Außerdem aus Performancegründen und zur Vermeidung von Endlosschleifen vom Typ
fr.wikipedia.org. IN CNAME text.wikimedia.org. text.wikipedia.org. IN CNAME fr.wikimedia.org.die Spezifikationen ( RFC 1034 Abschnitt 3.6.2, RFC 1912 Abschnitt 2.4) empfehlen, einen CNAME weder auf einen anderen CNAME noch auf einen DNAME (Alias für einen Namen und alle seine Unternamen) zu verweisen.
Daher würde das erste Beispiel vorzugsweise wie folgt gespeichert:
fr.wikipedia.org. IN CNAME text.esams.wikimedia.org. text.wikimedia.org. IN CNAME text.esams.wikimedia.org. text.esams.wikimedia.org. IN A 91.198.174.232Derzeit nicht weit verbreitet (sie werden hauptsächlich von ENUM verwendet ), beschreiben sie das Umschreiben eines Schlüssels (eines Domänennamens) in URI . In ENUM können NAPTR-Einträge beispielsweise verwendet werden, um die E-Mail-Adresse einer Person zu finden, die ihre Telefonnummer kennt (die als Schlüssel für ENUM dient).
Seine Parameter sind in der richtigen Reihenfolge:
Der NAPTR-Record wird durch RFC 3403 definiert .
In diesem Datensatz können Sie den (primären) Master-Nameserver, die E-Mail-Adresse eines technischen Kontakts (wobei @ durch einen Punkt ersetzt wird) und Ablaufparameter angeben.
Es bezeichnet die Autorität ( Start of Authority ) oder den Verantwortlichen für die Zone in der DNS-Hierarchie. Dies ist die Geburtsurkunde der DNS-Zone.
Diese Parameter sind in der Reihenfolge:
wikipedia.org. IN SOA ns0.wikimedia.org. hostmaster.wikimedia.org. 2010060311 43200 7200 1209600 3600Neuere Versionen von BIND ( named ) akzeptieren die Suffixe M, H, D oder W, um ein Zeitintervall in Minuten, Stunden, Tagen bzw. Wochen anzugeben.
Jedem Datensatz ist eine Time-to-Live (TTL) zugeordnet, die bestimmt, wie lange er in einem Cache- Server aufbewahrt werden kann . Diese Zeit beträgt normalerweise einen Tag (86400 s), kann jedoch für Informationen, die sich selten ändern, wie z. B. NS-Datensätze, länger sein. Es ist auch möglich, anzugeben, dass Informationen nicht zwischengespeichert werden sollen, indem eine TTL von Null angegeben wird.
Einige Anwendungen wie Webbrowser verfügen auch über einen DNS-Cache, der jedoch nicht unbedingt die DNS-TTL respektiert. Dieser Anwendungscache ist im Allgemeinen in der Größenordnung einer Minute, aber Internet Explorer speichert beispielsweise Informationen bis zu 30 Minuten lang, unabhängig von der konfigurierten TTL.
Wird eine Domain an einen Nameserver delegiert, der zu dieser Subdomain gehört, ist es notwendig, auch die IP-Adresse dieses Servers anzugeben, um Zirkelverweise zu vermeiden. Dies weicht vom allgemeinen Prinzip ab, nach dem die Informationen einer Domain nicht an anderer Stelle im DNS dupliziert werden.
Zum Beispiel in der folgenden Antwort zu NSs für die Domain wikimedia.org:
wikimedia.org. IN NS ns2.wikimedia.org. wikimedia.org. IN NS ns1.wikimedia.org. wikimedia.org. IN NS ns0.wikimedia.org.Die Angabe der IP-Adressen der in der Antwort angegebenen Server ( Glue Records ) ist ebenfalls erforderlich , da diese Teil der jeweiligen Domain sind:
ns0.wikimedia.org. IN A 208.80.152.130 ns1.wikimedia.org. IN A 208.80.152.142 ns2.wikimedia.org. IN A 91.198.174.4Eine DNS-Erweiterung namens Dynamic DNS (DDNS) ermöglicht es einem Client, eine Zone mit Informationen darüber zu aktualisieren ( RFC 2136). Dies ist nützlich, wenn Clients eine IP-Adresse von DHCP beziehen und möchten, dass das DNS den tatsächlichen Namen des Computers widerspiegelt.
Die Aktualisierungen werden auf dem Primärserver der Domäne vorgenommen, wobei die Sekundärserver Informationen vom Primärserver in einem Mechanismus namens Zonentransfer kopieren . Um zu bestimmen, ob eine Zonenübertragung stattfinden soll, überprüft der sekundäre Server die Versionsnummer der Zone und vergleicht sie mit der Version, die sie hat. Der Primärserver bestimmt, wie oft die Versionsnummer überprüft wird. Wenn eine Änderung vorgenommen wird, senden die Server Benachrichtigungen an die sekundären Server, um den Prozess zu beschleunigen.
Informationen, die nicht mehr aktuell sind, können jedoch in Cache-Servern gehalten werden. Es ist dann notwendig, den Ablauf ihrer Time to live abzuwarten , damit diese versteckten Informationen verschwinden und damit das Update vollständig wirksam ist. Die erforderliche Zeit kann minimiert werden, indem die TTL verringert wird, die den Domänennamen zugeordnet ist, die vor einer Änderungsoperation modifiziert werden.
Wenn sich die Liste der Nameserver ändert oder wenn eine IP-Adresse geändert wird, die einem ' Glue Record ' unterliegt, muss der Verwalter der Top-Level-Domain die entsprechende Aktualisierung durchführen.
Um einzelne Fehlerquellen zu vermeiden , vermeiden Sie die gemeinsame Nutzung der Infrastruktur zwischen autoritativen Servern. Ein sekundärer Server wird vorzugsweise delokalisiert und anders geroutet als der primäre Server.
Obwohl dies technisch möglich ist, vermeiden wir es, die Rolle des rekursiven DNS und des autoritativen Servers auf demselben Server zu vermischen.
Ebenso wird ein Host mit mehreren rekursiven Servern konfiguriert, sodass, wenn der erste nicht auf die Anfrage reagiert, der nächste verwendet wird. Im Allgemeinen lehnen rekursive Server, die von ISPs bereitgestellt werden, Anfragen von IP-Adressen anderer ISPs ab.
Es gibt offene rekursive DNS-Dienste, dh sie akzeptieren Anfragen von allen Clients. Es ist daher für einen Benutzer möglich, diese anstelle der vom ISP bereitgestellten zu konfigurieren. Dies wirft jedoch folgende Probleme auf:
Das DNS-Protokoll wurde mit minimalen Sicherheitsbedenken entwickelt. Seitdem wurden mehrere Sicherheitslücken im DNS-Protokoll identifiziert. Die Hauptfehler in DNS wurden in RFC 3833 beschrieben, veröffentlicht inAugust 2004.
Einer der vorgebrachten Mängel ist die Möglichkeit, übertragene Pakete abzufangen. DNS-Server kommunizieren über eindeutige, unsignierte Pakete. Diese beiden Besonderheiten machen das Abfangen sehr einfach. Das Abhören kann auf verschiedene Weise erfolgen, insbesondere durch einen Angriff vom Typ „Man in the Middle“, das Abhören der übertragenen Daten und das Senden einer gefälschten Antwort (siehe Abschnitt unten).
Da die Pakete der DNS-Server schwach gesichert und durch eine Anfragenummer authentifiziert sind, ist es möglich, falsche Pakete herzustellen. Beispiel: Ein Benutzer, der auf die Site http://mabanque.example.com zugreifen möchte, stellt eine Anfrage an die DNS-Site. Zu diesem Zeitpunkt muss ein Hacker nur noch auf die Anfrage des Benutzers antworten, bevor der DNS-Server und der Benutzer auf einer Phishing-Site landen .
Serververrat oder Datenbeschädigung ist technisch dasselbe wie das Abfangen von Paketen. Der einzige Unterschied besteht darin, dass der Benutzer seine Anfrage freiwillig an den Server sendet. Dies kann passieren, wenn beispielsweise der Betreiber des DNS-Servers einen Geschäftspartner hervorheben möchte.
DNS-Cache-Poisoning ist eine Technik, mit der DNS-Server glauben gemacht werden können, dass sie eine gültige Anfrage erhalten, während diese betrügerisch ist.
Ein Denial-of-Service-Angriff (oder Denial-of-Service-Angriff oder DoS-Angriff) ist ein Angriff auf einen Computerserver, der dazu führt, dass der Server nicht auf Anfragen seiner Clients reagieren kann.
Um diesen Schwachstellen (Datenkorruption, DNS-Cache-Poisoning usw.) entgegenzuwirken, wurde das DNSSEC- Protokoll ( RFC 4033, RFC 4034, RFC 4035) entwickelt. Es verwendet die Prinzipien der asymmetrischen Kryptographie und der digitalen Signatur , um die Datenintegrität sowie den Nachweis der Nichtexistenz sicherzustellen, wenn der angeforderte Datensatz nicht existiert. Die DNS-Rootzone wurde angemeldet15. Juli 2010, und die Bereitstellung von DNSSEC auf Top-Level-Domains (TLD: Top Level Domain) wird fortgesetzt, wobei eine Liste der abgedeckten Domains verfügbar ist.
Seit 2015 arbeitet die IETF an der Sicherheit des DNS-Kommunikationskanals (wo DNSSEC Daten schützt). Dies führte zur Veröffentlichung mehrerer RFCs, die die Verwendung von TLS zum Verschlüsseln der Kommunikation zwischen DNS-Clients und Resolvern ermöglichen. Dies sind hauptsächlich: DNS über TLS ( RFC 7858, unter Verwendung von Port 853) und DNS über HTTPS ( RFC 8484, DNS-Anfrage gekapselt in einer HTTP- Anfrage und von einem Webserver verarbeitet).
Im Jahr 2018 gibt es keine Möglichkeiten, die Kommunikation zwischen einem Resolver und einem autoritativen Server über TLS zu verschlüsseln.
In Juli 2008, ein paar Tage nach der Veröffentlichung des Berichts des United States Computer Emergency Readiness Teams über die Sicherheitslücke der DNS-Server, die ihren Cache vergiftete, wurden mehrere große DNS-Server angegriffen. Einer der wichtigsten war der gegen AT&T- Server . Der Angriff, der den Cache der DNS-Server von AT & T vergiftete, ermöglichte es dem Hacker, alle Google-Anfragen an eine Phishing-Site umzuleiten .
DNS verwendet normalerweise UDP und Port 53. Die maximale verwendete Paketgröße beträgt 512 Byte. Wenn eine Antwort diese Größe überschreitet, sieht der Standard vor, dass die Anfrage an TCP-Port 53 zurückgesendet werden muss. Dieser Fall ist jedoch selten und wird vermieden, und Firewalls blockieren oft den TCP-Port 53.
Die Erweiterung EDNS 0 ( RFC 2671) ermöglicht die Verwendung einer größeren Paketgröße, ihre Unterstützung wird sowohl für IPv6 als auch für DNSSEC empfohlen.
Der Standard sieht vor, dass es eine Klasse gibt, die Abfragen zugeordnet ist. Die Klassen IN (Internet), CH (Chaos) und HS ( Hesiod ) sind definiert, in der Praxis wird nur die Klasse IN verwendet. Die Chaos- Klasse wird von BIND verwendet , um die Versionsnummer anzuzeigen.
Um die Zuordnung zwischen einem Namen und einer IP-Adresse zu überprüfen, stehen je nach verwendetem Betriebssystem mehrere Befehle zur Verfügung.
Unter Windows ist beispielsweise der Befehl nslookup über die Eingabeaufforderung verfügbar:
> nslookup www.google.fr Serveur : Livebox-6370 Address: 192.168.1.1 Réponse ne faisant pas autorité : Nom : www.l.google.com Addresses: 209.85.229.104 209.85.229.106 209.85.229.103 209.85.229.147 209.85.229.105 209.85.229.99 Aliases: www.google.fr www.google.comoder graben Sie auf Systemen, die mit UNIX kompatibel sind :
> dig www.google.com aaaa ; <<>> DiG 9.7.0-P1 <<>> www.google.com aaaa ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47055 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.google.com. IN AAAA ;; ANSWER SECTION: www.google.com. 422901 IN CNAME www.l.google.com. www.l.google.com. 77 IN AAAA 2a00:1450:8004::67 www.l.google.com. 77 IN AAAA 2a00:1450:8004::68 www.l.google.com. 77 IN AAAA 2a00:1450:8004::69 www.l.google.com. 77 IN AAAA 2a00:1450:8004::6a www.l.google.com. 77 IN AAAA 2a00:1450:8004::93 www.l.google.com. 77 IN AAAA 2a00:1450:8004::63 ;; AUTHORITY SECTION: google.com. 155633 IN NS ns2.google.com. google.com. 155633 IN NS ns1.google.com. google.com. 155633 IN NS ns3.google.com. google.com. 155633 IN NS ns4.google.com. ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Sun May 23 16:23:49 2010 ;; MSG SIZE rcvd: 292