DE602004005035T2

DE602004005035T2 - Verbesserung der datenbankleistungsfähigkeit in einem domänennamensystem

Info

Publication number: DE602004005035T2
Application number: DE602004005035T
Authority: DE
Inventors: Roy Lillqvist; Juha Uski
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2003-05-27
Filing date: 2004-05-24
Publication date: 2007-11-22
Anticipated expiration: 2024-05-25
Also published as: CN1777889A; ATE355563T1; CN100392650C; KR100664005B1; FI20030797A0; KR20060021836A; EP1627328A1; WO2004107207A1; DE602004005035D1; US20040243596A1; EP1627328B1

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die vorliegende Erfindung betrifft eine verteilte Datenbank, insbesondere ein Domänen-Namensystem (DNS), welches eine im Internet verwendete verteilte Datenbank ist. Etwas genauer betrifft die Erfindung ein Verfahren zum Verbessern der Leistungsfähigkeit der aktuellen de-facto-DNS-Namenserver, das heißt, die Servereinheiten des Client-Server-Einrichtung des DNS.
Beschreibung der betroffenen Technik
Wie allgemein bekannt ist, ist das Domänen-Namensystem (DNS) eine hierarchische, verteilte Datenbank, die in Computernetzwerken, wie zum Beispiel im Internet verwendet wird, um Domänen-Namen in IP-Adressen zu übersetzten. Die in der Datenbank gespeicherten Dateneinheiten werden durch Domänen-Namen identifiziert, die als eine invertierte Baumstruktur organisiert sind, welche der Domänen-Namenraum genannt wird. Jedem Knoten in dem Baum ist ein Kennzeichen zugewiesen. Der Domänen-Namen eines Knotens ist die Folge der Kennzeichen auf dem Weg von dem Knoten zu dem Wurzelknoten des Baums, wobei Punkte die Kennzeichen voneinander trennen. Mit anderen Worten identifiziert der Domänen-Name einen Knoten in dem Baum. Die jedem Domänen-Namen zugeordneten Daten sind in einer oder mehreren Ressourcenaufzeichnungen (bzw. Resource Records, RRs) gespeichert. Im Moment befinden sich ungefähr 20 verschiedene Typen von RRs in allgemeiner Verwendung. Im Folgenden wird das DNS-System kurz besprochen, um die Konzepte oder Bestandteile, welche die vorliegende Erfindung betreffen, zu erläutern.
Für eine dezentralisierte Verwaltung des Domänen-Namenraums, ist der letztere Teil in Bereiche unterteilt, die Zonen genannt werden. Jede Zone beginnt an einem bestimmten Knoten und erstreckt sich zu den Blattknoten des Baumes oder zu den Knoten, an dem andere Zonen beginnen. Jede Zone wird verwaltet und bedient durch wenigstens einem Namenserver, der als ein autoritativer Namensserver bezeichnet wird, der für die Zone verantwortlich ist. Ein autoritativer Namenserver enthält vollständige Informationen für die Zone, für die er verantwortlich ist. Um das DNS fehlertolerant zu machen, besitzt eine Zone typischerweise mehr als einen autoritativen Namensserver. Der autoritative Server, der die Hauptkopie der Zonendaten speichert, wird ein primärer Master-Server genannt, wobei die anderen für dieselbe Zone autoritativen Namensserver Slave-Server oder sekundäre Master-Server genannt werden. Jeder Slave-Server erhält die Zonendaten von anderen Namensservern, die für diese Zone autoritativ sind. Dieser Replizierungsprozess wird allgemein als ein Zonentransfer bezeichnet. Die vorliegende Erfindung betrifft hauptsächlich die Slave-Server, wie unten in größerem Detail erörtert wird.
Das DNS kann außerdem zum Identifizieren der Dienste verwendet werden, die mit einer bestimmten Telefonnummer, die als eine Standard-E.164-Nummer gegeben ist, zugeordnet sind. Wie bekannt ist, sind die E.164-Nummern global einzigartige Kennzeichen, (das heißt internationale Telefonnummern) für Ressourcen, wie zum Beispiel Telefone oder Geräte, in öffentlichen Telekommunikationsnetzwerken. Der verwendete Name, E.164, stammt von der Empfehlung E.164 der International Telecommunication Union (ITU), die das Format der Kennzeichen festlegt.
RFC (Anforderung von Kommentaren bzw. Request for Comments) 2916 erörtert die Verwendung des DNS zum Identifizieren verfügbarer Dienste, die einer E.164-Nummer zugeordnet sind. Dieses RFC-Dokument definiert ein Protokoll, das ENUM genannt wird, welches die Internationale Telefonnummer auf Internet-Dienste abbildet. Das DNS-basierende System für dieses Abbilden wird in diesem Zusammenhang als das ENUM-System bezeichnet. Wenn ein Endanwender eine E.164-Nummer eingibt oder wählt, wird die Nummer in einen vollständig qualifizierten Domänen-Namen (bzw. Fully Qualified Domain Name, FQDN) umgewandelt und in das DNS eingegeben, welches alle Namensautoritätszeiger (bzw. Name Authority Pointer, NAPTR)-Aufzeichnungen, die dem FQDN zugeordnet sind, zurückgibt. Der NAPTR ist einer der Ressourcenaufzeichnungstypen, die oben beschrieben worden sind. Die NAPTRs, die einer bestimmten E.174-Nummer zugeordnet sind und in dem DNS gespeichert sind, enthalten Informationen, die zum Kontaktieren einer oder mehreren Netzwerkressourcen, die der Nummer zugeordnet sind, verwendet werden können.
Aktuelle de-facto-DNS-Server basieren auf der Berkeley-Internet-Namendomänen (Berkerley Internet Name Domain, BIND)-Implementierung, bei der die Datenbank auf einem Rot-Schwarz-Binärbaum basiert. Ein Nachteil der mit diesen Servern in Zusammenhang steht, besteht darin, dass ihre Leistungsfähigkeit nicht für das ENUM-System optimiert ist, sondern die oben erwähnte Umwandlung der Telefonnummer in die FQDN setzt ihre Leistungsfähigkeit herab. Die vorliegende Erfindung zielt darauf ab, diesen Nachteil zu beseitigen, der auf die Eigenart der nachstehend beschriebenen Umwandlung zurückzuführen ist.
ZUSAMMENFASSUNG DER ERFINDUNG
Die Erfindung sucht, die Leistungsfähigkeit der aktuellen de-facto-Namenserver zu verbessern. Die Erfindung versucht außerdem, die Leistungsfähigkeit der aktuellen de-facto-Namenserver für das ENUM-System oder für jede andere Abfrage, bei der die dem Domänenservernamensystem eingegebenen FQDNs den in dem ENUM-System verwendeten FQDNs gleichen, zu optimieren.
In der vorliegenden Erfindung werden die, an dem Namensserver empfangenen FQDNs, abgeändert, bevor die aktuelle Datenbankschnittstelle und die abgeänderten FQDNs in die Schnittstelle eingegeben werden. Wie nachstehend beschrieben, wird die Abänderung in Verbindung mit einem Zonentransfer und in Verbindung mit einer nachfolgenden DNS-Anfrage durchgeführt. In diesem Kontext bezieht sich die Datenbankschnittstelle auf die Punkte in dem Namensserver, die den tatsächlichen Datenbankoperationen vorausgehen, das heißt auf eine Schnittstelle, durch welche die Zonendaten und die DNS-Anfragen in die Datenbankoperationen eingegeben werden, wie zum Beispiel Einfügungen, Löschungen oder Suchanfragen.
So besteht ein Ausführungsbeispiel der Erfindung in der Bereitstellung eines Verfahrens zum Verbessern der Datenbankleistungsfähigkeit in einem Domänen-Namensystem (bzw. Domain Name System, DNS). Das Verfahren enthält die Schritte: Empfangen von Datenbankoperationen bereitzustellenden Daten, wobei die Daten wenigstens einen Domänen-Namen mit einer Vielzahl von aufeinanderfolgenden Kennzeichen enthalten, wobei der wenigstens eine Domänen-Namen in einem ersten Format vorliegt, und Umwandeln des wenigstens eines Domänen-Namen in ein zweites Format, bei dem wenigstens zwei aufeinanderfolgende Kennzeichen eines Domänen-Namens kombiniert werden, um ein einziges Kennzeichen zu bilden. Das Verfahren sorgt außerdem dafür, dass die Daten den Datenbankoperationen bereitgestellt werden, bei denen die bereitgestellten Daten wenigstens einen Domänen-Namen in dem zweiten Format enthalten.
In einem anderen Ausführungsbeispiel stellt die Erfindung ein System bereit zum Verbessern der Datenbankleistungsfähigkeit in einem Domänen-Namensystem. Das System enthält erste Mittel zum Empfangen von Datenbankoperationen bereitzustellenden Daten, wobei die Daten wenigstens einen Domänen-Namen mit einer Vielzahl von aufeinanderfolgenden Kennzeichen enthalten, wobei wenigstens ein Domänen-Name in einem ersten Format vorliegt. Das System enthält außerdem zweite Mittel zum Umwandeln des wenigstens einen Domänen-Namens in ein zweites Format, in dem wenigstens zwei aufeinanderfolgende Kennzeichen eines Domänen-Namens kombiniert werden, um ein einziges Kennzeichen zu bilden und dritte Mittel zum Bereitstellen der Daten den Datenbankoperationen, wobei die bereitgestellten Daten wenigstens einen Domänen-Namen in dem zweiten Format enthalten.
In einem anderen Ausführungsbeispiel stellt die Erfindung einen Namensserver für ein Domänen-Namensystem bereit. Der Namensserver enthält eine erste Schnittstelle zum Empfangen von Datenbankoperationen bereitzustellenden Daten, wobei die Daten wenigstens einen Domänen-Namen enthalten, der eine Vielzahl aufeinanderfolgenden Kennzeichen aufweist, wobei wenigstens ein Domänen-Namen in einem ersten Format vorliegt, ein Abänderungsmodul, das operativ mit der ersten Schnittstelle verbunden ist, zum Umwandeln wenigstens eines der Domänen-Namen in ein zweites Format, bei dem wenigstens zwei aufeinanderfolgende Kennzeichen eines Domänen-Namens ein einzelnes Zeichen bilden, und eine zweite Schnittstelle, die operativ mit den Abänderungsmodul verbunden ist, zum Bereitstellen der Daten den Datenbankoperationen, wobei die bereitgestellten Daten wenigstens einen Domänen-Namen in dem zweiten Format enthalten.
In noch einem anderen Ausführungsbeispiel stellt die Erfindung ein Computerprogrammprodukt bereit. Das Computerprogrammprodukt umfasst Computer lesbaren Code, der konfiguriert ist, einen Computer zu veranlassen, im Wesentlichen, sobald durch den Computer ausgeführt, die oben erwähnten Schritte des Verfahrens durchzuführen.
Mittels der Lösung der Erfindung kann die Leistungsfähigkeit des ENUM-Systems wesentlich verbessert werden, da die hauptsächlichen internen durch die oben erwähnte Umwandlung verursachten Verzögerungen in dem Namensserver beseitigt werden können.
Ein weiterer Vorteil der Erfindung besteht darin, dass die Leistungsfähigkeit der DNS-Namensserver in einer einfachen und kosteneffizienten Weise gesteigert werden kann. Dies ist darauf zurückzuführen, dass die bestehende Serversoftware (BIND) weiter verwendet werden kann, und dass in der aktuellen Datenbank (das heißt in dem Suchbaum) keine Veränderungen notwendig sind.
Andere Merkmale und Vorteile der Erfindung werden offensichtlich unter Bezug auf die folgende detaillierte Beschreibung und die begleitenden Zeichnungen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Im Folgenden wird die Erfindung und viele ihrer Ausführungsbeispiele etwas näher unter Bezug auf die Beispiele, die in den 1 bis 6 in den beigefügten Zeichnungen gezeigt sind, beschrieben, wobei:
1 das ENUM-System durch Darstellen der Verwendung des DNS veranschaulicht, wenn ein Anruf von einem gewöhnlichem Telefon angestoßen wird;
2 veranschaulicht das Format eines Domänen-Namens im aktuellen DNS-System;
3 veranschaulicht, wie das Format des Domänen-Namens der 2 in der aktuellen Erfindung abgeändert wird;
4 ist ein schematisches Diagramm, das den Aufbau eines Namensservers der Erfindung veranschaulicht;
5 ist ein Flussdiagramm, das die Abänderung des Domänen-Namens in Verbindung mit einem Zonentransfer veranschaulicht; und
6 ist ein Flussdiagramm, das die Abänderung des Domänen-Namens in Verbindung mit einer DNS-Anfrage veranschaulicht.
DETAILLIERTE BESCHREIBUNG DES/DER BEVORZUGTEN AUSFÜHRUNGSBEISPIEL(E)
Um ein Beispiel der Umgebung, in der die vorliegende Erfindung angewendet wird, zu veranschaulichen, zeigt 1 ein Beispiel der Verwendung des ENUM-Systems. In 1 wird angenommen, dass ein Teilnehmer einen Anruf von einem gewöhnlichen Telefon 100 zu einem anderen Teilnehmer (nicht gezeigt) anstößt bzw. initiiert, dessen internationale Telefonnummer, das heißt die E.164-Nummer, +358-60-111-2222 ist. Das Telefonnetzwerk 120 leitet die Anrufanforderung zuerst an einen Gateway 130 weiter, welcher der Dienstagent für diese E.164-Nummer ist. Auf Empfang der Anrufsanforderung hin, wandelt der Gateway die E.164-Nummer in eine FQDN um. Dies wird derart durchgeführt, dass die Ziffern in der E.164-Nummer zuerst umgekehrt werden, dann werden Punkte zwischen den Ziffern eingefügt und schließlich wird die Domäne „e.164.arpa" an das Ende der Kette angefügt. In diesem Fall ist die resultierende FQDN 2.2.2.2.1.1.1.0.6.8.5.3.e164.arpa. Der Gateway sendet dann dem DNS eine Standard-DNS-Anfrage, welche die gerade gebildete FQDN enthält. Der Namensserver 140, der die Anfrage empfängt, führt eine Such(abfrag)e durch und gibt, in einer DNS-Antwort, alle NAPTR-Aufzeichnungen, die der FQDN entsprechen, zurück. Diese Aufzeichnungen spezifizieren die Internet-Dienste, die auf die E.164-Nummer abgebildet sind. Für diesen Zweck enthalten die NAPTR-Aufzeichnungen zum Beispiel ein Reihenfolgenfeld, das die Reihenfolge anzeigt, mit der mehrere NAPTR-Aufzeichnungen zu verarbeiten sind, und ein Dienstfeld, das ein Auflösungsprotokoll und einen zu verwendenden Dienst anzeigt, das heißt, Anweisungen darüber, wie mit der Anrufanforderung weiter zu verfahren ist. Basierend auf den in den Satz von NAPTR-Aufzeichnungen empfangenen Informationen, bestimmt der Gateway dann den Auflösungsdienst, der als nächstes zu verwenden ist. Auf diese Weise setzt sich die Verarbeitung der Anforderung gemäß den von dem DNS empfangenen Informationen fort. Da die vorliegende Erfindung sich nicht auf diese Stufe des Verfahrens bezieht, sondern eher auf den Betrieb der oben beschriebenen Namensserver, wird der Abschluss der Anrufsanforderung in diesem Zusammenhang nicht erörtert.
Die Erfinder der vorliegenden Erfindung haben herausgefunden, dass die Eigenart der Umwandlung der E.164-Nummer in die FQDN die Leistungsfähigkeit der de-facto-Namensserver herabsetzt. Wie oben diskutiert, enthalten in dem ENUM-System die Domänen-Namen eine Vielzahl von Kennzeichen, die nur ein Zeichen (ein Byte) lang sind. In den de-facto-Namensservern verarbeitet der Suchalgorithmus die Domänen-Namen derart, dass der Domänename Kennzeichen um Kennzeichen von der Wurzel an durchläuft und jedes Mal, wenn ein Punkt angetroffen wird, wird die Suche in einem neuen Unterbaum, dessen Wurzelknoten dem Domänen-Namen der bereits durchlaufenen Kennzeichen entspricht, fortgesetzt. Dies bedeutet, dass die Verwendung der ENUM-Systemübersetzungen zu einer erhöhten Anzahl von Unterbäumen führt, in denen die Suche durchgeführt wird. Es wird hier angenommen, dass es eine Million Telefonnummern gibt, die auf entsprechende Internetdienste abgebildet werden müssen. Wenn das herkömmliche System verwendet wird, das lange Kennzeichen erlaubt, kann dies als ein einzelner Baum implementiert werden, der eine Million Knoten enthält. Jedoch in dem Fall des ENUM, in dem ein Kennzeichen aus nur einer Nummer besteht, muss die Suche in sechs verschiedenen Bäumen (einem für jede Ziffer der Telefonnummer) durchgeführt werden, wobei jeder 10 Knoten (gekennzeichnet von 0 bis 9) enthält. Da ein Baum 10 Kennzeichen haben kann (eine Ziffer kann von 0 bis 9 betragen) beträgt die Anzahl der Bäume:
wobei k die Anzahl der Kennzeichen mit einer Ziffer ist. In diesem Fall ist k = 6, wodurch die Anzahl der möglichen Bäume 111111 beträgt.
Die Zeit, um einen Knoten von einem Rot-Schwarz-Binärbaum zu finden, beträgt O(log n), wobei n die Anzahl der Knoten in dem Baum und O(.) die allgemein verwendete O-Notation ist. Daher ist im herkömmlichen Fall die Suchzeit gleich O(log 1000000) = 6. In dem entsprechenden ENUM-Fall beträgt die Suchzeit in einem Baum O(log 10) = 1. Da 6 Bäume für eine Million Telefonnummern zu verwenden sind, beträgt die gesamte Suchzeit 6, das heißt die Suchzeiten sind in beiden Fällen gleich. Jedoch bildet in dem ENUM-Fall der Wechsel von einem Binär-Baum zu einem anderen einen wesentlichen Teil der gesamten Suchzeit, da die Aufgabe des Wechsels von einem Baum zu einem anderen in der Praxis komplizierter ist als eine Suche in einem Binär-Baum.
In aktuellen de-facto-Namensservern sind die Domänen-Namen typischerweise in einem unkomprimierten Wire-Format gespeichert. Die Domänen-Namen erscheinen außerdem in diesem Format in den DNS-Anfragen. In diesem Format geht jedem Kennzeichen eine 1-Byte-Zählung voraus, welche die Anzahl der Bytes spezifiziert, die der Domänen-Name für das Kennzeichen trägt, welches das nächste in dem Domänen-Namen ist. Der Domänen-Name wird mit einem Bytewert Null abgeschlossen, der das Kennzeichen der Wurzel ist. 2 zeigt wie der Domänen-Name 5.3.2.2.2.2.e164.arpa in diesem Format gespeichert wird. Wie zu erkennen ist, enthält der gespeicherte Domänen-Name sechs Zählwerte mit 1, entsprechend sechs 1-Byte-Kennzeichen.
Die Struktur der gespeicherten Namensdaten kann außerdem wie folgt dargestellt werden:

wobei „ndata" sich auf die Domänen-Namendaten im unkomprimierten Wire-Format bezieht, „labels" zeigt die Anzahl der Kennzeichen in den „ndata" an, „offsets" zeigt den Offset des Zählbytes des Kennzeichens mit der Nummer x an. Die Zählung der Kennzeichen (bzw. labels) beginnt von der gegenüberliegenden Seite zum Wurzelkennzeichen, wobei das erste Kennzeichen einen Wert von Null besitzt.
In dem Beispiel der 2 sind die Werte von „labels" und „offsets" wie folgt:

– label = 9,
– offsets: offsets[label=0]=0, offsets[label=1]=2, offsets[label=2]=4, offsets(label=3]=6, usw,
– ndata-Werte mit den obigen Offsets sind: ndata[offsets=0]=1, ndata[offsets=2]=1, ndata[offsets=4]=1, usw.

In diesem Beispiel der vorliegenden Erfindung wird die Leistungsfähigkeit der Namensserver durch Abändern der Domänen-Namen derart verbessert, dass eine bestimmte Anzahl von Kennzeichen kombiniert werden, um ein einziges Kennzeichen zu bilden. Die Änderung beginnt von einem gegebenem Ursprung und wird derart durchgeführt, dass der erste Zähl-Wert des Wire-Formats (das heißt ndata[offset=0]) in einem Wert abgeändert wird, welcher der Summe der Anzahl der Bytes in dem kombinierten Kennzeichen und in den Zählungen zwischen den Kennzeichen entspricht. Mit anderen Worten wird die erste Zählung in einen Wert abändert, welcher der gesamten Anzahl von Bytes in dem kombinierten Kennzeichen entspricht. 3 zeigt, wie der Domänen-Namen, der in 2 gezeigt ist, abändert wird, unter der Annahme, dass der gewünschte Ursprung e164.arpa ist. In diesem Fall ist die Gesamtanzahl in dem zu kombinierenden Kennzeichen 6(5.3.2.2.2.2) und die Anzahl der Bytes in den Zwischenzählungen beträgt 5. Daher wird der ersten Zählung in den Namen der Wert von 11 gegeben, der anzeigt, dass die nächsten 11 Bytes das Kennzeichen bilden, die der ersten Zählung folgen.
Im obigen Beispiel werden die Kennzeichen- und Offset-Werte wie folgt geändert:

– labels=4
– offsets: offsets[label=0]=0, offsets[label=1]=12, offsets[label=2]=17, offsets[label=3]=22.
– ndata-Werte mit den obigen Offsets sind: ndata[offsets=0]=11, ndata[offsets=12]=4, ndata[offsets=17]=4, ndata[offsets=22]=0.

4 ist eine schematische Darstellung des Aufbaus eines Beispiels eines Namensservers der Erfindung. Der vorliegenden Erfindung wird ein separates Abänderungsmodul 40 in den Namensserver derart eingefügt, dass das Abänderungsmodul den aktuellen Datenbankoperationen, wie zum Beispiel Hinzufügungen, Löschungen und Suchanfragen, mit Bezugszeichen 43, 44 bzw. 45 markiert sind, vorausgeht. Wie oben erwähnt, ist die tatsächliche Datenbank Typ 40 typischenrweise ein Rot-Schwarz-Binär-Baum. Das Abänderungsmodul empfängt Eingabedaten über durchzuführende Datenbartkoperationen, wobei die Eingabedaten in Verbindung zum Beispiel mit einem Zonentransfer oder einer DNS-Anfrage erlangen werden. Falls notwendig verändert das Abänderungsmodul Domänen-Namen, die in den Eingabedaten enthalten sind, in der oben erörterten Weise. Das Abänderungsmodul untersucht so, ob Abänderungen notwendig sind, und führt die Abänderungen in dem bestätigten Fall durch. Anderenfalls lässt das Modul die Eingabedaten intakt, das heißt der Namensserver arbeitet in einer herkömmlichen Weise.
Sobald es eine Anfragenantwort von der Datenbank (das heißt von Modul 46) empfängt, gibt das Abänderungsmodul einen geänderten Domänen-Namen in seinem ursprünglichen Format zurück. In der Praxis kann das Abänderungsmo dul derart implementiert werden, dass es innerhalb einer normalen BIND-Implementierung liegt, das heißt im Fall von hereinkommenden Daten werden bestimmte BIND-Funktionen außerdem vor der Änderung durchgeführt. Diese Funktionen schließen ein dns_db_beginload() and beginload() im Fall eines normalen Zonentransfers, xfrin_recv_done() und xfr_rr() im Falle von einem inkrementellen Zonentransfer, client_request() und ns_query_start() im Falle von DNS-Anfrage und lookup_find() und view_find() im Falle von einer Iwresd-Anfrage. Die Funktion, an welche die DNS-Anfragenantwort, die von der Datenbank empfangen wurde, weitergeleitet wird, ist continue_query_find(). Die den Abänderungsmodul vorausgehende Stufe wird in diesem Kontext eine Vorverarbeitungsstufe genannt. Das Abänderungsmodul kann als ein Patch-Datei an den Quellcode der BIND-Software angefügt werden.
Die Erfindung kann in Verbindung mit einem Zonentransfer und einer nachfolgenden DNS-Anfrage verwendet werden. Dies wird im Folgenden erörtert.
5 ist ein Flussdiagramm, das ein Beispiel des Grundbetriebs des Modifikationsmoduls in Verbindung mit einem Zonentransfer veranschaulicht, das heißt, wenn die gesamte Zone an den Namensserver transferiert wird. In diesem Fall ändert das Abänderungsmodul die Zonendaten, wie in 3 gezeigt, um sicherzustellen, dass die Zonendaten in einem Binär-Baum gespeichert werden. Dies wiederum beseitigt das oben beschrieben Leistungsfähigkeitsproblem, da eine nachfolgende Suche in einem Suchbaum durchgeführt werden kann.
Während die Zonendaten empfangen und vorverarbeitet werden, untersucht das Abänderungsmodul die NAPTR-Aufzeichnungen eine nach der anderen „on the fly", um zu überprüfen, ob sie vorbestimmte Bedingung erfüllen, die für die Änderung (Schritt 51) eingestellt ist. Dafür verwendet das Abänderungsmodul das Standardformat der NAPTR-Aufzeichnungen, um die relevanten Daten innerhalb der hereinkommenden Aufzeichnungen zu finden. Die vorherbestimmte Bedingung, die für die NAPTR-Aufzeichnungen eingestellt sind, können typischerweise derart sein, dass der Domänen-Name wenigstens eine bestimmte Anzahl von 1-Byte-Kennzeichen enthält, die den Ursprung der Zone „Überschreiten", dafür, dass die Änderung stattfindet. Zum Beispiel könnte das Abänderungsmodul die Kennzeichen nur kombinieren, wenn der Domänen-Name wenigstens drei 1- Bytes-Kennzeichen enthält, die den Ursprung „überschreiten". Unter Verwendung des obigen Domänen-Namens (5.3.2.2.2.e164.arpa) als ein Beispiel und angenommen, dass der Zonenursprung 2.2.2.e164.arpa ist, würde das Abänderungsmodul die ersten drei Kennzeichen (5.3.2) in dem obigen Domänen-Namen kombinieren, aber keine Kombination würde für einen Domänen-Namen 4.4.2.2.2.164.arpa durchgeführt, der nur zwei Kennzeichen (4.4) über dem Ursprung besitzt. Daher bestimmt für jede NAPTR-Aufzeichnung das Abänderungsmodul den „Unterschied" zwischen dem Zonenursprung und dem Domänen-Namen und kombiniert (Schritt 52) die Kennzeichen des „Unterschieds", ehe sie eine vorherbestimmte Bedingung erfüllen.
Nach der Überprüfung in Schritt 51 und der möglichen Veränderung in Schritt 52 werden die Daten zu der Datenbank (Schritt 53) zugefügt.
6 ist ein Flussdiagramm, das ein Beispiel des Grundbetriebs des Abänderungsmoduls in Verbindung mit einer hereinkommenden DNS-Anfrage veranschaulicht. Wenn die Anfragedaten der Vorverarbeitungsstufe verarbeitet worden sind, führt das Abänderungsmodul Vorprüfungen in den Schritten 601, 602 und 603 durch, um herauszufinden, ob der Domänen-Name in Verbindung mit dieser Anfrage zu abzuändern ist. Zuerst überprüft das Abänderungsmodul, ob der Ursprung des Domänen-Namens in dem Server gefunden werden kann (Schritt 601). Als zweites überprüft das Abänderungsmodul, ob eine ENUM-Anfrage betroffen ist (Schritt 602), und als drittes überprüft das Abänderungsmodul, ob der Namensserver für die interessierende Zone autoritativ ist (Schritt 603).
Falls alle obigen drei Bedingungen erfüllt sind, kombiniert das Abänderungsmodul die Kennzeichen, die den betroffenen Domänenursprung überschreiten (Schritt 606), vorausgesetzt, dass der Domänen-Name eine oder mehrere vorherbestimmte Bedingungen erfüllt, die in Schritt 605 überprüft werden. Diese Überprüfung entspricht in Schritt 52 in 5, das heißt es wird überprüft, ob das Kennzeichen eine ausreichende Anzahl von 1-Byte-Kennzeichen über den Ursprung hinaus besitzt.
Die Anfrage wird dann den Datenbankoperationen bereitgestellt (Schritt 607), das heißt dem Modul 45 in 4. Wenn das Abänderungsmodul eine Antwort von der Datenbank enthält (Schritt 608/ja), untersucht es, ob die Kennzeichen des EingabeDomänen-Namens vorausgehend in Verbindung mit dieser Anfrage kombiniert wurden (Schritt 609). Falls dies der Fall ist, trennt das Abänderungsmodul die Kennzeichen (Schritt 610), das heißt es gibt den Domänen-Namen im ursprünglichen Format durch Veränderung der ersten Zählung in dem Domänen-Namen zurück in ihren ursprünglichen Wert zurück. Das Abänderungsmodul gibt dann die Antwort der Vorverarbeitungsstufe weiter (Schritt 611). Keine Trennung von Kennzeichen wird durchgeführt, wenn festgestellt wird, dass die Kennzeichen der EingabeDomänen-Namens nicht den Datenbankoperationen kombiniert worden sind. Hier sei angemerkt, dass die Antwort in der obigen Weise ohne Rücksicht darauf, ob sie eine Antwort enthält oder nicht, gehandhabt wird, das heißt die Schritte 609 bis 611 bleiben die gleichen, selbst wenn keine Antwort aus der Datenbank gefunden wird.
Wenn die erste Überprüfung in Schritt 601 anzeigt, dass der Ursprung in dem Namensserver nicht gefunden werden kann, wird die Anfrage an einen anderen Server weitergeleitet (Schritt 604). Wenn die zweite Überprüfung in Schritt 602 anzeigt, dass die Anfrage keine ENUM-Anfrage ist, wird die Änderung übersprungen und die Anfrage wird den Datenbankoperationen bereitgestellt. Damit arbeitet in diesem Fall der Namensserver in einer herkömmlichen Weise. Wenn die dritte Überprüfung in Schritt 603 anzeigt, dass das Abänderungsmodul nicht autoritativ für die in Frage stehende Zone ist, wird die Änderung übersprungen und die Anfrage wird den Datenbankoperationen bereitgestellt. In diesem Fall ist die Anfrage eine rekursive Anfrage, welche der Namensserver zwischengespeichert hat, das heißt der Namensserver arbeitet als ein Zwischenspeicherserver.
Der oben beschriebene Namensserver ist typischerweise ein Slave-Server. Mit anderen Worten empfängt der Namensserver die Zonendaten von einem Master-Server. Die Änderung der Erfindung kann jedoch außerdem durchgeführt werden in einem Master-Server, bevor die Zonendaten an einen Slave-Server übertragen werden, wobei in diesem Fall keine Änderungen dem Slave-Server notwendig sind. In diesem Fall entspricht der Zonentransfer zwischen dem Master und dem Slave nicht vollständig dem Standard-Verfahren (da geänderte Domänen-Namen über das Netzwerk übertragen werden).
Obwohl die Erfindung oben unter Bezug auf die Beispiele, die in den beigefügten Zeichnungen dargestellt sind, beschrieben wurde, ist es offensichtlich, dass die Erfindung nicht auf diese beschränkt ist, sondern durch Fachleute, ohne von dem Bereich der Erfindung abzuweichen, geändert werden kann. Zum Beispiel kann die Lösung der Erfindung in Verbindung mit anderen Diensten als dem ENUM-Dienst verwendet werden, vorausgesetzt die Anwendungen produzieren ähnlich FQDNs mit einer Menge von kurzen Kennzeichen. Darüber hinaus ist das Verfahren nicht auf das Kombinieren auf 1-Byte-langen Kennzeichen beschränkt, sondern Kennzeichen unterschiedlicher Länge können in derselben Weise kombiniert werden. In diesem Fall wird die Änderung durchgeführt, wenn die oben beschriebene Überprüfung (Schritt 51) anzeigt, dass der Domänen-Name wenigstens eine vorbestimmte Anzahl von Kennzeichen über dem gegebenen Ursprung enthält, und dass die Kennzeichen eine vorherbestimmte maximale Länge besitzen, die jetzt größer als ein Byte ist. Weiter ist es nicht notwendig, alle Kennzeichen, die den Ursprung überschreiten, zu kombinieren, sondern es könnte nur ein Teil solcher Kennzeichen kombiniert werden.

Claims

Verfahren zum Steigern von Datenbankleistungsfähigkeit in einem Domänen-Namens-System DNS, wobei das Verfahren die Schritte umfasst: – Empfangen (600) von Datenbankoperationen bereitzustellenden Daten, wobei die Daten wenigstens einen Domänen-Namen enthalten, der eine Vielzahl von aufeinanderfolgenden Kennzeichen umfasst, wobei der wenigstens eine Domänen-Name in einem ersten Format vorliegt; – Umwandeln (606) zumindest eines von den wenigstens einen Domänen-Namen in ein zweites Format, in dem mindestens zwei aufeinanderfolgende Kennzeichen des zumindest einen von den wenigstens einen Domänen-Namen kombiniert werden, um eine einzelne Kennzeichnung zu bilden; und – Bereitstellen (607) der Daten an die Datenbankoperationen, wobei die bereitgestellten Daten wenigstens einen Domänen-Namen in dem zweiten Format enthalten.
Verfahren nach Anspruch 1, das weiter einen Prüfschritt, ob ein Domänen-Name eine vorbestimmte Bedingung in dem ersten Format erfüllt, umfasst.
Verfahren nach Anspruch 2, wobei der Prüfschritt eine Prüfung enthält, ob der Domänen-Name zumindest eine vorbestimmte Anzahl von Kennzeichen außerhalb eines gegebenen Ursprungs enthält, wobei die Kennzeichen eine vorbestimmte maximale Länge aufweisen.
Verfahren nach Anspruch 3, wobei der Umwandlungsschritt für den Domänen-Namen durchgeführt wird, wenn der Prüfschritt anzeigt, dass der Domänen-Name zumindest die vorbestimmte Anzahl von Kennzeichen außerhalb des gegebenen Ursprungs enthält, wobei die Kennzeichen die vorbestimmte maximale Länge aufweisen, und wobei der Umwandlungsschritt nicht durchgeführt wird, wenn der Prüfschritt anzeigt, dass der Domänen-Name nicht zumindest die vorbestimmte Anzahl von Kennzeichen aufweist.
Verfahren nach Anspruch 3, wobei die vorbestimmte Anzahl von Kennzeichen drei ist.
Verfahren nach Anspruch 3, wobei die vorbestimmte maximale Länge ein Byte ist.
Verfahren nach Anspruch 5, wobei die vorbestimmte maximale Länge ein Byte ist.
Verfahren nach Anspruch 1, das weiter die Schritte umfasst: – Empfangen von Daten, die einen anderen Domänen-Namen in dem zweiten Format enthalten; und – Umwandeln des in dem zweiten Format empfangenen anderen Domänen-Namens zurück in das erste Format.
System zum Steigern von Datenbankleistungsfähigkeit in einem Domänen-Namens-System, wobei das System umfasst: – erste Mittel zum Empfangen von Datenbankoperationen bereitzustellenden Daten, wobei die Daten wenigstens einen Domänen-Namen enthalten, der eine Vielzahl von aufeinander folgenden Kennzeichen umfasst, wobei der wenigstens eine Domänen-Name in einem ersten Format vorliegt; – zweite Mittel (40) zum Umwandeln zumindest eines von den wenigstens einen Domänen-Namen in ein zweites Format, in dem mindestens zwei aufeinander folgende Kennzeichen des zumindest einen von den wenigstens einen Domänen-Namen kombiniert werden, um eine einzelne Kennzeichnung zu bilden; und – dritte Mittel zum Bereitstellen der Daten an Datenbankoperationen, wobei die bereitgestellten Daten wenigstens einen Domänen-Namen in dem zweiten Format enthalten.
System nach Anspruch 9, das weiter umfasst vierte Mittel zum Prüfen, ob ein Domänen-Name eine vorbestimmte Bedingung erfüllt, wobei die zweiten Mittel ausgestattet sind, den Domänen-Namen in das zweite Format umzuwandeln, wenn der Domänen-Name die vorbestimmte Bedingung erfüllt.
Ein Namens-Server für ein Domänen-Namens-System, wobei der Namens-Server umfasst: – eine erste Schnittstelle zum Empfangen von Datenbankoperationen bereitzustellenden Daten, wobei die Daten wenigstens einen Domänen-Namen enthalten, der eine Vielzahl von aufeinander folgenden Kennzeichen umfasst, wobei der wenigstens eine Domänen-Name in einem ersten Format vorliegt; – einen Abänderungsmodul (40), das operativ mit der ersten Schnittstelle verbunden ist, zum Umwandeln wenigstens eines von den zumindest einen Domänen-Namen in ein zweites Format, in dem mindestens zwei aufeinanderfolgende Kennzeichen des zumindest einen von den wenigstens einen Domänen-Namen eine einzelne Kennzeichnung bilden; und – eine zweite Schnittstelle, die operativ mit dem Abänderungsmodul zum Bereitstellen der Daten an Datenbankoperationen verbunden ist, wobei die bereitgestellten Daten wenigstens einen Domänen-Namen in dem zweiten Format enthalten.
Computer-Programm-Produkt, wobei das Produkt computerlesbaren Code umfasst, der ausgestattet ist, einen Computer zu veranlassen, die Schritte des Verfahrens des Anspruchs 1 durchzuführen, wenn er auf einem Computer ausgeführt wird.