Domain Name System (DNS) ist ein hierarchisches verteiltes Namengeben-System für Computer, Dienstleistungen oder jede Quelle, die mit dem Internet oder einem privaten Netz verbunden ist. Es vereinigt verschiedene Information mit jeder der teilnehmenden Entitäten zugeteilten Domainnamen.

Ein Domainname-Dienst übersetzt Abfragen für Domainnamen (die leichter sind, zu verstehen und zu verwerten, wenn sie auf das Internet zugreifen), in IP-Adressen zum Zweck, Computerdienstleistungen und Geräte weltweit ausfindig zu machen.

Eine oft benutzte Analogie, um das Domainname-System zu erklären, ist, dass es als das Telefonbuch für das Internet durch das Übersetzen menschlich-freundlichen Computers hostnames in IP-Adressen dient. Zum Beispiel übersetzt der Domainname www.example.com zu den Adressen 192.0.43.10 (IPv4) und 2620:0:2d0:200:: 10 (IPv6).

Das Domainname-System macht es möglich, Domainnamen Gruppen von Internetmitteln und Benutzern auf eine bedeutungsvolle Weise zuzuteilen, die der physischen Position jeder Entität unabhängig ist. Wegen dessen können Hypertext-Links des World Wide Web (WWW) und Internetkontakt-Information konsequent und unveränderlich bleiben, selbst wenn die aktuelle Internetroutenplanungsmaßnahmen-Änderung oder der Teilnehmer ein bewegliches Gerät verwenden. Internetdomainnamen sind leichter sich zu erinnern als IP-Adressen wie (IPv4) oder (IPv6). Benutzer nutzen das aus, wenn sie bedeutungsvolle Internetadressen (URL-ADRESSEN) rezitieren und Adressen per E-Mail schicken, ohne wissen zu müssen, wie der Computer sie wirklich ausfindig macht.

Das Domainname-System verteilt die Verantwortung, Domainnamen zuzuteilen und jene Namen zu IP-Adressen durch die Kennzeichnung herrischer Namenserver für jedes Gebiet kartografisch darzustellen.

Herrische Namenserver werden damit beauftragt, für ihre besonderen Gebiete verantwortlich zu sein, und können der Reihe nach andere herrische Namenserver für ihre Subgebiete zuteilen. Dieser Mechanismus hat den DNS verteilt und Schuld tolerant gemacht und hat geholfen, das Bedürfnis nach einem einzelnen Hauptregister zu vermeiden, das ständig zu befragen und zu aktualisieren ist.

Im Allgemeinen versorgt das Domainname-System auch andere Typen der Information wie die Liste von Mailservern, die E-Mail für ein gegebenes Internetgebiet akzeptieren. Durch die Versorgung eines weltweiten, verteilten Schlüsselwort-basierten Wiederrichtungsdienstes ist das Domainname-System ein wesentlicher Bestandteil der Funktionalität des Internets.

Andere Bezeichner wie RFID-Anhängsel, UPCs, internationale Charaktere in E-Mail-Adressen und Hostnamen und einer Vielfalt anderer Bezeichner konnten alle DNS potenziell verwenden.

Das Domainname-System gibt auch die technische Funktionalität dieses Datenbankdienstes an. Es definiert das DNS Protokoll, eine ausführliche Spezifizierung der Datenstrukturen und des Nachrichtenaustausches, der in DNS als ein Teil des Internetprotokoll-Gefolges verwendet ist.

Übersicht

Das Internet erhält zwei hauptsächliche namespaces, die Domainname-Hierarchie und die Adressräume von Internet Protocol (IP) aufrecht. Das Domainname-System erhält die Domainname-Hierarchie aufrecht und stellt Übersetzungsdienste dazwischen und den Adressräumen zur Verfügung. Internetnamenserver und ein Nachrichtenprotokoll führen das Domainname-System durch. Ein DNS-Namenserver ist ein Server, der die DNS-Aufzeichnungen für einen Domainnamen, wie Adresse (A) Aufzeichnungen, Aufzeichnungen des Namenservers (NS) und Postex-Wechsler (MX) Aufzeichnungen versorgt (sieh auch Liste von DNS-Rekordtypen); ein DNS-Namenserver erwidert mit Antworten auf Abfragen gegen seine Datenbank.

Geschichte

Die Praxis, einen Namen als eine einfachere, denkwürdigere Abstraktion einer numerischen Adresse eines Gastgebers in einem Netz zu verwenden, geht auf das ARPANET Zeitalter zurück. Bevor der DNS 1982 erfunden wurde, hat jeder Computer im Netz eine Datei genannt HOSTS.TXT von einem Computer an SRI (jetzt SRI International) wiederbekommen. HOSTS.TXT hat Datei Namen zu numerischen Adressen kartografisch dargestellt. Eine Gastgeber-Datei besteht noch auf den meisten modernen Betriebssystemen standardmäßig und enthält allgemein von "localhost" zur IP-Adresse 127.0.0.1 kartografisch darzustellen. Viele Betriebssysteme verwenden Namenentschlossenheitslogik, die dem Verwalter erlaubt, Auswahl-Prioritäten für verfügbare Namenentschlossenheitsmethoden zu konfigurieren.

Das schnelle Wachstum des Netzes hat zentral aufrechterhalten, mit der Hand gemacht HOSTS.TXT unnachhaltige Datei gemacht; es ist notwendig geworden, ein ersteigbareres System durchzuführen, das dazu fähig ist, automatisch die notwendige Information zu verbreiten.

Auf Bitte von Jon Postel hat Paul Mockapetris das Domainname-System 1983 erfunden und hat die erste Durchführung geschrieben. Die ursprünglichen Spezifizierungen wurden durch die Internettechnikeinsatzgruppe in RFC 882 und RFC 883 veröffentlicht, die im November 1987 durch RFC 1034 und RFC 1035 ersetzt wurden. Mehrere zusätzliche Bitte um Anmerkungen hat verschiedene Erweiterungen auf die DNS Kernprotokolle vorgeschlagen.

1984, vier Studenten von Berkeley — Douglas Terry, Zeichen-Maler, David Riggle und Songnian Zhou — haben die erste Durchführung von Unix, genannt Den Server von Berkeley Internet Name Domain (BIND) geschrieben. 1985 hat Kevin Dunlap von DEZ bedeutsam die DNS Durchführung umgeschrieben. Mike Karels, Phil Almquist und Paul Vixie haben aufrechterhalten BINDEN seitdem. BINDEN SIE wurde zur Plattform des Windows NT am Anfang der 1990er Jahre getragen.

BINDEN SIE wurde besonders auf Systemen von Unix weit verteilt, und ist die dominierende DNS Software im Gebrauch im Internet. Mit dem schweren Gebrauch und der resultierenden genauen Untersuchung seines Codes der offenen Quelle, sowie den zunehmend hoch entwickelteren Angriffsmethoden wurden viele Sicherheitsfehler darin entdeckt BINDEN. Das hat zur Entwicklung mehrer alternativer Namenserver und resolver Programme beigetragen. BINDEN SIE Version 9 wurde von Kratzer geschrieben und hat jetzt eine mit anderer moderner DNS Software vergleichbare Sicherheitsaufzeichnung.

Struktur

Domainname-Raum

Der Domainname-Raum besteht aus einem Baum von Domainnamen. Jeder Knoten oder Blatt im Baum haben Null oder mehr Quellenaufzeichnungen, die Information vereinigt mit dem Domainnamen halten. Der Baum teilt sich in Zonen auf, die an der Wurzelzone beginnen. Eine DNS Zone

kann aus nur einem Gebiet bestehen, oder kann aus vielen Gebieten und Subgebieten bestehen, je nachdem die Verwaltungsautorität dem Betriebsleiter delegiert hat.

Die Verwaltungsverantwortung über jede Zone kann durch das Schaffen von zusätzlichen Zonen geteilt werden. Wie man sagt, wird Autorität für einen Teil des alten Raums, gewöhnlich in der Form von Subgebieten, zu einem anderen nameserver und Verwaltungsentität delegiert. Die alte Zone hört auf, für die neue Zone herrisch zu sein.

Domainname-Syntax

Die endgültigen Beschreibungen der Regeln, um Domainnamen zu bilden, erscheinen in RFC 1035, RFC 1123 und RFC 2181.

Ein Domainname besteht aus einem oder mehr Teilen, technisch genannten Etiketten, die herkömmlich verkettet, und durch Punkte, solcher als abgegrenzt werden.

• Das niedrigstwertige Etikett befördert das Gebiet auf höchster Ebene; zum Beispiel gehört der Domainname dem Gebiet auf höchster Ebene.
• Die Hierarchie von Gebieten steigt vom Recht bis linken hinunter; jedes Etikett gibt nach links eine Unterteilung oder Subgebiet des Gebiets nach rechts an. Zum Beispiel: Das Etikett gibt ein Subgebiet des Gebiets an, und ist ein U-Boot-Gebiet dessen. Dieser Baum von Unterteilungen kann bis zu 127 Niveaus haben.
• Jedes Etikett kann bis zu 63 Charaktere enthalten. Der volle Domainname kann keine Gesamtlänge von 253 Charakteren in seiner Außenspezifizierung des punktierten Etiketts überschreiten. In der inneren binären Darstellung des DNS verlangt die maximale Länge 255 Oktette der Lagerung. In der Praxis können einige Bereichsregistrierungen kürzere Grenzen haben.
• DNS Namen können aus jedem in einem Oktett wiederpräsentablen Charakter technisch bestehen. Jedoch verwenden die erlaubte Formulierung von Domainnamen in der DNS-Wurzelzone und die meisten anderen U-Boot-Gebiete, ein bevorzugtes Format und Codierung. Die in einem Etikett erlaubten Charaktere sind eine Teilmenge der ASCII Codierung, und schließt die Charaktere durch z, durch Z, Ziffern 0 bis 9, und der Bindestrich ein. Diese Regel ist als die LDH-Regel (Briefe, Ziffern, Bindestrich) bekannt. Domainnamen werden auf die mit dem Fall unabhängige Weise interpretiert. Etiketten können nicht anfangen oder mit einem Bindestrich enden.
• Ein hostname ist ein Domainname, der mindestens eine vereinigte IP-Adresse hat. Zum Beispiel sind die Domainnamen und auch hostnames, wohingegen das Gebiet nicht ist.

Internationalisierte Domainnamen

Die erlaubte Codierung des DNS hat die Darstellung von Namen und Wörter von vielen Sprachen in ihren heimischen Alphabeten oder Schriften verhindert. ICANN hat die Internationalisieren-Domainnamen in Anwendungen (IDNA) System genehmigt, das Schnuren von Unicode ins gültige DNS Codierungsverwenden Punycode kartografisch darstellt. 2009 hat ICANN die Installation der IDN internationalen Vorwahl Gebiete auf höchster Ebene genehmigt. Außerdem haben viele Registrierungen der vorhandenen Spitzenniveau-Domainnamen (TLD) s IDNA angenommen.

Namenserver

Das Domainname-System wird durch ein verteiltes Datenbanksystem aufrechterhalten, das das Client/Server-Modell verwendet. Die Knoten dieser Datenbank sind die Namenserver. Jedes Gebiet hat mindestens einen herrischen DNS Server, der Information über dieses Gebiet und die Namenserver jedes Bereichsuntergebenen dazu veröffentlicht. Der Spitze der Hierarchie wird durch die Wurzel nameservers, die Server gedient, um zu fragen, wenn man (Auflösung) eines TLD aufblickt.

Herrischer Namenserver

Ein herrischer Namenserver ist ein Namenserver, der Antworten gibt, die von einer ursprünglichen Quelle, zum Beispiel, dem Bereichsverwalter oder durch dynamische DNS Methoden im Gegensatz zu Antworten konfiguriert worden sind, die über eine regelmäßige DNS-Abfrage zu einem anderen Namenserver erhalten wurden. Ein herrisch-einziger Namenserver gibt nur Antworten auf Abfragen nach Domainnamen zurück, die vom Verwalter spezifisch konfiguriert worden sind.

Ein herrischer Namenserver kann entweder ein Master-Server oder ein Sklavenserver sein. Ein Master-Server ist ein Server, der das Original (Master) Kopien aller Zonenaufzeichnungen versorgt. Ein Sklavenserver verwendet einen automatischen aktualisierenden Mechanismus des DNS Protokolls in der Kommunikation mit seinem Master, um eine identische Kopie der Master-Aufzeichnungen aufrechtzuerhalten.

Jede DNS Zone muss eine Reihe herrischer Namenserver zugeteilt werden, die in NS-Aufzeichnungen in der Elternteilzone installiert werden.

Wenn Domainnamen mit einem Domainname-Registrator eingeschrieben werden, verlangt ihre Installation bei der Bereichsregistrierung eines Spitzenniveau-Gebiets die Anweisung eines primären Namenservers und mindestens eines sekundären Namenservers. Die Voraussetzung von vielfachen Namenservern hat zum Ziel, das Gebiet noch funktionell zu machen, selbst wenn ein Namenserver unzugänglich oder inoperabel wird. Die Benennung eines primären Namenservers wird allein durch den dem Domainname-Registrator gegebenen Vorrang bestimmt. Für diesen Zweck ist allgemein nur der völlig qualifizierte Domainname des Namenservers erforderlich, wenn die Server im eingetragenen Gebiet nicht enthalten werden, in welchem Fall die entsprechende IP-Adresse ebenso erforderlich ist.

Primäre Namenserver sind häufig Master-Namenserver, während sekundärer Namenserver als Sklavenserver durchgeführt werden kann.

Ein herrischer Server zeigt seinen Status an, endgültige Antworten, gehalten herrisch zu liefern, durch das Setzen einer Softwarefahne (hat eine Protokoll-Struktur gebissen), genannt Authoritative Answer (AA) hat in seinen Antworten gebissen. Diese Fahne wird gewöhnlich prominent in der Produktion von DNS Regierungsanfragenwerkzeugen wieder hervorgebracht (solchen, die graben) anzuzeigen, dass der antwortende Namenserver eine Autorität für den fraglichen Domainnamen ist.

Operation

Adressentschlossenheitsmechanismus

Domainname resolvers bestimmt die passenden Domainname-Server, die für den fraglichen Domainnamen durch eine Folge von Abfragen verantwortlich sind, die mit dem niedrigstwertigen Bereichsetikett (auf höchster Ebene) anfangen.

Der Prozess hat zur Folge:

1. Ein Netzgastgeber wird mit einem anfänglichen geheimen Lager (so genannte Hinweise) von den bekannten Adressen der Wurzel nameservers konfiguriert. Solch eine Hinweis-Datei wird regelmäßig von einem Verwalter von einer zuverlässigen Quelle aktualisiert.
2. Eine Abfrage zu einem der Wurzelserver, um den Server herrisch für das Gebiet auf höchster Ebene zu finden.
3. Eine Abfrage zum erhaltenen TLD Server für die Adresse eines DNS für das Gebiet des zweiten Niveaus herrischen Servers.
4. Die Wiederholung des vorherigen Schritts, jedes Domainname-Etikett in der Folge bis zum Endschritt zu bearbeiten, der die IP Adresse des Gastgebers zurückgibt, hat gesucht.

Das Diagramm illustriert diesen Prozess für den Gastgeber www.wikipedia.org.

Der Mechanismus in dieser einfachen Form würde eine große Betriebslast auf den Wurzelservern, mit jeder Suche nach einer Adresse legen, die durch das Fragen von einem von ihnen anfängt. So kritisch seiend, wie sie zur gesamten Funktion des Systems sind, würde solcher schwerer Gebrauch einen unüberwindlichen Engpass für Trillionen von Abfragen gelegt jeden Tag schaffen. In der Praxis wird das Verstecken in DNS Servern verwendet, um dieses Problem zu überwinden, und infolgedessen, um nameservers einwurzeln zu lassen, werden wirklich mit sehr wenig vom Gesamtverkehr beteiligt.

Rekursiver und versteckender Namenserver

Im Prinzip sind herrische Namenserver für die Operation des Internets genügend. Jedoch, mit nur dem herrischen Namenserver-Funktionieren, muss jede DNS-Abfrage mit rekursiven Abfragen an der Wurzelzone des Domainname-Systems anfangen, und jedes Benutzersystem muss resolver zur rekursiven Operation fähige Software durchführen.

Um Leistungsfähigkeit zu verbessern, reduzieren Sie DNS Verkehr über das Internet und Zunahme-Leistung in Endbenutzer-Anwendungen, die Domainname-Systembetreuungen DNS Server des geheimen Lagers, die DNS-Anfragenergebnisse auf die Dauer von der Zeit versorgen, die in der Konfiguration (Zeit-zu-lebend) der fraglichen Domainname-Aufzeichnung bestimmt ist.

Gewöhnlich führt solches Verstecken DNS Server, auch genannt DNS geheime Lager, auch den rekursiven Algorithmus durch, der notwendig ist, um einen Vornamen aufzulösen, der mit der DNS-Wurzel durch zu den herrischen Namenservern des gefragten Gebiets anfängt. Mit dieser im Namenserver durchgeführten Funktion gewinnen Benutzeranwendungen Leistungsfähigkeit im Design und der Operation.

Die Kombination des DNS-Versteckens und der rekursiven Funktionen in einem Namenserver ist nicht obligatorisch; die Funktionen können unabhängig in Servern zu speziellen Zwecken durchgeführt werden.

Internetdienstleister stellen normalerweise rekursive und versteckende Namenserver für ihre Kunden zur Verfügung. Außerdem führen viele Hausnetzwerkanschlussrouter DNS geheime Lager und Wiedercursors durch, um Leistungsfähigkeit im lokalen Netz zu verbessern.

DNS resolvers

Die Kundenseite des DNS wird einen DNS resolver genannt. Es ist für das Einleiten und sequencing die Abfragen verantwortlich, die schließlich zu einer vollen Entschlossenheit (Übersetzung) der Quelle gesucht, z.B, Übersetzung eines Domainnamens in eine IP-Adresse führen.

Eine DNS-Abfrage kann entweder eine nichtrekursive Abfrage oder eine rekursive Abfrage sein:

• Eine nichtrekursive Abfrage ist diejenige, in der der DNS Server eine Aufzeichnung für ein Gebiet zur Verfügung stellt, für das es selbst herrisch ist, oder es ein teilweises Ergebnis zur Verfügung stellt, ohne andere Server zu fragen.
• Eine rekursive Abfrage ist ein, für den der DNS Server auf die Abfrage völlig antworten (oder einen Fehler geben wird) durch das Fragen anderer Namenserver, wie erforderlich. DNS Server sind nicht erforderlich, rekursive Abfragen zu unterstützen.

Der resolver oder ein anderer DNS Server, der rekursiv im Auftrag des resolver handelt, verhandelt Gebrauch des rekursiven Dienstes mit Bit in den Anfragenkopfbällen.

Auflösung hat gewöhnlich das Wiederholen durch mehrere Namenserver zur Folge, um die erforderliche Information zu finden. Jedoch fungieren einige resolvers einfacher durch das Kommunizieren nur mit einem einzelnen Namenserver. Diese einfachen resolvers (genannt "Stummel resolvers") verlassen sich auf einen rekursiven Namenserver, um die Arbeit durchzuführen, Information für sie zu finden.

Kreisförmige Abhängigkeiten und Leim-Aufzeichnungen

Namenserver in Delegationen werden namentlich, aber nicht durch die IP-Adresse identifiziert. Das bedeutet, dass ein Auflösungsnamenserver eine andere DNS-Bitte ausgeben muss, die IP Adresse des Servers herauszufinden, auf den es verwiesen worden ist. Wenn der in der Delegation gegebene Name ein Subgebiet des Gebiets ist, für das die Delegation zur Verfügung gestellt wird, gibt es eine kreisförmige Abhängigkeit. In diesem Fall muss der nameserver Versorgung der Delegation auch eine oder mehr IP-Adressen für den herrischen in der Delegation erwähnten nameserver zur Verfügung stellen. Diese Information wird Leim genannt. Der delegierende Namenserver stellt diesen Leim in der Form von Aufzeichnungen in der zusätzlichen Abteilung der DNS Antwort zur Verfügung, und stellt die Delegation in der Antwort-Abteilung der Antwort zur Verfügung.

Zum Beispiel, wenn der herrische Namenserver dafür, ein Computer ist, der versucht, die erste Entschlossenheit aufzulösen. Seitdem wird darin enthalten, das verlangt Auflösung zuerst, die eine kreisförmige Abhängigkeit präsentiert. Um die Abhängigkeit zu brechen, schließt der nameserver für das Spitzenniveau-Gebiet Leim zusammen mit der Delegation dafür ein. Die Leim-Aufzeichnungen sind Adresssätze, die IP-Adressen dafür zur Verfügung stellen. Der resolver verwendet ein oder mehr von diesen IP-Adressen, um einen der herrischen Server des Gebiets zu fragen, der ihm erlaubt, die DNS-Abfrage zu vollenden.

Das Rekordverstecken

Der DNS Entschlossenheitsprozess reduziert die Last auf individuellen Servern durch das Verstecken von DNS Bitte-Aufzeichnungen auf die Dauer von der Zeit nach einer Antwort. Das hat die lokale Aufnahme und nachfolgende Beratung der Kopie zur Folge, anstatt eine neue Bitte stromaufwärts zu beginnen. Die Zeit, für die resolver geheime Lager eine DNS Antwort durch einen Wert bestimmt wird, hat die Zeit, um zu leben (TTL) vereinigt mit jeder Aufzeichnung genannt. Der TTL wird vom Verwalter des DNS Servers gesetzt, der die herrische Antwort austeilt. Die Periode der Gültigkeit kann sich von gerade Sekunden bis zu den Tagen oder sogar Wochen ändern.

Als eine beachtenswerte Folge dieser verteilten und versteckenden Architektur pflanzen sich Änderungen zu DNS-Aufzeichnungen überall im Netz sofort nicht fort, aber verlangen, dass alle geheimen Lager ablaufen und nach dem TTL erfrischen. RFC 1912 befördert Grundregeln, um passende TTL-Werte zu bestimmen.

Ein resolvers kann TTL-Werte, als das Protokoll-Unterstützungsverstecken seit bis zu 68 Jahren oder kein Verstecken überhaupt überreiten. Das negative Verstecken, d. h. das Verstecken der Tatsache des Nichtseins einer Aufzeichnung, wird namentlich Server bestimmt, die für eine Zone herrisch sind, die die Aufzeichnung des Anfangs der Autorität (SOA) einschließen muss, wenn das Melden keiner Daten des gebetenen Typs besteht. Der Wert des MINIMALEN Feldes der SOA-Aufzeichnung und des TTL des SOA selbst wird verwendet, um den TTL für die negative Antwort zu gründen.

Rückseite lookup

Eine Rückseite lookup ist eine Abfrage des DNS für Domainnamen, wenn die IP-Adresse bekannt ist. Vielfache Domainnamen können mit einer IP-Adresse vereinigt werden. Der DNS versorgt IP-Adressen in der Form von Domainnamen als besonders formatierte Namen im Zeigestock Aufzeichnungen innerhalb der Infrastruktur Gebiet auf höchster Ebene arpa. Für IPv4 ist das Gebiet. Für IPv6 ist die Rückseite lookup Gebiet. Die IP-Adresse wird als ein Name in der rückbestellten Oktett-Darstellung für IPv4 vertreten, und Nagen-Darstellung für IPv6 rückbestellt.

er eine Rückseite lookup durchführt, wandelt der DNS Kunde die Adresse in diese Formate um, und fragt dann den Namen für eine PTR-Aufzeichnung im Anschluss an die Delegationskette bezüglich jeder DNS-Abfrage. Nehmen Sie zum Beispiel an, dass die IPv4-Adresse Wikimedia zugeteilt wird. Es wird als ein DNS-Name in umgekehrter Reihenfolge wie das vertreten:. Wenn der DNS resolver einen PTR (Rück-Lookup) Bitte bekommt, beginnt es durch das Fragen der Wurzelserver (die zu den Servern von ARIN für die Zone hinweisen). Auf den Servern von ARIN, wird Wikimedia zugeteilt, so sendet der resolver eine andere Abfrage zu Wikimedia nameserver dafür, der auf eine herrische Antwort hinausläuft.

Kunde lookup

Benutzer kommunizieren allgemein direkt mit einem DNS resolver nicht. Stattdessen findet DNS Entschlossenheit durchsichtig in Anwendungen wie WWW-Browser, E-Mail-Kunden und andere Internetanwendungen statt. Wenn eine Anwendung eine Bitte macht, die einen Domainnamen lookup verlangt, senden solche Programme eine Entschlossenheitsbitte an den DNS resolver im lokalen Betriebssystem, das der Reihe nach die erforderlichen Kommunikationen behandelt.

Der DNS resolver wird fast ein geheimes Lager unveränderlich haben (sieh oben), neuen lookups enthaltend. Wenn das geheime Lager die Antwort auf die Bitte zur Verfügung stellen kann, wird der resolver den Wert im geheimen Lager zum Programm zurückgeben, das die Bitte gemacht hat. Wenn das geheime Lager die Antwort nicht enthält, wird der resolver die Bitte an ein oder mehr benannte DNS Server senden. Im Fall von den meisten Hausbenutzern wird der Internetdienstleister, dem die Maschine in Verbindung steht, gewöhnlich diesen DNS Server liefern: Solch ein Benutzer wird entweder die Adresse dieses Servers manuell konfiguriert haben oder DHCP erlaubt haben, es zu setzen; jedoch, wo Systemverwalter Systeme konfiguriert haben, um ihre eigenen DNS Server zu verwenden, weisen ihre DNS resolvers zu getrennt aufrechterhaltenem nameservers der Organisation hin. Auf jeden Fall wird der so gefragte Namenserver dem Prozess folgen, der oben, bis dazu entworfen ist, entweder findet erfolgreich ein Ergebnis oder tut nicht. Es gibt dann seine Ergebnisse in den DNS resolver zurück; das Annehmen davon hat ein Ergebnis gefunden, die resolver verstecken ordnungsgemäß, die für den zukünftigen Gebrauch resultieren, und das Ergebnis zurück der Software reicht, die die Bitte begonnen hat.

Gebrochener resolvers

Ein zusätzliches Niveau der Kompliziertheit erscheint, wenn resolvers die Regeln des DNS Protokolls verletzen. Mehrere große ISPs haben ihre DNS Server konfiguriert, um Regeln (vermutlich zu verletzen, um ihnen zu erlauben, auf weniger - teure Hardware zu laufen, als ein völlig entgegenkommender resolver), solcher als durch das Missachten von TTLs, oder durch das Anzeigen, dass ein Domainname gerade nicht besteht, weil einer seiner Namenserver nicht antwortet.

Als ein Endniveau der Kompliziertheit haben einige Anwendungen (wie WWW-Browser) auch ihr eigenes DNS geheimes Lager, um den Gebrauch des DNS resolver Bibliothek selbst zu reduzieren. Diese Praxis kann Extraschwierigkeit hinzufügen, wenn sie bei DNS Problemen die Fehler beseitigt, weil es die Frische von Daten verdunkelt, und/oder welche Daten aus der geheimes Lager kommt. Diese geheimen Lager verwenden normalerweise sehr kurze Verstecken-Zeiten — auf der Ordnung einer Minute.

Internet Explorer vertritt eine bemerkenswerte Ausnahme: Versionen bis zu D. H. 3.x geheimes Lager DNS registrieren seit 24 Stunden standardmäßig. Internet Explorer 4.x und spätere Versionen (bis dazu D. H. 8) vermindern Sie den Verzug-Unterbrechungswert zu einer halben Stunde, die in entsprechenden Registrierungsschlüsseln geändert werden kann.

Andere Anwendungen

Das System, das oben entworfen ist, stellt ein etwas vereinfachtes Drehbuch zur Verfügung. Das Domainname-System schließt mehrere andere Funktionen ein:

• Hostnames und Adressen von IP passen auf einer isomorphen Basis nicht notwendigerweise zusammen. Vielfacher hostnames kann einer einzelnen IP-Adresse entsprechen: Verbunden mit der virtuellen Bewirtung erlaubt das einer einzelnen Maschine, vielen Websites zu dienen. Wechselweise kann ein einzelner hostname vielen IP-Adressen entsprechen: Das kann Schuld-Toleranz erleichtern und Vertrieb laden, und erlaubt auch einer Seite, physische Position nahtlos zu bewegen.
• Es gibt vielen Gebrauch von DNS außer dem Übersetzen von Namen zu IP-Adressen. Zum Beispiel verwenden Postübertragungsagenten DNS, um herauszufinden, wohin man E-Mail für eine besondere Adresse liefert. Das Gebiet, um Ex-Wechsler kartografisch darstellend zur Verfügung gestellt durch MX-Aufzeichnungen zu schicken, passt eine andere Schicht der Schuld-Toleranz und des Lastvertriebs oben auf dem Namen zur kartografisch darstellenden IP-Adresse an.

• E-Mail-Listen: Das DNS System wird für die effiziente Lagerung und den Vertrieb von IP Adressen von auf die schwarze Liste gesetzten E-Mail-Gastgebern verwendet. Die übliche Methode stellt die IP Adresse des unterworfenen Gastgebers ins Subgebiet eines höheren Niveau-Domainnamens, und lösen Sie dass Name zu verschiedenen Aufzeichnungen auf, um einen positiven oder eine Verneinung anzuzeigen. Hier ist eine hypothetische schwarze Beispiel-Liste:
• 102.3.4.5 wird => auf die schwarze Liste gesetzt Schafft 5.4.3.102.blacklist.example und löst sich zu 127.0.0.1 auf
• 102.3.4.6 ist nicht => 6.4.3.102.blacklist.example, wird oder Verzug zu 127.0.0.2 nicht gefunden
• E-Mail-Server können dann blacklist.example durch den DNS Mechanismus fragen herauszufinden, ob ein spezifischer Gastgeber, der zu ihnen in Verbindung steht, in der schwarzen Liste ist. Heute sind viele solcher schwarzen Listen, entweder frei oder Abonnement-basiert, hauptsächlich für den Gebrauch durch E-Mail-Verwalter und anti-spam Software verfügbar.
• Softwareaktualisierungen: Viele Antivirus und kommerzielle Software verwenden jetzt das DNS System, um Versionsnummern der letzten Softwareaktualisierungen so Kundencomputer zu versorgen, brauchen zu den Aktualisierungsservern jedes Mal nicht in Verbindung zu stehen. Für diese Typen von Anwendungen ist die Zeit des geheimen Lagers der DNS-Aufzeichnungen gewöhnlich kürzer.
• Absenderpolitikfachwerk und DomainKeys, anstatt ihre eigenen Rekordtypen zu schaffen, wurden entworfen, um einen anderen DNS-Rekordtyp, die TXT-Aufzeichnung auszunutzen.
• Um Elastizität im Falle des Computermisserfolgs zur Verfügung zu stellen, werden vielfache DNS Server gewöhnlich für den Einschluss jedes Gebiets, und am Spitzenniveau zur Verfügung gestellt, dreizehn sehr starke Wurzelserver, bestehen mit zusätzlichen "Kopien" von mehreren von ihnen verteilt weltweit über Anycast.
• Dynamischer DNS (hat manchmal DDNS genannt), erlaubt Kunden, ihren DNS Zugang als ihre IP-Adressänderungen zu aktualisieren, wie es zum Beispiel tut, wenn es sich zwischen ISPs oder beweglichen Krisenherden bewegt.

Protokoll-Details

DNS verwendet in erster Linie User Datagram Protocol (UDP) auf dem Hafen Nummer 53, um Bitten zu dienen. DNS Abfragen bestehen aus einer einzelnen UDP-Bitte vom Kunden, der von einer einzelnen UDP-Antwort vom Server gefolgt ist. Transmission Control Protocol (TCP) wird verwendet, wenn die Ansprechdatengröße um 512 Bytes, oder für Aufgaben wie Zonenübertragungen zu weit geht. Einige resolver Durchführungen verwenden TCP für alle Abfragen.

DNS Quellenaufzeichnungen

Resource Record (RR) ist das grundlegende Datenelement im Domainname-System. Jede Aufzeichnung hat einen Typ (A, MX, usw.), eine Grenze des Ablaufs der Frist, eine Klasse und einige mit dem Typ spezifische Daten. Quellenaufzeichnungen desselben Typs definieren ein Quellenrekordsatz-(RRset). Die Ordnung von Quellenaufzeichnungen in einem Satz, der durch einen resolver in eine Anwendung zurückgegeben ist, ist unbestimmt, aber häufig führen Server Einrichtung des gemeinsamen Antrags durch, um das Lastausgleichen zu erreichen. DNSSEC arbeitet jedoch an ganzen Quellenrekordsätzen in einer kanonischen Ordnung.

Wenn gesandt, über ein IP Netz verwenden alle Aufzeichnungen das Standardformat, das in RFC 1035 angegeben ist:

NAME ist der völlig qualifizierte Domainname des Knotens im Baum. Auf der Leitung kann der Name mit der Etikett-Kompression verkürzt werden, wo gegen Enden von Domainnamen erwähnt früher im Paket für das Ende des aktuellen Domainnamens ausgewechselt werden kann.

TYP ist der Rekordtyp. Es zeigt das Format der Daten an, und es gibt einen Hinweis seines beabsichtigten Gebrauches. Zum Beispiel wird Eine Aufzeichnung verwendet, um von einem Domainnamen bis eine IPv4-Adresse zu übersetzen, die NS-Rekordlisten, die Server nennen, können auf lookups auf einer DNS Zone antworten, und die MX-Aufzeichnung gibt an, dass der Mailserver gepflegt hat, Post für ein in einer E-Mail-Adresse angegebenes Gebiet zu behandeln (sieh auch Liste von DNS-Rekordtypen).

RDATA ist Daten der mit dem Typ spezifischen Relevanz, wie die IP-Adresse für Adresssätze, oder der Vorrang und hostname für MX-Aufzeichnungen. Weithin bekannte Rekordtypen können Etikett-Kompression im RDATA Feld verwenden, aber "unbekannte" Rekordtypen müssen nicht (RFC 3597).

Die KLASSE einer Aufzeichnung wird auf (für das Internet) für allgemeine DNS-Aufzeichnungen gesetzt, die Internet hostnames, Server oder IP-Adressen einschließen. Außerdem besteht die Klassenverwirrung und Hesiod . Jede Klasse ist ein unabhängiger Namenraum mit potenziell verschiedenen Delegationen von DNS Zonen.

Zusätzlich zu in einer Zonendatei definierten Quellenaufzeichnungen definiert das Domainname-System auch mehrere Bitte-Typen, die nur in der Kommunikation mit anderen DNS Knoten (auf der Leitung), solcher als verwendet werden, wenn das Durchführen von Zonenübertragungen (AXFR/IXFR) oder für EDNS (WÄHLT).

Wildcard DNS Aufzeichnungen

Die Domainname-Systembetreuungswildcard-Domainnamen, die Namen sind, die mit dem Sternchen-Etikett, '*' z.B anfangen. DNS Aufzeichnungen, die Wildcard-Domainnamen gehören, geben Regeln an, um Quellenaufzeichnungen innerhalb einer einzelnen DNS Zone durch das Ersetzen ganzer Etiketten mit dem Zusammenbringen von Bestandteilen des Anfragennamens einschließlich irgendwelcher angegebenen Nachkommen zu erzeugen.

Zum Beispiel, in der DNS Zone x.example, gibt die folgende Konfiguration an, dass alle Subgebiete (einschließlich Subgebiete von Subgebieten) x.example den Postex-Wechsler a.x.example verwenden. Die Aufzeichnungen für a.x.example sind erforderlich, um den Postex-Wechsler anzugeben. Da das das Ergebnis des Ausschließens dieses Domainnamens und seiner Subgebiete von den Wildcard-Matchs hat, müssen alle Subgebiete von a.x.example in einer getrennten Wildcard-Behauptung definiert werden.

Die Rolle von Wildcard-Aufzeichnungen wurde in RFC 4592 raffiniert, weil die ursprüngliche Definition in RFC 1034 unvollständig war und auf Missdeutungen durch implementers hinausgelaufen ist.

Protokoll-Erweiterungen

Das ursprüngliche DNS Protokoll hatte Bestimmungen für die Erweiterung mit neuen Eigenschaften beschränkt. 1999 hat Paul Vixie in RFC 2671 ein Erweiterungsmechanismus, genannt Erweiterungsmechanismen nach DNS (EDNS) veröffentlicht, der fakultative Protokoll-Elemente eingeführt hat, ohne oben wenn nicht im Gebrauch zuzunehmen. Das wurde durch die Pseudoquellenaufzeichnung vollbracht, die nur in Leitungsübertragungen des Protokolls, aber nicht in irgendwelchen Zonendateien besteht. Anfängliche Erweiterungen wurden auch (EDNS0), wie Erhöhung der DNS Nachrichtengröße in UDP Datenpaketen angedeutet.

Dynamische Zonenaktualisierungen

Dynamische DNS-Aktualisierungen verwenden den DNS opcode, um Quellenaufzeichnungen dynamisch von einer auf einem herrischen DNS Server aufrechterhaltenen Zonendatenbasis hinzuzufügen oder zu entfernen. Die Eigenschaft wird in RFC 2136 beschrieben. Diese Möglichkeit ist nützlich, um Netzkunden in den DNS einzuschreiben, wenn sie starten oder sonst verfügbar im Netz werden. Da ein Starten-Kunde eine verschiedene IP-Adresse jedes Mal von einem DHCP Server zugeteilt werden kann, ist es nicht möglich, statische DNS Anweisungen für solche Kunden zur Verfügung zu stellen.

Sicherheitsprobleme

Ursprünglich waren Sicherheitssorgen nicht Hauptdesignrücksichten für die DNS Software oder jede Software für die Aufstellung im frühen Internet, weil das Netz für die Teilnahme durch die breite Öffentlichkeit nicht offen war. Jedoch hat die Vergrößerung des Internets in den kommerziellen Sektor in den 1990er Jahren die Voraussetzungen für Sicherheitsmaßnahmen geändert, um Datenintegrität und Benutzerbeglaubigung zu schützen.

Mehrere Verwundbarkeitsprobleme wurden entdeckt und von böswilligen Benutzern ausgenutzt. Ein solches Problem ist DNS Vergiftung des geheimen Lagers, in denen Daten zum Verstecken resolvers unter dem Vorwand verteilt wird, ein herrischer Ursprung-Server zu sein, dadurch den Datenladen mit der potenziell falschen Information und lange Ablauf-Zeiten (Zeit-zu-lebend) beschmutzend. Nachher können legitime Anwendungsbitten umadressiert werden, um mit der böswilligen Absicht bediente Gastgeber zu vernetzen.

DNS Antworten werden traditionell nicht kryptografisch unterzeichnet, zu vielen Angriffsmöglichkeiten führend; die Domainname-Systemsicherheitserweiterungen (DNSSEC) modifizieren DNS, um Unterstützung für kryptografisch unterzeichnete Antworten hinzuzufügen. Mehrere Erweiterungen sind ausgedacht worden, um Zonenübertragungen ebenso zu sichern.

Einige Domainnamen können verwendet werden, um Manipulationseffekten zu erreichen. Zum Beispiel, paypal.com und sind paypa1.com verschiedene Namen, noch können Benutzer unfähig sein, sie in einer grafischen Benutzerschnittstelle abhängig vom gewählten Schriftbild des Benutzers zu unterscheiden. In vielen Schriftarten sehen der Brief l und die Ziffer 1 sehr ähnlich oder sogar identisch aus. Dieses Problem ist in Systemen akut, die internationalisierte Domainnamen, seit vielen Charakter-Codes in ISO 10646 unterstützen, kann identisch auf typischen Computerschirmen scheinen. Diese Verwundbarkeit wird gelegentlich in phishing ausgenutzt.

Techniken wie vorwärtsbestätigter Rück-DNS können auch verwendet werden, um zu helfen, DNS-Ergebnisse gültig zu machen.

Domainname-Registrierung

Das Recht, einen Domainnamen zu verwenden, wird von Domainname-Registratoren delegiert, die von Internet Corporation für Zugeteilte Namen und Zahlen (ICANN), die Organisation akkreditiert werden, die wegen des Beaufsichtigens des Namens und der Zahl-Systeme des Internets angeklagt ist. Zusätzlich zu ICANN wird jedes Gebiet auf höchster Ebene (TLD) aufrechterhalten und technisch von einer Verwaltungsorganisation bedient, eine Registrierung bedienend. Eine Registrierung ist dafür verantwortlich, die Datenbank von Namen aufrechtzuerhalten, die innerhalb des TLD eingeschrieben sind, den es verwaltet. Die Registrierung erhält Registrierungsinformation von jedem Domainname-Registrator, der bevollmächtigt ist, Namen im entsprechenden TLD zuzuteilen, und veröffentlicht die Information mit einem speziellen Dienst, dem whois Protokoll.

ICANN veröffentlicht die ganze Liste von TLD Registrierungen und Domainname-Registratoren. Mit Domainnamen vereinigte Information von Registrant wird in einer mit dem WHOIS Dienst zugänglichen Online-Datenbank aufrechterhalten. Für den grössten Teil der mehr als 240 internationalen Vorwahl Gebiete auf höchster Ebene (ccTLDs) erhalten die Bereichsregistrierungen den WHOIS aufrecht (Registrant, nennen Sie Server, Verfallsdaten, usw.) Information. Zum Beispiel hält DENIC, Netzinformationszentrum von Deutschland, die DE Bereichsdaten. Ungefähr seit 2001 haben die meisten gTLD Registrierungen diese so genannte dicke Registrierungsannäherung, d. h. das Halten der WHOIS Daten in Hauptregistrierungen statt Registrator-Datenbanken angenommen.

Für und Domainnamen wird ein dünnes Registrierungsmodell verwendet: die Bereichsregistrierung (z.B. VeriSign) hält grundlegenden WHOIS (Registrator und Namenserver, usw.) Daten. Man kann den ausführlichen WHOIS (registrant, Namenserver, Verfallsdaten, usw.) an den Registratoren finden.

Einige Domainname-Registrierungen, häufig genannt Netzinformationszentren (NIC), fungieren auch als Registratoren Endbenutzern. Die allgemeinen Hauptbereichsregistrierungen auf höchster Ebene, solcher bezüglich, Gebiete, verwenden ein Registrierungsregistrator-Modell, das aus vielen Domainname-Registratoren In dieser Methode des Managements besteht, die Registrierung führt nur die Domainname-Datenbank und die Beziehung mit den Registratoren. Die registrants (Benutzer eines Domainnamens) sind Kunden des Registrators in einigen Fällen durch zusätzliche Schichten von Wiederverkäufern.

Internetstandards

Das Domainname-System wird auf Verlangen für Anmerkungen (RFC) Dokumente definiert, die durch die Internettechnikeinsatzgruppe (Internetstandards) veröffentlicht sind. Der folgende ist eine Liste von RFCs, die das DNS Protokoll definieren.

• RFC 920, Bereichsvoraussetzungen - Angegebene ursprüngliche Gebiete auf höchster Ebene
• RFC 1032, Bereichsverwalter-Führer
• RFC 1033, Bereichsverwalter-Operationsführer
• RFC 1034, Domainnamen - Konzepte und Möglichkeiten
• RFC 1035, Domainnamen - Durchführung und Spezifizierung
• RFC 1101, DNS Encodings Netznamen und Anderer Typen
• RFC 1123, Voraussetzungen für Internetgastgeber — Anwendung und Unterstützung
• RFC 1178, einen Namen für Ihren Computer (FYI 5) Wählend
• RFC 1183, Neuer DNS RR Definitionen
• RFC 1591, Domainname-Systemaufbau und Delegation (Informations-)
• RFC 1912, Üblich DNS Betrieblich und Konfigurationsfehler
• RFC 1995, Zusätzliche Zonenübertragung in DNS
• RFC 1996, Ein Mechanismus für die Schnelle Ankündigung von Zonenänderungen (GEBEN DNS BEKANNT)
• RFC 2100, Das Namengeben von Gastgebern (Informations-)
• RFC 2136, Dynamische Aktualisierungen im Domainname-System (DNS AKTUALISIERUNG)
• RFC 2181, Erläuterungen zur DNS Spezifizierung
• RFC 2182, Auswahl und Operation von Sekundären DNS Servern
• RFC 2308, das Negative Verstecken von DNS-Abfragen (DNS NCACHE)
• RFC 2317, Klassenlos IN - ADDR.ARPA Delegation (BCP 20)
• RFC 2671, Erweiterungsmechanismen für DNS (EDNS0)
• RFC 2672, DNS Nichtendnamenwiederrichtung
• RFC 2845, Heimliche Schlüsseltransaktionsbeglaubigung für DNS (TSIG)
• RFC 3225, Resolver Unterstützung von DNSSEC Anzeigend
• RFC 3226, DNSSEC und IPv6 A6 bewusste server/resolver Nachrichtengröße-Voraussetzungen
• RFC 3597, das Berühren von Unbekannten DNS Typen von Resource Record (RR)
• RFC 3696, Anwendungstechniken für die Überprüfung und Transformation von Namen (Informations-)
• RFC 4343, Fall-Gefühllosigkeitserläuterung von Domain Name System (DNS)
• RFC 4592, Die Rolle von Wildcards im Domainname-System
• RFC 4635, Algorithmus-Bezeichner von HMAC SHA TSIG
• RFC 4892, Voraussetzungen für einen Mechanismus, der ein Namenserver-Beispiel (Informations-) Identifiziert
• RFC 5001, DNS Namenserver-Bezeichner (NSID) Auswahl
• RFC 5452, Maßnahmen, um DNS Elastischer gegen Geschmiedete Antworten Zu machen
• RFC 5625, DNS Proxydurchführungsrichtlinien (BCP 152)
• RFC 5890, Internationalisierte Domainnamen für Anwendungen (IDNA): Definitionen und Dokumentenfachwerk
• RFC 5891, Internationalisierte Domainnamen in Anwendungen (IDNA): Protokoll
• RFC 5892, Die Unicode-Codepunkte und Internationalisierten Domainnamen für Anwendungen (IDNA)
• RFC 5893, Schriften des Rechts-zu-link für Internationalisierte Domainnamen für Anwendungen (IDNA)
• RFC 5894, Internationalisierte Domainnamen für Anwendungen (IDNA): Hintergrund, Erklärung und Grundprinzip (Informations-)
• RFC 5895, Charaktere für Internationalisierte Domainnamen in Anwendungen (IDNA) 2008 (Informations-) Kartografisch darstellend
• RFC 6195, Domain Name System (DNS) IANA Rücksichten (BCP 42)

Sicherheit

• RFC 4033, DNS Sicherheit Einführung und Voraussetzungen
• RFC 4034, Quellenaufzeichnungen für die DNS Sicherheit Erweiterungen
• RFC 4035, Protokoll-Modifizierungen für die DNS Sicherheit Erweiterungen
• RFC 4509, Gebrauch von SHA-256 in DNSSEC Quellenaufzeichnungen von Delegation Signer (DS)
• RFC 4470, Minimal Bedeckung von NSEC Aufzeichnungen und DNSSEC, Online Unterzeichnend
• RFC 5011, Automatisierte Aktualisierungen der DNS Sicherheit (DNSSEC) Vertrauensanker
• RFC 5155, DNS Sicherheit (DNSSEC) Hashed Beglaubigte Leugnung der Existenz
• RFC 5702, Gebrauch von SHA-2 Algorithmen mit RSA in DNSKEY und RRSIG Quellenaufzeichnungen für DNSSEC
• RFC 5910, Sicherheitserweiterungen von Domain Name System (DNS), die für Extensible Provisioning Protocol (EPP) Kartografisch darstellen
• RFC 5933, Gebrauch von GOST Unterschrift-Algorithmen in DNSKEY und RRSIG Quellenaufzeichnungen für DNSSEC

Siehe auch

• Alternative DNS lassen einwurzeln
• Vergleich der DNS Server-Software
• DNS geheimes Lager, das vergiftet
• DNS, der entführt
• DNS Verwaltungssoftware
• Dynamischer DNS
• Internetversorger-Sicherheit
• IPv6 brokenness und DNS whitelisting
• Die Liste von DNS registriert Typen
• Microsoft DNS
• Gemeinsamer Antrag DNS
• Spalt-Horizont DNS

Links

• Zytrax.com, Führer des Open Sources - DNS für Rakete-Wissenschaftler, einen Online-technischen.
• Schaffen Sie eine Zonendatei auf zonefile.org
• Domainname-System auf Microsoft TechNet