DE60037502T2

DE60037502T2 - Domänennamen-Auflösungssystem mit einem oder mehreren Servern

Info

Publication number: DE60037502T2
Application number: DE60037502T
Authority: DE
Inventors: Ronald Northbrook LACHMAN; Steve Michael Plya Del Ray HOTZ; William Carl El Segundo MANNING; Alec Harkness Lakewood PETERSON; Michael Allen Phoenix HOTZ; Rodney L. Phoenix JOFFE
Original assignee: Ultradns Inc Danville; UltraDNS Inc
Current assignee: Ultradns Inc Danville; UltraDNS Inc
Priority date: 1999-03-03
Filing date: 2000-03-02
Publication date: 2008-12-11
Anticipated expiration: 2020-03-03
Also published as: ATE381846T1; WO2000052594A2; EP1157524A2; WO2000052594A3; US20040039798A1; DE60037502D1; EP1157524B1; AU3390500A

Description

Ein Abschnitt der Offenbarung dieses Patentdokuments enthält Material, welches Gegenstand eines Urheberrechts- bzw. Copyrightschutzes ist. Der Urheberrechtsinhaber hat keinen Einwand gegen eine originalgetreue Wiedergabe sowohl durch das Patentdokument als auch die Patentoffenbarung, wie sie in der Akte bzw. Datei oder in den Datensätzen des Patent- und Markenamtes erscheint, aber er behält sich andererseits alle Urheberrechte welcher Art auch immer vor.
HINTERGRUND
1. BEREICH DER ERFINDUNG
Diese Erfindung betrifft im Allgemeinen verbesserte Domänennamen-Server, und insbesondere effiziente Verarbeitung von Domänennamen-Anforderungen in einem Netzwerk, wie zum Beispiel dem Internet.
2. HINTERGRUND
Das Internet hat eine Informationsrevolution durch die Entwicklung von mit Computern ausgestatteten Informationsquellen, Online-Diensten und des World-Wide-Web (WWW) mit sich gebracht. Das Internet wachst schnell mit einer sich vergrößernden Zahl von Computern und Benutzern, welche täglich mit dem Internet verbunden werden.
Damit Vorrichtungen bzw. Geräte (Computer, Drucker und dergleichen) an einem Netz, wie beispielsweise dem Internet, in der Lage sind, miteinander zu kommunizieren, müssen die Geräte Adressen der anderen kennen (oder fähig sein, diese festzulegen). Viele Verteilungssysteme (z. B. das Internet) weisen Gerätenamen in dem Verteilungssystem durch ein hierarchisches Namensgebungsschema zu, welche als Domänennamen bekannt sind. Ein Internet-Domänenname ist im Allgemeinen eine Folge von Domänenkennsätzen bzw. -labeln, die durch Punkte voneinander getrennt sind. Zum Beispiel ist „a.ultradns.com" ein Domänenname, wobei „com" ein Hauptdomänenname einer obersten Domäne, „ultradns" ein Domänenname zweiter Stufe einer Domäne zweiter Stufe und „a" ist ein Domänenname dritter Stufe einer Domäne dritter Stufe. Ein Gerät in einer Domäne ist durch den Namen des Gerätes gefolgt von dem Domänenname gekennzeichnet. Somit weist ein Gerät mit der Kennung „Server" in der „a.ultradns.com"-Domäne den Namen „server.a.ultradns.com" auf. Ein Gerätename wird auch als ein Domänenname bezeichnet. Das Domänennamen-System (DNS) ist eine verteilte hierarchische Datenbank, welche Client-/Server-Transaktionsservern umfasst, die ein Mapping von Domänennamen zu zugehörigen Informationen, z. B. zu IP-Adressen, bereitstellen.
Während Domänennamen ein Verteilungssystem in einer logischen und hierarchischen Art und Weise aufteilen, werden Nachrichten zwischen Geräten des DNS durch Identifizierung von Geräten unter Verwendung spezifischer IP-Adressen übertragen. In dem vorliegenden Internetprotokoll, sind IP-Adressen 32-Bit-Zahlen, welche als vier 8-Bit-Werte (z. B. vier Zahlen in dem Bereich von 0 bis 255) durch Punkte getrennt, z. B. „121.121.121.2", ausgedrückt. IP-Adressen enthalten Informationen, wie zum Beispiel als Netzwerkidentifizierer („ID") einer Gerätenetzwerkverbindung und eine Geräte-ID. IP-Adressen werden von einer Adressenautorität zugeordnet. Die Adressen werden in Blöcken maßgeblichen Adressenservern zugeordnet.
Eine umfassende Beschreibung des Betriebs von Domänennamen-Servern und IP-Adressen wird in DNS and BIND In A Nutshell, Paul Abitz and Cricket Liu, O'Reilly & Associates, 1994, ISBN: 1-56582-010-4 gegeben, was hier durch Bezugnahme aufgenommen ist.
IP-Adressen beziehen sich aufeinander in einer hierarchischen Weise. Somit stellt das DNS auch ein „Reverse Mapping" von IP-Adressen zu Domänennamen unter Verwendung einer Darstellung einer IP-Adresse, welche dem DNS-Indexierungsmodell folgt, bereit. Jedoch sind die Domänennamen-Hierarchie und die IP-Adressen-Hierarchie nicht direkt aufeinander bezogen. Während einige Namenserver auch Adressenserver sind, müssen Namen- und Adressenserver nicht dasselbe Gerät sein. Somit ist es für einen Server möglich, die Autorität zur Auflösung eines Domänennamens in eine korrespondierende IP-Adresse eines Gerätes zu besitzen, wobei der gleiche Namenserver nicht dazu fähig sein kann, die IP-Adresse in den korrespondierenden Domänennamen des gleichen Gerätes aufzulösen. Somit folgt eine Auflösung von IP-Adressen in Domänennamen einem ähnlichen Prozess wie eine Auflösung von Domänennamen in IP-Adressen mit der Ausnahme, dass unterschiedliche Server daran beteiligt sind.
Da IP-Adressen numerisch ausgeführt und nicht wie Domänennamen ohne Bezug auf die logische und hierarchische Organisation des DNS zugeordnet sind, werden Domänennamen im Allgemeinen bei Anweisungen für Funktionen, wie beispielsweise Datenübertragungen, verwendet. So identifiziert eine Datenübertragungsanweisung das Empfangsgerät über seinen Domänennamen. Der Domänenname muss jedoch in eine zugehörige IP-Adresse übersetzt werden, bevor die Datenübertragung stattfinden kann.
Domänennamen werden durch maßgebliche Geräte, die Namenserver genannt werden, gesteuert. Das heißt, Domänennamen-Server führen die Aufgabe von Umwandlung von Namen in IP-Adressen durch. Namenserver übersetzen Domänennamen in korrespondierende IP-Adressen und umgekehrt. Wenn ein erstes Gerät eine Nachricht an ein zweites Gerät, das nur durch seinen Domänennamen bekannt ist, übertragen will, muss das erste Gerät bei einem Namenserver eine Anforderung stellen, um die korrespondierende IP-Adresse zu dem bekannten Domänennamen des zweiten Gerätes zu erhalten.
EP 0817444 A2 offenbart ein kontextabhängiges Auflösungssystem für Namen mit Mehrfachbindung, wobei ein Namenauflöser ein Anfrage empfängt und der beabsichtigte Empfänger der Anfrage auf Grundlage einer Kombination von einem oder mehreren vorher festgelegten Kriterien aufgelöst wird. Die Anfrage wird dann zu einem ausgewählten Bestimmungsort weitergeleitet.
Es wird geschätzt, dass sich im Verlauf des Jahres 2003 die Zahl von Domänen im Internet zehnfach vergrößern wird, wobei 150 Millionen Domänen überschritten werden. Verbunden mit diesem Anstieg der Zahl von Domänen wird es einen Anstieg einer Benutzermissstimmung geben. Derzeitige Implementierungen des Domänennamen-Systems sind gänzlich ungeeignet und unfähig, resultierende DNS-Dateigröße oder die Größe und Frequenz von Änderungen zu diesen DNS-Dateien zu handhaben. Schon heute existieren reale Probleme mit Inhaltszugriff und/oder Inhaltsverteilung über dem Internet. Es wird geschätzt, dass zehn bis dreißig Prozent von Verbindungsereignissen im Internet erfolglos oder ungenügend sind.
ZUSAMMENFASSUNG
Die vorliegende Erfindung schafft eine skalierbare und flexible Plattform zur Bereitstellung von globalen Adressenverzeichnisdiensten. In einigen Ausführungen verwendet die Erfindung redundante Datenserver zur Bereitstellung von allgegenwärtigem und hochleistungsfähigem Zugriff auf Adressenverzeichnisdienste. Das System von Server übt eine Hebelwirkung auf die Skalierbarkeit und Wiederholmechanismen aus, welche von kommerzieller Datenbanksoftware bereitgestellt werden. Das DNS gemäß der vorliegenden Erfindung weist ein zugrundeliegendes modulares Design auf, welches zusätzliche Leitungsprotokolldienste gestattet, die leicht in dem System aufnehmbar sind, und ermöglicht es zusätzlichen Modulen, intelligente/dynamische Reaktionen bereitzustellen, indem Änderungen in dem Datendepot beeinflusst werden.
In verschiedenen Aspekten schafft die vorliegende Erfindung:

• Unterstützung von Dienstmodellen im großen Maßstab besser als alternative DNS-Server.
• Integration von weiteren Internetdiensten, z. B. „Whois", in einem einzelnen Datendepot.
• Einen Multithreading fähigen Server zur Bereitstellung einer Skalierbarkeit zur Auswertung von Hardware auf kommerziellem Stand.
• Eine modulare Datenbankimplementation zur Erleichterung der Hinzufügung von neuen Merkmalen.
• Eine Datenbankreproduktion zur leichten Steuerung von verteilten Server, und Datenbank-Backup-Eigenschaften zur Bereitstellung von Datenintegrität.

Global verteilte Serverreplikas schaffen die Zuverlässigkeit, den Durchsatz und die kurze Verzögerung, welche zur Skalierung eines breiten kommerziellen Dienstes erforderlich sind. Die Server sind unter Verwendung fortschrittlicher Internet-Routing- Mechanismen, welche auf den Zustand von individuellen Servernachbildungen reaktionsfähig sind.
Mehrfachserver schaffen einen erhöhten Systemdurchsatz, Zuverlässigkeit bei dem Vorkommen von Serverfehler, Zuverlässigkeit bei dem Ereignis eines Provider-Netzwerkfehlers, und nächste Servermechanismen dienen als Grundlage für fortschrittlichen Umleitungsdienst.
Ausführungen der Erfindung schaffen ein DNS-System basierend auf einer informationszentrierten Konstruktion, wobei Mehrfachsystemkomponenten mit einem Systemzustand zusammenwirken, der in der Datenbank aufrecht erhalten wird. Die Datenbank stellt sowohl die prinzipielle Internetinformationen und die erforderlichen Verbindungen und die erforderliche Konfiguration zur Spezifizierung des Betriebs der aktiven Komponenten bereit. Das System gestattet reduzierte Betriebspersonalanforderungen durch Unterstützung einer Kunden-Benutzerschnittstelle zur direkten Steuerung von Benutzerdaten mit integrierter Sicherheit und Datenvalidierung zur Aufrechterhaltung von Datenintegrität.
Die vorliegende Erfindung schafft auch:

• Datenaktualisierung über Mehrfachbenutzerspezifische Kundenschnittstellen, Progarmmier-APIs oder Internetdienste, wie beispielsweise dynamische DNS-Updates.
• Fein abgestufte Sicherheit basierend auf einer Verbindung zwischen Login und Datenobjekten.
• Modulare aktive Komponenten zum Berichten bzw. Reporting, Berechnen und Prüfen von Datenintegrität.

In einem Aspekt schafft diese Erfindung ein System zur Verarbeitung von Domänennamen-Anforderungen. Das System weist einen Anfragemechanismus auf, der (a) zur Erlangung einer Benutzeranfrage für Antwortdaten korrespondierend zu einem besonderen Domänennamen konstruiert und ausgelegt ist; und (b) vollständige Antwortdaten in einer einzelnen Antwort auf die Benutzeranforderung bereitstellt. Die Benutzeranfrage kann eine Domänennamen-Auflösungsanforderung sein, wobei in diesem Fall der Anfragemechanismus eine Internetprotokoll-(IP-)Adresse korrespondierend zu dem Domänennamen bereitstellt. Das System passt Benutzeranfragen für weitere eingegebene DNS-Daten an.
In einigen Ausführungen ist ein Anfragemechanismus weiterhin so konstruiert und angepasst, um die Antwort in Abhängigkeit von Kontextdaten zu liefern. Die Kontextdaten können zumindest (a) Kontextdaten von der Anfrage; (b) Kontextdaten von dem System; und (c) globale Kontextdaten aufweisen.
Die Kontextdaten können Adressendaten aufweisen, welche eine Adresse des Benutzers; die Ortszeit; und/oder den Ort des Systems angeben.
In einigen Ausführungen weist das System einen Daten-Cache auf, und der Anfragemechanismus ist so konstruiert und angepasst, um bei Empfang einer Benutzeranfrage zuerst zu versuchen, eine Antwort auf die Benutzeranfrage in dem Daten-Cache zu finden.
In einigen Ausführungen ist der Anfragemechanismus weiterhin dahingehend konstruiert und ausgebildet, (a) wenn die Antwort in dem Daten-Cache vorhanden ist und die Antwort frisch bzw. aktuell ist, die Antwort direkt von den im Cache gespeicherten Daten zu senden; und, (b) wenn die Antwort in dem Daten-Cache vorhanden ist und die Antwort veraltet ist, oder die Antwort nicht in dem Daten-Cache vorhanden ist, dann die Antwort von einer Datenbank zu erhalten; die Antwort zu senden; und den Daten-Cache zu aktualisieren, um die erhaltene Antwort widerzuspiegeln.
Manchmal weisen Daten in dem Daten-Cache eine maximale Lebensdauer auf, welche von der Lebenszeit für einen niedrigsten Resourcen-Datensatz in einer vollständigen Antwort bis zu dem maximalen Cache-Zeitwert dauert, der für das System als ganzes konfiguriert ist.
In einigen Ausführungen ist der Anfragemechanismus weiterhin so konstruiert und angepasst, um ein negative Cache-Speicherung so zu implementieren, dass, wenn eine Anfrage für einen Host gestellt wird, der nicht in einer aktiven Domäne vorhanden ist, die negative Antwort in dem Cache gespeichert wird.
In einem weiteren Aspekt ist die Erfindung ein Verfahren zum Bereitstellen einer Internetprotokoll-(IP-)Adresse eines von einer Vielzahl von Geräten im Internet. Das Verfahren weist folgende Verfahrensschritte auf: Erhalten einer Benutzeranfrage für eine IP-Adresse, welche zu einem besonderen Domänennamen korrespondiert; und bereitstellen der IP-Adresse in einer einzelnen Antwort auf die Benutzeranfrage. Das Verfahren kann ein Bereitstellen der IP-Adresse in Abhängigkeit von Kontextdaten aufweisen. Die Kontextdaten können zumindest (a) Kontextdaten von der Benutzeranfrage; (b) lokale Kontextdaten; und (c) globale Kontextdaten umfassen.
In einem noch weiteren Aspekt ist die Erfindung ein System, welches ein Netzwerk von verteilten Domänennamen-Servern (DNS) aufweist, wobei jeder DNS eine Datenbank und einen Anfragemechanismus aufweist, der so konstruiert und angepasst ist, um von der Datenbank eine Benutzeranfrage für Antwortdaten korrespondierend zu einem besonderen Domänennamen zu erhalten, und vollständige Antwortdaten in einer einzelnen Antwort auf die Benutzeranfrage bereitzustellen. Die Datenbanken in dem Netzwerk sind nachgebildet.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Aufgaben und Vorteile der Erfindung werden unter Betrachtung der folgenden detaillierten Beschreibung im Zusammenhang mit den begleitenden Zeichnungen ersichtlich, in welchen die Bezugszeichen sich überall auf gleiche Teile beziehen, und in welchen
1 eine Übersicht von Ausführungen der vorliegenden Erfindung im Betrieb innerhalb des Internets bereitstellt; und
2 den logischen Aufbau des Datenbankschemas gemäß den Ausführungen der vorliegenden Erfindung darstellt.
DETAILLIERTE BESCHREIBUNG
Mit Bezug auf 1 weist ein Domänennamen-Server (DNS) 100 (DNS₁) gemäß der vorliegenden Erfindung eine Datenbank 102 mit einem eindeutigen Datenbankschema und einem komplementären eindeutigen SQL-Interface 104 auf. Ein Anfragemechanismus 106 verwendet das SQL-Interface 104, um eine Anfrage an die Datenbank 102 zu stellen und um Ergebnisse an anfragende Benutzer, z. B. Benutzer 108, zurückzugeben.
Die vorliegende Erfindung kann auf zwei Stufen betrachtet werden, nämlich auf einer Serverstufe (z. B. DNS₁ 100) und auf einer Systemstufe (z. B. DNS₁, DNS₂, ..., DNS_n).

1. Serverstufe: Auf der Serverstufe stellt diese Erfindung einen Mechanismus bereit, welcher es einem DNS-Server (z. B. DNS₁ 100) gemäß der vorliegenden Erfindung ermöglicht, eine genügende Leistungsfähigkeit (ca. tausende von Anfragen pro Sekunde) auch dann zu erreichen, wenn die zugrundeliegende Datenquelle eine Basisdatensuche bei einer Geschwindigkeit von hunderten von Anfragen pro Sekunde unterstützt. Eigenschaften dieser Serverstufe, die unten ausführlich diskutiert wird, umfassen Folgendes: • Aggregierte Datenbankanfragen • Common-Case-Optimierungen • Daten-Cache (und konsequenterweise erforderliche Cache-Invalidierungsmechnismen)
2. Systemstufe: Auf der Systemstufe stellt diese Erfindung Mechanismen bereit, welche einem System von DNS-Servern (z. B. DNS₁, DNS₂, ..., DNS_n in 1) eine verbesserte/integrierte Steuerung von Daten ermöglicht und verschiedene Stufen zur Leistungsverbesserung für eingehende Anfragen und interne Transaktionen bereitstellt. Eigenschaften dieser Systemstufe, die unten ausführlich diskutiert wird, umfassen Folgendes: • Modulares datenzentriertes Design • Datenbanklayer-Synchronisation • Einzelne IP-Adressen-Angaben von nachgebildeten Server

Die Serverstufenmechanismen gemäß der vorliegenden Erfindung ermöglichen es dem DNS-Server eine höhere Transaktionsdurchsatzrate zu erlangen. Die Systemstufenmechanismen arbeiten synergistisch und gestatten es dem DNS-System gemäß der Erfindung einen mannigfaltigen Satz an Eigenschaften und Vorteilen bereitzustellen.
Die Serverstufenmechanismen gemäß der vorliegenden Erfindung ermöglichen das modulare datenzentrierte Design und die Datenbanklager-Synchronisation.
SERVERSTUFENMECHANISMEN
Eine Namenserverantwort auf eine DNS-Anfrage erfordert einen komplexen Satz von Berechnungen, welcher Folgendes ermöglicht:

(a) unterschiedliche zurückzugebende Antworten in Abhängigkeit von den Serverautoriäten;
(b) unterschiedliche Antworten in Abhängigkeit von den vorhandenen Domänennamen-Daten; und
(c) dem Server, eine Antwort zurückzugeben, welche mehrfach wechselseitig abhängige Abschnitte umfasst.

Genauer gesagt muss ein DNS-Antwortalgorithmus zumindest das Folgende aufweisen:

• Drei Antwortabschnitte: Antworten, Autorität und Zusätzliches
• CNAME (Domänennamen-Alias) Dereferenzierung
• Wildcard-Übereinstimmung (Übereinstimmung von führenden Superstrings)
• Iterative Domänennamen-Suche (Übereinstimmung der längsten erkannten Domänennamen)

Herkömmliche (aus dem Stand der Technik) DNS-Server führen viele getrennte Anfragen an die Datenquelle aus, um die korrekten Datensätze zum Einfügen in eine Antwort festzulegen. Folglich wird die Transaktionsrate des DNS-Servers um einen ähnlichen Faktor reduziert (z. B., wenn acht Datenbankanfragen erforderlich sind, wird die Transaktionsrate um einen Faktor von ungefähr acht verringert). Der DNS-Server gemäß der vorliegenden Erfindung reduziert die durchschnittliche Anzahl von Anfragen zur Konstruktion einer DNS-Antwort in signifikanter Weise im Vergleich mit herkömmlichen so genannten „straight-forward" bzw. „geradeaus" Algorithmen, welche von vielen getrennten Anfragen an die Datenquelle abhängig sind.
Aggregierte Datenbankanfragen
Der DNS-Server gemäß der vorliegenden Erfindung benutzt zusammengesetzte Datenbankanfragen derart, dass eine einzelne Anfrage Datensätze mit vielfachen Komponenten zurückgegeben kann, die erforderlich sind, um eine DNS-Antwort zu konstruieren. Außerdem werden Datenbankanfragen so korreliert, dass in Fällen, in welchen mehrfache Anfragen erforderlich sind, anschließende Anfragen basierend auf Datensätzen, die bei früheren Datenbankanfragen erhalten wurden, optimiert werden können. Die DNS-Anfragestrategie ist gemäß der vorliegenden Erfindung ist wie folgt:

(a) Abrufen von Kombinationen von Antwort, Autorität und Zusatz- Datensätzen in einer einzelnen Anfrage;
(b) Abrufen von verfügbaren CNAME-Datensätzen zusammen mit Antwort/Autorität/Zusatz- Datensätzen; und
(c) Reduzieren von iterativer Overhead-Domänennamen-Suche durch Korrelierung von Datensätzen aus unterschiedlichen Iterationen.

Mit dieser Erfindung kann die Anzahl von Datenbankanfragen, die zum Aufbau einer vollständigen DNS-Antwort erforderlich sind, so gering wie eine sein. Dies ist eine beträchtliche Verbesserung im Vergleich zu einer ähnlichen Strategie, die auf einfa chen Datenbankanfragen basiert, welche eine separate Anfrage für jede von Antworten und Autorität, und mehrfache Anfragen für Zusatz-Datensätze erfordert.
Common-Case-Optimierungen
Im Allgemeinen sind Common-Case-Optimierungen in Systemen wirksam, in welchen es Folgendes gibt: eine Zahl von getrennten potenziellen Ergebnissen (a) mit unterschiedlichen Wahrscheinlichkeiten eines Vorkommens; (b) erforderliche variierende Stufen von inkrementalem Overhead; und (c) wo eine Festlegung erfolgen kann, dass ein spezifisches Ergebnis ohne eine erschöpfende Ergebnisanalyse erreicht worden ist.
Die vorliegende Erfindung erkennt, dass eines Common-Case-Optimierung auf die Datenbankanfragestrategie des DNS-Servers anwendbar ist, und hat zwei spezifische Optimierungen basierend auf einer Kenntnis von DNS-Protokollen und des erwarteten eingehenden Anfragestroms identifiziert. Das DNS-System gemäß der vorliegenden Erfindung implementiert diese Optimierungen, indem der Test für jeden (und die Handhabung von jedem) Fall als separates Codesegment ausgelegt wird, und unterstützt diesen Code zur Handhabung der Aufgabe vor der Ausführung jedes allgemeinen Anfragekodes.
Fall #1:
Der DNS-Server gemäß der vorliegenden Erfindung enthält eine maßgebliche Antwort auf eine Domänennamen-Anfrage, die ein Label länger ist als der Domänenname der Zone (z. B. mit einem Zonennamen „foo.com" ist dann eine Optimierung wirksam für „www.foo.com", aber nicht für „www.mkt.foo.com").
Fall #2:
Der DNS-Server gemäß der vorliegenden Erfindung hat den Subdomänennamen der nächsten Stufe delegiert (z. B. ist die eingehende Anfrage für den Domänennamen „www.mkt.foo.com", welcher in der Zone „foo.com" liegt, dann ist die Optimierung wirksam, wenn die „mkt.foo.com"-Zone subdelegiert worden ist).
Die Verwendung dieser spezifischen Optimierungen schließt nicht die Entwicklung von zusätzlichen Optimierungen aus. Die fundamentale Realisierung und die Anforderungen bleiben unverändert, wobei es Common-Case-Optimierungen gestattet wird, auf Ergebnisse angewendet zu werden, die auf revidierten Ergebniswahrscheinlichkeiten basieren.
Insbesondere stützen sich weitere spezifizierte Common-Case-Optimierungen auf Restriktionen der Datensätze in der Datenbank, um die Validität der Anfrageantwort zu garantieren. Zum Beispiel eine Verallgemeinerung von Fall #1 (oben), welche Domänennamen-Anfragen für beliebige Länge optimiert (z. B. liegt die eingehende Anfrage für den Domänennamen „www.unit.mkt.foo.com" innerhalb der Zone für „foo.com"). Dieser Fall kann optimiert werden, wenn keine Konflikt erzeugenden Datensätze vorhanden sind, z. B. irgendein Datensatz, der den gemachten Vorrang für den Optimierungsfall ändern könnte (z. B. ein dazwischen kommender NS-Datensatz oder ein Wildcard-Datensatz verbunden mit dem Domänennamen „mkt.foo.com" würde eine Wirkung auf das obige Beispiel von „www.unit.mkt.foo.com" in Zone „foo.com" ausüben).
Zusätzlich ermöglicht die DNS-Anfragestrategie gemäß der vorliegenden Erfindung, dass ein flexibler/dynamischer Optimierungscode erstellt werden kann, wo z. B. eine spezifische Abwicklung von individuellen Common-Case-Optimierungen mit jeder Zone basierend auf vorherige Kenntnis oder beibehaltene Statistiken über jede Zone verbunden ist. Diese Technik kann so angewendet werden, dass die beste Strategie bei der Auflösung jeder Zone, jedes Servers oder irgendeiner identifizierbaren Klasse von Anfragestrom ausgewählt wird.
Daten-Cache und Cache-Invalidierung
Dynamischer Daten-Cache ist ein Mechanismus, der angewendet wurde, um Leistungsfähigkeit bei vielen Systemtypen zu erreichen, aber nie zuvor benutzt wurde, um einen schnellen Zugriff auf Datenquellen von maßgeblichen Daten innerhalb eines Domänennamen-Servers bereitzustellen.
Das Domänennamen-System wurde mit einem integrierten „Zeit zu leben" (TTL) Cache-Mechanismus konstruiert, und es werden drei Beispielanwendungen von Cache irgendwo innerhalb des Internet und Domänennamen-Systems angegeben.

• Anwendungen wie beispielsweise Web-Browser behalten häufig Kopien von DNS-Datensätzen, die sie bei Verarbeitung von HTTP-Anfragen erhalten haben, bei und benutzen anwendbare DNS-Datensätze für anschließende Anfragen. Diese Verwendung von Cache behält weder maßgebliche Daten bei noch beeinflusst sie direkt den Betrieb eines DNS-Servers.
• Cache ausführende DNS-Server (auch bekannt als rekursive Server oder „Hilfs-" Server) stellen eine separate Funktion von „hosting" DNS-Servern bereit. Rekursive Server arbeiten zu Gunsten einer Anwendung (z. B. ein Web-Browser eines Benutzers) und fragen eine hierarchische Reihe von Hosting-DNS-Servern zum Erhalt der erforderlichen DNS-Antwort an. Daten, die im Verlauf einer DNS-Anfrageauflösung erhalten wurden, können beibehalten werden und zur Beschleunigung von anschließenden DNS-Anfragen benutzt werden, bis jede spezifizierte Lebensdauer eines jeden Datensatzes ausgelaufen ist. Dies ist eine fundamentale Verwendung innerhalb des DNS, aber sie adressiert nur das Verhalten von nicht maßgeblichen Servern, wenn maßgebliche Daten gehandhabt werden.
• Herkömmliche primäre DNS-Server (z. B. wie durch die „Bind"-Serververteilung verkörpert) lesen alle maßgeblichen Domänendaten direkt aus Dateien in einen Computerspeicher und beantworten Anfragen basierend auf einer vollständig im Speicher residenten Kopie aller Domänendaten. Im Gegensatz zu den obigen Cache-Beispielen ist dies keine Anwendung eines dynamischen Cache, sondern ist eine statische Kopie von DNS-Daten, welche sich basierend auf wohlbekannten Cache-Kriterien wie Benutzungshäufigkeit weder ändert oder ersetzt wird noch irgendwelche dynamischen Mechanismen zur Beibehaltung einer Cache-Konsistenz verkörpert. Es gibt keinen dynamischen Mechanismus für einen „Cache-Miss", welcher das Standard-Alternativ-Verfahren einer Durchführung einer Back-Up-Anfrage an die Primärquelle (d. h. kein Cache) einschließt.

Gemäß Ausführungen der vorliegenden Erfindung hält der DNS-Server einen internen dynamischen Cache von kürzlich benutzten maßgeblichen DNS-Datensätzen aufrecht, die von der Datenbankquelle stammen. Zwei Ausführungen werden spezifiziert: (1) bei welcher individuelle Resourcen-Datensätze separat im Cache gespeichert werden und eine anschließende DNS-Antwort die individuellen Datensätze umfassen; und (2) bei welcher die gesamte Antwort auf eine DNS-Anfrage im Cache als eine Sammlung gespeichert wird und sofort für eine anschließende Anwort verfügbar ist, wobei ein Overhead beseitigt wird, der zur Konstruktion einer vollständigen Antwort erforderlich ist. Die Strategie zur Handhabung eingehender DNS-Anfragen weist eine Untersuchung des internen Cache für effizienten Zugriff auf Daten auf, und wenn nicht verfügbar, wird eine anschließende Anfrage an die Primärdatenquelle (Datenbank) ausgeführt. Diese Mechanismen werden sowohl für „positiven Cache", d. h. wenn die Daten vorhanden sind, und „negativen Cache" durchgeführt, d. h. wenn der Server maßgeblich antworten kann, dass die Daten nicht vorhanden sind.
Der DNS-Server gemäß der vorliegenden Erfindung weist auch Cache-Ersatzmechanismen zur Steuerung der Menge von „veralteten" (nicht häufig benutzten) Daten in dem Cache auf, und zur Ermöglichung einer wirksamen Nutzung von Cache und Systemresourcen. Mehrfache Ausführungen existieren zur Entfernung von DNS-Daten aus dem Cache basierend auf Häufigkeit oder Gebrauchsaktualität.
Cache-Invalidierung
Ein dynamisches Cache-System muss Cache-Invalidierungs-Mechanismen aufweisen, um zu gewährleisten, dass die Daten im Cache zu dem Zustand der Primärdatenquelle korrespondieren. Dies macht es erforderlich, dass Datenteile aus dem Cache entfernt (oder in ihm ersetzt) werden, wenn sich die korrespondierenden Daten innerhalb der Primärdatenquelle ändern. Dies ermöglicht ein DNS-Server gemäß der vorliegenden Erfindung zu exakten Widerspiegelung der korrekten Daten innerhalb des Systems.

Der DNS-Server gemäß der vorliegenden Erfindung ist durch eine Anzahl von zugehörigen Cache-Invalidierungs-Mechanismen verwirklicht, welche den vollständigen Bereich von Transaktionstypen adressieren, die auf die Primärdatenquelle angewendet werden können, und den Typ von Cache-Daten, die in dem System aufrecht erhalten werden können. Der Designraum, welcher die Cache-Transaktionen von Interesse fest legt, wird von der Tabelle unten dargestellt, welche vierundzwanzig unterschiedliche Cache-Invalidierungs-Transaktionen spezifiziert, die von der Cache-Invalidierungs-Strategie der Erfindung adressiert werden können. Es ist zu beachten, dass jeder durch eine besondere Ausführung der Erfindung adressiert werden muss, und dass einige Cache-Invalidierungs-Mechanismen mehrfache Invalidierungserfordernisse adressieren werden.

	Datensatz-Cache	Anfrage-Cache (Antworten)	Anfrage-Cache (maßgeblich)	Anfrage-Cache (zusätzlich)
Löschen aus Primärdatenbank	Positiv gegen Negativ	Positiv gegen Negativ	Positiv gegen Negativ	Positiv gegen Negativ
Hinzufügen zu Primärdatenbank	Positiv gegen Negativ	Positiv gegen Negativ	Positiv gegen Negativ	Positiv gegen Negativ
Modifizieren in Primärdatenbank	Positiv gegen Negativ	Positiv gegen Negativ	Positiv gegen Negativ	Positiv gegen Negativ

Mehrfache Invalidierungsmechanismen können zusammen angewendet werden, dergestalt, dass jeder eine Untergruppe der potenziellen Cache-Interaktionen und Erfordernisse adressiert. Weiterhin können diese Mechanismen variierende Kriterien zur Aktualität von Dateninvalidierungen verkörpern, entsprechend der Bedeutung, die jeder Untergruppe zugewiesen ist. Wenn zum Beispiel ein Cache-Vorgang von vollständigen DNS-Antworten erfolgt, können die Daten innerhalb eines Antwortabschnitts kritischer betrachtet werden als die Daten innerhalb eines maßgeblichen Abschnitts. In diesem Fall können Mechanismen verwendet werden, die unmittelbar auf Aktualisierungen von Daten in dem Antwortabschnitt reagieren, während andere weniger rechtzeitige Mechanismen schließlich die Datensätze innerhalb des maßgeblichen Abschnitts invalidieren.
SYSTEMSTUFENMECHANISMEN
Die Systemstufenmechanismen gemäß der vorliegenden Erfindung arbeiten synergistisch, wobei das DNS-System gemäß der vorliegenden Erfindung ermöglicht wird, eine verbesserte/integrierte Steuerung von Daten zu schaffen und einen Bereich einer Leistungsverbesserung für eingehende Anfragen und interne Transaktionen bereitzustellen.

• Modulares datenzentriertes Design
• Datenbanklayer-Synchronisation
• Einzel-IP-Adressen-Angabe von nachgebildeten Servern

Modulares datenzentriertes Design
Der DNS-Domänennamen-Server gemäß der vorliegenden Erfindung (z. B. DNS₁ 100 aus 1) trennt die Funktionalität des monolithischen Standard-Internet-Servers in zwei getrennte Komponenten: ein kommerzielles Datenbanksystem wie die Datenquelle und einen DNS-Leitungsprotokoll-Server, der zur Beantwortung von Anfragen basierend auf maßgeblichen DNS-Daten von der Datenbankkomponente ausgebildet ist. Die Architekturauswahl schafft ein klares modulares Design, welches seinerseits eine flexible und skalierbare Plattform bereitstellt, die eine Hebelwirkung zur Bereitstellung einer mannigfaltigen Gruppe von Eigenschaften und Erfindungen ist.

• Datenzentrierte Modellierung und funktionale Servermodulerweiterungen – Das Zweikomponentendesign gestattet modulare Erweiterungen sowohl für das Datenmodell als auch für die Funktionen (z. B. Server), welche auf dem System betrieben werden. Ausführungen dieser Erfindung umfassen, sind aber nicht darauf beschränkt, ein oder mehr Benutzerschnittstellen bzw. -interface zur Datenverwaltung bzw. zum Datenmanagement, Transaktionsprozessoren zur Bereitstellung eines dehnbaren API zum Datenmanagement, Internet-Systemmonitore, welche einen externen Systemzustand abfragen können (z. B. Webserververfügbarkeit) und Änderungen der Datenquelle beeinflussen können, und Server für weitere Internet-Directory-Server (z. B. whois, radius, etc.).
• Integrierte Zugriffssteuermechanismen – Eine Verwendung einer Datenbankquelle für DNS-Daten gestattet mehrere prinzipielle zu modellierende und steuernde Objekte (z. B. Benutzer und andere Netzwerkdatenschemata). Eine signifikante Eigenschaft des DNS-Domänenmanagement-Systems gemäß der vorliegenden Erfindung ist die Fähigkeit die Zugriffsmuster „mang-to-mang" von Benutzern, welche auf Domänennamen-Daten zugreifen, zu steuern und zu delegieren.
• Anfrage- und kontextspezifische Antworten – Herkömmliche (Stand der Technik) DNS-Server verwenden als Eingabe ein <Domänenname, Anfragetyp, Anfrageklasse>-Tupel und geben die geeignete Resourcendaten zurück. Das DNS-System gemäß der vorliegenden Erfindung hat die grundlegende Anfrage/Antwort-Transaktion durch Einfügen von zusätzlichen Feldern innerhalb des Datenmodells so verbessert, dass die Antwort auf eine Anfrage auf zusätzlichen Kriterien basieren kann. Diese Kriterien können Daten aufweisen, welche aus der eingehenden Anfrage erhalten werden (z. B. Quellen-IP-Adressen), welche dem lokalen Server verfügbar sind (z. B. Tageszeit oder Serveridentität), und ähnlichen Kontext oder anfragespezifische Daten.
• Dynamisch konfigurierbare DNS-Datensatztypen – Der DNS-Server gemäß der vorliegenden Erfindung ermöglicht es, neue Resourcen-Datensatztypen festzulegen und unmittelbar in das System aufzunehmen. Basierend auf Resourcen-Datensatzschablonen, die in dem Datenmodell eingeschlossen sind, kann der DNS-Server gemäß der vorliegenden Erfindungssystem neue Datensatztypen in Minuten ohne zusätzliche Codeentwicklung auf niedrigem Level einarbeiten. Dies steht im Gegensatz zu dem Herkömmlichen (Stand der Technik), wobei ein Einsatz eines neuen Resourcen-Datensatztyps beträchtliches Programmierdesign auf niedrigem Level und Codierung erfordert, und erforderlich macht, dass ein neuer Server binär auf allen anwendbaren Maschinen einsetzbar ist. Außerdem, kombiniert mit kontextspezifischen Antworten (oben) können Domänenadministratoren ihre eigenen „lokalen" Typen festlegen, die spezifisch zu den Antworten sind, welche für ihre DNS-Domäne zurückgegeben werden.
• Fähigkeit zur Entfaltung und Beibehaltung eines Stand-der-Technik-Datenmanagementdienstes basierend auf Handels- bzw. Gebrauchsimplementationen von Core-Datenbanktechnologien. Die konventionellen (Stand der Technik) Systeme für Domänennamen-Systemmanagement setzen integrierte Ad-Hoc-Implementationen von Datenbanktechnologie ein, welchen es an fortschrittlichen Datenbankeigenschaften mangelt, und machen es schwierig, neue Eigenschaften basierend auf Datenbanktechnologiefortschritten anzuwenden.

Datenbanklager-Synchronisation
Das DNS-System gemäß der vorliegenden Erfindung hält eine Datenkonsistenz zwischen vielen redundanten Servern (z. B. DNS₁, DNS₂, ..., DNS_n in 1) aufrecht, indem Änderungen an den gesteuerten bzw. gehandhabten Daten unter Verwendung einer Transaktionsverarbeitung auf Datenbanklevel weitergeleitet werden. Dies weist Vorteile gegenüber herkömmlichen (Stand der Technik) Konsistenzmechanismen auf, welche auf Transaktionen auf einem Anwendungslevel basieren. Diese Vorteile umfassen Folgendes:

• Virtuelle unmittelbare Weiterleitung von Änderungen an Domänennamen-Systemdaten. Dies ist besonders wichtig, wenn unrichtige Daten korrigiert werden müssen, oder wenn sich kritische Domänendaten häufig ändern und Veränderungen schnell erkennbar sein müssen. Zum Beispiel besitzt eine der am häufigsten geänderten Zonen ".COM" auch die größte Anzahl an Datensätzen. Unter Verwendung von herkömmlichen (Stand der Technik) Systemen ist ".COM" auf historische Weise auf periodische Zwölf-Stunden-Aktualisierungen bzw. – Updates eingeschränkt. Unter Verwendung des DNS-Systems der vorliegenden Erfindung werden Änderungen an ".COM" üblicherweise innerhalb von 5 bis 15 Minuten weitergeleitet.
• Fähigkeit zur Akzeptanz und Weiterleitung von Änderungen an Domänennamen-Systemdaten von vielen Servern, und folglich die Fähigkeit dazu, Datenmanagement verlässlicher mit besserer Systemverfügbarkeit und Leistungsfähigkeit durchzuführen. Dies ist im Gegensatz zu herkömmlichen (Stand der Technik) Systemen, welche nicht die erforderlichen Konfliktauflösungsmechanismen aufweisen, um viele Quellen von Aktualisierungstransaktionen zu unterstützen.

Einsatz von Einzel-IP-Adressen für nachgebildete Server
Global verteilte Servernachbildungen (z. B. DNS₁, DNS₂, ..., DNS_n) schaffen die Zuverlässigkeit, den Durchsatz und die geringe Verzögerung, welche erforderlich sind, um einen breiten kommerziellen Dienst zu skalieren bzw. maßstäblich zu ändern. Die Server sind zusammen gebunden, indem fortschrittliche Internet-Routing- Mechanismen benutzt werden, welche auf den Zustand von individuellen Servernachbildungen reaktionsfähig sind. In bevorzugten Ausführungen teilt sich jedes DNS-System gemäß der vorliegenden Erfindung eine gemeinsame IP-Adresse und unterstützt eine Namenservernachbildung. Die geteilte IP-Adressen werden in das Internet-Routing-Mesh von jedem Server so eingegeben, dass Internet-Router IP-Pakete zu dem nächstgelegenen topologischen gerichtet werden. Jede Servernachbildung wird auf korrektes Verhalten hin überwacht, und die IP-Route wird zurückgezogen, wenn der Server nicht länger auf DNS-Anfragen antwortet. Diese Mechanismen schaffen die folgenden Vorteile:

• Benutzer-DNS-Anfragen werden zu der nächstliegenden DNS-Nachbildung gerichtet, was die aufgetretene Verzögerung für DNS-Auflösung minimiert.
• Durchgangsserver und Netzwerkfehler sind für eine Benutzer-DNS-Anfrage und Anwendungstransaktion transparent. Server, die nicht erreichbar oder funktional sind, sind unsichtbar, und DNS-Anfragen kommen bei dem nächsten funktionalen Server an, ohne dass sie die Verzögerung für Standard-DNS-Unterbrechung und Rückübertragung erfahren.
• Das DNS-System erlangt Benutzer-Proximitydaten basierend auf der Servernachbildung, welche die Benutzer-DNS-Anfrage empfängt. Diese Daten können benutzt werden, um auf Proximity basierende Antworten zu liefern, um Benutzer zu nahegelegenen Anwendungsservern zu leiten.

IMPLEMENTIERUNG
DIE DATENBANK
Dieser Abschnitt beschreibt das einzige Datenbankschema der Datenbank 102.
ÜBERSICHT
Die Datenbank gemäß bevorzugter Ausführungen dieser Erfindung ist entsprechend dem folgenden einzigen Datenbankschema organisiert und strukturiert. Das Datenbankschema weist vierzehn (14) Tabellen auf. Nur drei (3) dieser Tabellen beinhalten aktuelle Daten (d. h. DNS & Kontakt), die anderen elf (11) Tabellen werden gebraucht, um die Daten zu steuern. Das Schema ermöglicht jemandem Management bzw. Verwaltung, auf welche Daten er Zugriff hat, wie auf diese zugegriffen werden kann, wer neue Daten erzeugen kann, und wie sie für Gebrauch des Systems in Rechnung gestellt werden können.
Die von dem DNS-Server 100 verwalteten Daten sind (a) Kontaktdaten, (b) Zonendaten, und (c) Resourcen-Datensatz-Informationen. Obwohl Zonen und Resourcen-Datensätze miteinander in Beziehung stehen, muss das System die Fähigkeit besitzen sie getrennt zu verwalten. Der Grund dazu besteht darin, dass auf unterschiedliche Benutzer gezielt ist, von denen einige den Server 100 zur Verwaltung einer ganzen Zone für sie benutzen möchten, und von denen einige gerade individuelle Resourcen-Datensätze (in einer besonderen Zone) eingeben wollen.

Für jedwede Daten, die in das System eingegeben werden können, gibt es zwei eingeschlossene Zugriffs-Steuermechanismen: (1) einen Mechanismus, welcher spezifiziert, ob die Posten in das System eingegeben (erzeugt) werden kann, und (2) einen Mechanismus, welcher spezifiziert, wie auf die Posten zugegriffen werden kann. TABELLENLISTE UND ZUSAMMENFASSUNG

Tabellenname	Beschreibung
LOGIN	Benutzerdaten (zur Einrichtung einer Identität auf dem System)
SYS_MGMT	Beschreibt, wie das DNS-System verwaltet wird (z. B. wer neue Zonen erzeugen kann, Rechnungsverfahrensweise, etc.)
RRJUMBO	Kombinierter Resourcen-Datensatz-Index (RR, Resource Record) und Daten
CONTACT	Leute/Rolle/Organisation (ähnlich whois)
CONTACT_ASSOC	Gibt eine Verbindung zwischen Kontaktdaten und anderen Daten/Posten (z. B. Zonen oder RRs) an
ZONE	Basis-mgmt-Daten für einen zugehörigen Satz von DNS-RRs
ZONE_INTERFACE	Liste von „auswärtigen" Servern, mit denen das System sprechen muss (Hauptserver/Master ODER Sekundäre, die aktualisiert werden)
ZONE_CNTL	Sehr ähnlich den Daten in einem SOA-Datensatz
ZONE_MGMT	Zonenbesitzer beschreibt, wie Zone benutzt werden kann (z. B. wer neue RRs erzeugen kann, Rechnungsverfahrensweisen, etc.)
ZONE_SERVERS	Aufrechterhaltung einer Liste von Zonen im System, und welche IP-Adressen Zonentransfer ausführen können
RR_MGMT	Gibt Logins an, die spezifische RRs (Resource Records bzw. Resourcen-Datensätze) modifizieren können
BillingPolicy	Regeln/Verfahrensweisen, die Besitzer zur Inrechnungsstellung des Gebrauchs für andere aufgestellt haben
BillingInfo	Aktuelle Rechnungsdaten für ein besonderes Objekt (abgeleitet von der BillingPolicy des Besitzers)
USAGE_HISTORY	Enthält vergangene Benutzungsdaten (um Rechnungszugehörigkeiten zu beantworten)
IPV4RANGE	Beschränkt (oder gestattet) Zugriff pro Quellen-IP-Adresse

TABELLENSCHEMA
Dieser Abschnitt beschreibt, welche Daten sich in den Tabellen befinden und gibt in einigen Fällen die Formate und Größen der in einigen Ausführungen der vorliegenden Erfindung benutzten Daten an.
Die LOGIN-Tabelle beschreibt Identität innerhalb eines DNS-Systems der vorliegenden Erfindung. Die Tabelle umfasst Daten, wie ein Benutzer einem System gegenüber seine Berechtigung nachweist. Die LOGIN-Tabelle wird über login/Passwort, X.509, PGP, DNSSec, etc. aufgestellt.

Die folgende Tabelle fasst die Felder der LOGIN-Tabelle zusammen.

LOGIN
Feld	Beschreibung	Beziehung zu anderen Tabellen
Id	Interner dbase bzw. Datenbankindex/zeiger	Erscheint in anderen Tabellen und gibt an, dass diese Benutzer einigen Anspruch/Zugriff auf das Objekt haben
Email	Kontaktdaten
Ipaddr	Beschränkt Logins auf einen spezifischen IP-Bereich	Index zur IPV4RANGETabelle
x509id	ID für primäres Berechtigungsnachweisverfahren
Username	Backup-Login-Name
Password	Backup-Passwort
Passques	Vom Benutzer gelieferte Frage nach verlorenen Daten
Passansw	Vom Benutzer gelieferte Antwort für verlorene Daten

Die SYS_MGMT-Tabelle (unten beschrieben) stellt eine Schablone über Benutzung, Zugriff, usw. dar. Sie liefert Informationen darüber, wie das System verwaltet wird; wer zugreifen, modifizieren, neue „Objekte" erzeugen kann; und Informationen darüber, wie Benutzern ein Zugriff in Rechnung gestellt wird. Die SYS_MGMT-Tabelle ermöglicht es dem DNS gemäß der vorliegenden Erfindung auf unterschiedliche Wege eingesetzt zu werden (z. B. geschlossener Zugriff bei großen Firmen gegenüber offenem ISP-Zugriff). Einige bevorzugte Ausführungen gestatten einen Einsatz von zwei zu erzeugenden Objekttypen, nämlich Kontakte und Zonen. Beide können von irgendjemandem erzeugt werden. Kontakte können ohne Berechnung erzeugt werden; Zonen können Berechnungen auslösen oder nicht (vielleicht pro Benutzer).

SYS_MGMT
Feld	Beschreibung	Beziehung zu anderen Tabellen
Objtype	Welcher Typ von Objekten erzeugbar ist
Access	Art (erzeugen oder lesen)
Login	(Login ID oder „IRGENDEINER"	ID in LOGIN-Tabelle über wer erzeugen kann
Ipaddr	Beschränkt/Gibt Zugriff durch Ipsrc Addr
Billing	Spezifiziert, wie Zugriff zu berechnen ist	Index in BILLING-Tabelle

Die RRJUMBO-Tabelle stellt DNS-Resourcen-Datensatz-(RR-)Informationen dar. Diese Tabelle ist für den „Index" oder „Lookup" der eingehende Anfrage vorgesehen und enthält Spalten für unterschiedlichen Teile eines RR-Datenabschnitts. Resourcen-Datensätze sind in RFC 1035 [Network Working Group Request for Comments: 1035, P. Mockapetris, ISI, November 1987] festgelegt, welche hierin durch Bezugnahme aufgenommen ist.

RRJUMBO
Feld	Beschreibung	Beziehung zu anderen Tabellen
Id	Interne dbase bzw. Datenbank-ID	Referenziert durch andere Tabellen
Active	Gibt an, dass RR „aktiv" ist (z. B. bezahlt ist)
Dead	Gibt an, dass „machine" inaktiv ist
Zone	Zonenmitgliedschaft-Identifizierer	Gibt an, dass RR mit ZONE-Tabelle verbunden ist
Dname	Domänenname (z. B. „www.ultradns.com")
Lname	Niedrigerer Fall von Dname zur Optimierung von Lookups
Type	RR-Typ
Class	RR-Klasse
Servers	Gibt an, welcher Server besonderen RR zurückgibt
Time	Gibt an, dass Zeitrahmen RR zurückgegeben wird

RRJUMBO
Feld	Beschreibung	Beziehung zu anderen Tabellen
ipv4addr	Index in IPV4RANGE-Tabelle	Index in IPV4RANGE-Tabelle (zur Spezifizierung per Ipaddress RRs)
ip_low	Einfache (Hochleistungs-)IP-Quellen-Adressen-Spezifikation
ip_high	Einfache (Hochleistungs-)IP-Quellen-Adressen-Spezifikation
ip_bits	Einfache (Hochleistungs-)IP-Quellen-Adressen-Spezifikation
Create_who	Login-ID des Datensatzerzeugers	Gibt erzeugten Datensatz durch LOGIN-Tabelle an
Create_ip	IP-Adresse des Erzeugers
Create_date	Wann erzeugt
Update_who	Login-ID letzte Modifizierung	Login-ID des letzten Updates
Updaten_when	Letzte Modifikationszeit
Billing	Index zu BillingInfo	Rechnungsinformationen verbunden mit RR
Readcnt	Kürzliche RR-Auslesungen
Readsince	Startzeit des Lesezählers
Writecnt	Kürzliche RR-Änderungen
Writesince	Startzeit des Schreibzählers
Tt1	Resourcen-Datensatz TTL (Lebensdauer) (Sekunden)
f1	RR-Datenfeld #1
F2	RR-Datenfeld #2
F3	RR-Datenfeld #3
F4	RR-Datenfeld #4
F5	RR-Datenfeld #5
F6	RR-Datenfeld #6
F7	RR-Datenfeld #7
F8	RR-Datenfeld #8
ref1	Dname-Referenz für „zusätzliche RRs

Ein „DNS-Lookup" in der RRJUMBO-Tabelle benutzt (vergleicht) die folgenden sechs Werte, um den angeforderten DNS-Resourcen-Datensatz zu finden:

1. Domänenname (aus dns-Anfragepaket)
2. dns-Typ (aus dns-Anfragepaket)
3. dns-Klasse (aus dns-Anfragepaket)
4. Server-ID (Name/ID des die Anfrage beantwortenden Servers)
5. Zeit (aktuelle Tageszeit im Server)
6. Quellen-IP-Adresse (aus dem IP-Paket)

Es ist zu beachten, dass der Gebrauch der RR-Datenfelder f1...f8 von dem RR-Typ abhängig ist (z. B. MX-Datensätze werden f1 und f2 benutzen, A-Datensätze werden nur f1 verwenden, und SOA-Datensätze werden f1–f7 benutzen).
Die RRJUMBO-Tabelle wird benutzt, um Daten für vielerlei Zwecke zu speichern: zusätzlich zur Speicherung von „lebenden" Domänen-Datensätzen werden „Schablonen-" Datensätze gespeichert, welche die Mechanismen zur Bereitstellung von konfigurierbaren DNS-Datensätzen verkörpern. Jeder DNS-Resourcen-Datensatztyp wird durch einen oder mehr Schablonen-Datensätze in der RRJUMBO-Tabelle dargestellt, welche das Format und die Struktur eines jeden Datensatztyps spezifiziert.

Die CONTACT-Tabelle enthält Informationen über eine Person, Rolle oder Organisation (d. h. dies sind grundlegend „whois"-Daten). Es ist zu beachten, dass die Daten in der CONTACT-Tabelle nichts mit einem System-Login zu tun haben.

CONTACT
Feld	Beschreibung	Beziehung zu anderen Tabellen
Id	Interner dbase bzw. Datenbankindex
Order	Reihenfolgeinformationen für zugehörige Datensätze
Type	Name, Telefon, Fax, E-Mail, etc. (siehe Liste unten)
Information	Verbundene Informationen (z. B. Name: Steve Hotz)
Anonacl	Leseerlaubnis für Feld (z. B. Telefonnummer nicht ausgeben)
ipaddr	IP-Adresse basierend auf Lesebeschränkungen/-erlaubnisse	Index in IPV4RANGE-Tabelle

Die TYPE-Werte für obiges „type"-Feld (ähnlich zu RIPE-181) weisen Folgendes auf:

• Name
• E-Mail
• E-Mail-Änderung
• Telefon
• Telefon-Änderung
• FAX-Nr.
• Nic-hdl
• Nic-hdl-Änderung
• Adresse (mehrzeiliger Textstring)
• Quelle (im Fall, dass Informationen von einem anderen Ort kamen)
• Datenerstellung
• Datenaktualisierung

Die CONTACT_ASSOC-Tabelle gibt Verbindungen zwischen Kontaktdaten und weiteren Daten/Posten (z. B. Zonen oder RRs) an.

CONTACT_ASSOC
Feld	Beschreibung	Beziehung zu anderen Tabellen
Id	Name/ID eines Objekts (z. B. „ultradns.com")	Interner Identifizierer von DNS-Datenposten (z. B. Kontakt, Zone oder RR)
Objtype	{System, Zone, Datensatz}
contact	ID von CONTACT-Daten
Type	{admin, tech, billing, registration}
Public	{ja, nein} Lesezugriff für allgemeine Öffentlichkeit

Die ZONE-Tabelle gibt Basisinformationen über eine Gruppe von in Beziehung stehenden RRs.

ZONE
Feld	Beschreibung	Beziehung zu anderen Tabellen
Zone	Name der Zone (z. B. „ultradns.com")	Jede Spalte in dieser Tabel le bezieht sich auf andere Tabellen.
Owner	LOGIN-ID des Zonenbesitzers
Billing	Wie die Zone berechnet wird (BillingInfo)
zonecnt1	ZONE_CRTL-ID für interne Konsistenz

Die ZONE_INTERFACE-Tabelle spezifiziert externe Server (d. h. Server, die keine Ausführungen der vorliegenden Erfindung sind), welche entweder als Haupt- bzw. Primärserver/Master benutzt oder als Zweiter/Slave aktualisiert sein müssen.

ZONE
Feld	Beschreibung	Beziehung zu anderen Tabellen
Zone	Zone, welche aktualisiert/transferiert wird	Bezieht sich auf Zonen-Name in zahlreichen Tabellen
inout	{in, out}
srvname	Name des Servers
Srvip	IP-Adresse des Servers
ctr1	ZONE_CTRL-ID für einen Datensatz steuernde Frequenz bzw. Häufigkeit	Referenz in ZONE_CTRL- Tabelle
view_ip	Falls Multi-Dimensions-Datensätze, Momentaufnahme dieser IP
view_time	Falls Multi-Dimensions-Datensätze, Momentaufnahme zu diesem Zeitpunkt
view_srv	Falls Multi-Dimensions-Datensätze, Momentaufnahme für Server

Die ZONE_CTRL-Tabelle enthält Zonen-Steuerdaten, ähnlich zu SOA-Parametern. Diese Tabelle wird für Datenbankkonsistenz benutzt (kann nicht mit internem Oracle gebraucht werden, kann jedoch ein Interface mit externen Servern spezifizieren).

ZONE_CRTL
Feld	Beschreibung	Beziehung zu anderen Tabellen
Id	Interner Identifizierer	Referenziert durch andere Tabellen
Serial
Refresh
Retry
Expire
Mincache
Flags	Notify bzw. Meldung ist eingeschaltet

Die ZONE_MGMT-Tabelle weist Informationen darüber, wie eine besondere Zone verwaltet wird; wer zugreifen, modifizieren, neue „Objekte" erzeugen kann, und Informationen darüber auf, wie der Benutzer für Zugriff rechnungsmäßig belastet wird.

ZONE_MGMT
Feld	Beschreibung	Beziehung zu anderen Tabellen
Zone	Verwaltete Zone	Bezieht sich auf verschiedene Tabellen, die Zonendaten aufweisen
login	Login-ID mit Zugriff (oder „JEDER")	LOGIN-Tabelle für denje nigen, der Zugriff hat
ipaddr	Quellen-IP-Adressenbeschränkungen	IPv4Range-Tabelle für src- Adressenzugriff
Billing	Rechnungsverfahrensweisen in Verbindung mit Zugriff	Index in BillingPolicy- Tabelle
rr1ist	Bit-Map von RR-Typen, die erzeugt werden können
Mods	Gestattet Zonenmodifikationen: • Kann über dynamisches Update modifizieren • Modifiziert alle RRs • Modifiziert alle Kontaktdaten • Modifiziert Zonendaten • Modifiziert zone_mgmt-Daten
Features	• Bit-Map von erlaubten Merkmalen • Festlegen neuer Typen • Multidimensionales Erzeugen • Kann RRs erzeugen, die dynamische Updates gestatten • Kann RRs unter Verwendung dynamischer Updates erzeugen • Dead-Machine-Überwachung • Weiteres
Flags	Zeigen weitere Aktionen in Verbindung mit Update/Zugriff an • Anzeigen von geforderten Informationen pro Datensatz (z. B. Kontakt) • Besitzer fordert Änderungsmitteilung an (via E-Mail)

Die ZONE_SERVERS-Tabelle ist eine Hilfstabelle, welche Zonen auflistet, für welche das System verantwortlich ist. Diese Tabelle wird von Servern benutzt, um Zonen aufzufinden, für welche sie maßgebend sind.

ZONE_SERVERS
Feld	Beschreibung	Beziehung zu anderen Tabellen
Zone	Zonenname	Zonenname bezieht sich auf viele Tabellen
Server	Serveraufbewahrungs-/haltezone
xferip	IPV4RANGE gestattete Zonentransfers	IPv4Range-Index

Die RR_MGMT-Tabelle stellt eine Zugriffsliste für spezifische RRs bereit.

RR_MGMT
Feld	Beschreibung	Beziehung zu anderen Tabellen
Rrod	Rrindex-ID	Jede Spalte (außer Flags) bezieht sich auf Spalten in anderen Tabellen
Login	Login zugelasse für Änderungen (oder „JEDER"
ipaddr	src-IP-basierte Zugriffsbeschränkungen
Flags	Zugriff gestattet (anfänglich, alle oder nichts)

Die BillingPolicy-Tabelle (aufgestellt vom/n Besitzer/n eines Systems oder einer Zone) enthält Informationen darüber, wie eine Systembenutzung in Rechnung zu stellen ist. Der Systembesitzer stellt dies vorzeitig auf, und das System erzwingt die verschiedenen Rechnungsstellungsverfahren.

BillingPolicy
Feld	Beschreibung	Beziehung zu anderen Tabellen
billp_id	Interner dbase bzw. Datenbankindex	Referenziert durch andere Tabellenspalten
what	Zone, Kontakt, Dname, RR-Type(n), Merkmal
type	einmalig, lesen, schreiben, Zeit <feature name>
Unit	<count> bzw. <zählen> für lesen/schreiben Tag/Woche/Monat/Jahr pro Zeit oder Merkmal
Amt	Betrag (in Dollar)
cnd_type	Lesen oder Schreiben [muss größer sein als]
end_unit	Zählung [per]
cnd_time	Zeiteinheit (Tag/Woche/Monat/Jahr)
intro_time	Tage vor Rechnungsstellung
period	Jährlich/monatlich/Auswahl
year_discount	Kann einen (prozentualen) Rabatt für jährliche Rate anbieten

Jede Zone kann mehr als eine Verfahrensweise spezifizieren. Zum Beispiel:

<what> <type> <unit> <amt> <cond>

Type > Unit Time

Zone 1-mal 29.99

Zone Zeit Jahr 9.99

Zone Schreiben 1 1.00 Schreiben > 10 Monat

Merkmal Dyn_Upd Monat 1.99

Die BILLINGINFO-Tabelle enthält Daten darüber, wem und wann für Benutzung eine Rechnung auszustellen ist.

BILLINGINFO
Feld	Beschreibung	Beziehung zu anderen Tabellen
bill_id	Interne dbase bzw. Datenbankindex	Referenziert durch andere Tabel lenspalten
who_id	Rechnungs-Kontaktindex	Referenz zur CONTACT-Tabelle
Method	Kreditkarte, USMail, E-Mail
billp_id	Referenz zur BillingPolicy-Tabelle
Credcard	Kreditkartenkonto
expire	Kreditkartenauslaufdatum
card_id	Rechnungsadresse für Kreditkarte (falls unterschiedlich zu who_id)	Referenz zur CONTACT-Tabelle
billp_id	Index zum BillingPolicy-Datensatz
Create_date	Wenn Rechnungsdatensatz erzeugt wurde
next_date	Nächstes Statement-Datum

Die USAGE_HIST-Tabelle enthält historische System/Daten-Benutzerinformationen. Sie kann an verschiedene Objekte anbringen: RRdata, Zone, Contact, etc. (Einige bevorzugte Ausführungen bringen sie an RRs an)

USAGE_HIST
Feld	Beschreibung	Beziehung zu anderen Tabellen
Id	Interne dbase bzw. Datenbank-ID des verfolgten Objekts	Bezieht sich auf ID-Feld anderer Tabellen
Objtype	RR/Zone/Kontakt/andere	Legt fest, welche „andere Tabelle"
Access	Lesen/Schreiben/andere
start	Beginn einer Periode (Sekunden seit einem Zeitabschnitt)
End	Dauer einer Periode (z. B. in Sekunden)
cnt	Anzahl von Zugriffen

Vorzugsweise ist Gebrauchs-Logging (a) nur eingeschaltet für einige Datensätze, und (b) könnte ein „Premium-Dienst" sein. Muss „aktuellen" Gebrauch für Rechnungsstellung beibehalten, aber dieses Merkmal ist „eingeschaltet".

Die IPv4Range-Tabelle enthält CIDR-bearbeitete Subnet-Masken, die hauptsächlich für auf Adressen basierender (d. h. schwacher) Echtheit bzw. Authentifizierung verwendet werden. Diese Tabelle wird (a) für Ausgabe von RRs basierend auf srcipaddress und (b) einfache Zugriffssteuerung für Updates von Daten (z. B. unter Verwendung von dynamischen Updates wie implementiert) benutzt.

IPv4Range
Feld	Beschreibung	Beziehung zu anderen Tabellen
Ipid	Index der IP-Bereichs-spec	Diese Tabellen-ID dient als Index und erscheint in anderen Tabellen (sie gibt an, ob ein Zugriff von spezifischen Quellen-IP-Adressen gestattet ist)
Flag	Flag, welches erlaubt/verboten anzeigt
bits	Anzahl von Bits in Maske
Low	Niedrigster Adresswert
High	Höchster Adresswert

Beispiel

listid	Flag	bits	iprangelow	Iprangehigh
#1	Verbieten	0	0x00000000	0xffffffff
#1	Erlauben	16	0x80090000	0x8009ffff
#2	Erlauben	0	0x00000000	0xffffffff
#2	Verbieten	16	0xa0070000	0xa007ffff
#2	Verbieten	16	0xa0090000	0xa009ffff
#3	Verbieten	0	0x00000000	0xffffffff
#3	Erlauben	16	0xc9140000	0xc914ffff
#3	Verbieten	24	0xc9142800	0xc91428ff
#3	Verbieten	24	0xc9142a00	0xc9142aff

#1 erlaubt kleine Zahl von Adressen;
#2 verbietet kleine Zahl von Adressen;
#3 erlaubt alle im Bereich, mit Ausnahmen;

Der folgende Abschnitt stellt die Datenbank-Feldformate und -größen für eine bevorzugte Ausführung der vorliegenden Erfindung bereit. Einige der Felder besitzen gemeinsame Größen:
256 char = dnames
10 num = 32-Bit-Integer (z. B. IPv4addr und Zeit in Sekunden)
14 num = interne Identifizierer

LOGIN
Id	num 14
Email	vch 256
Ipaddr	num 14	null-ok
x509id	vch 256
Username	vch 64
Password	vch 32
Passques	vch 80
Passansw	vch 80

SYS_MGMT
objtype	vch 16
access	vch 16
login	Num 14
ipaddr	Num 14	null-ok
billing	Num 14	null-ok

RRJUMBO
id	num 14
active	num 1
dead	num 2
zone	vch 256
dname	vch 256
type	vch 16
class	vch 16
servers	vch 32	null-ok
time	vch 168	null-ok
ipv4addr	num 14	null-ok
ip_low	num 10	null-ok
ip_high	num 10	null-ok
ip_bits	num 3	null-ok
create_who	num 14
create_ip	num 10
create_date	num 10
update_who	num 14
update_when	num 10
billing	num 14	null-ok
readcnt	num 8	null-ok
readsince	num 10	null-ok
writecnt	num 8	null-ok
writesince	num 10	null-ok
TTL	num 10
f1	vch 1024
f2	vch 1024	null-ok
f3	vch 256	null-ok
f4	vch 256	null-ok
f5	vch 256	null-ok
f6	vch 256	null-ok
f7	vch 256	null-ok
f8	vch 256	null-ok
reff	vch 256	null-ok

CONTACT
id	num 14
order	num 2
type	vch 16
info	vch 168
anonac1	vch 8	null-ok
ipaddr	num 14	null-ok

CONTACT_ASSOC
id	num 14
objtype	vch 16
contact	num 14
type	vch 20	null-ok
public	vch 8

ZONE
zone	vch 256
owner	num 14
billing	num 14	null-ok
zonecnt1	num 14

ZONE_INTERFACE
zone	vch 256
inout	vch 8
srvname	vch 256	null-ok
svrip	num 10	null-ok
ctr1	num 14
view_ip	num 10	null-ok
view_time	num 3	null-ok
view_srv	num 3	null-ok

ZONE_CNTL
id	num 14
serial	num 10
refresh	num 10
retry	num 10
expire	num 10
mincache	num 10
flags	vch 8	null-ok

ZONE_MGMT
zone	vch 256
login	num 14	null-ok
ipaddr	num 14	null-ok
billing	num 14	null-ok
rrlist	vch 256
mods	vch 16

ZONE_MGMT
features	vch 16	null-ok
flags	vch 8

ZONE_SERVERS
zone	vch 256
server	vch 256
xferip	num 14	null-ok

RR_MGMT
rrid	num 14
login	num 14	null-ok
ipaddr	num 14	null-ok
flags	vch 8	null-ok

BILLINGPOLICY
billp_id	num 14
what	vch 32
type	vch 32
unit	vch 16
amt	num 8
cnd_type	vch 8	null-ok
cnd_unit	num 8	null-ok
cnd_time	vch 8	null-ok
intro_time	num 6
period	vch 8
year_discount	num 4

BILLINGINFO
billi_id	num 14
who_id	num 14
method	vch 12

BILLINGINFO
credcard	num 16	null-ok
expire	vch 7	null-ok
card_id	num 14	null-ok
billp_id	num 14
create_date	num 10
next_date	num 10

USAGE_HIST
id	num 14
objtype	vch 16
access	vch 16
start	num 10
end	num 10
cnt	num 12

IPv4RANGE
ipid	num 14
flag	num 2
bits	num 2
low	num 10
high	num 10

DESIGNAUSWAHLEN
Wahrscheinlich ist die am geringsten offensichtliche Designauswahl der Weg, dass CONTACT ausgelegt wird. Was offensichtlicher/natürlicher sein würde, ist eine Tabellenzeile zu haben, welche jeden besonderen Kontaktdatensatz darstellt. Dieses Design zerbricht jedoch Kontaktdaten in mehrfache Felder und stellt jedes Feld als eine Zeile in einer Datenbank dar. Dieses Verfahren ist flexibler (die gegebene flexible Natur der Daten) und unterstützt die Assoziation und den wirksamen Lookup von „AC-CESS POLICY" auf individuelle Felder (z. B. um zufälligen Leuten, die auf einen CONTACT-Datensatz blicken, es zu ermöglichen eine E-Mail-Adresse zu sehen, aber keine mit dem Datensatz verbundene Telefonnummer).
DAS SQL-INTERFACE
Das SQL-Interface 104 nimmt Anfragen/Anforderungen für Domänennamen/adressen-Auflösungen an und gibt die geeignete Adresse und weitere Daten wieder zurück. Das SQL, welches das Interface 104 in einer bevorzugten Ausführung implementiert, ist unten aufgelistet (in der Tabelle mit dem Titel SQL Anfrage).
BEISPIEL
Hier wird eine Musteranfrage von einem Benutzer 108 des DNS 100 gemäß der vorliegenden Erfindung gemacht. Die Anforderung wird von dem Anfrage-Mechanismus 106 verarbeitet, welcher das SQL-Interface 104 benutzt, um auf die Datenbank 102 zuzugreifen.
Anfrage: a.b.c.d.wonk.com <type>
wobei das System weiß, dass es „wonk.com.ZONE" aufweist.

Im schlimmsten Fall muss das System dann die folgenden Anfragen an die Datenbank 102 stellen:

a.b.c.d.wonk.com.	<type>	## gibt gewöhnlich ANSWER zurück
b.c.d.wonk.com.	NS	## gibt gewöhnlich AUTH-Daten zurück
a.b.c.d.wonk.com.	NS	## gewöhnlich Subdelegation anzeigen
*.b.c.d.wonk.vom	<type>
b.c.d.wonk.com.	NS
*.c.d.wonk.com	<type>
c.d.wonk.com	NS
*.d.wonk.com	<type>
d.wonk.com	NS
*.wonk.com	<type>

Diese Erfindung weist eine Anfragestrategie auf, welche die durchschnittliche Anzahl von Datenbankanfragen, die zur Vervollständigung einer DNS-Anfrage erforderlich sind, signifikant reduziert.
Es gibt im Wesentlichen zwei übliche Fälle:

(1) keine Subdelegation – Anfrage erhält eine einfache Antwort für foo.wonk.com
(2) das System wird damit enden, dass es über Subdelegation berichtet – Ausgeführte Anfrage für a.b.c.d.wonk.com erhält NS für d.wonk.com

In beiden der oben angeführten gewöhnlichen Fälle ist die Anwort „dname" wahrscheinlich eine Komponente länger als der Zonenname. Somit prüft das System dies, bevor es die Anfrage ausführt (d. h. das System will nicht für „a.b.c.d.wonk.com", „b.c.d.wonk.com" und „c.d.wonk.com" anfragen, um gerade schließlich zu sagen, dass die Delegation bei „d.wonk.com" gemacht wurde).
Folglich kann die folgende Anfrageoptimierung (in dem Anfrage-Mechanismus 106) verwendet werden:
Wenn der angeforderte Name eine Komponente länger ist als ein Zonenname, dann suche eine schnelle Antwort.
Dies kann geschrieben werden als:
Wenn ein langer Anforderungsname vorliegt, prüfe zuerst eine kürzeste Delegation. Wenn zum Beispiel der Anforderungsname „a.b.c.d.wonk.com" lautet, prüfe, ob „d.wonk.com" NS aufweist.
Wenn keine Optimierung Auswirkungen gezeigt hat, dann beginne mit der ursprünglichen Frage.
Wenn keine Antwort gefunden wurde, dann durchlaufe die Schleife und suche NS-Delegationen.
Es wurde keine Delegation gemacht
Nun durchlaufe die Schleife für „*"-Datensätze.
BEISPIEL
Gib die Beispielanfrage „foo.bar.wonk.com. MX", rufe folgende SQL (Tabelle XX) mit folgenden Variablen auf:
req.name 1 = „foo.bar.wonk.com"
req.name2 = „*.bar.wonk.com"
req.name3 = „bar.wonk.com"
req.type = 15 (dies ist der MX-Typ)
req.class = 1 (dies ist die IN-Klasse)
req.time = <current time>
req.server = <server ID#>
req.ipaddr = <incoming pkt IP source>
WEITERE MERKMALE
Aufbau eines modularen Systems gestattete es, zusätzliche Mechanismen leicht in das System einzubringen, was als Grundlage für neue Eigenschaften/Verwendungen dienen kann.
KONFIGURIERBARE RESOURCEN-DATENSATZTYPEN
Das DNS gemäß einigen Ausführungen der vorliegenden Erfindung weist über dreißig (30) festgelegte Resourcen-Datensatztypen auf, welche Datenformate/felder zur Verwendung durch unterschiedliche Anwendungen bereitstellen; aktuelle Implementationen festigen die Typfestlegungen. Somit bietet die vorliegende Erfindung Benutzern die Fähigkeit zum dynamischen Konfigurieren von RR-Typen, um es zu ermöglichen, dass vom Verzeichnis freigegebene Anwendungen eingesetzt und innerhalb kurzer Zeitrahmen geprüft werden.
KONTEXTSENSITIVE (ANFRAGESPEZIFISCHE) ANTWORTEN
In der Zusammenfassung ordnet ein Verzeichnisdienst eine eingehende Anforderung (Schlüssel, Key) einer Anfrage einer ausgehenden Antwort (datenindexiert durch den Schlüssel) zu. Unter Verwendung eines relationalen Datenbankmodells liefert die vorliegende Erfindung einen wirksamen Mechanismus zur Hinzufügung weiterer Komponenten zu dem Lookup-Key. Bei dem DNS-Beispiel kann eine unterschiedliche Antwort in Abhängigkeit von verschiedenen Kontextdaten gegeben werden: von dem Paket (IP-Adresse), von der Maschine (lokale Zeit) und vom globalen System (welcher Serverort). Somit kann das System zum Beispiel unterschiedliche Antworten zu unterschiedlichen Tageszeiten oder zu unterschiedlichen geografischen Regionen bereitstellen.
DYNAMISCHER DATEN-CACHE
In einigen Ausführungen beinhaltet der DNS-Server 100 einen dynamischen „load-on-demand"-Cache-Algorithmus, welcher in signifikanter Weise eine Leistungsfähigkeit verbessert, indem die Datenmenge reduziert wird, welche aus der Datenbank 102 abgerufen werden muss.
Wenn ein eingehende Anfrage empfangen wird, wird der Server 100 zuerst versuchen, die Antwort in dem Daten-Cache 110 zu finden. Wenn die Antwort vorhanden und frisch ist, wird die Antwort direkt von den Cache-Daten, die in dem Daten-Cache 110 gespeichert sind, gesendet. Wenn die Antwort in dem Cache 110 existiert, aber veraltet ist, oder wenn die Antwort in dem Cache 110 noch nicht vorhanden ist, werden die Daten aus der Datenbank 102 beschafft, in die Antwort übertragen und dann zu dem Cache 110 hinzugefügt oder in diesem aktualisiert. In einigen Ausführungen wird der Cache in einem Zustand beibehalten, der als „Most-Recently-Used" bzw. „soeben verwendet" bezeichnet wird, um Suchzeiten zu optimieren und Cache-Management zu erleichtern.
Posten bzw. Objekte in dem Cache 110 besitzen eine maximale Lebensdauer, die von der Lebenszeit (TTL, Time To Live) des niedrigsten Datensatzes (RR, Resource Record) in der vollständigen Antwort bis zu dem maximalen Cache-Lebenszeitwert reicht, welche in dem Server als Ganzes konfiguriert ist. Für Datensätze, die sich häufig ändern, kann der TTL-Wert auf Null gesetzt werden, um sicherzustellen, dass die Daten niemals dem Cache hinzugefügt und immer aus der Datenbank abgerufen werden.
Indem in dem Cache 110 eine relativ kurze Lebensdauer für die Daten eingestellt wird, kann der Server 100 einen maximalen Durchsatz liefern, während er noch eine Weiterleitung von Zonenänderungen in Echtzeit bietet. Da der Cache als „load-on-demand" ausgebildet ist, kann der DNS-Daemon unmittelbar auf Anfragen innerhalb von Ausführungsaugenblicken antworten.
Zusätzlich zu einem normalen Cache-Vorgang von DNS-Antwortdaten ist der Cache-Algorithmus so ausgelegt, dass auch ein negativer Cache-Vorgang erreicht wird. Wenn zum Beispiel eine Anforderung für einen Host erfolgt, der nicht in einer aktiven Domäne vorhanden ist, wird die negative Antwort wie eine gültige Antwort gespeichert. Wenn der Server aus irgendeinem Grund mit einem Sperrfeuer von Anfragen für diesen gleichen ungültigen Host belagert wird, können sie unter Verwendung der negativen Antwort im Cache erfüllt werden, wobei wieder unnötige Anfragen an die Datenbank unterbleiben.
Weiterhin ist in einigen Ausführungen ein Management-Thread in das Cache-Design eingearbeitet. Dieser Thread wird in einem konfigurierbaren Intervall aktiviert und durchlauft den RR-Daten-Cache, wobei alle veralteten Eintragungen gelöscht werden, die enthalten sind. Dieses Merkmal gewährleistet, dass die Daten mit der größten Aktivität immer die am schnellsten verfügbaren sind.
In einigen Ausführungen ist ein Cache-Invalidierungs-Mechanismus eingefügt, welcher zur Entfernung (oder Modifizierung) von Daten innerhalb des dynamischen Cache so verantwortlich ist, dass der Cache exakt und akzeptabel Änderungen widerspiegelt, welche an der Primärdatenquelle ausgeführt wurden.
IMPLEMENTIERUNGSDETAILS
Eine Ausführung dieser Erfindung ist implementiert worden. Der DNS-Server 100 wurde auf der Datenbank 102 ausgebildet und mit ihr eng integriert. Die Datenbank 102 wurde unter Verwendung von Oracle implementiert, es wurde jedoch dafür gesorgt, dass das Datenbankinterface so modularisiert wurde, dass das System mit einer Datenbank von einem unterschiedlichen Lieferanten, wie beispielsweise Sybase oder Informix, leicht integrierbar ist. Der Server wurde unter Verwendung von Gnu C++ auf einer Linux-Plattform entwickelt. Der Serveraufbauvorgang wurde später erweitert, um sowohl Linux als auch Solaris zu unterstützen.
Implementierungen der vorliegenden Erfindung können in jeder geeigneten Programmier- bzw. Computer-Hochsprache geschrieben werden. Während Aspekte der vorliegenden Erfindung in Software implementiert wurden, die auf einem wie oben beschriebenen Computersystem läuft, können weiterhin alle Aspekte der vorliegenden Erfindung auch in Hardware oder in einer Kombination von Software und Hardware implementiert werden. Das heißt, dass, obwohl mit Bezug auf ein besonderes System beschrieben, die vorliegende Erfindung auf jedem Computersystem betreibbar und in Software, Hardware oder in jeder Kombination davon implementierbar ist. Wenn sie vollständig oder teilweise in Software implementiert ist, kann die Erfindung in jedem Speicher oder Speichermedium permanent oder temporär verbleiben, dabei sind eingeschlossen: RAM, ROM, Platte, ASIC, PROM und dergleichen, wobei die Erfindung darauf nicht beschränkt ist.
Während sich die obigen Ausführungen auf eine Verarbeitung von Domänennamen beziehen, erkennt ein Fachmann, dass Domänennamen nur ein Beispiel von Verzeichnisdiensten sind, und dass die vorliegende Erfindung auf andere Verzeichnisdienste bzw. Directory Services anwendbar ist.
Somit sind Verfahren, Systeme und Geräte für eine skalierbare Domänennamen-Auflösung geschaffen. Einem Fachmann ist es offensichtlich, dass die vorliegende Erfindung in die Praxis durch andere als die beschriebenen Ausführungen umsetzbar ist, welche zu Illustrationszwecken und nicht zur Einschränkung dargestellt sind, und die vorliegende Erfindung ist nur durch die folgenden Ansprüche begrenzt.

Claims

Domänennamen-Auflösungssystem mit einem oder mehreren Servern (100), wobei jeder der Server dafür ausgelegt ist, Domänennamen-Auflösungsanforderungen aufzulösen, und mit einem auf einen Zustand des Servers reagierenden Routing-Mechanismus, wobei jeder Server einen Anfragemechanismus (106) enthält, dadurch gekennzeichnet, daß der Anfragemechanismus eine zusammengesetzte Datenbankanfrage umfaßt und (106) dafür ausgelegt ist, als Reaktion auf die zusammengesetzte Datenbankanfrage eine Gruppe von Datensätzen aus einer Datenbank (102) zu erhalten, dergestalt, daß der Server (100) die Gruppe von Datensätzen mit einer Datenrate erhält, die schneller als die zugrundeliegende Datenabrufrate der Datenbank (102) ist.
Domänennamen-Auflösungsverfahren, mit den folgenden Schritten: Empfangen einer Domänennamen-Auflösungsanforderung in einem oder mehreren Servern (100); Bilden, unter Verwendung eines Anfragemechanismus (106), mindestens einer Datenbankanfrage entsprechend der Domänennamen-Auflösungsanforderung; Senden der mindestens einen Datenbankanfrage zu einer Datenbank (102); und Erhalten einer Domänennamen- Auflösungsantwort von der Datenbank (102), dadurch gekennzeichnet, daß: mindestens eine der Datenbankanfragen eine zusammengesetzte Datenbankanfrage ist und die Domänennamen-Auflösungsantwort auf die zusammengesetzte Datenbankanfrage eine Gruppe von Datenbankdatensätzen umfaßt, wobei der eine bzw. die mehreren Server (100) die Datensätze mit einer Datenrate empfangen, die schneller als die zugrundeliegende Datenabrufrate der Datenbank (102) ist.
System nach Anspruch 1, bei dem der Anfragemechanismus (106) ferner dafür ausgelegt ist, auf der Basis der unter Verwendung früherer Anfragen erhaltenen Datensätze eine Sequenz mehrerer Anfragen zu organisieren.
System nach Anspruch 3, bei dem der Anfragemechanismus (106) ferner dafür ausgelegt ist, die Sequenz mehrerer Anfragen zu organisieren, indem für jede Domänennamen-Auflösungsanforderung mindestens eine Anfrage auf der Basis von Common-Case-Optimierung gebildet wird, wobei der Test für jede Anfrage als ein separates Codesegment ausgelegt wird; und die mindestens eine Anfrage auf der Basis von Common-Case-Optimierung vor jeder anderen Anfrage ausgeführt wird.
System nach Anspruch 4, bei dem die Datensätze gemäß einer Vielzahl von Domänennamenzonen geführt werden und der Anfragemechanismus (106) ferner dafür ausgelegt ist, eine Sequenz der Anfragen auf der Basis von Common-Case-Optimierung gemäß für jede Zone geführten Statistiken zu optimieren.
System nach Anspruch 1, wobei der Anfragemechanismus (106) so ausgelegt ist, daß die zusammengesetzte Datenbankanfrage von der Datenbank (102) alle Datensätze erhält, die erforderlich sind, um eine Domänennamen-Auflösungsantwort zu konstruieren.
System nach Anspruch 6, bei dem der Anfragemechanismus (106) so ausgelegt ist, daß die zusammengesetzte Datenbankanfrage Kombinationen von Antwort-, Autoriäts- und zusätzlichen Datensätzen aus der Datenbank (102) abruft.
System nach Anspruch 7, bei dem der Anfragemechanismus (106) so ausgelegt ist, daß die zusammengesetzte Datenbankanfrage verfügbare CNAME-Datensätze aus der Datenbank (102) abruft.
System nach Anspruch 4, bei dem der Anfragemechanismus (106) so ausgelegt ist, daß die mindestens eine auf Common-Case-Optimierung basierende Anfrage auf den Ausgangswahrscheinlichkeiten für die Domänennamen-Auflösungsanforderung basiert.
System nach Anspruch 1, wobei die aus der Datenbank (102) erhaltenen Datensätze eine der Domänennamen-Auflösungsanforderung entsprechende Internet-Protokoll-Adresse enthalten.
System nach Anspruch 1, bei dem der Routing-Mechanismus dafür ausgelegt ist, Domänennamen-Auflösungsanforderungen auf der Basis von Benutzerproximitätsinformationen zu dem nächsten Server zu routen.
System nach Anspruch 1, bei dem der Routingmechanismus dafür ausgelegt ist, jeden Server zu überwachen und Routen zu Servern (100), die nicht auf Domänennamen-Auflösungsanforderungen reagieren, zurücknimmt.
System nach Anspruch 1, bei dem der Anfragemechanismus (106) für folgendes konstruiert und ausgelegt ist: Empfangen einer Benutzeranforderung für eine IP-Adresse, die einem Domänennamen entspricht; Konstruieren jeder zusammengesetzten Datenbankanfrage auf der Basis von Common-Case-Optimierung, um die Antwort abzurufen, wobei der Test für jede Anfrage als ein separates Codesegment ausgelegt wird, wobei die zusammengesetzte Datenbankanfrage auf der Basis von Common-Case-Optimierung vor jeder anderen Anfrage ausgeführt wird; und Geben der Antwort durch Anfragen bei der Datenbank (102) unter Verwendung der zusammengesetzten Datenbankanfrage, wobei die Antwort mindestens eine dem Domänennamen entsprechende IP-Adresse und andere relevante Informationen enthält.
Verfahren nach Anspruch 2, wobei die Domänennamen-Auflösungsanforderung für eine Adresse des Internet-Protokolls IP einer einer Vielzahl von Einrichtungen im Internet bestimmt ist und das Bilden der mindestens einen Datenbankanfrage folgendes umfaßt: Konstruieren jeder zusammengesetzten Datenbankanfrage in Bezug auf den maßgeblichen Namenserver auf der Basis von Common-Case-Optimierung, um die Antwort abzurufen, und Geben der Antwort durch Befragen des maßgeblichen Namenservers unter Verwendung der zusammengesetzten Datenbankanfrage, wobei die Antwort mindestens eine dem Domänennamen entsprechende IP-Adresse und andere relevante Informationen enthält.
System nach Anspruch 13, wobei der Anfragemechanismus (106) ferner für folgendes konfiguriert ist: wenn der Domänenname ein Label länger als der des Namens der Zone ist, für die ein erster Namenserver (100), der die Anforderung empfängt, verantwortlich ist, Auswählen des ersten Namenservers (100), der die Zone repräsentiert, als den maßgeblichen Namenserver (100); wenn keine Antwort für den die Zone repräsentierenden ersten Namenserver (100) erhalten wird, Auswählen eines zweiten Namenservers (100), der für den Domänennamen der nächsten Ebene relativ zu der Zone als der maßgebliche Namenserver (100) delegiert wurde; und wenn keine Antwort für den zweiten Namenserver (100) erhalten wird, Auswählen des maßgeblichen Namenservers durch rekursives Durchsuchen des maßgeblichen Namenservers (100) in Bezug auf den Domänennamen bis die Antwort gefunden ist.
System nach Anspruch 13, wobei der Anfragemechanismus (106), um die Antwort zu geben, ferner für folgendes ausgelegt ist: Befragen des maßgeblichen Namenservers (100) unter Verwendung der zusammengesetzten Datenbankanfrage; Empfangen des Anfrageergebnisses von dem maßgeblichen Namenserver (100); und Ableiten der Antwort aus dem Anfrageergebnis.
System nach Anspruch 16, ferner mit einem Cache (110), wobei der Anfragemechanismus (106) dafür konstruiert und ausgelegt ist, die Anfrage durchzuführen, indem zuerst versucht wird, das Anfrageergebnis aus dem Cache (110) abzurufen.
System nach Anspruch 17, wobei der Anfragemechanismus (106) dafür ausgelegt ist, das Anfrageergebnis in dem Cache (110) zu identifizieren; und das Anfrageergebnis verarbeitet.
System nach Anspruch 18, wobei der Anfragemechanismus (106) dafür ausgelegt ist, das Anfrageergebnis durch folgendes zu verarbeiten: wenn das Anfrageergebnis frisch ist, Senden des Anfrageergebnisses direkt aus dem Cache (110); und wenn das Anfrageergebnis entweder veraltet ist oder nicht in dem Cache (110) existiert, Abrufen des Anfrageergebnisses aus einer Datenbank (102), Senden des Anfrageergebnisses und Aktualisieren des Cache (110), um das abgerufene Anfrageergebnis widerzuspiegeln.
System nach Anspruch 19, wobei Posten in dem Cache (110) individuelle Datensätze oder aggregierte Datensätze umfassen.
System nach Anspruch 20, wobei jeder Datensatz in dem Cache (110) folgendem entspricht: entweder einem positiven Datensatz, der ein positives Anfrageergebnis repräsentiert, wobei eine Anforderung für einen Host erfolgt, der in einer aktiven Domäne existiert; oder einem negativen Datensatz, der ein negatives Anfrageergebnis repräsentiert, wobei eine Anforderung für einen Host erfolgt, der nicht in einer aktiven Domäne exitiert.
System nach Anspruch 21, wobei jeder Datensatz in dem Cache (110) eine maximale Lebensdauer aufweist, die von der Lebenszeit für den niedrigsten Ressourcendatensatz in einer vollständigen Antwort bis zu einem maximalen Cache-Zeitwert reicht, womit ausgewertet wird, ob jeder Datensatz veraltert ist.
System nach Anspruch 22, wobei der Anfragemechanismus (106) ferner dafür konstruiert und ausgelegt ist, das Anfrageergebnis aus einer Datenbank (102) des maßgeblichen Namenservers abzurufen, wenn das Anfrageergebnis nicht in dem Cache (110) gefunden wird.
Verfahren nach Anspruch 2, ferner umfassend: Organisieren einer Sequenz mehrerer Anfragen auf der Basis der unter Verwendung früherer Anfragen erhaltenen Datensätze.
Verfahren nach Anspruch 24, wobei das Organisieren folgendes umfaßt: für jede Domänennamen-Auflösungsanforderung, Bilden mindestens einer Anfrage auf der Basis von Common-Case-Optimierung, wobei der Test für jede Anfrage als separates Codesegment ausgelegt wird; und Ausführen der mindestens einen Anfrage auf der Basis von Common-Case-Optimierung vor jeder anderen Anfrage.
Verfahren nach Anspruch 25, wobei die Datensätze gemäß einer Vielzahl von Domänennamenzonen geführt werden und wobei die mindestens eine auf Common-Case-Optimierung basierende Anfrage auf für jede Zone geführten Statistiken basiert.
Verfahren nach Anspruch 2, wobei die zusammengesetzte Datenbankanfrage von der Datenbank (102) alle Datensätze erhält, die erforderlich sind, um eine Domänennamen-Auflösungsantwort zu konstruieren.
Verfahren nach Anspruch 27, wobei die zusammengesetzte Datenbankanfrage Kombinationen von Antwort, Autoritäts- und zusätzlichen Datensätzen von der Datenbank (102) abruft.
Verfahren nach Anspruch 28, wobei die zusammengesetzte Datenbankanfrage verfügbare CNAME-Datensätze aus der Datenbank (102) abruft.
Verfahren nach Anspruch 25, wobei die mindestens eine Anfrage auf der Basis von Common-Case-Optimierung auf den Ausgangswahrscheinlichkeiten für die Domänennamen-Auflösungsanforderung basiert.
Verfahren nach Anspruch 14, wobei das Geben der Antwort folgendes umfaßt: wenn der Domänenname ein Label länger als der des Namens der Zone ist, für die ein erster Namenserver (100), der die Anforderung empfängt, verantwortlich ist, Auswählen des ersten Namenservers (100), der die Zone repräsentiert, als den maßgeblichen Namenserver (100); wenn keine Antwort für den die Zone repräsentierenden ersten Namenserver (100) erhalten wird, Auswählen eines zweiten Namenservers (100), der für den Domänennamen der nächsten Ebene relativ zu der Zone als der maßgebliche Namenserver (100) delegiert wurde; und wenn keine Antwort für den zweiten Namenserver (100) erhalten wird, Auswählen des maßgeblichen Namenservers durch rekursives Durchsuchen des maßgeblichen Namenservers (100) in Bezug auf den Domänennamen bis die Antwort gefunden ist.
Verfahren nach Anspruch 14, wobei das Geben der Antwort folgendes umfaßt: Befragen des maßgeblichen Namenservers (100) unter Verwendung der zusammengesetzten Datenbankanfrage; Empfangen des Anfrageergebnisses von dem maßgeblichen Namenserver (100); und Ableiten der Antwort aus dem Anfrageergebnis.