Domain-Name-System

Domain Name System (DNS)
Familie	Familie der Internetprotokolle
Funktion	Domain-Namensauflösung
Häfen	53/UDP, 53/TCP
Speicherort im Protokollstapel
App DNS Transport TCP oder UDP Netz IP ( IPv4 , IPv6 )
Normen
RFC 881 (The Domain Name Scheme and Agenda, 1983) RFC 1034 (1987) RFC 1035 (1987)

Das Domain Name System ( DNS ) [ ist ein dezentralisiertes hierarchisches Namenssystem für Geräte , die mit IP - Netzwerken wie dem Internet oder einem privaten Netzwerk verbunden sind Dieses System verknüpft verschiedene Informationen mit Domänennamen , die jedem der Teilnehmer zugewiesen sind. Seine wichtigste Funktion besteht darin, menschenlesbare Namen in binäre Identifikatoren zu „übersetzen“, die Computern zugeordnet sind, die mit dem Netzwerk verbunden sind, um diese Computer weltweit lokalisieren und adressieren zu können. ]

Der DNS-Server verwendet eine hierarchische , verteilte Datenbank , in der Informationen zu Domänennamen in Netzwerken wie dem Internet gespeichert werden . Obwohl das DNS als Datenbank in der Lage ist, jedem Namen verschiedene Arten von Informationen zuzuordnen, sind die häufigsten Anwendungen die Zuordnung von Domänennamen zu IP-Adressen und der Standort der E-Mail-Server jeder Domäne.

Die Zuordnung von Namen zu IP-Adressen ist sicherlich die bekannteste Funktion der DNS-Protokolle. Wenn die IP-Adresse der Google-Site beispielsweise 216.58.210.163 lautet, erreichen die meisten Benutzer diesen Computer, indem sie www.google.com und nicht die IP-Adresse angeben. Der Name ist nicht nur leichter zu merken, sondern auch zuverlässiger. ​ Die numerische Adresse kann sich aus vielen Gründen ändern, ohne dass Sie den Namen der Website ändern müssen. Auch für den Fall, dass eine Webseite ein Content Delivery Network ( CDN, englische Abkürzung) über DNS verwendet, erhält der Benutzer die IP-Adresse des nächstgelegenen Servers gemäß seinem geografischen Standort (jedes CDN hat wiederum ein eigenes DNS Server).

Geschichte

Das DNS entstand hauptsächlich aus der Notwendigkeit, sich die Namen aller mit dem Internet verbundenen Server leicht merken zu können. Ursprünglich hostete SRI (jetzt SRI International ) eine Datei namens HOSTS , die alle bekannten Domänennamen enthielt. ]

Das explosionsartige Wachstum des Netzwerks machte das zentralisierte Benennungssystem in der Hosts-Datei unpraktisch, und im November 1983 veröffentlichte Jon Postel die Planung in RFC 881 und veröffentlichte später zusammen mit Paul Mockapetris im selben Jahr RFC 882 und RFC 883. . Im Oktober 1984 gaben sie nach langen Diskussionen den RFC 920 heraus , der definiert, was sich heute zum modernen DNS entwickelt hat (diese RFCs 882 und 883 wurden 1987 durch die RFCs 1034 und RFC 1035 ersetzt ). ]

In Ermangelung von DNS-Servern müssten Benutzer die IP-Adresse der Website schreiben, anstatt ihre URL zu schreiben, was zu Verwirrung führen würde und die Internetnavigation für Benutzer sehr kompliziert werden würde.

In dieser Phase bestand die beste Möglichkeit, "Kontinuität" zu gewährleisten, darin, mehrere Server zu haben, die mehrere Anfragen beantworten. Ein Server war der Master und die anderen waren Slaves . Jeder der Slaves musste sich regelmäßig beim Master erkundigen, dass sich die Daten nicht geändert hatten.

Etwa 10 Jahre später wurden einige größere Anpassungen am DNS-Protokoll vorgenommen. Dies war eine dynamischere Methode, um Server mithilfe von NOTIFY und inkrementellen Zonenübertragungen ( IXFR ) auf dem neuesten Stand zu halten. ]

NOTIFY war eine Schlüsseländerung. Anstatt auf die Überprüfung durch einen Slave zu warten, könnte der Master NOTIFY-Nachrichten an die Slaves senden und sie auffordern, die neuen Daten zu erfassen. IXFR bedeutete seinerseits eine Änderung in der Art und Weise, wie Daten übermittelt wurden. Wenn Sie nur einen von Hunderten von Datensätzen ändern, würde die ursprüngliche Spezifikation Hunderte von Nachrichten senden. IXFR änderte das System und erlaubte nur das Senden von Datensätzen, die geändert wurden. ]

Die nächste Entwicklung von DNS kam, als dynamische Änderungen in RFC 2136 definiert wurden . Dadurch konnten Serveradministratoren Registrierungsänderungen besser vornehmen. Später wurden in RFC 2671 DNS-Erweiterungsmechanismen (EDNS) definiert , die das System weiter modernisierten. ]

Das Interesse, mögliche Domainnamen um Zeichen aus anderen Sprachen zu erweitern, spiegelte sich 2010 in internationalisierten Domainnamen wider, wie sie in RFC 5890 und RFC 5891 definiert sind .

Komponenten

Für den praktischen Betrieb des DNS-Systems werden drei Hauptkomponenten verwendet:

Kunden der Phase 1

Ein DNS-Clientprogramm, das auf dem Computer des Benutzers ausgeführt wird und Anfragen zur DNS-Namensauflösung an einen DNS-Server generiert (z. B.: Welche IP-Adresse entspricht name.domain?)

DNS-Server

Sie beantworten Kundenanfragen. Rekursive Server haben die Möglichkeit, die Anfrage an einen anderen Server weiterzuleiten, wenn sie nicht über die angeforderte Adresse verfügen.

Autoritätszonen

Es ist ein Teil des Domänennamensraums, der für einen DNS-Server verantwortlich ist, der Autorität über mehrere Zonen haben kann. (Zum Beispiel: subdomain.Wikipedia.ORG, subdomain.COM usw.)

Die Teile eines Domainnamens verstehen

Ein Domain-Name besteht normalerweise aus zwei oder mehr Teilen (technisch "Etiketten"), die durch Punkte getrennt sind, wenn sie als Text geschrieben werden. Beispiel: www.example.com oder en.wikipedia.org

• Das Etikett ganz rechts wird als „ Top-Level-Domain “ bezeichnet . Wie „ com “ in www.example.com oder „ org “ in en.wikipedia.org
• Jedes Label auf der linken Seite gibt eine Unterteilung oder "Subdomain" an. Beachten Sie, dass "Subdomain" relative Abhängigkeit ausdrückt, nicht absolute Abhängigkeit. Theoretisch kann diese Unterteilung bis zu 127 Ebenen umfassen, und jedes Label kann bis zu 63 Zeichen enthalten, jedoch beschränkt auf die Gesamtlänge des Domainnamens, der 255 Zeichen nicht überschreitet, obwohl Domains in der Praxis fast immer viel kürzer sind.
• Schließlich drückt der äußerst linke Teil der Domäne normalerweise den Namen der Maschine aus (auf Englisch hostname ). Der Rest des Domänennamens gibt einfach an, wie ein logischer Pfad zu den erforderlichen Informationen erstellt wird. Beispielsweise hätte die Domäne es.wikipedia.org den Maschinennamen "es", obwohl sie sich in diesem Fall nicht auf eine bestimmte physische Maschine bezieht.

Das DNS besteht aus einer hierarchischen Gruppe von DNS-Servern. Jede Domain oder Subdomain hat eine oder mehrere "Autoritätszonen", die Informationen über die Domain und die Namensdienste aller enthaltenen Domains veröffentlichen. Die Hierarchie der Autoritätszonen stimmt mit der Hierarchie der Domänen überein. An der Spitze dieser Hierarchie stehen die Root-Server – die Server, die antworten, wenn sie versuchen, eine First- und Second-Level-Domain aufzulösen.

DNS in der realen Welt

Benutzer kommunizieren im Allgemeinen nicht direkt mit dem DNS-Server: Die Namensauflösung erfolgt transparent durch Clientanwendungen (z. B. Browser , E-Mail-Clients und andere Anwendungen, die das Internet verwenden). Wenn Sie eine Anfrage stellen, die eine DNS-Suche erfordert, wird die Anfrage an den lokalen DNS-Server des Betriebssystems gesendet. Das Betriebssystem prüft vor dem Aufbau einer Kommunikation, ob sich die Antwort im Cache befindet. Falls es nicht gefunden wird, wird die Anfrage an einen oder mehrere DNS-Server gesendet, der Benutzer kann die eigenen Server seines Internetdienstanbieters verwenden, er kann einen kostenlosen Domänenauflösungsdienst nutzen oder einen erweiterten Domänenauflösungsdienst mieten Dies sind im Allgemeinen Dienstleistungen, die von Unternehmen aufgrund ihrer Geschwindigkeit und der von ihnen gebotenen Sicherheit beauftragt werden.

Die meisten Heimanwender verwenden den vom Internetdienstanbieter bereitgestellten DNS-Server, mit Ausnahme derjenigen, die ihre Geräte oder Router für bestimmte öffentliche Server anpassen. Die Adresse dieser Server kann manuell oder automatisch über DHCP (dynamische IP) konfiguriert werden. In anderen Fällen haben Netzwerkadministratoren ihre eigenen DNS-Server konfiguriert.

In beiden Fällen prüfen die DNS-Server, die die Anfrage erhalten, zuerst, ob sie die Antwort im Cache haben. Wenn ja, serviere die Antwort; andernfalls würden sie die Suche rekursiv starten. Sobald die Antwort gefunden wurde, wird der DNS-Server das Ergebnis für die zukünftige Verwendung zwischenspeichern und das Ergebnis zurückgeben. ]

Typischerweise transportiert das DNS-Protokoll die Anfragen und Antworten zwischen Client und Server unter Verwendung des UDP-Protokolls , da es viel schneller ist. Die Fälle, in denen das TCP-Protokoll verwendet wird, sind: wenn Antworten mit einer Länge von mehr als 512 Byte transportiert werden müssen (z. B. bei Verwendung von DNSSEC) und wenn Informationen zwischen Servern ausgetauscht werden (z. B. bei einem Zonentransfer), aus Gründen der Zuverlässigkeit . ]

DNS-Hierarchie

DNS-Baum

Der Domänennamensraum hat eine Baumstruktur . Die Blätter und Knoten des Baums werden als Medienetiketten verwendet. Ein vollständig qualifizierter Domänenname eines Objekts besteht aus der Verkettung aller Labels eines Pfads. Labels sind alphanumerische Zeichenfolgen (mit "-" als einzigem zulässigen Symbol), müssen mindestens ein Zeichen und maximal 63 Zeichen lang sein und müssen mit einem Buchstaben beginnen (und nicht mit "-"). ​ Einzelne Labels werden durch Punkte getrennt. Ein Domainname endet mit einem Punkt (obwohl dieser letzte Punkt normalerweise weggelassen wird, da er rein formal ist). Ein korrekt gebildeter Domänenname (FQDN, für sein englisches Akronym) ist beispielsweise dieser: www.example.com. (einschließlich des Punktes am Ende).

Ein Domainname muss alle Punkte enthalten und darf maximal 255 Zeichen lang sein.

Ein Domainname wird immer von rechts nach links geschrieben. Der Punkt ganz rechts neben einem Domainnamen trennt das Root-Tag von der Hierarchie. Diese erste Ebene wird auch als Top Level Domain (TLD) bezeichnet.

Die Objekte einer DNS-Domäne (z. B. der Computername) werden in einer Zonendatei registriert, die sich auf einem oder mehreren Nameservern befindet.

Arten von DNS-Servern

Dies sind die Arten von Servern entsprechend ihrer Funktion: ]

Grundschule oder Lehrer

speichern die Daten eines Namensraums in ihren Dateien.

Secondaries oder Sklaven

Sie erhalten die Daten von den primären Servern über einen Zonentransfer.

Lokal oder Cache

sie arbeiten mit der gleichen Software, enthalten aber nicht die Datenbank zur Namensauflösung. Wenn eine Anfrage an sie gestellt wird, wenden sie sich wiederum an die entsprechenden DNS-Server und speichern die Antwort in ihrer Datenbank, um die Wiederholung dieser Anfragen in der kontinuierlichen oder kostenlosen Zukunft zu beschleunigen.

Arten der Auflösung von Domainnamen

Ein DNS-Server kann einen Domänennamen „rekursiv“ oder „iterativ“ auflösen. Bei einer "iterativen" Abfrage bittet ein Client einen DNS-Server, die vollständige Antwort für sich selbst abzurufen (dh bei gegebener Domäne my.domain.com erwartet der Client, die entsprechende IP-Adresse zu erhalten). Auf eine „rekursive“ Anfrage hingegen gibt der DNS-Server keine vollständige Antwort: Im Fall von my.domain.com gibt der erste Server, an den die Anfrage gestellt wird (ein Root-Server), die IP zurück Adressen der für die .com -Domain zuständigen Top-Level-Server (TDL) . Also muss der Client nun eine neue Anfrage an einen dieser Server stellen, der sich die Endung .domain.com merkt und mit der entsprechenden DNS-Server-IP antwortet, zum Beispiel dns.domain.com . Schließlich sendet der Client eine neue Abfrage an dns.domain.com , um die IP-Adresse von my.domain.com zu erhalten .

In der Praxis ist die Abfrage eines Hosts an ein lokales DNS rekursiv, während Abfragen, die vom lokalen DNS durchgeführt werden, iterativ sind. Außerdem werden rekursive Abfragen nur durchgeführt, wenn der lokale DNS-Server nicht über die entsprechenden zwischengespeicherten Daten verfügt (oder abgelaufen ist). Zusammenfassend wird der normale Auflösungsprozess wie folgt durchgeführt:

1. Der lokale DNS-Server erhält eine rekursive Abfrage vom Resolver des Client-Hosts .
2. Das lokale DNS führt iterative Abfragen an die entsprechenden Server durch.
3. Der lokale DNS-Server übermittelt die Auflösung an den Host, der die Informationen angefordert hat.
4. Der Resolver auf dem Client-Host liefert die Antwort an die entsprechende Anwendung.

Sicherheitsprobleme

Ursprünglich waren Sicherheitsbedenken keine großen Designüberlegungen bei DNS-Software oder anderer Software für den Einsatz im frühen Internet, da das Netzwerk nicht für die Teilnahme der allgemeinen Öffentlichkeit offen war. Die Ausweitung des Internets in den kommerziellen Bereich in den 1990er Jahren veränderte jedoch die Anforderungen an Sicherheitsmaßnahmen zum Schutz der Datenintegrität und Benutzerauthentifizierung .

Viele Schwachstellen wurden von böswilligen Benutzern entdeckt und ausgenutzt. Ein solches Problem ist die DNS-Cache-Poisoning , bei der Daten unter dem Deckmantel, ein Ursprungsautoritätsserver zu sein, an Cache-Resolver verteilt werden, wodurch der Datenspeicher mit möglicherweise falschen Informationen und langen Ablaufzeiten (Time-to-Live) kontaminiert wird. Anschließend können legitime Anwendungsanforderungen an Netzwerkgeräte umgeleitet werden, die mit bösartigen Inhalten betrieben werden.

DNS-Antworten waren traditionell nicht kryptografisch signiert , was viele Angriffsmöglichkeiten ermöglichte; DNS Security Extensions (DNSSEC) modifiziert DNS, um die Möglichkeit hinzuzufügen, kryptografisch signierte Antworten zu erhalten. DNSCurve wurde als Alternative zu DNSSEC vorgeschlagen. Andere Erweiterungen wie TSIG fügen Unterstützung für die kryptografische Authentifizierung zwischen vertrauenswürdigen Peers hinzu und werden häufig verwendet, um Zonenübertragungen oder dynamische Aktualisierungsvorgänge zu autorisieren.

Einige Domänennamen können zu Täuschungszwecken verwendet werden. Beispielsweise sind paypal.com und paypa1.com unterschiedliche Namen, aber Benutzer können den Unterschied je nach verwendeter Schriftart möglicherweise nicht erkennen. In vielen Schriftarten sehen der Buchstabe l und die Ziffer 1 sehr ähnlich oder sogar identisch aus. Dieses Problem ist in Systemen, die internationalisierte Domänennamen zulassen, schwerwiegend, da viele Zeichen in ISO 10646 auf typischen Computerbildschirmen identisch erscheinen können. Diese Schwachstelle wird gelegentlich beim Phishing ausgenutzt . ]

Techniken wie Forward- Commit-Reverse-FDNS können auch verwendet werden, um DNS-Ergebnisse zu validieren.

Ressourcenaufzeichnungen

Das Domain Name System spezifiziert eine Datenbank von Informationselementen für Netzwerkressourcen. Informationselementtypen werden kategorisiert und mit einer Liste von DNS-Datensatztypen organisiert – den Ressourcendatensätzen (RRs). Jeder Datensatz hat einen Typ (Name und Nummer), eine Ablaufzeit ( Lebensdauer) , eine Klasse und typspezifische Daten. Ressourcendatensätze des gleichen Typs werden als Ressourcendatensätze (RRset) bezeichnet und haben keine bestimmte Reihenfolge. DNS-Auflöser geben bei Abfragen den vollständigen Satz zurück, Server können jedoch eine Round-Robin- Reihenfolge für den Lastenausgleich implementieren . Im Gegensatz dazu arbeitet DNSSEC ( Domain Name System Security Extensions ) mit dem gesamten Satz von Ressourceneinträgen in kanonischer Reihenfolge.

Wenn sie über ein Internetprotokoll -Netzwerk gesendet werden , verwenden alle Datensätze das gemeinsame Format, das in RFC 1035 spezifiziert ist : ]

Ressourcendatensatz (RR)-Felder

Landschaft	Beschreibung	Länge ( Oktette )
SÜSSKARTOFFEL	Name des Knotens, zu dem der Datensatz gehört	Variable
TYP	RR-Typ in numerischer Form (z. B. 15 für MX RR)	zwei
KLASSE	Klassencode	zwei
TTL	Anzahl der Sekunden, die der RR gültig ist (das Maximum ist 2 31 −1, was ungefähr 68 Jahren entspricht)	4
RDLÄNGE	RDATA-Feldlänge (Angabe in Oktetts)	zwei
RDATEN	Zusätzliche RR-spezifische Daten	Variabel, je nach RDLENGTH

NAME ist der vollständig qualifizierte Domänenname des Knotens im Baum. Während der Verbindung kann der Name mithilfe der Label-Komprimierung gekürzt werden, wobei die Enden der zuvor im Paket erwähnten Domänennamen durch das Ende des aktuellen Domänennamens ersetzt werden können. Ein unabhängiges @ wird verwendet, um den aktuellen Ursprung zu bezeichnen.

TYPE ist der Datensatztyp. Gibt das Format der Daten an und gibt Aufschluss über den Verwendungszweck. Beispielsweise wird der A -Eintrag verwendet, um einen Domänennamen in eine IPv4-Adresse zu übersetzen , der NS -Eintrag listet auf, welche Nameserver Anfragen in einer DNS-Zone beantworten können , und der MX -Eintrag gibt den Mailserver an, der für die Bearbeitung von E-Mails einer Domäne verwendet wird in einer E-Mail-Adresse Ebenen der DNS angegeben, die sind.

RDATA sind relevante typspezifische Daten, wie z. B. IP-Adresse für Adressdatensätze oder Priorität und Hostname für MX-Datensätze. Bekannte Datensatztypen können Tag-Komprimierung für das RDATA-Feld verwenden, mit Ausnahme von "unbekannten" Datensatztypen ( RFC 3597 ).

CLASS ist die Klasse des auf IN (Internet) gesetzten Datensatzes für allgemeine DNS-Datensätze mit Hostnamen, Servern oder IP-Adressen. Hinzu kommen die Klassen Chaos (CH) und Hesiod (HS). Jede Klasse ist ein separater Namespace mit potenziell unterschiedlichen Delegierungen von DNS-Zonen.

Neben den in einer Zonendatei definierten Resource Records definiert das Domain Name System auch verschiedene Request-Typen, die nur bei der Kommunikation mit anderen DNS-Knoten (auf der Verbindung) verwendet werden, etwa bei der Durchführung von Zonentransfers (AXFR/IXFR) oder z EDNS (OPT).

Wildcard-DNS-Einträge

Das Domain Name System unterstützt Platzhalter - DNS-Einträge , die Namen angeben, die mit dem Sternchen-Tag „*“ beginnen, z. B. * .example. ​ DNS-Einträge, die sich auf Platzhalter-Domainnamen beziehen, legen Regeln zum Generieren von Ressourceneinträgen innerhalb einer einzelnen DNS-Zone fest, indem Labels durch übereinstimmende Komponenten des Namens ersetzt werden, einschließlich aller angegebenen Nachkommen. In der folgenden Konfiguration gibt die DNS-Zone x.example beispielsweise an, dass alle Subdomains, einschließlich Subdomains von Subdomains, von x.example den Mail Exchanger (MX) axexample verwenden . Der A-Record für axexample wird benötigt, um die IP-Adresse des Mail-Exchangers anzugeben. Da dies dazu führt, dass dieser Domainname und seine Subdomains vom Wildcard-Matching ausgeschlossen werden, muss auch für die Subdomain axexample ein zusätzlicher MX-Record definiert werden, sowie ein Wildcard-MX-Record für alle seine Subdomains in der DNS-Zone.

x.Beispiel. MX 10 axbeispiel.
*.x.Beispiel. MX 10 axBeispiel.
*.ax-Beispiel. MX 10 axBeispiel.
Beispiel. MX 10 axbeispiel.
Beispiel. JJJJ 2001:db8::1

Die Rolle von Platzhalterdatensätzen wurde in RFC 4592 verfeinert , da die ursprüngliche Definition in RFC 1034 unvollständig war und zu Fehlinterpretationen durch Implementierer führte. ]

Arten von DNS-Einträgen

Die am häufigsten verwendeten Datensatztypen sind:

Art des Registers	Bedeutung
EIN	Adresse ( Adresse ). Dieser Eintrag wird verwendet, um Hosting-Servernamen in IPv4-Adressen zu übersetzen.
AAAA	Adresse ( Adresse ). Dieser Eintrag wird in IPv6 verwendet , um Hostnamen in IPv6-Adressen zu übersetzen.
CNAME	Kanonischer Name ( kanonischer Name ). Es wird verwendet, um zusätzliche Hosting-Namen oder Aliase für die Hosting-Server einer Domain zu erstellen. Es wird verwendet, wenn mehrere Dienste (z. B. FTP und Webserver) auf einem Server mit einer einzigen IP-Adresse ausgeführt werden . Jeder Dienst hat seinen eigenen DNS-Eintrag (z. B. „ftp.example.com.“ und „www.example.com.“). Dies wird auch verwendet, wenn mehrere HTTP -Server mit unterschiedlichen Namen auf demselben Host ausgeführt werden. Zuerst wird der Alias ​​geschrieben und dann der richtige Name. Bsp. „Beispiel1 IN CNAME Beispiel2“
NS	Nameserver ( Nameserver ). Definiert die Zuordnung zwischen einem Domänennamen und den Nameservern, die die Informationen für diese Domäne speichern. Jede Domain kann beliebig vielen Nameservern zugeordnet werden
MX	Mailaustausch . _ Ordnet einen Domänennamen einer Liste von Mail-Exchangern für diese Domäne zu. Es hat einen Lastausgleich und eine Priorität für die Nutzung eines oder mehrerer Mail-Dienste
PTR	Indikator ( Zeiger ). Auch als "Reverse Record" bekannt, funktioniert es umgekehrt zum A-Record und übersetzt IPs in Domainnamen. Wird in der Konfigurationsdatei der Reverse-DNS-Zone verwendet
SOA	Autorität des Gebiets ( Autoritätsbeginn ). Stellt Informationen zum primären DNS-Server der Zone bereit
SRV	Serviceaufzeichnung ( SRV-Aufzeichnung )
IRGENDEIN	Alle Informationen aller Art, die es gibt. (Kein Datensatztyp, sondern ein Abfragetyp)

Klebeprotokoll

Ein "A"- und "AAAA"-Record wird als " Glue Record " bezeichnet, wenn er eine Domain definiert , auf die ein NS-Record zeigt. Ein Glue-Eintrag ordnet der Subdomain, die Sie als DNS-Server verwenden möchten, eine „Glue“-IP-Adresse zu. ]

Nehmen wir zum Beispiel an, wir haben die Domain „yourdomain.com“, für die ich die Subdomains „ns1.yourdomain.com“ und „ns2“ habe. ihredomain.com“. Dann könnten wir eine Konfiguration vornehmen wie: ]

ihredomain.com IN NS ns1.ihredomain.com
ihredomain.com IN NS ns2.ihredomain.com
ns1.ihredomain.com IN A 182.18.164.24
ns1.ihredomain.com IN JJJJ 2400:3b00:1:1::2
ns2.ihredomain.com IN A 103.231.77.204
ns2.ihredomain.com IN JJJJ 2400:3b00:20:4::d4

Die letzten vier Register sollen Kleberegister sein.

DNS-Standards

Die folgenden Dokumente definieren das Domain Name System:

• RFC 881 , The Domain Names Plan and Schedule – The Domain Names Plan and its Agenda, formeller Beginn der Arbeitsplanung für die Konzeptualisierung.
• RFC 920 , Domain Requirements – Gibt die ursprünglichen Top-Level-Domains an
• RFC 1032 , Leitfaden für Domänenadministratoren
• RFC 1033 , Betriebshandbuch für Domänenadministratoren
• RFC 1034 , Domänennamen – Konzepte und Einrichtungen
• RFC 1035 , Domänennamen – Implementierung und Spezifikation
• RFC 1101 , DNS-Kodierungen von Netzwerknamen und anderen Typen
• RFC 1123 , Anforderungen für Internet-Hosts – Anwendung und Support
• RFC 1178 , Auswählen eines Namens für Ihren Computer (FYI 5)
• RFC 1183 , Neue DNS-RR-Definitionen
• RFC 1591 , Domain Name System Structure and Delegation (Information)
• RFC 1912 , Häufige DNS-Betriebs- und Konfigurationsfehler
• RFC 1995 , inkrementelle Zonenübertragung in DNS
• RFC 1996 , Ein Mechanismus zur sofortigen Benachrichtigung über Zonenänderungen (DNS NOTIFY)
• RFC 2100 , Die Benennung von Hosts (Information)
• RFC 2136 , Dynamische Updates im Domain Name System (DNS UPDATE)
• RFC 2181 , Erläuterungen zur DNS-Spezifikation
• RFC 2182 , Auswahl und Betrieb sekundärer DNS-Server
• RFC 2308 , Negatives Caching von DNS-Anfragen (DNS NCACHE)
• RFC 2317 , klassenlose IN-ADDR.ARPA-Delegierung (BCP 20)
• RFC 2671 , Erweiterungsmechanismen für DNS (EDNS0)
• RFC 2672 , Nicht-Terminal-DNS-Namensumleitung
• RFC 2845 , Transaktionsauthentifizierung mit geheimem Schlüssel für DNS (TSIG)
• RFC 3225 , zeigt die Resolver-Unterstützung von DNSSEC an
• RFC 3226 , DNSSEC und IPv6 A6-fähige Server/Resolver-Nachrichtengrößenanforderungen
• RFC 3597 , Umgang mit unbekannten Typen von DNS-Ressourceneinträgen (RR).
• RFC 3696 , Anwendungstechniken zur Überprüfung und Umwandlung von Namen (zur Information)
• RFC 4343 , Domain Name System (DNS) Case Insensitivity Clarification
• RFC 4592 , Die Rolle von Wildcards im Domain Name System
• RFC 4635 , HMAC SHA TSIG-Algorithmus-Identifikatoren
• RFC 4892 , Anforderungen an einen Mechanismus zur Identifizierung einer Nameserver-Instanz (zur Information)
• RFC 5001 , DNS Name Server Identifier (NSID)-Option
• RFC 5452 , Maßnahmen, um DNS widerstandsfähiger gegen gefälschte Antworten zu machen
• RFC 5625 , DNS-Proxy-Implementierungsrichtlinien (BCP 152)
• RFC 5890 , Internationalisierte Domänennamen für Anwendungen (IDNA): Definitionen und Dokumentenrahmen
• RFC 5891 , Internationalisierte Domänennamen in Anwendungen (IDNA): Protokoll
• RFC 5892 , Die Unicode-Codepunkte und internationalisierte Domänennamen für Anwendungen (IDNA)
• RFC 5893 , Rechts-nach-links-Skripte für internationalisierte Domainnamen für Anwendungen (IDNA)
• RFC 5894 , Internationalisierte Domainnamen für Anwendungen (IDNA): Hintergrund, Erläuterung und Begründung (zur Information)
• RFC 5895 , Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 (Information)
• RFC 5966 , DNS-Transport über TCP – Implementierungsanforderungen
• RFC 6195 , Domain Name System (DNS) Überlegungen der IANA (BCP 42)

Sicherheit

• RFC 4033 , Einführung und Anforderungen der DNS-Sicherheit
• RFC 4034 , Ressourceneinträge für die DNS-Sicherheitserweiterungen
• RFC 4035 , Protokolländerungen für die DNS-Sicherheitserweiterungen
• RFC 4509 , Verwendung von SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
• RFC 4470 , minimale Abdeckung von NSEC-Einträgen und DNSSEC-Online-Signaturen
• RFC 5011 , Automatisierte Aktualisierungen von DNS-Sicherheits-(DNSSEC-)Vertrauensankern
• RFC 5155 , DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
• RFC 5702 , Verwendung von SHA-2-Algorithmen mit RSA in DNSKEY und RRSIG-Ressourceneinträgen für DNSSEC
• RFC 5910 , Zuordnung von Domain Name System (DNS)-Sicherheitserweiterungen für das Extensible Provisioning Protocol (EPP)
• RFC 5933 , Verwendung von GOST-Signaturalgorithmen in DNSKEY- und RRSIG-Ressourcendatensätzen für DNSSEC

Siehe auch

• Anhang: Liste der Arten von DNS-Einträgen
• hosts-Datei
• Reverse-DNS-Lookup
• Sicherheitserweiterungen für das Domain Name System
• Dynamisches DNS
• DNS-Erweiterungsmechanismen
• Internationalisierter Domainname
• Black-Hole-Server
• Root-Server
• DNS-Zonenübertragung

Angriffe

• DNS-Vergiftung
• DNS-Rebinding

Externe Links

• Wo befinden sich die Root-Server
• DNS der wichtigsten Betreiber
• Liste der öffentlichen DNS-Server