Sie sind auf Seite 1von 14

Das DNS (Domain Name System)

1. Aufgabe

1

2. DNS Struktur

1

3. Domain Struktur

2

4. Delegation

2

5. Was ist eine Zone?

3

6. Root-NS

3

7. Resolver

4

8. Nameserver

5

8.1 Primary NS & Secondary NS

5

8.2 Caching NS und rekursive Anfragen

6

9. Das Zonefile

7

9.1 SOA (Start of Authority)

7

9.2 Resource-Records

8

9.3. Das „@ “

10

10. Reverse Mapping

11

11. Tools

12

12. NICs und Nameserver

13

12.1. DENIC

13

12.2. Verisign-GRS

13

1. Aufgabe

Das Domain Name System weist einem für Menschen einfach zu merkenden Namen (Domain) eine für eine Maschine verwendbare Nummer (IP) zu.

2. DNS Struktur

Das DNS ist absolut hierarchisch und eine Domain folglich immer „Top Down“, also von der sog. Wurzel (Root) aus, aufgebaut.

Down“, also von der sog. Wurzel (Root) aus, aufgebaut. Version 1.0, 04.12.2001 © 1&1 Internet AG

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 1/14

3.

Domain Struktur

Eine Domain ist im Gegensatz zu der üblichen Leseweise der westlichen Welt von rechts nach links zu lesen und kann durch einen oder mehrere "." in Unterdomains (Subdomains) von jeweils maximal. 63 Zeichen aufgeteilt werden. Die laut RFC2181 erlaubte Gesamtlänge einer kompletten Domain inklusive der Trennpunkte beträgt maximal 255 Zeichen.

inklusive der Trennpunkte beträgt maximal 255 Zeichen. 4. Delegation Einer der Grundgedanken bei der Einführung

4. Delegation

Einer der Grundgedanken bei der Einführung des DNS war es, eine möglichst dezentrale Struktur zu schaffen, die für Störungen so unempfindlich wie möglich ist. Der Großteil dieses Konzeptes wird durch das Weiterreichen der Zuständigkeit für Domains auf unterschiedliche Nameserver, die sog. Delegation, erreicht.

Daraus resultiert, dass nicht ein einziger Nameserver (der ein sehr einfacher Angriffspunkt wäre) für alle Domains zuständig ist, sondern dass die Zuständigkeit für jede einzelne Domain nach dem Top Down Prinzip von der jeweils übergeordneten Domain auf andere Nameserver weitergereicht werden kann.

Domain auf andere Nameserver weitergereicht werden kann. Bei der Delegierung einer Domain auf Nameserver, die keine

Bei der Delegierung einer Domain auf Nameserver, die keine Informationen für diese Domain vorhalten spricht man von einer sog. „Lame Delegation“ Um diesen Zustand zu verhindern, werden von einigen Vergabestellen (wie z.B. DENIC, NIC.AT oder das Schweizer NIC, Switch) die zur Delegierung angegebenen Nameserver vor der Registrierung auf deren Funktionstüchtigkeit geprüft.

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 2/14

5.

Was ist eine Zone?

Durch die Delegation einer Domain auf andere Nameserver können sog. Zonen entstehen. Eine Zone beinhaltet somit alle Informationen zu einem bestimmten Teil oder einer kompletten Domain.

Ein Beispiel hierfür ist die Domain www.providerdomain.de. In diesem Fall wurde die Subdomain providerdomain welche innerhalb der Zone de liegt an die Nameserver nsa.schlund.de und nsa2.schlund.de delegiert. Der Administrator der Zone providerdomain.de hat nun zur größeren Erreichbarkeit des Webservers eine weitere Subdomain mit dem Namen www eingetragen. Da diese Subdomain nicht an neue Nameserver delegiert wurde, sondern innerhalb der Zone providerdomain.de angelegt ist, entsteht hierdurch die Domain www.providerdomain.de, in der Zone providerdomain.de liegt, für die die Nameserver nsa und nsa2.schlund.de zuständig sind.

die die Nameserver nsa und nsa2.schlund.de zuständig sind. 6. Root-NS Derzeit gibt es weltweit 13 Root-Server,

6. Root-NS

Derzeit gibt es weltweit 13 Root-Server, die bis auf drei Ausnahmen alle in den USA stehen.

A.ROOT-SERVERS.NET.

4d39m53s IN A

198.41.0.4

B.ROOT-SERVERS.NET.

4d39m53s IN A

128.9.0.107

C.ROOT-SERVERS.NET.

4d39m53s IN A

192.33.4.12

D.ROOT-SERVERS.NET.

4d39m53s IN A

128.8.10.90

E.ROOT-SERVERS.NET.

4d39m53s IN A

192.203.230.10

F.ROOT-SERVERS.NET.

4d39m53s IN A

192.5.5.241

G.ROOT-SERVERS.NET.

4d39m53s IN A

192.112.36.4

H.ROOT-SERVERS.NET.

4d39m53s IN A

128.63.2.53

I.ROOT-SERVERS.NET.

4d39m53s IN A

192.36.148.17

J.ROOT-SERVERS.NET.

4d39m53s IN A

198.41.0.10

K.ROOT-SERVERS.NET.

4d39m53s IN A

193.0.14.129

L.ROOT-SERVERS.NET.

4d39m53s IN A

198.32.64.12

M.ROOT-SERVERS.NET.

4d39m53s IN A

202.12.27.33

Dem A.ROOT-SERVERS.NET kommt dabei die besondere Aufgabe zu, der sog. Primary Root NS zu sein, von dem alle der 12 weiteren, die sog. Secondary Root NS, die dort vorgehaltenen Daten übernehmen.

Auf den A.ROOT-SERVERS.NET werden derzeit die Topleveldomain Zonen .edu, .gov und .mil. komplett verwaltet. Des weiteren sind die Rootserverinformationen für alle weiteren weltweit delegierten Topleveldomains enthalten.

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 3/14

Das bedeutet, dass eine Topleveldomain, die im weltweiten DNS verfügbar sein soll, in diesen Root- Server aufgenommen werden muss, damit eine Auflösung stattfinden kann. Die letzten Eintragungen waren die im Laufe des Jahres 2001 eingeführten Topleveldomains .info, .biz, .name, und .museum.

Topleveldomains .info, .biz, .name, und .museum . 7. Resolver fähigen Netzwerkrechner vorhandene

7. Resolver

fähigen Netzwerkrechner vorhandene

Betriebssystemskomponente, die die Kommunikation zwischen den verschiedenen Netzwerkapplikationen wie beispielsweise dem Webbrowser und dem für die Nutzung zugewiesenen Nameserver übernimmt.

Ein

Resolver

ist

eine

auf

jedem

TCP/IP

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 4/14

8. Nameserver

Grundsätzlich unterscheidet man zwischen "authoritativem" und "nicht authoritativem" Verhalten von Nameservern. Authoritative Nameserver sind zuständig für eine Domain und können eine Antwort aufgrund der lokal gespeicherten Domaindaten geben, während nicht authoritative Nameserver einen der authoritativen Nameserver befragen müssen, um eine angefragte Domain in eine IP aufzulösen.

Das grundlegende Schema einer Adressauflösung lässt sich am besten anhand der folgenden Grafik erläutern:

sich am besten anhand der folgenden Grafik erläutern: 8.1 Primary NS & Secondary NS Eine Domain

8.1 Primary NS & Secondary NS

Eine Domain wird bei Ihrer Registrierung in der Regel auf mindestens zwei und maximal 13 Nameserver delegiert.

Bei der Aussicht auf 13 mögliche Nameserver stellt sich natürlich die Frage, wie ein Abgleich vonstatten gehen soll. Zur Bewerkstelligung dieser Aufgabe gibt es einen sog. Primary NS welcher als Master immer die Originaldaten vorhält und bis zu 12 weitere Nameservern, die sich der Daten des Primary NS bedienen. Die Änderung von Domaindaten auf einem der Secondary NS hat nur lokale Auswirkungen, führt aber nicht zur Änderung der Domaindaten auf allen delegierten Nameservern.

Trotz dieses doch großen Unterschiedes ist das Antwortverhalten all dieser authoritativen Nameserver identisch, so dass man nicht erkennen kann, ob es sich bei dem jeweilig antwortenden NS um einen Primary oder Secondary handelt.

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 5/14

8.2 Caching NS und rekursive Anfragen

Caching sowie rekursive Anfragen sind Nameservereinstellungen, die nur bei der Benutzung eines Nameservers zur Auflösung einer nicht auf diesen Nameserver delegierten Domain zum Tragen kommen.

Unter Caching versteht man, dass der NS die Zoneninformationen einer von ihm erfragten Domain so lange vorhält (cached) und bei einer an ihn gerichteten Anfrage weitergibt, wie dies ein bestimmter Eintrag innerhalb des Zonefiles vorschreibt. In der Regel ist dies eine Zeitspanne von acht Stunden.

Die Option rekursive Anfrage führt dazu, dass ein NS solange "nachforscht" bis er die angefragte Domain auflösen kann oder feststellt, dass es diese nicht gibt. Ein nicht auf diese Option konfigurierter Nameserver wird lediglich eine Antwort auf Basis der bei ihm eingetragenen Domains geben. Dies verliert natürlich insofern seine Aussagekraft, dass man bei einer negativen Antwort nicht davon ausgehen kann, dass die Domain nicht doch auflösbar ist.

ausgehen kann, dass die Domain nicht doch auflösbar ist. Version 1.0, 04.12.2001 © 1&1 Internet AG

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 6/14

9. Das Zonefile

Das Zonefile könnte man als Gehirn einer Zone bezeichnen, da es alle für eine Zone notwendigen Angaben enthält.

Begin zonefile providerdomain.de ---------------------------------------------------------------------

@

IN SOA

nsa.schlund.de. hostmaster.schlund.de. (

 

2001100201

; serial

8H

; refresh

2H

; retry

1W

; expiry

11h6m40s )

; minimum

 

IN NS

nsa.schlund.de.

IN NS

nsa2.schlund.de.

IN A

212.227.126.74

IN MX

10 mx00.schlund.de.

IN MX

10 mx01.schlund.de.

end zonefile providerdomain.de ---------------------------------------------------------------------

Man kann hierbei zwischen zwei verschiedenen Informationsarten unterscheiden: die sog. SOA-Werte enthalten Informationen über die Behandlung des Zonefiles selbst, alle übrigen Einträge, die sog. Resource-Records, beschreiben bestimmte "Fähigkeiten" einer Domain. Die am häufigsten benutzten Dienste wie NS, A, MX werden untenstehend einzeln erläutert.

9.1 SOA (Start of Authority)

Wie eben schon kurz angerissen, enthalten diese Werte Informationen für Nameserver, die sich auf die administrative Behandlung einer Zone beziehen und nicht auf den eigentlichen Inhalt.

Aufsteigende Zahl, anhand welcher festgestellt werden kann, ob sich ein Zonefile geändert hat oder nicht. Wird bei einer Änderung der Zone diese „Versionsnummer“ nicht hochgesetzt, werden alle anfragenden Secondary Nameserver, die vorgenommenen Änderungen nicht übernehmen, da sie davon ausgehen, dass sich die Zone nicht geändert hat.

Refresh Ist das Zeitintervall (i.d.R. acht Stunden), nach dessen Ablauf ein Secondary beim Primary nachprüfen muss, ob die vorgehaltenen Daten noch aktuell sind.

Falls der Primary bei einem Refresh nicht erreichbar sein sollte, wird nach Ablauf dieses Zeitintervalls von dem jeweiligen Secondary ein erneuter Versuch unternommen, einen sog. Zone Transfer (AXFR) auszuführen.

Expiry Wenn nach dem Ablauf der Zeitspanne noch kein Refresh vorgenommen werden konnte, wird die Zone als "Ungültig" (expired) erklärt. Daraus resultiert, dass der NS für diese Zone keine authoritative Antwort mehr gibt.

Minimum TTL

Die TTL (Time To Live) gibt an, wie lange ein nicht authoritativer NS diese Zone ohne Nachfrage cashen darf.

Retry

Serial

Diese Werte sind dafür verantwortlich, wie schnell eine Änderung der Daten einer Domain weltweit propagiert wird. Bei einer Redelegation einer Domain auf neue Nameserver sind immer die SOA- Records der übergeordneten (delegierenden) Zone in Betracht zu ziehen. Daraus resultiert, dass der normale Dienstanbieter - z.B. bei Änderungen der Nameserver unterhalb einer Topleveldomain - nur bedingt Einfluss auf die zur Propagierung notwendigen Dauer hat.

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 7/14

9.2 Resource-Records

NS-Record Syntax: $domain IN NS $nameserver.

gibt an, welche Nameserver für diese Domain authoritativ sind. Aus der Reihenfolge der angeführten Nameserver lässt sich nicht schließen, welcher Nameserver der Primary und welcher der Secondary ist.

A-Record Syntax: $domain IN A $ip

gibt an, welche IP für diese Domain hinterlegt ist.

Dieser Eintrag muss nicht notwendigerweise gemacht werden; man kann eine Domain beispielsweise durchaus auch nur für Mailservices nutzen - ein A-Record ist dafür nicht notwendig.

Auf der anderen Seite kann man auch mehr als einen Record pro Domain eintragen. Die jeweiligen IPs werden in diesem Fall dann roundrobin, d.h. bei jeder Anfrage eine neuer Record, ausgegeben. Dies ist besonders für größenskalierbare Systeme wichtig.

MX-Record Syntax: $domain IN MX $prioritaetsnummer $mailserver.

gibt an, welche Mailserver für diese Domain zuständig sind. Auch dieser Eintrag ist natürlich keine Pflicht, und es können - wie beim A-Record - auch mehrere Einträge vorgenommen werden.

Eine Besonderheit sind die $prioritaetsnummern, die dem nachfragenden Mailserver Auskunft darüber geben, welchen Mailserver sie zuerst benutzen sollten. Nur wenn der Mailserver mit der höchsten Priorität nicht erreichbar ist, wird der nächst angegebene ausprobiert. Die Priorität der $prioritaetsnummern steigt entgegengesetzt zur Wertigkeit der Zahl, so dass die niedrigere Zahl die höhere Priorität hat.

Eine weitere Besonderheit ist, dass als Mailserver nur Domains angegeben werden dürfen. Ein Eintrag, der auf eine IP verweist, ergibt einen Fehler.

C-Name Syntax: $domain IN CNAME $zieldomain.

CNAME steht für canonical Name und ist eine Weiterleitung auf das Zonenfile der angegebenen Zieldomain. Somit gelten alle Einträge (NS, MX, A) dieser Zieldomain.

Meistens wird dies benutzt, um Domains mit den gleichen Grunddaten leichter pflegen zu können bzw. weiteren, in der selben Zone eingetragenen Domains die selben Daten wie der Zone selbst zuzuweisen.

Weitere Einträge:

IN ?:

Der Eintrag IN steht für die Datenklasse Internet. Es existieren noch weitere Klassen, deren Anwendung allerdings nicht sehr weit verbreitet ist.

Der "." Grundsätzlich werden alle nicht auf einen Punkt endenden Domainname vom einem Nameserver beim Laden des Zonefiles automatisch um den Domainnamen der Zone verlängert.

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 8/14

begin zonefile $domain -----------------------------------------------

IN NS

ns

aus diesem Eintrag wird automatisch

 

IN NS

ns.$domain.

bzw. aus

www

IN A

212.100.100.100

wird

www.$domain.

IN A

212.100.100.100

end zonefile $domain ----------------------------------------------

Um dieses Verhalten zu unterbinden, muss am Ende eines Statements ein „.“ gesetzt werden. Dies ist besonderst wichtig, wenn z.B. Mailexchanger angegeben werden sollen, die nicht innerhalb der selben Zone liegen.

begin zonefile $domain -----------------------------------------------

MX liegt in der selben Zone

IN MX

Oder

IN MX

mx

mx.$domain.

MX liegt nicht in der selben Zone

IN MX

mx.mailexchange.de.

ohne Punkt würde hier ein Fehler entstehen

Aus

IN MX

Wird

IN MX

mx.mailexchange.de

mx.mailexchange.de.$domain.

end zonefile $domain ----------------------------------------------

Ein Domainname der auf einen „.“ endet wird als ein „Fully Qualified Domain Name“ (FQDN) bzw. „Fully Rooted Domain Name“ bezeichnet.

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 9/14

9.3. Das „@“

Das @-Zeichen steht für den Namen einer Zone. Da sich in einem Zonefile alle Resource-Records immer auf den zuletzt genannten Domainnamen beziehen, kann dieses Zeichen zur Unterbrechung und Eintragung weiterer Records direkt unterhalb der Zone benutzt werden.

begin zonefile $domain ----------------------------------------------

@

IN SOA

nsa.schlund.de. hostmaster.schlund.de. (

 

2001100201

; serial

8H

; refresh

2H

; retry

1W

; expiry

11h6m40s )

; minimum

 

IN NS

nsa.schlund.de.

Gilt für die Zone

IN NS

nsa2.schlund.de.

$domain

www

IN A

212.227.126.74

Gilt für die Domain

IN MX

10 mx00.schlund.de.

www.$domain.

IN MX

10 mx00.schlund.de.

ftp

IN A

212.227.126.74

Gilt für ftp.$domain.

@

IN A

212.227.126.74

Gilt für die Zone

IN MX

10 mx00.schlund.de.

$domain.

IN MX

10 mx01.schlund.de.

end zonefile $domain ----------------------------------------------

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 10/14

10. Reverse Mapping

Es gibt derzeit viele Anwendungen (wie z.B. einige Mail Transfer Agents), die es nötig machen, nicht nur eine Domain zu einer IP zu mappen, sondern auch einer IP eine Domain zuweisen zu können.

Deshalb wurde die Domain in-addr.arpa eingeführt, durch die eine IP in eine Domain umgewandelt werden kann, so dass sie sich mit der normalen DNS-Logik auflösen lässt. Die Schreibweise dieser Art von Domain ist dabei analog zur Schreibweise einer "normalen Domain": die höchste Wertigkeit steht auf der rechten Seite. Aus der IP 212.227.126.74 würde also die Domain 74.126.227.212.in-addr.arpa werden.

würde also die Domain 74.126.227.212.in-addr.arpa werden. Das Forward-Mapping und das Reverse-Mapping sind

Das Forward-Mapping und das Reverse-Mapping sind gänzlich von einander getrennte Einträge, die sich nicht bedingen und auch nicht konsistent sein müssen. Es ist also durchaus möglich, dass ein Forwardlookup eine IP ausgibt, die bei einem Reverselookup nicht notwendigerweise die Ausgangsdomain zum Ergebnis hat.

Es ist vor allem zu beachten, dass für die jeweiligen Einträge die jeweils registrierten Nameserver zuständig sind. Dies müssen nicht die selben sein, da beide "Kennungen" von unabhängigen Institutionen delegiert werden. Bei einer Domain handelt des sich dabei um die jeweilige Registry der Topleveldomain (.de: DENIC; .com: Verisign), wohingegen bei einer IP, zumindest in Europa, das Ripe NCC sich zuständig zeichnet.

Um diese Art von Domain auf einem Nameserver abbilden zu können gibt es einen speziellen, bisher noch nicht erwähnten Resource-Record:

Pointer Record Syntax: $in-addr.arpa IN PTR $domain.

Dieser Eintrag wird dafür benutzt, eine IN-ADDR.ARPA Domain in eine „normale“ Domain aufzulösen.

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 11/14

11. Tools

Um die Konfiguration einer Zone in Augenschein nehmen zu können, gibt es verschiedene Programme, die es ermöglichen, die in einem Zonefile vorgehaltenen Daten - genau wie ein Nameserver - abzufragen, um so das Antwortverhalten des befragten NS zu testen. Die meisten dieser Programme sind als Free- oder Shareware im Internet erhältlich bzw. auf einem netzwerkfähigem System bereits installiert.

Die prominentesten Programme diese Art sind derzeit wohl:

Unix

Dig

http://fsck.ch/projects/dns/theory/man_dig.php

host

http://fsck.ch/projects/dns/theory/man_host.php

nslookup

http://fsck.ch/projects/dns/theory/man_nslookup.php

Windows

nslookup

cyperkit

Mac

dns lookup

whatroute

http://www.trumphurst.com/dnsocx/nslookup.phtml

http://cyberkit.net

http://www.macosarchives.com/dns_tools.html

http://www.mac.org/internet/whatroute/

Die Benutzung der oben genannten Tools erfolgt über eine graphische Oberfläche oder aber wie im Fall des Programms „dig“ über die Kommandozeile:

wie im Fall des Programms „dig“ über die Kommandozeile: Version 1.0, 04.12.2001 © 1&1 Internet AG

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 12/14

12. NICs und Nameserver

12.1. DENIC

Die korrekte Konfiguration Ihrer Nameserver ist die Voraussetzung, damit Ihr Domainantrag von der Vergabestelle akzeptiert wird.

Prüfen Sie folgende Einstellungen, bevor Sie einen Domainantrag stellen:

1. Die Nameserver im Domainantrag müssen identisch sein mit den Nameservern in der Zone, die auf diesen angegebenen Nameservern konfiguriert ist.

Gerne gemachter Fehler: Im Domainantrag steht z.B. ns.beispiel.de, wenn man ns.beispiel.de direkt fragt, meint dieser aber gw.beispiel.de -> nicht identisch.

2. Alle angegebenen Nameserver müssen die Zone vorrätig haben. Die Nameserver müssen Anfragen zur Domain beantworten.

3. Die SOA-Werte müssen in folgendem Wertebereich liegen:

refresh

10000 -

86400

retry

1800 -

28800

expire

604800 - 3600000

minmum

40000 - 345600

Diese

SOA-Einstellungen

werden

auf

dem

Primary

Nameserver

verwaltet.

4. Die Serial Number muss das 10stellige Format YYYYMMDDxx haben. Vergessen Sie bitte nicht, die Serial Number zu erhöhen, wenn Sie eine Änderung in der Zone gemacht haben. Nur dann wird diese Änderung von den Secondary Nameservern übernommen. Die Serial Number wird auf dem Primary Nameserver verwaltet.

5. Die angegeben Nameserver dürfen nicht im selben Class-C Netz liegen. Das heisst, deren IP-Adressen dürfen sich nicht nur im letzten Feld der IP-Adresse unterscheiden. 212.227.10.1 und 212.227.10.2 liegen z.B. im selben Class-C Netz.

Unter UNIX können diese Punkte z.B. mit dig@nameserver domain.de any getestet werden.

Fehlerhafte Registrierungen werden von DENIC nach 4 Wochen wieder gelöscht!

12.2. Verisign-GRS

Benutzen Sie für Ihre com/net/org-Domain eigene Nameserver, die innerhalb der Domain com/net/org liegen, ist folgende Besonderheiten zu beachten:

Ein Registrar kann unterhalb einer com/net/org-Domain nur Nameserver anlegen, für die er selbst Registrar ist.

Ein Registrar kann nur seine eigenen Nameserver updaten; benutzt werden können diese jedoch von allen Registraren.

Folgender Fall führt zu einem Fehler:

Sie haben die Domain "bsp.com" über einen anderen Registrar registriert und wollen nun einen bis jetzt noch nicht benutzten Nameserver unterhalb dieser Domain (z.B. "nsneu.bsp.com") verwenden:

Folge: Die Registrierung bzw. das Update der Domain können dann nicht durchgeführt werden, da

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 13/14

der Nameserver nicht registriert werden kann.

Lösung: Veranlassen Sie eine Registrierung des Nameservers über den anderen Registrar oder einen Registrarwechsel der entsprechenden Domains zu uns.

Verwenden Sie Nameserver innerhalb einer anderen Topleveldomain (z.B. DE), so treten diese Probleme nicht auf, da wir diese ohne IP Adresse registrieren können.

Version 1.0, 04.12.2001 © 1&1 Internet AG / Schlund + Partner AG

Seite 14/14