Eine Verteilte Datenbank (Distributed Database) ist auf mehrere physische Datenbanken verteilt und wird von einem Verteilten Datenbank-Management-System (Verteiltes DBMS oder DDBMS (Distributed Datebase Management System)) verwaltet.  Dieses Verteilte DBMS wird durch verschiedene Kriterien spezifiziert: Autonomie, Heterogenität und Verteilung.  Je nach Spezifizierung dieser Kriterien ergibt sich ein anderer Typus von verteilten Datenbanken. Beispiele sind: Stark Verteilt (Peer-to-Peer), Gering Verteilt (Client-Server) oder Master-Slave Systeme. Distributed Databases (DDB)  sind zwar physisch auf mehrere Datenbanken verteilt und können auch über viele Orte auf der Erde oder innerhalb eines Unternehmens verteilt sein, erscheinen jedoch nach außen durch das Verteilte DBMS als logische Einheit auf der auch  logische Sichten (Views) erstellt werden können. Die physichen Datenbanken sind durch Netze mit mehreren Netzknoten miteinander verbunden.

Datenintegrität und Datenkonsistenz, Update-Anomalien bei Verteilten DBMS 
Wichtig ist, dass es nicht zu Update- oder Insert-Anomalien kommt. Deshalb besteht eine zentrale Anforderung an das Verteilte DBMS, lokale und zentrale Zugriffe zu koordinieren.  Aus diesem Grund empfiehlt sich eine den Anforderungen entsprechende Behandlung der Daten. Man unterscheidet Unikate Daten, welche nur auf einem einzigen Datenbank-Server gespeichert sind, Partitionierte Daten, welche sich auf mehreren Datenbank-Servern  befinden oder Replikate Daten bzw. Redundanzen welche eine mehrfache Speicherung eines Datensatzes implizieren.  Unikate Daten können leicht verwaltet werden, bedeuten jedoch, dass alle Anfragen zu diesen Daten nur über den entsprechenden Server laufen können. Wenn dieser mal ausfällt oder langsam wird, kann es zu einem Anfrage-Stau kommen.  Bei Verteilten DBMS-Systemen unterscheidet man zwischen Homogen verteilten Systemen mit und ohne Replikation und Heterogen Verteilten Systemen.                                       

Die DNS-Datenbank liegt in Form einer baumförmigen Struktur vor. Es handelt sich um eine verteilte Datenbank (Distributed Database) welche auf mehrere Server im ganzen Internet verteilt ist (Internet-DNS).  Diese Datenbanken sind im Internet durch Verweise (Delegationen) verknüpft. Die Nameserver verwalten die Zonendateien, welche die notwendigen Daten zur Navigation im Internet enthalten.  Die Zonendateien werden intern durch eine Liste von Resource Records repräsentiert. Man unterscheidet grundsätzlich 2 Ausprägungen von Resource Records: 

1. Der A Resource Record: hier findet die Datendefinition statt. Einem Domain-Namen wird eine IPv4 bzw. IPv6 Adresse zugewiesen. 

2. Der NS-Record, Nameserver Record: er enthält die Delegationen (Verknüpfungen der Server untereinander). Der NS-Record definiert also die Zuständigkeit von Nameservern für ihre Zone und weiterhin verkettet der NS-Resource Record  (NS-RR) die Zonen zu einem Zonen-Baum. 
Weiterhin benötigt werden der SOA Resource Record, welcher Informationen zur Zonenverwaltung und zum Zonentransfer (RFC 1035) enthält. Der Start of Authority (SOA) ist ein bedeutender Bestandteil einer Zonendatei des Domain Name System.  Der strukturelle Aufbau und ein Beispiel für einen Nameserver Resource Record (NS-RR) sind:

IN NS <nameserver-name>, wobei nameserver-name eine FQDN ist.

Beispiel: IN NS dns1.beispiel.com. IN NS dns2.beispiel.com. 
Dasselbe für einen A Resource Record:

<host> IN A <IP-address>
Beispiel: server1 IN A 10.0.1.3 IN A 10.0.1.5 für die beispiel.com Zonen-Datei, d.h. Anfragen für beispiel.com weisen auf 10.0.1.3 oder 10.0.1.5. 
Der CNAME Record (Canonical-Name) ordnet Namen einander zu (Alias):

<alias-name> IN CNAME <real-name>

server1 IN A 10.0.1.5 www IN CNAME server1 

"named" wird angewiesen, dass alle Anfragen, die an den <alias-name> gesendet werden, auf den Host <real-name> zeigen. 

CNAME-Records werden oft eingesetzt, um auf Dienste zu verweisen, die ein allgemeines Namensschema für den entsprechenden Host, wie www für Web-Server, verwenden.  In den Zonendateien muss mindestens ein Nameserver-Resource Record vorhanden sein, aus dem zu entnehmen ist, welcher Nameserver für diese Zone autoritativ ist. Die entsprechenden Nameserver-Resource Records sind normalerweise am Beginn  einer Zonendatei unmittelbar hinter dem SOA-Resource Record zu finden. Die NS Resource Records (NS RR) geben nicht Preis, welcher Nameserver Primary Nameserver und welcher Nameserver Secondary Nameserver ist.  Aus dem SOA Resource Record kann man den Primary Resource Record ablesen. Die restlichen NS-RR Einträge verweisen auf Secondary Resource Records.  Nameserver-Resource Records können Verweise zu Subdomänen beinhalten. Die betreffende Subdomäne wird aus dem Zonenfile ausgelagert.  Der Nameserver-Resource Record dient somit als Pointer und verweist auf einen anderen Nameserver bzw. auf ein anderes Zonenfile auf demselben Server. Dies wird dann "Delegation" genannt. Delegation bedeutet, daß Anfragen an einen Resolver an einen  weiteren Nameserver delegiert werden.

Ein Beispiel für eine Namensauflösung wäre:
linux37:~ # cat /etc/hosts
# Syntax:
#
# IP-Address Full-Qualified-Hostname Short-Hostname
# 
127.0.0.1 localhost

217.89.70.36 linux36.amov.de linux36 klaus
217.89.70.37 linux37.amov.de linux37 willi 
217.89.70.38 linux38.amov.de linux38 petra
217.89.70.39 linux39.amov.de linux39 ludwig
217.89.70.40 linux40.amov.de linux40 ines

217.89.70.38 mail.amov.de mail 

Die ursprüngliche Form der Namensauflösung ist die Datei /etc/hosts. Es wird eine Tabelle eingesetzt, in der die IP-Nummer, der FQDN (Fully Qualified Domain Name) und verschiedene Alias-Namen stehen.  Eine Zeile steht für eine Kombination aus IP-Nummer und FQDN. Die IP-Nummer kann mehrfach vorkommen. Am Anfang jeder dieser Zeilen steht die IP-Adresse, danach folgt die FQDN.  Im Anschluß an den FQDN können mehrere Alias-Namen für den Rechner vergeben werden. Wie funktioniert eine Namensauflösung am Beispiel des Befehls "ping"? 

linux37:~ # ping linux37.amov.de
PING linux37.amov.de (217.89.70.37) 56(84) bytes of data. 

linux37:~ # ping linux37
PING linux37.amov.de (217.89.70.37) 56(84) bytes of data. 

linux37:~ # ping willi
PING linux37.amov.de (217.89.70.37) 56(84) bytes of data.  Anhand des FQDN oder eines Alias-Namen wird der entsprechende Eintrag identifiziert, die passende IP-Nummer und der FQDN ermittelt. Dies können Sie schön im folgenden Beispiel sehen. 

linux37:~ # ping manuela
PING linux38.amov.de (217.89.70.38) 56(84) bytes of data.

linux37:~ # ping mail
PING mail.amov.de (217.89.70.38) 56(84) bytes of data. 

Es gibt nicht nur eine Namensauflösung für Hostnamen sondern auch eine Namensauflösung für Netzwerkadressen. Jede Zeile bezeichnet eine Verbindung zwischen Netzwerkname und Netzwerkadresse.

linux37:~ # cat /etc/networks 
loopback 127.0.0.0

amov 217.89.70.0
sub1.amov 217.89.70.32
sub2.amov 217.89.70.64

Quellenangaben: http://www.redhat.com/docs/manuals
http://www.fibel.org/linux/lfo-0.6.0/node483.html