28.11.2001

DNS

DNS-Zonen: in der Forward-lookup-Zone werden Namen in IP-Adressen aufgelöst. Wenn man eine DNS-Zone einrichtet, muss man den Typ (primär, sekundär) und den Namen der Zone eingeben. Letzteren kann man auswählen oder neu anlegen lassen. Damit ist eine neue Zone angelegt. In dieser liegen sofort zwei Einträge drin: Der SOA (Start of Authority)-Eintrag ordnet eine Zone dem Rechner zu, der sie verwaltet:

Und zwar sieht man die Zone (der übergeordnete Ordner heisst ja example.ms.com), eine Seriennummer (die sich um 1 erhöht bei Änderungen an der Zone), der FQDN-Name des verwaltenden Rechners der Zone und der zuständige Administrator. Dieser Eintrag soll ein Hinweis auf eine mögliche E-Mail-Adresse sein: admin@test.de.

Der darunterliegende Eintrag des Typs NS ist der Rechner, der die Namensauflösung durchführen kann. Ein Host (Typ A) weisst einer IP-Adresse einen Namen zu. Damit ist der Rechner sowohl über einen FQDN als auch dessen Alias erreichbar.

Ein MX-Eintrag ist für Microsoft-Exchange. Damit kennzeichnet man den Rechner in der Zone, Mails anzunehmen. Sinnvollerweise sollte ein SMTP-Server darauf laufen. Eine Mail mit dem Namen irgendwas@example.ms.com landen somit auf dem Dozisrv:

Die Reverse-Lookup-Zone:

Der Sinn dieser Zone ist die Auflösung von IP-Adressen in Namen. Bei der Einrichtung gibt man ebenfalls den Typ an, zusätzlich aber die Netzkennung:

Diese wird (wie man etwas schwer erkennen kann) umgedreht, um daraus den Namen zu erstellen. Das übernimmt der Computer für uns. Da wir eine 16bittige Subnetmask haben und die Netzkennung 172.20.0.0 lautet, ist die Reverse-Lookup-Zone: 20.172.in-addr-arpa (inverse Addressierung).

Das Problem, was wir haben ist, dass die Zone nur C-Klasse annimmt. Da wir aber ein B-Klasse-Netz haben, müssen wir eine Unterdomäne erstellen, die 0 heisst, und darin unseren Zeiger. Der hat dann den Namen 1.0.20.127.in-addr-arpa.

Es gibt im allgemeinen folgende Zonentypen: primär, sekundär und Active-Directory integriert. Eine Primäre Zone speichert die Zoneneinträge. Eine Sekundäre beinhaltet eine Nur-Lese-Kopie einer anderen Zone. Es muss zwingend eine andere Zone aber es können mehrere sekundäre Zonen sein. Der Sinn ist die Fehlertoleranz und Lastenausgleich. Damit letzterer gut funktioniert, gebe ich bei 50% der Clients den primären und danach den sekundären DNS-Server, bei den anderen 50% erst den sekundären und dann den primären DNS-Server an. Die Speicherung erfolgt in den jew. Dateien. Aber der Zonentransfer muss konfiguriert werden. Diese Methode ist klassisch und weitestgehend betriebssystemunabhängig.

In einer Active-Directory-Zone müssen ebenfalls DNS-Server stehen, welche aber die entsprechenden Zonen besitzen. Hauptsächlich erfolgt die Speicherung und Replikation aber über das AD. Im Rahmen der Replikation werden beide Zonen abgeglichen, also sind Änderungen an allen AD-integrierten Zonen möglich. Der Transfer erfolgt automatisch und ist im Gegensatz zu den anderen Zonen verschlüsselt. Ausserdem sind die Zonen nur auf autorisierte Domänencontroller beschränkt. Rechner, die keine DC's sind, können keine Zonen enthalten. Sekundäre Zonentypen können trotzdem AD integrierte Zonen beinhalten.

Es existieren folgende Zonendateien in winnt\system32\dns: Domänenname.dns, x.y.z.in-aaddr.arpa, cache.dns und boot. Es stehen in diesem Ordner jede Zone, die auf diesem Rechner gehostet wird, ausser Active-Directory integrierte. Die Root-Name-Server stehen normalerweise immer in der cache.dns. Die Boot-Datei ist im Unterverzeichnis Sample, da W2k standardmässig die Registrierung ausliest und diese Datei nicht zwingend benutzt. Darin sind die DNS-Server-Einstellungen enthalten.

Bei Unix-Derivaten existiert ein BIND-DNS-Server (Berkeley Internet Name Domains). Die Dateien lauten dann: db.Domänenname, db.z.y.x und named.boot. Erfreulicherweise braucht man diese Textdateien nur zu transferieren und umzubenennen.

Zum Zonentransfer kommen Protokolle wie AXFR und IXFR zum Einsatz. IXFR wird von W2k benutzt und bedeutet Inkremental Zone Transfer. NT4 benutze das AXFR. Beim IXFR werden nur die Änderungen übertragen. Der Master sagt dem Slave, dass Änderungen vorliegen und dieser fordert sie daraufhin an. Weitere Gründe, wann ein Transfer stattfindet ist das (Neu-) Starten des Dienstes auf dem Slave, wenn der Refresh-Intervall abläuft oder wenn die Anforderung manuell gestellt wird. Auf dem Master kann man den Zonentransfer auf bestimmte Rechner zu begrenzen. Standardmässig ist der Transfer nur bei AD verschlüsselt, allerdings: verschlüsselt man die Kommunikation zwischen den DNS-Servern, verschlüsselt man automatisch damit den Zonentransfer. Konfigurationen nimmt man an den Eigenschaften der Master-Zone in Zonenübertragungen vor. Dort findet auch die Begrenzung nach nur Nameserver oder nur voreingestellte IP-Adressen statt. Standardmässig sind alle Server dort eingestellt. Die nächste Registerkarte gibt die Benachrichtigung an. Standardmässig werden alle Server der Namensliste benachrichtigt, aber diese kann man auch eingrenzen auf bestimmte IP-Adressen. Eine weitere Registerkarte "Namenserver" zeigt alle Namenserver in dieser Zone. Die Registerkarte Autoritätsursprung (SOA) stellt u.a. die Seriennummer dar, die ein Indiz für den Transfer ist (Vergleich zwischen prim. und sek. Seriennummer). Ist die primäre Seriennummer kleiner oder gleich gross wie die sekundäre, muss der Transfer manuell ausgelöst werden. Weiterhin ist dort das Aktualisierungsintervall einstellbar (Standard 15 min). Das Wiederholungsintervall stellt dar, wann die nächste Übertragung stattfinden soll, wenn die vorhergehende gescheitert ist. Wird das Aktualisierungsintervall ohne Datenübertragung überschritten, ist mit der Ablaufzeit (Standard 1 Tag) nach dieser Zeit erst der Namensserver gesperrt, denn er hat keine aktualisierte Datenbank erhalten. Wird ein Name aufgelöst, bleibt dieser Wert solange im Cache, wie die TTL-Zeit eingegeben ist (Standard: 1h).

Hat man eine Domäne, kann man mehrere Unterdomänen einrichten. Die Domäne (Hostname.ms.com) würde dann Untereinträge (Hostname.test.ms.com) enthalten. Der Sinn ist eine weitere Namensstrukturierung. Man kann aber auch eine Unterdomäne delegieren:

Der Unterschied zwischen den beiden ist der, dass eine Unterdomäne von der ms.com verwaltet wird, eine Anfrage nach Hostname.del.ms.com wird weitergeleitet an den zuständigen Namenserver weitergeleitet. Die IP-Adresse und der Namenserver der delegierten Unterdomäne ist dem DNS-Server bekannt (Delegierungseintrag):

Wenn man kein Internet benutzt oder über einen ProxyServer mit dem Web verbunden ist, kann man sich eine Root-Domäne aufbauen. In diesem Fall ist auf dem DNS-Server, der die Root-Zone verwaltet, diese mit einem Punkt gekennzeichnet und der Server hat keine Hinweise auf das Stammverzeichnis (dort stehen die Root-Namen-Server drin). Die Unterdomänenserver haben diese Root-Zone nicht, dafür aber standardmässig die Root-Namenserver der Welt. An dieser Stelle muss ich dann meinen Root-Server hinzufügen. Dieser muss dann aber auch die Delegationseinträge enthalten, damit die Unterdomänen die Verwaltung übernehmen können.

DDNS

Beim dynamischen DNS ist ein DHCP Vorraussetzung.

 

DHCP-Server (W2k) DNS-Server (Zone test.de / W2k) Client
Eigenschaften des DHCP-Servers \ DNS
Haken bei automatisch aktualisieren: dann Netzwerkverkehrverringerung bei W2k-Clients: Untereintrag: auf Clientanforderung aktualisieren (Std.)
für ältere Clients: immer aktualisieren
Haken bei Forward-Lookups bei Lease-Ende löschen (Std.)
Hakenmöglichkeit: Aktualisierung für Clients, die kein DDNS können
Diese Einträge für jede Zone:
RM \Zone \ Allgemein
dynam. Aktualisierung: nein (Std.)
ja
nur gesichert (AD-Std.), d.h. nur autorisierte Rechner
Folgen: A-Eintrag in der forward-Zone
PTR-Eintrag in der reverse-Zone
W2k ohne DHCP: A-Eintrag wird automatisch erstellt
PTR-Eintrag wird nicht erstellt (muss noch geprüft werden, da die Einträge wohl offensichtlich doch erstellt werden)
W2k mit DHCP A-Eintrag wird automatisch erstellt
PTR-Eintrag wird vom DHCP automatisch erstellt
andere BS: ohne DHCP keine Einträge
mit DHCP A- und PTR-Einträge, wenn DHCP immer aktualisiert und für Clients ohne DDNS eingerichtet ist
zur vollen Unterstützung sollte man das DNS-Suffix eintragen (primär oder verbindungsspezifisch, primär Std.)
In den DNS-Clienteigenschaften sollte man das Häkchen für registrieren setzen
Im Standardfall werden die A- und PTR- Einträge bei Lease-Ende gelöscht
 

Clienteinstellung WinME