Für Projekte, die prominent in Suchmaschinen auftauchen sollen, ist es notwendig, eine “kanonische” Domain (meist www.domain.de) zu definieren.
http://domain.de soll dabei aber auch funktionieren – und per 301 Redirect auf http://www.domain.de weiterleiten.

Mit Apache2 geht das folgendermaßen:
RewriteCond %{HTTP_HOST} !^www
RewriteRule /?(.*) http://www.%{HTTP_HOST}/$1 [R=301,L]

Cave: Sollten noch andere Subdomains als “www” existieren (mit eigenen Inhalten womöglich), müssen diese mit weiteren Rewritecond-Statements abgebildet werden.

Am letzten Mittwoch (12.05.2010) waren zwischenzeitlich 4 von 6 der Anycast-Nameserver, die die Top-Level-Infrastruktur für die TLD “.de” stellen, außer Betrieb oder lieferten falsche Daten. Insbesondere letzteres war ein massives Problem, da die Antwort “NXDOMAIN” (Not eXistant DOMAIN) auf eine Anfrage nach einem Hostnamen dazu führt, daß z.b. ein Mailserver Mails direkt bounced anstatt sie (wie es richtig gewesen wäre) so lange in die Queue zu packen, bis wieder ein Nameserver antwortet.
Der DNS-Ausfall war für DENIC somit ein ziemlicher GAU.
Laut DENIC lag dieser GAU daran, daß ein Kopiervorgang, der die komplette .de-Zone betraf, mittendrin abbrach und somit die Zonendatei inkonsistent war. Oder, in eigenen Worten:

Hintergrund dafür war, dass im Rahmen der regelmäßigen 2-stündigen
Aktualisierung der Nameservicedaten auf 12 der 16 Servicestandorte durch
einen unterbrochenen Kopiervorgang die Verteilung einer nicht
vollständigen Aktualisierung (sog. Zonendatei) angestoßen wurde.

Wir erkennen hier aber folgendes: Die besten Redundanzen helfen nichts, wenn nicht sichergestellt ist, daß die redundant vorgehaltenen Dienste stets eine korrekte Datenbasis haben – und wenn nicht durch zentral von einer bestimmten Stelle angestoßene Vorgänge (hier: Kopiervorgang, vmtl. rsync o.ä.) ein Single Point of Failure (oder Error) eingeflanscht wird.

Die Frage ist: wie verhindert man das bei einer riesigen Zone wie .de?

Daß der Hoster/Registrar GoDaddy.com sich öffentlichkeitswirksam aus dem chinesischen Markt zurückzieht, ist ein schöner PR-Coup. Der Grund dafür ist jedoch (Zitat Washington Post) recht nachvollziehbar:
In December, China began to enforce a new policy that required any registrant of a new .cn domain name to provide a color, head-and-shoulders photograph and other business identification, including a Chinese business registration number and physical, signed registration forms.

Das treibt den Aufwand in ungeahnte Höhen für den Registrar und ist schlicht nicht wirtschaftlich machbar. Vor dem Hintergrund, daß .cn Domains in der Vergangenheit durchaus auch einmal für wenige Euro verramscht wurden, eine spannende Entwicklung. Aus Sicht des Spam- und Abuse-Bekämpfers auch nicht zu 100% negativ, denn .cn fiel (eben wegen der günstigen Preise und laxen Registrierungsbedingungen) schon als Schrott-TLD auf.
In welchem Domain-Namespace werden die Viagraspammer nun ihre Domains registrieren?

Unter den neuen Bedingungen werden wir bei Filoo wohl auch eher keine .cn Domainregistrierungen mehr abhandeln – nicht, daß da schon viele Leute gefragt hätten…

Ein etwas seltsamer Newsletter kam gestern von der DENIC: Da eine einstweilige Verfügung gegen die deutschen Domainvergabestelle scheinbar aufgehoben wurde, wird die Domain “br.de” am 18.02., 15:00 Uhr registrierbar. Interessenten sollen ein spezielles Fax mit einem Registrierungsformular an eine spezielle Faxnummer schicken, die ausschließlich einseitige Faxe annimmt und danach die Verbindung kappt.

Allerdings weist DENIC darauf hin, dass
Antragsteller, wie stets bei der Domainregistrierung, Sorge dafür tragen
müssen, dass keine Rechte Dritter verletzt werden.

Dieser Passus ist nicht ganz unwichtig, schließlich dürfte der Bayrische Rundfunk (BR) Namens- und vermutlich auch Markenrechte an der Domain “br.de” halten, die nur durch ältere Rechte aufgehoben werden können – etwa, wenn Bernd Romberg, Jahrgang 1942, die Domain für sich beansprucht oder so.

Davon mal abgesehen, klingt das ganze Prozedere zum Einen ein wenig nach “Ätsch bätsch, jetzt seid Ihr Eure einstweilige Verfügung los, nun seht Ihr, was passiert” an die Adresse des Antragstellers (ich nehme mal an, der BR war’s selbst) und zum Anderen nach einem dezentralen Lasttest für die DENIC-Telefonanlage.

Ich werde mich jedenfalls morgen um 15:00 nicht mit dem Besetztzeichen beim DENIC-Fax rumschlagen…

[EDIT: Leider ist der Volltext der Pressemitteilung nicht auf denic.de verfügbar, daher erlaube ich mir, ihn hier abzubilden - schließlich kam die PM über die öffentliche DENIC-Liste. Wer was dagegen hat, bitte bei chris@filoo.de meckern!]

aufgrund einer gegen DENIC ergangenen einstweiligen Verfügung war die
Domain br.de von der im Herbst 2009 erfolgten Freigabe zweistelliger
Domains ausgenommen. Auf den Widerspruch von DENIC wurde diese
einstweilige Verfügung nun aufgehoben. Als Konsequenz gibt DENIC die
Domain br.de am 18. Februar 2010 um 15:00 Uhr (MEZ) zur Registrierung
frei. Damit steht es jedem Interessierten offen, diese Domain auf seinen
Namen registrieren zu lassen. Allerdings weist DENIC darauf hin, dass
Antragsteller, wie stets bei der Domainregistrierung, Sorge dafür tragen
müssen, dass keine Rechte Dritter verletzt werden.

Um Chancengleichheit zu gewährleisten, wird bei der Freigabe ein
besonderes Verfahren angewandt: Akzeptiert werden ausschließlich
Registrierungsaufträge, die ein gesondertes, von DENIC erstelltes
Auftragsformular verwenden. Dieses Formular umfasst eine Seite und steht
auf den DENIC-Webseiten unter
http://denic.de/fileadmin/Domains/Formulare/br_domainauftrag.pdf zum
Download zur Verfügung. Das Formular muss leserlich, vollständig und
korrekt ausgefüllt sowie unterschrieben übermittelt werden.

Die Annahme der Aufträge erfolgt per Fax über eine eigens für diesen Zweck
eingerichtete Sonderrufnummer. Diese lautet +49 69 24246982. Der Faxserver
ist für den Empfang von maximal einer Seite je Sendung konfiguriert und
beendet danach selbsttätig die Verbindung. Interessenten müssen daher
sicherstellen, dass ihr Faxgerät die Sendung nicht etwa mit einem
Deckblatt versieht oder auf zwei Seiten verteilt. Die genannte Faxnummer
wird 24 Stunden vor dem offiziellen Registrierungs-Startzeitpunkt
freigeschaltet. Ein vorheriges Testen der eigenen Faxkonfiguration ist
somit gegebenenfalls möglich.

Die Domain wird dem Antragsteller zugesprochen, dessen korrekt
ausgefüllter und unterschriebener Antrag per Fax als erster nach dem
Stichzeitpunkt 15:00 Uhr (MEZ) – synchronisiert mit dem Zeitserver von
DENIC (ntp1.denic.de) – vollständig eingeht (first come, first served).
Durch Übernahme in die Domain-Datenbank wird die Registrierung
anschließend durch DENIC faktisch vollzogen und ist danach über die
automatischen Informationsdienste (whois etc.) nachvollziehbar.

Der erfolgreiche Antragsteller wird durch DENIC informiert und muss bis
zum 1. März 2010 (eingehend bei DENIC per Brief oder Telefax) erklären,
welches DENIC-Mitglied die Domain künftig verwalten soll. Andernfalls geht
die Domain automatisch in die Verwaltung von DENICdirect über.

Für weitergehende Auskünfte steht Ihnen DENIC Support gerne zur Verfügung.

Mit freundlichen Grüßen

Stefanie Welters
Business Services / Unternehmenskommunikation

–

DENIC eG
Kaiserstraße 75-77
60329 Frankfurt am Main
GERMANY

E-Mail: presse (at) denic.de
Fon: +49 69 27235-274
Fax: +49 69 27235-235
http://www.denic.de

Angaben nach § 25a Absatz 1 GenG:
DENIC Domain Verwaltungs- und Betriebsgesellschaft eG (Sitz: Frankfurt am
Main)
Vorstand: Sabine Dolderer, Marcus Schäfer, Carsten Schiefner, Dr. Jörg
Schweiger
Vorsitzender des Aufsichtsrats: Elmar Knipp
Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht
Frankfurt am Main

Ich habe mir mit PHP eine kleine Site gebastelt, auf der ich von unterwegs grundlegende Netztools zur Verfügung habe.
Unter ipv4.mobi gibts:

• ein “Was ist meine IP”-Tool (bei den mehrfach geNATteten Anbindungen im Mobilfunk essentiell)
• dazu Traceroute
• AS-Informationen
• und Reverse DNS Lookup.

Später werde ich wohl auch noch ein paar Funktionen wie BGP Routing einbauen (im Sinne eines “Looking Glass”), denn auch das kann man von unterwegs gut brauchen.

Auf der Suche nach Informationen über das Individual Network, in dem alle Filoo-Leute vor Gründung der Filoo GmbH tätig waren (PriOWL – Privates Internet OWL), fand ich einen Artikel bei Google Groups, den ich für die Nachwelt aufbewahren möchte. Er dokumentiert die Geschichte des Individual Network e.v., das sich leider 2000 aufgelöst hat.

Dieser Artikel stammt ursprünglich von Martin Schulze aus der Usenet-Gruppe de.org.in, 02.12.1998.

Informationen zum ‘Individual Network’ (IN)

1.  Vorbemerkung
2.  Ideen und Ziele des Individual Network
3.  Vorteile durch die Teilnahme am Individual Network
4.  Geschichte des Individual Network
5.  Das Praesidium
6.  Beirat und erweiterter Vorstand
7.  Arbeitskreise
8.  Leistungen
9.  Kosten
10. Beitritt und Antragsverfahren fuer neue Betreibergemeinschaften
11. Teilnahme auslaendischer Betreibergemeinschaften
12. Netiquette
13. Wichtige EMail-Adressen im Individual Network
14. Offizielle Adresse des Individual Network e.V.
15. Verweise auf andere Texte

1. Vorbemerkung

Dieser Text kann durch Entscheidungen auf Mitgliederversammlungen oder durch Beschluesse des Praesidiums veraltet sein. Dinge, die beschossen wurden und nicht in diesem Text auftauchen, haben trotzdem Gueltigkeit. Die Versionsnummer der IN-Document-ID [1] und das angegebene Datum geben ueber die Aktualitaet dieses Textes Auskunft.

2. Ideen und Ziele des Individual Network

Die vorrangigen Ziele des Individual Network (IN) sind:

• Die Schaffung und Sicherung von guenstigen Zugaengen zu den internationalen Kommunikationsnetzen (Konnektivitaet) fuer Privatpersonen in Deutschland.
• Foerderung von Wissen und regionalen Strukturen zur nichtkommerziellen Netznutzung.
• Erschaffung einer stabilen und kostenguenstigen Infrastruktur bzw. rechtliche Absicherung bei gemeinsamer Nutzung mit anderen Organisationen.
• Foerderung leistungsfaehiger Netzanwendungen (z.B. TCP/IP-Dienste) mit dem Bestreben, diese auch privaten Nutzern moeglich und erschwinglich zu machen.
• Aufbau eines “Network Management” zwischen den Domains, um Verbindungen zuverlaessig, kostenguenstig und schnell zu organisieren.
• Die Vertretung privater Netznutzer und deren Interessen nach aussen.

Dem Individual Network e.V. gehoeren Betreibergemeinschaften an[2], die Netzdienste zur privaten, nichtkommerziellen Nutzung anbieten. Einzelpersonen sind nicht direkt Mitglied im Individual Network, sondern sind Teilnehmer in den Betreibergemeinschaften, die groesstenteils regional organisiert sind. Der Individual Network e.V. vermittelt Interessenten an diese Betreibergemeinschaften.

Die Betreibergemeinschaften, oft auch “Domains” genannt, benennen einen oder mehrere Vertreter, die an den verschiedenden Gremien des Individual Network teilnehmen und die Domainteilnehmer ueber die wichtigsten Belange des Individual Network informieren sollen.

Mit “Mitgliedern im Individual Network” sind die Betreibergemeinschaften gemeint, die dem Individual Network e.V. beigetreten sind. Unter den “Teilnehmern des Individual Network” werden alle Nutzer von Individual Network Leistungen verstanden, insbesondere auch die Teilnehmer in den regionalen Betreibergemeinschaften. Die “Teilnehmer” sind nicht Mitglied im Individual Network e.V. und werden von der eigenen Betreibergemeinschaft vertreten und informiert. Auf Anfrage beraet der Info-Kontakt des Individual Network Interessenten und vermittelt eine geeignete Betreibergemeinschaft.

3. Vorteile durch die Teilnahme am Individual Network

Die grossen internationalen Kommunikationsnetze (wie z.B. das Internet) erfordern heute einigen administrativen, technischen und finanziellen Aufwand zur Teilnahme. Als privater Nutzer ist es kaum moeglich, alle Dinge selbst zu realisieren. Aus diesem Grund ist es guenstig, wenn man sich mit Gleichgesinnten zu einer groesseren Gruppe zusammenschliesst, dort Erfahrungen austauscht und die Vorarbeiten der anderen nutzt.

Das Individual Network hat inzwischen einige Jahre Erfahrung beim Anschluss von Privatpersonen gesammelt und bietet in den meisten Gegenden Deutschlands kostenguenstige Zugangspunkte an, die nur durch eine grosse Zahl von Teilnehmern realisiert werden konnten. Durch die steigenden Teilnehmerzahlen war es dem Individual Network in der Vergangenheit moeglich, die Dienste zu verbessern, zuverlaessiger zu machen und neue Dienste anzubieten – bei sinkenden Preisen. Das Individual Network hat ausschliesslich Privatpersonen als Nutzer und geht deshalb mit der Preis- und Netzwerkpolitik auf deren Beduerfnisse ein. In vielen Bereichen war es moeglich, Pauschalpreise anzubieten und so den Teilnehmern die Angst vor einer hohen Rechnung durch unbedarfte oder falsche Netznutzung zu nehmen. Fuer viele private Teilnehmer war die Netznutzung erst durch die stabilen Preise moeglich, die nur eine so grosse Gemeinschaft wie das Individual Network bieten kann.

Das Individual Network hilft auch den Betreibergemeinschaften bei den administrativen Aufgaben (z.B. Beantragung einer Domain) sowie bei den technischen Aufgaben (z.B. Betrieb eines Nameservers). Das Individual Network vertritt ausserdem die Mitgliederinteressen gegenueber den Providern, also den Anbietern von Netzdiensten, mit denen das Individual Network Vertraege abschliesst. Dadurch ist es den Betreibergemeinschaften moeglich, lokale und kostenguenstige Anbindungen zu nutzen und eine eigene regionale Infrastruktur aufzubauen.

Der Teilnehmer an einer Betreibergemeinschaft kann die Netzdienste meist ohne grossen administrativen Aufwand nutzen. Die noetigen Eintragungen beim DE-NIC (Deutsches Network Information Center), bei den Providern, bei RIPE und in den Nameservern wurden bereits durch das Individual Network veranlasst.

Das Individual Network hat auch das Bestreben, die Netzdienste sicherer und zuverlaessiger zu machen. Dazu gehoert auch, dass die Dienste nicht nur bei einem Provider eingekauft werden, sondern Vertraege mit mehreren Anbietern geschlossen werden, um die Abhaengigkeit zu verringern. So kann das Individual Network z.B. auch das WiN (Wissenschaftnetz der deutschen Hochschulen) und die Infrastruktur mehrerer Provider mitnutzen.Desweiteren vertritt das Individual Network die Interessen von Privatpersonen
in diversen Gremien und Organisationen, wie z.B. dem Deutschen Forschungsnetz.

4. Geschichte des Individual Network

Am 4. Mai 1991 fand in der Freien Universitaet Berlin ein Treffen mehrerer Leute (Vera Heinau, Ralf Moritz, Heiko Schlichting, Frank Simon, Thomas Wieske) mit dem Ziel statt, fuer die seit 1990 vor allem in Berlin, Hamburg und Oldenburg bestehenden Gruppen privater Netznutzer eine weitere Verbesserung der Konnektivitaet im Rahmen der internationalen Netze, die Erweiterung des Dienstangebots und eine Verringerung der Teilnahmekosten zu erreichen.

Das Ergebnis dieses Treffens hat den Namen Individual Network (IN) bekommen. Das Individual Network war kein neues Netz im herkoemmlichen Sinne, sondern ein Dach fuer die bestehenden Domains, die damals am deutschen EUnet in Dortmund teilgenommen haben. Die Gruendungsdomains des Individual Network sind Hanse.DE, IN-Berlin.DE, Maus.DE und North.DE, die sich aus Gruenden der Vereinfachnung und der Vereinheitlichung der Tarife sowie des Leistungsangebotes zu einem Interessenverband zusammengeschlossen haben.

Dieser Zusammenschluss hat es ermoeglicht, gegenueber dem deutschen EUnet als gemeinsamer InterEUnet-Teilnehmer aufzutreten. Aufgabe des Individual Network sollte sein, die Teilnahme an privaten de-Domains preiswert zu realisieren und die Gruendung neuer ‘de’-Domains auf der Basis der Privatpersonenregelung mit dem deutschen EUnet zu erleichtern, sowie den Aufbau von privaten Internetnetzen zu unterstuetzen und fuer Privatpersonen von den Kosten her akzeptabel zu gestalten.

Bereits ein Jahr spaeter war das Individual Network auf 21 Domains angewachsen und in der Lage, mit weiteren Providern (XLink, DFN) zu sprechen und mit dem EUnet Neuverhandlungen zu fuehren. Diese haben dazu gefuehrt, dass das Individual Network bei allen drei Providern (DFN, EUnet und XLink) Kunde wurde und als DFN-Mitglied eigene WiN-Anschluesse besitzt.  Fuer diese Vertraege mit den Providern und der Telekom war es notwendig, einen geeigneten rechtlichen Rahmen zu schaffen, was mit der Vereinsgruendung des “Individual Network e.V.” am 21.06.1992 in Oldenburg umgesetzt wurde [3][4].

Ursprueglich war nicht vorgesehen, den Verein mit weitergehenden Aufgaben zu betrauen. Durch das grosse Wachstum des Individual Network und die immer komplexer werdenden rechtlichen und finanziellen Aufwendungen wurden jedoch bis heute zunehmend Taetigkeiten und Kompetenzen beim Verein und dessen Vorstand angesiedelt.

Seit dem 01.01.1993 sind desweiteren die sogenannten “Dortmunder Beschluesse” [5][6] in Kraft. Das Individual Network hat sich dort zu den Themen “Regionalisierung”, “Internationalisierung” und zur inneren und aeusseren Struktur weitere Gedanken gemacht.

Nach der Mitgliedsversammlung 1993 in Muenchen gab es weitere Veraenderungen im Individual Network. So wurden z.B. die Mehrwertdienste beim DFN eingekauft. Dies beinhaltet neben der internationalen Internet-Anbindung auch den Mailverkehr ins EARN/Bitnet und X.400-Gatewaying. Desweiteren wurde ein Vertrag mit einem vierten Provider (Belwue) zur Verbesserung der Konnektivitaet in Baden-Wuerttemberg geschlossen. Der Verein hat ausserdem ein neues Gremium, den sogenannten Beirat,
bekommen, der zusammen mit dem Vorstand den “erweiterten Vorstand” bildet und ein Bindeglied zwischen Vorstand und Praesidium darstellt. Seit Mai 1994 hat das Individual Network eine eigene Geschaeftsstelle in Oldenburg, die insbesondere eine feste Adresse fuer die Vertragspartner und den ersten Anlaufpunkt fuer Interessenten darstellt.

Anfang 1998 besteht das Individual Network aus etwa 60 Domains und hat circa 300.000 Endnutzer (geschaetzt), die die Kommunikationsdiente in Anspruch nehmen.

Die Mitgliederversammlung 1995, die im Februar 1995 in der Naehe von Jena stattgefunden hat, hat sich fuer eine Verstaerkung der Geschaeftsstelle und fuer die Uebernahme der Providerverkehrsgebuehren ausgesprochen [15]

Die Mitgliederversammlung 1997, die im Maerz 1997 in Ilsenburg, im Harz, stattgefunden hat, hat sich fuer eine Verstaerkung der Aktivitaeten im gesellschaftspolitischen Spektrum ausgesprochen.

5. Das Praesidium

Das Praesidium [7] ist das Gremium des Individual Network (IN), welches die richtungsweisenden Entscheidungen trifft und eine Art staendig tagende Mitgliederversammlung darstellt. Zu diesem Zweck benennen alle Mitglieder (Domains) des Individual Network einen oder mehrere Vertreter, die in die Praesidiums-Mailingliste eingetragen werden. Vorstand und Beirat des Individual Network handeln nach den Vorgaben des Praesidiums (und der Mitgliederversammlung). Das Praesidium mit seinen derzeit ueber 100
Teilnehmern ist somit eines der wichtigsten Gremien im Individual Network. Es sollten daher dort nur wichtige Dinge zum Individual Network besprochen werden oder Fragen, die mehrere Domains betreffen.

Das Praesidium setzt sich aus den Vertretern der einzelnen Betreibergemeinschaften (Domains) im Individual Network zusammen. Dabei hat jede Domain genau einen “Domainverantwortlichen” (DV), naemlich den im Aufnahmeantrag angegebenen “administrativen Vertreter”, sofern der Geschaeftsstelle kein Wechsel mitgeteilt wurde. Ausserdem kann eine Domain dem Listenverwalter weitere Teilnehmer benennen, die als “kooptierte Mitglieder” (KMs) eingetragen werden und ebenfalls Vertreter der Domain gegenueber dem Individual Network sind. Der einzige Unterschied zwischen DV und KMs besteht in der Moeglichkeit, weitere KMs fuer eine Domain zu benennen. Dieses kann nur der Domainverantwortliche (DV) einer Domain machen. Er sollte die benannten Personen dafuer aber in die Gepflogenheiten des Individual Network einfuehren und auch ueber die in der Vergangenheit gefuehrten Diskussionen berichten, so dass ein KM nicht unwissend in die Praesidiumsliste aufgenommen wird. Da in der Praesidiumsliste oft sehr viele Kenntnisse verausgesetzt werden und ein solches Gremium fuer Anfaengerfragen der falsche Platz ist, sollte der DV diese Aufgabe ernst nehmen. Weitere Unterschiede zwischen DV
und KMs einer Domain gibt es nicht. Es wird hiermit nochmal ausdruecklich darauf hingewiesen, dass die KMs auch das Wahlrecht fuer die Domain wahrnehmen koennen und dass bei mehrfacher Stimmabgabe fuer eine Domain die zuletzt abgegebene Stimme zaehlt.

Bei Entscheidungen im Praesidium ist zunaechst eine Konsensentscheidung anzustreben. Gelingt dieses nicht, so kann auf Antrag von mind. 7 Domains eine Abstimmung eingeleitet werden, wobei die Stimmanteile der Domains wie in Paragraph 8a der Satzung des Individual Network [10] festgelegt werden. Wahlaufrufe im Praesidium werden ueblicherweise mit einem speziellen Formular [13] durchgefuehrt, in dem Name und Nummer der Abstimmung angegeben sind. Zur Erleichterung der Auswertung sollte das
in dem Formular vorgegebene Format des elektronischen Stimmzettels eingehalten werden. Ein Vorschlag gilt als angenommen, wenn sich nicht mehr als 25% der moeglichen Stimmen gegen diesen ausgesprochen haben und sich die einfache Mehrheit der abgegebenen Stimmen fuer diesen ausgesprochen hat.

Bei Abstimmungen kann jeder Vertreter einer Domain im Praesidium das Stimmrecht wahrnehmen, so dass eine vorherige Koordinierung innerhalb der Domain angeraten wird. Die Abstimmungsdauer betraegt in der Regel drei Wochen, so dass jede Domain ausreichend Zeit haben sollte, eine Entscheidung zu finden. Einer Wahl geht ueblicherweise eine Diskussionsphase im Praesidium voraus (ggf. auch eine Empfehlung von Vorstand und Beirat). Fuer die Ansetzung einer Wahl sind laut Satzung sieben Mitglieder noetig, die
sich fuer eine Wahl aussprechen. Wahlen werden nur noetig, wenn in der Diskussionsphase kein Konsens erzielt werden konnte (sonst: Konsensentscheidung). Wahlen werden im Praesidium normalerweise mit einem speziellen Formular [13] durchgefuehrt, damit eine einfache Auswertung erfolgen kann.
Wahlen erhalten eine eindeutige Wahlnummer und einen Wahlnamen, um sie ggf. von anderen Wahlen im Praesidium unterscheiden zu koennen. Die Stimmen
werden in der Regel an in-v…@individual.net geschickt. Zur Zeit sind Wahlen im Praesidium selten (1-2 pro Jahr).

Die Aufgabe der Domainvertreter (DV + KMs) ist neben der Mitbestimmung im Praesidium auch die Information der eigenen Domainteilnehmer ueber grundlegende Entwicklungen und Entscheidungen im Individual Network in einer Form, dass diese auch verstaendlich werden.

Bei den Mitgliedern der Praesidiumsliste handelt es sich um die Domainvertreter gegenueber dem Individual Network und nicht um die Infokontakte der Domains. Anfragen nach Zugaengen sollten an in-i@individual.net weitergeleitet werden. Die Infokontakte der Domains werden auch in einer Liste in der Newsgruppe ‘de.org.in’ veroeffentlicht.

6. Beirat und erweiterter Vorstand

Mit Beschluss der Mitgliederversammlung 1993 wurde im Individual Network e.V. in Beirat als neues Gremium eingefuehrt. Der Beirat bildet zusammen mit dem Vorstand des sogenannten “erweiterten Vorstand” und kann Entscheidungen in gewissem Umfang treffen. Dadurch die wird mittlerweile sehr grosse Runde des Praesidiums von kleineren Entscheidungen entlastet und die Handlungsfaehigkeit erhoeht. Grundlegende und richtungsweisende Entscheidungen bleiben weiterhin dem Praesidium vorbehalten. Bei wichtigen Fragen oder bei Uneinigkeit wird das Praesidium vom erweiterten Vorstand eingeschaltet.

7. Arbeitskreise

Aufgrund der positiven Erfahrungen, die 1993 mit den “inoffiziellen” Arbeitskreisen gesammelt wurden, sind diese auf der Mitgliederversammlung 1993 auch in der Satzung aufgenommen worden. Arbeitskreise koennen bei Bedarf eingerichtet werden und ermoeglichen die Diskussion eines Themas unter den Interessierten. Arbeitskreise informieren
und beraten das Praesidium und sollten fuer diesen Zweck moeglichst einen Sprecher bestimmen. Jede Domain kann Vertreter in die Arbeitskreise entsenden. Der Vorstand kann auch andere Netzteilnehmer berufen.

8. Leistungen

Das Individual Network stellt den Betreibergemeinschaften internationale Konnektivitaet zur Verfuegung und vertritt die Interessen der Mitglieder gegenueber den Providern und anderen Gremien (z.B. DE-NIC, RIPE). Das Individual Network unterstuetzt den Aufbau von neuen regionalen Betreibergemeinschaften, hilft in der Aufbauphase und vermittelt bei der Anbindung an andere Organisationen (z.B. Universitaeten). Das Individual Network betreibt Networkmanagement und stellt konkrete Leistungen (z.B. Domain Name Service) bereit. Aus Gruenden des Networkmanagements kann das Individual Network auch bei  Angelegenheiten der Betreibergemeinschaften eingreifen, wie bei der Namenswahl oder der regionalen Abdeckung.

Da dem Individual Network auch einige Betreibergemeinschaften angehoeren, deren Netze nicht auf IP- oder UUCP basieren, bemueht sich das Individual Network auch um funktionierende Relays und Gateways zu den anderen Protokollwelten.

Die Mitglieder des Individual Network sind ausschliesslich organisatorische der regionale Betreibergemeinschaften (Domains). Um Teilnehmer in der fuer die Region zustaendigen Betreibergemeinschaft zu werden, sollte man sich direkt an deren Info-Kontakt wenden und sich um Anschluss bemuehen. Den Namen der richtigen Betreibergemeinschaft und die Adresse des Infokontaktes behaelt man per E-Mail von “IN-I@Individual.NET” oder per Brief/Fax/Telefon von der Geschaeftsstelle (Adresse siehe unten).

Mitglieder des Individual Network  koennen unter anderem folgende Leistungen in Anspruch nehmen:

• Mails:      Ohne Volumenbeschraenkung und ohne zusaetzliche Kosten weltweit.
• News:       “all.all” und viele internationalen und nationalen NetNews-Hierachien ohne zusaetzliche Kosten.
• Internet:   Das Individual Network ist InterEUnet-, XLink, Belwue und DFN/IP-Teilnehmer mit Mehrwertdienstvertrag. Demzufolge hat jeder Teilnehmer am Individual Network die Moeglichkeit, direkt oder indirekt Internetdienste in Anspruch zu nehmen, sofern die entsprechenden technischen Voraussetzungen erfuellt sind. Allerdings koennen dadurch Vereinbarungen zwischen Domains und Universitaeten oder anderen Institutionen bzw. zwischen Domains und den POPs notwendig sein. Im Individual Network werden auch schon eigene Internet-Strukturen geschaffen, so z.B. via ISDN und ueber die WiN-Anschluesse.
• C Netze:    Betreibergemeinschaften, die an einem direkten Internet- schluss ueber TCP/IP interessiert sind, koennen von dem jeweiligem Providerkontakt ein oder mehrere Class C Netze erhalten. Der sparsame und vernuenftige Umgang mit diesen Netzen wird vorausgesetzt. Bei manchen Providern kann es zu zusaetzlichen Kosten je geroutetem Class C Netz kommen. Diese Kosten werden an die Betreibergemeinschaft weitergegeben und es sollte im Interesse der Domain liegen, den Kassenwart des Individual Network rechtzeitig ueber die Eintragungen zu informieren, um hohe Nachzahlungen zu vermeiden.
• Bitnet:     Das Individual Network hat die Dienste beim deutschen Gateway zu BITNET/EARN eingekauft. Dadurch kann unnoetiger Auslandstraffic vermieden werden und die Individual Network Domains sind aus dem Bitnet schnell und zuverlaessig erreichbar.
• WiN:        Das Individual Network besitzt Anschluesse an das Wissenschafts- netz (WiN) des DFN. Durch den WiN-Vertrag und die eigenen WiN-Anschluesse ist es moeglich, auch andere WiN-Anschluesse und Leitungen mitzunutzen, sofern der Anschlussinhaber zustimmt. Dadurch ist es rechtlich moeglich, dass sich eine Domain an eine Universitaet in ihrer Region anschliesst und ueber diese versorgt wird. Das Individual Network und der DFN-Verein helfen im Rahmen ihrer Moeglichkeiten, damit dieses in der Praxis auch wahrgenommen werden kann. Ein Anspruch an die Universitaet, deren WiN-Anschluss mitnutzen zu koennen, besteht aber nicht.
• X.400:      Die Teilnahme an deutschen und europaeischen X.400-Netzen ist durch die DFN-Mitgliedschaft und WiN-Teilnahme moeglich, durch den Mehrwertdienstvertrag ist der Uebergang zu X.400 gesichert.
• Support:    Bei technischen, administrativen und netzpolitischen Fragen werden die entsprechenden Ansprechpartner der Domains oder des Individual Network nach besten Kraeften versuchen zu helfen.
• DFN:        Das Individual Network ist Mitglied im “Verein zur Foerderung eines deutschen Forschungsnetzes e.V.” (DFN-Verein) und vertritt dort die Interessen der privaten Netznutzer. Aufgrund der DFN-Mitgliedschaft besteht auch die Moeglichkeit, WiN-Anschluesse zu mieten.
• XLink:      Der Provider XLink/NTG betreibt inzwischen ebenfalls mehrere POPs in Deutschland, ueber die Individual Network Domains angeschlossen werden koennen. Auch hier muss zwischen der Domain und dem POP eine Vereinbarung geschlossen werden.
• Belwue:     In Baden-Wuerttemberg wird von der Universitaet Stuttgart ein eigenes Landesnetz (“Belwue”) betrieben. Das Individual Network hat auch mit diesem Anbieter einen Vertrag abgeschlossen und hat so die Moeglichkeit auch die Anschlusspunkte von Belwue zu nutzen.

Fuer alle Provider gilt: die Domains (und die Antragsteller) sollten unbedingt zuerst mit dem Providerkontakt des Individual Network sprechen und sich keinesfalls direkt an den Provider wenden. Saemtliche Absprachen sind von den Providerkontakten zu fuehren. Lediglich die Verhandlungen mit einem POP oder einer Universitaet (also den Einrichtungen vor Ort) sind von der Domain selbst zu fuehren. Auch in solchen Faellen ist es aber sehr ratsam, den entsprechenden Providerkontakt des Individual Network vorher zu befragen, da dort sehr viel Erfahrung vorhanden und auch die Vertragslage bekannt ist.

9. Kosten

Die Gebuehren, die ein Teilnehmer einer Betreibergemeinschaft an diese entrichtet, setzen sich ueblicherweise aus zwei Anteilen zusammen: dem Individual Network Anteil und dem Anteil fuer die lokale Infrastruktur, die die Betreibergemeinschaft unterhaelt.

Im Folgenden geht es ausschliesslich um den Individual Network Anteil, da ja die anderen Kosten ausschliesslich im Ermessen der Betreibergemeinschaft liegen und es da aufgrund der unterschiedlichen Anbindung, dem Leistungsspektrum und lokalen Anschlussmoeglichkeiten zu grossen regionalen Unterschieden kommen kann. Die Teilnehmer einer Domain zahlen die Beitrage an ihre Betreibergemeinschaft, die wiederum den Anteil fuer das Individual Network gesammelt an den IN-Kassenwart abfuehrt. Um den tatsaechlichen Preis fuer einen Anschluss zu erfahren, sollte man sich also mit der entsprechenden Betreibergemeinschaft in Verbindung setzen und die Preise dort erfragen. Fuer das gesamte Individual Network kann dieses nicht einfach beantwortet werden.

Das Individual Network laesst den Domains bei der Preisgestaltung einige Freiheiten. So wird zum Beispiel nicht in allen Domains der Individual Network Anteil gleichfoermig auf die Teilnehmer umgelegt. Mit Hilfe des Preises haben die Domains die Moeglichkeit, bestimmte Dienste oder Strukturen zu foerdern (IP, Mailboxen etc), wenn dieses in ihremInteresse liegt. Haeufig profitieren von einer IP-Anbindung der Verteiler- rechner auch die anderen Domainteilnehmer, so dass man sich z.B. vorstellen kann, dass diese Struktur gefoerdert wird.

Der Individual Network Anteil der Kosten besteht aus einer “Mindestgebuehr”, die pro Rechner entrichtet werden muss. Alle Individual Network Domains sind aufgefordert, jeden Monat (am besten zum 20. des jeweiligen Monats) die Anzahl der teilnehmenden Rechner (“Sites”) zu melden [8]. Der niedrigst moegliche Betrag, den eine Betreibergemeinschaft an das Individual Network abfuehren muss, besteht aus dem Produkt von Siteanzahl und der aktuellen Mindestgebuehr. Nimmt eine Individual Network Domain aber besonders kostenintensive Dienste (z.B. IP) stark in Anspruch, so ist diese Domain gehalten, einen “freiwilligen Mehrbeitrag” zu leisten, der ebenfalls in der monatlichen Meldung anzugeben ist. Die Zahlung und die Hoehe des Mehrbeitrags ist von der Domain selbst festzulegen, wobei aber bedacht werden sollte, dass es sich beim Individual Network um eine
Interessengemeinschaft handelt und dieses nur funktionieren kann, wenn man das Individual Network nicht auf Kosten der anderen Domains ausnutzt.  In der Vergangenheit hat sich das Verfahren aus Mindestgebuehr und freiwilligem Mehrbeitrag als sehr leistungsfaehig und flexibel herausgestellt. Grundsaetzlich waere es auch moeglich, dass der Vorstand einen Mehrbeitrag fuer eine Domain festsetzt. In der Vergangenheit ist das allerdings nicht noetig gewesen.

Beim freiwilligen Mehrbeitrag ist auch die Domainstruktur zu beruecksichtigen. Besteht eine Domain ueberwiegend oder ausschliesslich aus Mailboxen (Vielbenutzersystemen), so ist ebenfalls die Zahlung eines Mehrbeitrages empfohlen. Ebenfalls beruecksichtigt werden sollte die Definition einer “Site” in der jeweiligen Domain. Eine exakte Definition
durch das Individual Network steht noch aus und ist aufgrund der unterschiedlichen Technologie in den Domains und dem stark unterschiedlichen Dienstangebot bisher nicht moeglich gewesen. Ob eine starre Definition den dynamischen Strukturen des Individual Network ueberhaupt gerecht werden kann, ist bisher voellig offen.

Vereinfacht ausgedrueckt kann eine Site im Sinne des Individual Network als ein Rechner gesehen werden, zu dem Netzdienste automatisiert uebertragen werden. Dieser Automatismus ist ueblicherweise UUCP, SLIP, PPP, ZConnect oder eines der FidoNet/MausNetz-Transportmechanismen. Systeme, die Online-Dienste in einer Mailbox in Anspruch nehmen, sind keine Site im Sinne des Individual Network. Allerdings ist eine Domain mit einem hohen Anteil solcher Mailbox-Systeme gehalten, einen freiwilligen Mehrbeitrag an das Individual Network zu leisten. Im Individual Network gibt es auch organisatorische Betreibergemeinschaften klassischer deutscher Mailbox-Netze (maus.de, zer.de, fido.de), wo zum Teil der Sitebegriff aufgrund der anderen Technik und der unterschiedlichen Nutzungsmoeglichkeiten etwas modifiziert wurde. Langfristig wird angestrebt, auch diese
Systeme in die regionalen Domains des Individual Network zu ueberfuehren, so dass eine stabile und preisguenstige Vorort-Versorgung genutzt werden kann und eine einheitliche Sitebewertung in einer Region erfolgt. Beim Z-Netz (zer.de) ist dieses bereits weitesgehend vollzogen. Die regionalen Domains sind aufgefordert, diese Migration zu unterstuetzen.

Die Hoehe der Mindestgebuehr wird im Individual Network durch die Mitgliederversammlung oder das Praesidium aufgrund des Berichts des Kassenwarts und des Finanzierungsplans festgelegt. Dabei werden die laufenden und geplanten Ausgaben sowie die bestehenden und erwuenschten Ruecklagen beruecksichtigt. Aenderungen bei der Mindestgebuehr sind selten. Das Individual Network ist stolz darauf, dass in der Vergangenheit die Preise immer gesenkt werden konnten, obwohl das Angebot kontinuierlich gestiegen ist. Trotz Inflationsrate, der gestiegenen Ansprueche, der hoeheren Nutzung, der verbesserten Zuverlaessigkeit, dem breiten Angebot, den verbesserten Diensten, zusaetzlicher Vertraege und der erreichten Unabhaengigkeit betragen die Preise nur noch etwa 25% der Gruenderzeit. Die Mindestgebuehr pro Site betraegt heute (Januar 95)
nur noch 7 DM/Monat – unabhaengig vom Volumen der Nutzung, der verwendeten Technik und der Anzahl der Benutzer. Durch diese Preisentwicklung ist es vielen Betreibergemeinschaften moeglich geworden, eine leistungsfaehige lokale Infrastruktur zu finanzieren und auch IP-Dienste anzubieten. Der Anteil fuer die lokale Infrastruktur (ISDN-Leitungen, Standleitungen, Rechner, Modems, Telefonleitungen) der Betreibergemeinschaft ist haeufig hoeher als der IN-Beitrag.

Von den eigenommenen Beitraegen der Teilnehmer bezahlt das Individual Network die laufenden Kosten durch die Providergebuehren (zur Zeit Belwue, DFN, EUnet, XLink), die WiN-Leitungen, die Mehrwertdienste, die DE-NIC-Gebuehren sowie die Ausgaben fuer die Geschaeftsstelle. Ein geringer Anteil wird auch fuer die Mitgliederversammlung, Reisekosten und sonstige Ausgaben (Notar, Amtsgericht, Porto, Kontofuehrung, Steuerberater etc.) aufgewandt.  Um eine stabile Preisentwicklung gewaehrleisten zu koennen und die Dienste bei der dynamischen Entwicklung der Teilnehmerzahlen und den volumenabhaengigen Berechnungen der Provider sicher stellen zu koennen, werden auch zweckgebundene Ruecklagen gebildet. Der Individual Network e.V. ist als Verein als (vorlaeufig) gemeinnuetzig anerkannt. [Das "vorlaeufig" entfaellt nach Abschluss der Pruefung durch das Finanzamt.]

Aufgrund haeufiger Nachfragen ein paar Anmerkungen, warum die Gebuehrenberechnung des Individual Network ausschliesslich aufgrund der Sitezahlen
der Domains erfolgt: Das Individual Network hatte in der Anfangszeit (1991) andere Abrechnungsmodelle, die sich allerdings als nicht sehr praktikabel herausgestellt haben.
So gab es zunaechst die Gebuehren, die fuer die jeweilige Domain festgesetzt wurden. Mit der zunehmenden Zahl von Domains ist eine solche Festsetzung nicht mehr moeglich, da niemand das Verhaeltnis der 60 Domains zueinander einschaetzen kann, ohne dass objektive Kriterien dafuer existieren. Abgeloest wurde dieses Abrechnungsverfahren durch eines, welches auf einer Nutzerzaehlung in den Domains beruhte. Eingefuehrt wurde dieses Verfahren, da der damalige Provider (EUnet) seine Gebuehren in Abhaengigkeit der Nutzer im Individual Network festgelegt hatte. Das IN-interne Verfahren, bei dem Nutzerzahlen mit Faktoren fuer virtuelle und reale Nutzer multipliziert werden mussten, um die tatsaechliche Anzahl der Netznutzer zu erhalten, konnte erfreulicherweise bald abgeloest werden. Es hatte sich herausgestellt, dass in den Domains die Zahl der tatsaechlichen Netznutzer nicht mit einem vertretbarem Aufwand ermittelt werden konnten. 1992 wurde dann ein neues Verfahren eingefuehrt, welches nur auf der Zaehlung von Systemen beruhte. Um die Unterscheide der verschiedenen Domainstrukturen (Mailboxdomains zu UUCP-Domains) auszugleichen, wurden diese Zahlen mit einem Gewichtungsfaktor (“NTK”, Netzteilnehmerklasse) multipliziert. Da sich die meisten Domains in ihrer Struktur aber immer staerker angeglichen haben und ein immer groesseres Gewicht auf den
IP-Diensten lag, wurde dieses Verfahren durch das heute gueltige Verfahren abgeloest, welches aus einem Sockelbetrag und der freiwilligen Mehrzahlung besteht. In Haertefaellen wurde der Beitrag fuer die Domains ueber einen Zeitraum von einem Jahr langsam angeglichen.

Aufgrund der stark steigenden Teilnehmerzahl wurde der Sockelbetrag 1993 in einen Mindestbetrag umgewandelt, da ein weiteres Absinken des Sitebeitrages neue Projekte unmoeglich zu machen drohte (zwischenzeitlich waren die Gebuehren pro Rechner auf unter DM 4.50 pro Monat abgesunken). Die heutige Tarifierung hat sich als flexibel und stabil herausgestellt und da eine Bewertung nach verursachtem Volumen nicht moeglich und nach Nutzerzahlen zu aufwendig erscheint, auch als sehr guenstig. Fuer die Nutzer und die Domains ist die pauschale Berechnung pro Site auch sehr erfreulich, denn sie wissen bereits im voraus, wie hoch der IN-Anteil in diesem Monat sein wird. Der niedrige Preis von 7 DM/(Monat*Site) rechtfertigt auch kaum aufwendigere Abrechnungsmethoden, die zusaetzlichen Verwaltungsaufwand (und damit Kosten) verursachen wuerden. Die feste Definition einer “Site” steht allerdings nach wie vor noch aus, ist aber aufgrund der inzwischen eingesetzten Offline-Reader nicht mehr einfach zu fassen. Die Mitgliederversammlung 1995 hat angeregt, diese Fragen im Arbeitskreis ‘Finanz’ zu eroertern und einen Vorschlag zu erarbeiten, der dem Praesidium vorgelegt werden kann.

10. Beitritt und Antragsverfahren fuer neue Betreibergemeinschaften

Dem Individual Network koennen keine Privatpersonen direkt beitreten. Die Mitglieder des Individual Network sind Betreibergemeinschaften, die ihren Teilnehmern Netzdienste des Individual Network anbieten. Neue Betreibergemeinschaften (Domains) koennen dem Individual Network beitreten, wenn in der Region noch keine andere Betreibergemeinschaft vertreten ist.
Bei Interesse wende man sich moeglichst fruehzeitig an den Antragsbearbeiter des Individual Network (Adresse siehe unten), damit die noetigen Fragen (Domainname, MX-Record, Mail/Newsversorgung, versorgende Einrichtung/Provider, Nameserver, DE-NIC-Antrag) gemeinsam geklaert werden koennen.

Folgende Schritte sind fuer den Beitritt einer neuen Regionaldomain noetig:

1. Kontaktaufnahme mit dem Antragsbearbeiter des Individual Network (in-ant@individual.net)
2. Pruefung der Region auf Ueberschneidungen mit bestehenden Regionaldomains des Individual Network und eventuelle Absprachen bezueglich einer Aufteilung einer Region.
3. Festlegung eines Domainnamens, der den regionalen Anspruch der Domain wiedergibt und nicht mit einer Person/Mailbox/Ideologie verknuepft ist. Dabei muessen zahlreiche Nebenbedingungen beruecksichtigt werden, so dass hier unbedingt eine Absprache mit dem Antragsbearbeiter des Individual Network angeraten ist.
4. Anforderung des administrativen und technischen Antrags [11][12] zum Individual Network Beitritt beim Antragsbearbeiter des IN.
5. Absenden (Briefpost!) des administrativen Antrags an die Geschaeftsstelle des Individual Network.
   Klaerung der Versorgung ueber Mitversorgung durch eine Universitaet, eine andere IN-Domain, einen Provider oder POP. Hierbei koennen die Providerkontakte des Individual Network eine grosse Hilfe sein. Auch der Vorstand des Individual Network e.V. muss in diesem Fall haeufig um Unterstuetzung gebeten werden, wenn die Mitversorgung ueber einen WiN-Anschluss (haeufig die beste Wahl fuer die Betreibergemeinschaft und das Individual Network) angestrebt wird. Eine Teilnahmebescheinigung am Individual Network und die DFN-Bestaetigung der Mitnutzungsberechtigung des Wissenschaftsnetzes (“Persilschein”) sind haeufig unverzichtbare Hilfen dabei.
6. Festlegung der MX-Records (Mailexchanger im Internet) fuer die Domain. Plant die Domain selbst IP, was zu diesem Zeitpunkt meist noch nicht realisiert ist, kann der Antragsbearbeiter meist mit den Defaulteinstellungen fuer das Individual Network arbeiten, die dann nach weltweiter Eintragung der Domain einfach geaendert werden koennen.
7. Benennung von Domain Name Servern (DNS), die die Propagation der Domaindaten uebernehmen. Hat die Domain noch keinen eigenen Nameserver, so koennen auch hier die Standard-Nameserver fuer Individual Network Domains verwendet werden, die von befreundeten Organisationen betrieben werden. Es ist dringend angeraten, dieses Angebot anzunehmen, wenn man nicht selbst einen stabilen und sicheren Nameserver bereitstellen kann. Falsch konfigurierte Nameserver koennen hohe Kosten fuer die Domain und
   das Individual Network erzeugen und zu aergerlichen Konnektivitaetsverlusten fuehren. Die Standard-Nameserver des Individual Network sind gut konnektiert, gut gewartet und staendig ueberwacht.
8. Stellen des technischen Antrags bei “in-ant@individual.net”.
9. Der Antragsbearbeiter des Individual Network prueft den Antrag und reicht den Antrag, der um die noetigen Daten ergaenzt wurde, ueber einen Provider beim DE-NIC ein. Die Eintragung erfolgt dann ueblicherweise in wenigen Tagen und geht besonders schnell, wenn die Default-MX-Eintraege und Standard-Nameserver verwendet werden, da dann zeitaufwenige Rueckfragen entfallen.
10. Je nach Antrag werden ueber den betreffenden Providerkontakt auch Class C IP-Netze beantragt und -falls gewuenscht- auch das Routing eingetragen.
11. Die Domain ist Mitglied im Individual Network und wird in de.org.in begruesst, die entsprechenden Daten gehen an IN-Info und die Geschaeftsstelle, um Interessenten aus der jeweiligen Region den richtigen Ansprechpartner nennen zu koennen.
12. Teilnahme auslaendischer Betreibergemeinschaften: Fuer auslaendische Domains gibt es die Moeglichkeit, uebergangsweise am Individual Network teilzunehmen. Seit 1992 gibt es das Konstrukt der “assoziierten Mitglieder” im Individual Network, welches als Anschubhilfe und zum Sammeln von Erfahrung bei Technik und Organisation gedacht ist. Angestrebt und unterstuetzt werden dem Individual Network vergleichbare Organisationen im Ausland, die sich auch ausschliesslich oder ueberwiegend um die Belange privater Nutzer bemuehen. Naehere Informationen erhaelt man vom erweiterten Vorstand (in-bei…@individual.net).

12. Netiquette

Das Individual Network hat ein paar Richtlinien in einer Netiquette [9] zusammengestellt, um das harmonische Miteinander der Domains und der Netzteilnehmer zu erleichtern. Es handelt sich dabei nur um einen Rumpf von Verhaltensregeln, die um eigene Richtlinien der Betreibergemeinschaften ergaenzt werden koennen. Die Domains des Individual Network sind gehalten, sich an diese Uebereinkuenfte zu halten und in den eigenen Regeln keine zuwiderlaufenden Bestimmungen aufzunehmen.

13. Referenzen

Leider sind die referenzierten Dokumente (waren auf dem IN-FTP-Server unter ftp.individual.net) nicht mehr erreichbar.

Wir haben unter http://faq.filoo.de/ eine Hosting-FAQ für alle, nicht nur Kunden der Filoo GmbH begonnen. Hier wird es in Zukunft natürlich auch Artikel speziell für unsere Kunden (etwa für Kunden von de-punkt Webhosting) geben, aber auch allgemeine Anleitungen etwa für das Einrichten von Gameservern auf dem eigenen Rootserver oder ähnliches. Stay tuned.

Dieser Artikel ist aus Sicht eines Gameserverhosters geschrieben, “wir” ist also die Filoo GmbH oder auch Gameserver-Hoster im Allgemeinen.

In unserer Gameserversparte Stormix Gameserver haben wir öfters mit Kunden zu tun, die sich über Probleme in der Anbindung (“Lag”, “Choke”, “loss”) beschweren. Diese Probleme werden häufig mit Ping- oder Traceroute-Ausgaben “belegt”. Es herrscht da aber bei den Kunden als auch bei einigen unserer Kollegen einige Verwirrung darüber, wie diese Ergebnisse zu interpretieren sind. Daher möchte ich hier mal grundsätzlich nach meinem besten Wissen aufklären, wie man einen “Trace” lesen sollte.

traceroute to absynth.dyndns.org (82.82.88.72), 30 hops max, 40 byte packets
1  ffm-93-190-64-1.gw.as47215.net (93.190.64.3)  3.165 ms  4.591 ms  4.575 ms
2  93-190-67-21.reverse.cust.as47215.net (93.190.67.21)  0.455 ms  0.550 ms  0.445 ms
3  194.25.210.57 (194.25.210.57)  4.372 ms  4.340 ms  4.306 ms
4  f-eb7-i.F.DE.NET.DTAG.DE (62.154.16.178)  0.727 ms  0.699 ms  0.664 ms
5  ffm-145-253-33-77.arcor-ip.net (145.253.33.77)  0.578 ms  0.599 ms  0.568 ms
6  ffm-145-254-16-241.arcor-ip.net (145.254.16.241)  2.227 ms  2.108 ms  2.072 ms
7  145.254.11.234 (145.254.11.234)  7.027 ms  6.800 ms  6.718 ms
8  dslc-082-082-088-072.pools.arcor-ip.net (82.82.88.72)  15.792 ms  16.716 ms  18.991 ms

Zuvor aber erst einmal eine kurze Einführung, wie Traceroute funktioniert und was es macht. Was es macht, ist einfach erklärt und ergibt sich schon aus dem Namen: Es verfolgt (= “trace”) den Weg (= “route”) eines Datenpakets durch ein IP-Netzwerk vom Sender zum Empfänger. Das macht es, indem es Pakete an den Empfänger schickt, die eine TTL (“Time To Live”) von anfangs 0, dann 1…etc. haben. Die TTL wird von jedem Router auf dem Weg um 1 gesenkt, und sobald sie 0 erreicht, wird eine Fehlermeldung an den Sender zurückgeschickt. Diese Fehlermeldung wird über das dafür gedachte Protokoll ICMP (Internet Control Message Protocol) versandt, das übrigens auch von traceroute oder ping genutzt wird, um die Pakete von Sender zu Empfänger zu schicken.

Über den Trick, die TTL schrittweise zu erhöhen, bis der Empfänger selber antwortet, kann in aller Regel jeder Router zwischen Quelle und Ziel ermittelt werden. Manchmal aber auch nicht und das ist

Problem 1: Wenn ein Router auf dem Weg ICMP-Nachrichten oder UDP-pakete (manche Versionen von traceroute nutzen keine ICMP- sondern UDP-Pakete) blockiert, etwa weil er firewalled ist, so wird dieser Hop des traceroute durch Timeouts (markiert durch Sternchen * * * ) markiert werden. Das heißt nicht, daß das Routing kaputt ist!

Problem 2: Wenn ein Traceroute (wie im Beispiel oben) reibungslos durchläuft, so kann man die aktuelle Route in eine Richtung von Quelle zu Ziel sehen. Diese kann sich aber deutlich von der Rückrichtung unterscheiden. Das nennt man “asynchrones asymmetrisches [danke an Kris] Routing” und das ist ein ganz normaler Vorgang im Traffic Engineering, z.B. wenn ein kleiner ISP wie wir sein Routing auf möglichst kurze Latenzen optimiert, aber große ISPs mit denen wir peeren, auf möglichst geringe Kosten. Dann schicken wir Pakete über die Telekom hin, sie kommen aber über unsere DE-CIX-Anbindung zurück. Das kann, muß aber nicht zu Problemen führen.

Schauen wir uns einen Traceroute mal an (komplettes Beispiel siehe oben):

2  93-190-67-21.reverse.cust.as47215.net (93.190.67.21)  0.455 ms  0.550 ms  0.445 ms

Hier steht, daß der zweite (2) Hop, der Host 93-190-67-21.reverse.cust.as47215.net mit der IP 93.190.67.21, innerhalb von 0.455, 0.550 und 0.445 ms auf jeweils ein ICMP-Paket geantwortet (also eines zurückgesendet) hat. Sieht erstmal OK aus. Woran sehen wir nun, wenn etwas nicht OK ist?

Typischerweise kann man tatsächliche Routingprobleme in einem einzelnen Traceroute an zwei Dingen sehen:

1. Ungewöhnlich lange Route (mehr als ca. 12 Hops von einem Dialin-Provider zu einem unserer Gameserver)
2. Dauerhaft ungewöhnlich hohe Latenzen auf einem oder mehreren Hops in der Route

Ich möchte beide Punkte hier erläutern und häufige Mißverständnisse ausräumen.

Zu 1)

Es passiert ab und an, daß irgendwo Leitungen wegbrechen (der berüchtigte Bagger) oder vom ISP auf Kosten optimiert wird (dann werden schlechtere Anbindungen, die halt billiger sind, bevorzugt). Dann verlängert sich die Route mal mehr, mal weniger.
Insbesondere wenn ein großer ISP Probleme mit einzelnen Knoten in seinem europaweiten Glasfaserring hat, kann es passieren, daß Pakete von z.B. Hamburg nach Frankfurt über seltsame Wege wie Paris oder Amsterdam geleitet werden. Diese Probleme sind in aller Regel temporär, aber stets meldenswert. Sie deuten auf Probleme an einem der großen Internetaustauschknoten (DECIX, VIX, AMSIX, LINX) hin, die nicht immer von einem Menschen bemerkt werden.

(Wieso das? Weil das Routingprotokoll BGP4, das in allen aktuellen IP-Netzen verwendet wird, Leitungsprobleme automatisch erkennt und behebt. So kann es passieren, daß ein Umrouting komplett automagisch vonstatten geht und das NOC, wenn angepißte Gameserverkunden anrufen, nicht einmal weiß, daß es Probleme gab.)

Ein weiteres, sehr viel selteneres Problem neben ungünstigem Routing sind tatsächliche Fehler im Routing, also z.B. Loops, bei denen derselbe Host/IP an mehreren Stellen nacheinander oder in Wechsel mit einem anderen mehrfach auftaucht. Das deutet auf echte Probleme hin und sollte unbedingt gemeldet werden.

Zu 2)

Wer einen normalen einzelnen tracert macht, der sollte sich darüber im Klaren sein, daß pro Hop genau 3 Pakete gesendet und gemessen werden, und daß die resultierende Aussage (Problem 3) genau nichts wert ist. Das Internet ist ein hochkomplexes Netz und es kann durchaus mal sein, daß ein paar Pakete zwischendurch höhere Laufzeiten hatten – z.B. auch weil der Clientrechner einfach gerade beschäftigt ist. Daher sollte man stets ein Tool wie z.B. mtr (Matt’s TraceRoute) oder WinMTR verwenden, die mehrere Pakete senden und daher auch einigermaßen aussagekräftige Resultate liefern. Es ist außerdem wichtig, unter Vista / Win7 das Tool als Admin zu starten, damit der IP-Stack nicht vollkommen verhunzt ist (das liefert nämlich auch unbrauchbare Resultate).

Mal so als Anhaltspunkt: Bevor ich einem meiner Upstreamprovider auf die Nase haue, weil seine Leitungen voll sind, lasse ich eine Stunde lang einen mtr-Traceroute laufen. Das sind über 3000 Pakete. Mindestens 100 Pakete sollte jeder vorweisen können, der uns eine Beschwerde zukommen läßt, alles andere ist aufgrund von Meßschwankungen zu ungenau um es sich überhaupt anzuschauen.

Sieht man an einem oder mehreren Hops deutlich erhöhte Reaktionszeiten, so ist das ein Indiz, daß etwas nicht in Ordnung ist. Besorgniserregend ist in der Regel eine Erhöhung um mindestens 20ms innerhalb eines Backbones und 100ms bei DSL-Zugangsnetzen. Daß ein traceroute derlei Probleme zeigt, heißt aber noch lange nicht, daß der Gameserveranbieter bzw. Hoster dran schuld ist. Um das festzustellen, muß man erst einmal ermitteln, wo der Hund begraben liegt.

Wie wir gerade schon erwähnt haben, ist ein Traceroute eine Verfolgung des Wegs von der Quelle zum Ziel einer Kommunikation. Die Quelle bei einem traceroute vom Kunden ist natürlich der Rechner des Kunden. Dann kommt sein eigener DSL-Router, der Übergang ins IP-Netz des Providers (T-Online, Vodafone, you name it) und dann beliebig viele Backbonerouter. Irgendwo gibt es dann einen oder mehrere Übergänge in andere Netze, die mehr oder minder schwer zu sehen sind. Schauen wir uns nochmal einen anderen Traceroute an.

Routenverfolgung zu dnscache1.de-punkt.de [93.190.64.60] über maximal 30 Abschni
tte:

1     3 ms     1 ms     1 ms  m638-mp2.cvx1-b.man.dial.ntli.net [62.252.202.126]
2    15 ms     9 ms     8 ms  popl-lam-4-tenge24-3716.network.virginmedia.net [82.14.169.62]
3     9 ms     7 ms     8 ms  popl-core-1a-ge-400-0.network.virginmedia.net [62.255.81.117]
4     7 ms     7 ms     7 ms  pop-bb-a-as2-0.network.virginmedia.net [213.105.174.234]
5    15 ms    15 ms    15 ms  amst-ic-1-as0-0.network.virginmedia.net [213.105.175.6]
6    24 ms    25 ms    32 ms  ramsix-astd-n101.nms.mediaways.net [195.69.144.91]
7    24 ms    25 ms    25 ms  195.71.254.129
8    27 ms    27 ms    27 ms  xmwc-frnk-de01-vlan-11.nw.mediaways.net [62.53.238.14]
9    28 ms    37 ms    29 ms  xfio-frnk-de01-vlan-35.nw.mediaways.net [217.188.245.170]
10    27 ms    26 ms    26 ms  tde-ffm-br01.as47215.net [195.71.237.218]
11    25 ms    32 ms    26 ms  bb01.av.backbone.filoo.de [93.190.67.18]
12    28 ms    34 ms    26 ms  dnscache1.de-punkt.de [93.190.64.60]

Ablaufverfolgung beendet.

Dieser traceroute ist ein bißchen länger, dafür kann man aber auch ein bißchen mehr sehen.

Los geht es bei einem merkwürdigen Hostnamen, der “dial” enthält. Das wird wohl irgendein Dialup-Knoten sein. Dann gehts bis zu Hop 5 weiter im Netzwerk “virginmedia.net”, das ist ein Dialup/DSL-Netzwerk in Großbritannien.

Auf Hop 5 sieht man eine Erhöhung der Laufzeit von 7 auf 15 ms. Das liegt daran, daß hier der Ärmelkanal überquert wurde (siehe der Hostname, “amst” steht für Amsterdam).

Hop 6 ist noch interessanter: Da steht “ramsix-irgendwas.mediaways.net”. Hier ist offenbar ein Übergang in ein anderes Netz passiert, nämlich in das von MediaWays (also known as Telefonica/O²). “ramsix” deutet darauf hin, daß dieser Hop physikalisch in Amsterdam am AMSIX (AMSterdam Internet eXchange) beheimatet ist.

Nun kommt ein bißchen Gedöns in Frankfurt (*-frnk-*.mediaways.net) und dann ist in Hop 10 wieder ein Übergang zu sehen: tde-ffm-br01.as47215.net ist unser Backbone-Router (“as47215″ steht für die internationale ID unseres IP-Netzwerks). Nun befindet sich das Paket also im Netz der Filoo GmbH und wird über einen Backboneswitch (bb01.av.backbone.filoo.de, Hop 11) zum Zielrechner (dnscache1.de-punkt.de, Hop 12) geleitet.

Beschwert sich der Kunde nun über eine hohe Latenz in Hop 5, ist er bei uns an der falschen Adresse. Wir sind erst ab Hop 10 überhaupt in der Lage, irgendetwas an einem möglichen Fehler zu ändern, davor können wir von der Filoo GmbH nur an den jeweiligen ISP zurückverweisen.

Mal noch ein paar Beispiele (danke an Crowfire!):

Hier ist der Fall auch klar (fett markiert): Bei Hop 2, also im Netzwerk des DSL-Zugangsanbieters, gibt es 14% Paketverlust. Da ist wahrscheinlich ein DSL-Knotenpunkt von T-Online überlastet. Das ist nicht Schuld des Gameserveranbieters!

Hier ist es etwas schwieriger, festzustellen woran es liegt. Sieht so aus als sei bei Hop 4/5, also bei der Netzverbindung zwischen dem Leipziger Knoten und dem Frankfurter Knoten von T-Online ein Problem. Vermutlich auch nix, was den Gameserverprovider (in diesem Fall nicht wir) anginge.

Auch ein schönes Beispiel (Kommentar des Kunden: “HIGHPING!!!!! an der Leitung kanns nicht liegen!”). Der fett markierte Hop ist der Übergang (“das Peering”) von Kabel Deutschland zu Telefonica. Dort ist offenbar die Leitung voll. Das kann Telefonicas Schuld sein oder die von Kabel Deutschland. Unsere ist es nicht.

Um das Ganze etwas zusammenzufassen: Wenn Ihr als Kunde eines Hosters oder Gameserverproviders eine mögliche Leistungsverschlechterung melden wollt, dann prüft bitte vorher, ob er auch Euer richtiger Ansprechpartner ist. In über 90% der Fälle in denen sich bei uns Kunden über hohe Pings, Paketverluste oder Schwankungen beklagen, ist der Zugangsprovider der Schuldige. Und an den solltet Ihr euch dann auch wenden, anstatt uns mit Kündigung, Klage, Leibstrafen oder sonstigem Ungemach zu drohen. Wir sind fast immer nicht schuld.

Seit heute ist unsere neue Seite online. Wir werden Sie an dieser Stelle in Zukunft mit aktuellen Nachrichten aus dem Bereich Webhosting versorgen. Also schauen Sie mal wieder rein!