2. Introduction (Einführung)
2. Introduction (Einführung)
2.1. Overview (Überblick)
Das Ziel von Domainnamen (domain names) besteht darin, einen Mechanismus zur Benennung von Ressourcen bereitzustellen, sodass die Namen auf verschiedenen Hosts (hosts), Netzwerken (networks), Protokollfamilien (protocol families), Internets und Verwaltungsorganisationen (administrative organizations) verwendbar sind.
Aus Sicht des Benutzers sind Domainnamen nützlich als Argumente für einen lokalen Agenten (local agent), genannt Resolver, der Informationen abruft, die mit dem Domainnamen verknüpft sind. So kann ein Benutzer nach der Hostadresse oder Mail-Informationen fragen, die mit einem bestimmten Domainnamen verknüpft sind. Um dem Benutzer zu ermöglichen, einen bestimmten Informationstyp anzufordern, wird ein geeigneter Abfragetyp (query type) zusammen mit dem Domainnamen an den Resolver übergeben. Für den Benutzer ist der Domainbaum (domain tree) ein einzelner Informationsraum (information space); der Resolver ist dafür verantwortlich, die Verteilung der Daten zwischen Nameservern (name servers) vor dem Benutzer zu verbergen.
Aus Sicht des Resolvers ist die Datenbank, die den Domainraum (domain space) bildet, auf verschiedene Nameserver verteilt. Verschiedene Teile des Domainraums werden in verschiedenen Nameservern gespeichert, obwohl ein bestimmtes Datenelement redundant (redundantly) in zwei oder mehr Nameservern gespeichert wird. Der Resolver beginnt mit Kenntnis von mindestens einem Nameserver. Wenn der Resolver eine Benutzerabfrage verarbeitet, fragt er einen bekannten Nameserver nach den Informationen; im Gegenzug erhält der Resolver entweder die gewünschten Informationen oder eine Verweisung (referral) auf einen anderen Nameserver. Mithilfe dieser Verweisungen lernen Resolver die Identitäten und Inhalte anderer Nameserver kennen. Resolver sind dafür verantwortlich, mit der Verteilung des Domainraums umzugehen und die Auswirkungen von Nameserverausfällen zu bewältigen, indem sie redundante Datenbanken in anderen Servern konsultieren.
Nameserver verwalten zwei Arten von Daten. Die erste Art von Daten wird in Sätzen namens Zonen (zones) gehalten; jede Zone ist die vollständige Datenbank für einen bestimmten "beschnittenen" (pruned) Teilbaum des Domainraums. Diese Daten werden als autoritativ (authoritative) bezeichnet. Ein Nameserver überprüft regelmäßig, ob seine Zonen aktuell sind, und erhält andernfalls eine neue Kopie der aktualisierten Zonen aus lokal gespeicherten Masterdateien (master files) oder von einem anderen Nameserver. Die zweite Art von Daten sind gecachte Daten (cached data), die von einem lokalen Resolver erworben wurden. Diese Daten können unvollständig sein, verbessern jedoch die Leistung des Abrufprozesses, wenn wiederholt auf nicht-lokale Daten zugegriffen wird. Gecachte Daten werden schließlich durch einen Timeout-Mechanismus (timeout mechanism) verworfen.
Diese funktionale Struktur isoliert die Probleme der Benutzeroberfläche (user interface), Fehlerwiederherstellung (failure recovery) und Verteilung in den Resolvern und isoliert die Datenbankaktualisierungs- und Auffrischungsprobleme in den Nameservern.
2.2. Common configurations (Gängige Konfigurationen)
Ein Host kann auf verschiedene Weise am Domainnamesystem teilnehmen, je nachdem, ob der Host Programme ausführt, die Informationen aus dem Domainsystem abrufen, Nameserver, die Abfragen von anderen Hosts beantworten, oder verschiedene Kombinationen beider Funktionen. Die einfachste und vielleicht typischste Konfiguration ist unten dargestellt:
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| cache | |
+----------+ |
Benutzerprogramme interagieren über Resolver mit dem Domainnamenraum; das Format von Benutzerabfragen und Benutzerantworten ist spezifisch für den Host und sein Betriebssystem. Benutzerabfragen sind typischerweise Betriebssystemaufrufe (operating system calls), und der Resolver und sein Cache sind Teil des Host-Betriebssystems. Weniger leistungsfähige Hosts können wählen, den Resolver als Subroutine (subroutine) zu implementieren, die mit jedem Programm verknüpft wird, das seine Dienste benötigt. Resolver beantworten Benutzerabfragen mit Informationen, die sie über Abfragen an fremde Nameserver und den lokalen Cache erwerben.
Beachten Sie, dass der Resolver möglicherweise mehrere Abfragen an mehrere verschiedene fremde Nameserver stellen muss, um eine bestimmte Benutzerabfrage zu beantworten, und daher kann die Auflösung einer Benutzerabfrage mehrere Netzwerkzugriffe und eine beliebige Zeitdauer umfassen. Die Abfragen an fremde Nameserver und die entsprechenden Antworten haben ein Standardformat, das in diesem Memo beschrieben wird, und können Datagramme (datagrams) sein.
Abhängig von seinen Fähigkeiten könnte ein Nameserver ein eigenständiges Programm auf einer dedizierten Maschine oder ein Prozess oder Prozesse auf einem großen Time-Sharing-Host sein. Eine einfache Konfiguration könnte sein:
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
Hier erwirbt ein primärer Nameserver (primary name server) Informationen über eine oder mehrere Zonen, indem er Masterdateien aus seinem lokalen Dateisystem liest, und beantwortet Abfragen zu diesen Zonen, die von fremden Resolvern eintreffen.
Das DNS erfordert, dass alle Zonen redundant von mehr als einem Nameserver unterstützt werden. Designierte sekundäre Server (secondary servers) können Zonen erwerben und Updates vom primären Server unter Verwendung des Zonentransferprotokolls (zone transfer protocol) des DNS überprüfen. Diese Konfiguration ist unten dargestellt:
Local Host | Foreign
|
+---------+ |
/ /| |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+
In dieser Konfiguration stellt der Nameserver periodisch eine virtuelle Verbindung (virtual circuit) zu einem fremden Nameserver her, um eine Kopie einer Zone zu erwerben oder zu überprüfen, dass eine vorhandene Kopie sich nicht geändert hat. Die für diese Wartungsaktivitäten gesendeten Nachrichten folgen derselben Form wie Abfragen und Antworten, aber die Nachrichtensequenzen sind etwas anders.
Der Informationsfluss in einem Host, der alle Aspekte des Domainnamesystems unterstützt, ist unten dargestellt:
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| Shared | |
| database | |
+----------+ |
A | |
+---------+ refreshes | | references |
/ /| | V |
+---------+ | +----------+ | +--------+
| | | | |responses| | |
| | | | Name |---------|->|Foreign |
| Master |-------------->| Server | | |Resolver|
| files | | | |<--------|--| |
| |/ | | queries | +--------+
+---------+ +----------+ |
A |maintenance | +--------+
| +------------|->| |
| queries | |Foreign |
| | | Name |
+------------------|--| Server |
maintenance responses | +--------+
Die gemeinsame Datenbank (shared database) hält Domainraumdaten für den lokalen Nameserver und Resolver. Der Inhalt der gemeinsamen Datenbank wird typischerweise eine Mischung aus autoritativen Daten sein, die durch die periodischen Auffrischungsoperationen des Nameservers gepflegt werden, und gecachten Daten aus früheren Resolveranfragen. Die Struktur der Domaindaten und die Notwendigkeit der Synchronisation zwischen Nameservern und Resolvern implizieren die allgemeinen Eigenschaften dieser Datenbank, aber das tatsächliche Format liegt beim lokalen Implementierer.
Der Informationsfluss kann auch so angepasst werden, dass eine Gruppe von Hosts zusammenarbeitet, um Aktivitäten zu optimieren. Manchmal wird dies getan, um weniger leistungsfähige Hosts zu entlasten, sodass sie keinen vollständigen Resolver implementieren müssen. Dies kann für PCs oder Hosts geeignet sein, die die Menge an neuem Netzwerkcode minimieren möchten, der erforderlich ist. Dieses Schema kann auch einer Gruppe von Hosts ermöglichen, eine kleine Anzahl von Caches zu teilen, anstatt eine große Anzahl separater Caches zu pflegen, unter der Prämisse, dass die zentralisierten Caches eine höhere Trefferquote (hit ratio) haben werden. In beiden Fällen werden Resolver durch Stub-Resolver (stub resolvers) ersetzt, die als Front-Ends für Resolver dienen, die sich in einem rekursiven Server (recursive server) in einem oder mehreren Nameservern befinden, von denen bekannt ist, dass sie diesen Dienst ausführen:
Local Hosts | Foreign
|
+---------+ |
| | responses |
| Stub |<--------------------+ |
| Resolver| | |
| |----------------+ | |
+---------+ recursive | | |
queries | | |
V | |
+---------+ recursive +----------+ | +--------+
| | queries | |queries | | |
| Stub |-------------->| Recursive|---------|->|Foreign |
| Resolver| | Server | | | Name |
| |<--------------| |<--------|--| Server |
+---------+ responses | |responses| | |
+----------+ | +--------+
| Central | |
| cache | |
+----------+ |
In jedem Fall ist zu beachten, dass Domainkomponenten nach Möglichkeit immer zur Zuverlässigkeit repliziert werden.
2.3. Conventions (Konventionen)
Das Domainsystem hat mehrere Konventionen, die sich mit grundlegenden, aber fundamentalen Problemen befassen. Während der Implementierer frei ist, diese Konventionen INNERHALB SEINES EIGENEN SYSTEMS zu verletzen, muss er diese Konventionen in ALLEM von anderen Hosts beobachteten Verhalten einhalten.
2.3.1. Preferred name syntax (Bevorzugte Namenssyntax)
Die DNS-Spezifikationen versuchen, in den Regeln zur Konstruktion von Domainnamen so allgemein wie möglich zu sein. Die Idee ist, dass der Name jedes existierenden Objekts mit minimalen Änderungen als Domainname ausgedrückt werden kann.
Beim Zuweisen eines Domainnamens für ein Objekt wird der umsichtige Benutzer jedoch einen Namen auswählen, der sowohl die Regeln des Domainsystems als auch alle vorhandenen Regeln für das Objekt erfüllt, unabhängig davon, ob diese Regeln veröffentlicht oder durch vorhandene Programme impliziert sind.
Wenn beispielsweise eine Mail-Domain benannt wird, sollte der Benutzer sowohl die Regeln dieses Memos als auch die in RFC-822 erfüllen. Beim Erstellen eines neuen Hostnamens sollten die alten Regeln für HOSTS.TXT befolgt werden. Dies vermeidet Probleme, wenn alte Software konvertiert wird, um Domainnamen zu verwenden.
Die folgende Syntax führt zu weniger Problemen mit vielen Anwendungen, die Domainnamen verwenden (z.B. Mail, TELNET).
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
Beachten Sie, dass obwohl Groß- und Kleinbuchstaben in Domainnamen erlaubt sind, keine Bedeutung an die Groß-/Kleinschreibung geknüpft ist. Das heißt, zwei Namen mit derselben Schreibweise, aber unterschiedlicher Groß-/Kleinschreibung, sind als identisch zu behandeln.
Die Labels müssen den Regeln für ARPANET-Hostnamen folgen. Sie müssen mit einem Buchstaben beginnen, mit einem Buchstaben oder einer Ziffer enden und als innere Zeichen nur Buchstaben, Ziffern und Bindestriche (hyphen) haben. Es gibt auch einige Längenbeschränkungen. Labels müssen 63 Zeichen oder weniger sein.
Zum Beispiel identifizieren die folgenden Zeichenfolgen Hosts im Internet:
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
2.3.2. Data Transmission Order (Datenübertragungsreihenfolge)
Die Reihenfolge der Übertragung der in diesem Dokument beschriebenen Header und Daten wird auf Oktett-Ebene (octet) aufgelöst. Wann immer ein Diagramm eine Gruppe von Oktetten zeigt, ist die Übertragungsreihenfolge dieser Oktette die normale Reihenfolge, in der sie auf Englisch gelesen werden. Zum Beispiel werden im folgenden Diagramm die Oktette in der Reihenfolge übertragen, in der sie nummeriert sind.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Wann immer ein Oktett eine numerische Menge darstellt, ist das am weitesten links stehende Bit im Diagramm das höherwertige oder signifikanteste Bit (most significant bit). Das heißt, das mit 0 bezeichnete Bit ist das signifikanteste Bit. Zum Beispiel stellt das folgende Diagramm den Wert 170 (dezimal) dar.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Ähnlich, wann immer ein Multi-Oktett-Feld eine numerische Menge darstellt, ist das am weitesten links stehende Bit des gesamten Feldes das signifikanteste Bit. Wenn eine Multi-Oktett-Menge übertragen wird, wird das signifikanteste Oktett zuerst übertragen.
2.3.3. Character Case (Zeichengroß-/Kleinschreibung)
Für alle Teile des DNS, die Teil des offiziellen Protokolls sind, werden alle Vergleiche zwischen Zeichenketten (z.B. Labels, Domainnamen usw.) auf eine Groß-/Kleinschreibung ignorierende Weise (case-insensitive) durchgeführt. Derzeit gilt diese Regel im gesamten Domainsystem ohne Ausnahme. Zukünftige Ergänzungen über den aktuellen Gebrauch hinaus könnten jedoch die vollen binären Oktettfähigkeiten in Namen verwenden müssen, daher sollten Versuche, Domainnamen in 7-Bit-ASCII zu speichern oder spezielle Bytes zur Beendigung von Labels usw. zu verwenden, vermieden werden.
Wenn Daten in das Domainsystem gelangen, sollte ihre ursprüngliche Groß-/Kleinschreibung nach Möglichkeit beibehalten werden. Unter bestimmten Umständen kann dies nicht erfolgen. Wenn beispielsweise zwei RRs in einer Datenbank gespeichert sind, einer bei x.y und einer bei X.Y, werden sie tatsächlich an derselben Stelle in der Datenbank gespeichert, und daher würde nur eine Groß-/Kleinschreibung beibehalten. Die Grundregel ist, dass die Groß-/Kleinschreibung nur verworfen werden kann, wenn Daten verwendet werden, um die Struktur in einer Datenbank zu definieren, und zwei Namen identisch sind, wenn sie auf eine Groß-/Kleinschreibung ignorierende Weise verglichen werden.
Der Verlust von groß-/kleinschreibungsempfindlichen Daten muss minimiert werden. Während Daten für x.y und X.Y beide unter einem einzigen Ort x.y oder X.Y gespeichert werden können, würden Daten für a.x und B.X niemals unter A.x, A.X, b.x oder b.X gespeichert. Im Allgemeinen bewahrt dies die Groß-/Kleinschreibung des ersten Labels eines Domainnamens, erzwingt jedoch die Standardisierung von inneren Knotenlabels.
Systemadministratoren, die Daten in die Domaindatenbank eingeben, sollten darauf achten, die Daten, die sie dem Domainsystem liefern, auf eine Groß-/Kleinschreibung konsistente Weise darzustellen, wenn ihr System groß-/kleinschreibungsempfindlich ist. Das Datenverteilungssystem im Domainsystem stellt sicher, dass konsistente Darstellungen beibehalten werden.
2.3.4. Size limits (Größenbeschränkungen)
Verschiedene Objekte und Parameter im DNS haben Größenbeschränkungen. Sie sind unten aufgelistet. Einige könnten leicht geändert werden, andere sind fundamentaler.
| Objekt | Grenze |
|---|---|
| labels (Labels) | 63 Oktette oder weniger |
| names (Namen) | 255 Oktette oder weniger |
| TTL | positive Werte einer vorzeichenbehafteten 32-Bit-Zahl |
| UDP messages (UDP-Nachrichten) | 512 Oktette oder weniger |