From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: de.org.sub
Subject: Erlaeuterungen Re: Antragsformular
Supersedes: <antrag-doku-12@smurf.sub.org>
Date: 4 Jan 1993 20:40:22 +0100
Organization: Smurf-O-Box Karlsruhe, FRG
Expires: Thu, 04 Feb 1993 19:40:08 GMT
NNTP-Posting-Host: smurf.sub.org


Inhalt: WasSollDas?, Vorgehensweise, Erlaeuterung, Beispiele.


Was sind Domains, wozu brauche ich sie?

Es waren einmal zehn Rechner, die haben sich alle gekannt, sich gegenseitig
  Mail zugeschachert, und alle waren happy.
Es waren einmal hundert Rechner, und man musste Dateien hin- und herschaufeln,
  in denen drinsteht, wer wie mit wem. Diese wurden "Maps" genannt.
Es waren einmal tausend Rechner, das Ganze begann unhandlich zu werden, und
  einige Rechner merkten ploetzlich, dass ihr Name schon mal vergeben war, und
  waren ungluecklich.
Es waren einmal zehntausend Rechner, und die Verwaltung der Grossen Listen
  fing an zu nerven (die US-Maps haben ungefaehr soviele Eintraege).
Es waren einmal hunderttausend Rechner, und das System brach in sich zusammen
  (das Internet hatte das Problem vor einigen Jahren).
Es waren einmal eine Million Rechner (Groessenordnung des Internets), alle
  verstehen und verwenden Domainnamen, keiner kennt genaue Daten des gesamten
  Netzes, trotzdem bzw. gerade deshalb sind alle happy.
(Oder so ungefaehr.)

Domains sind _die_ Methode, den einzelnen Rechnernamen sowie den Wegen, auf
denen diesen Rechnern elektronische Post zuzustellen sei, in eine Hierarchie
zu bringen. Folgerung: Es muss nicht mehr jeder alle anderen kennen, und der
Aufwand ist nicht mehr quadratisch, sondern irgendwas zwischen logarithmisch
und linear.

Die meisten Rechnerbetreiber auf dem Internet haben inzwischen weder Zeit,
Lust, noch ueberhaupt den Bedarf, sich um das Einspielen von Maps zu
kuemmern, so dass Rechner ohne Domainnamen nicht mehr oder nur mit mehr oder
weniger grossen Adressierungskruecken erreichbar sind.

Der VzFdpbD eV (nennen wir ihn mal Subnetz-Verein) hat sich daher die
weltweiten Vermarktungsrechte der Domain .sub.org gesichert, unter der sich
alle registrieren lassen koennen, die das wollen oder brauchen.

Domainnamen sind im Prinzip nichts anderes als Rechnernamen mit Punkten drin,
zB smurf.sub.org Das Ganze bildet eine Hierarchie: "org" steht ueber
"sub.org" steht ueber "smurf.sub.org" steht neben "ka.sub.org" ... etc.pp.
"org" ist hier die "Toplevel"-Domain. Alle Topleveldomains muessen in den
USA bei der dortigen Netzkoordination registriert sein. Neue Topleveldomains
werden grundsaetzlich nur fuer anschlusswillige Staaten vergeben, in der
Form von ISO-2-Buchstaben-Abkuerzungen ("de", "us"); das Beantragen einer
solchen Domain fuer ein Mailboxnetz ist daher sinnlos.

Logischerweise muessen zwei Domains verschiedene Namen haben, wenn sie
denselben "Vater" besitzen. Ansonsten hat jedes Namenssegment max 64 Zeichen
(ueblicherweise weniger als 12), Namen bestehen aus Buchstaben gefolgt von
Buchstaben oder Ziffern oder Bindestrichen, und der vollstaendige Name ist
weniger als 256 Zeichen lang.

Wer mehr wissen will, muss jemanden finden, der eine der diversen
ausfuehrlichen Dokumentationen zu dem Thema uebersetzt. Oder selber eine
schreiben. ;-)
Oder jemand anders fragen. Aber bitte nicht mich, es sei denn es geht wirklich
nicht anders.

Mit einem erfolgreichen Antrag auf eine Unterdomain geht die Verantwortung
fuer das korrekte Verhalten (Weiterleiten von Mail, Nicht-Zumuellen des
Subnetzes, Bezahlung von Mailrechnungen) der an die Domain angeschlossenen
Rechner auf den Antragsteller ueber. Unter anderem aus diesem Grund ist das
Formular (welche Verantwortung geht auf wen ueber) mit definiertem "Hand-
shake" (Antrag wird gestellt, Domain wird eingerichtet und bestaetigt,
Daten werden dem Rest der Welt bekanntgegeben) notwendig.


Mailrechnungen etc.pp.:
Entfaellt fuer Leute, die keine internationalen Mails brauchen bzw. dafuer
nix zahlen wollen. (In letzterem Fall bekommen sie naemlich keine Mails.  ;-)

Der Subnetz-Verein hat folgende Gebuehrenstruktur:
- Nationale Mails sind kostenlos.
- Internationale Mails kosten Geld, naemlich 3 Pf/kByte. Wegen der
  einfacheren Rechnerei ist das kByte bei uns 1000 Bytes gross. Zum
  Ausgleich werden Mailheader nur zur Haelfte mitgerechnet.
- Es gibt ein Freikontingent von 50 kBytes/Monat.
- Aus diversen Gruenden gibt es Domains mit internationaler Konnektivitaet
  nur fuer Vereinsmitglieder. Das kostet DM 60/Jahr fuer Studenten und
  DM 120/Jahr fuer normale Menschen.
- Wie all diese Kosten und Kontingente auf die lokalen Teilnehmer in einer
  Unterdomain aufgeteilt werden, ist dem Verein egal.

Das Freikontingent gibt's pro Vereinsmitglied. Ein Mitglied kann waehlen,
ob er/sie/es fuer seine Unterdomain eine eigene Abrechnung vom Verein 
haben will und/oder welcher Domain das Freikontingent zugeschlagen werden 
soll. Fuer die Zwecke der Abrechnerei gelten "bla.sub.org" und "alles unter
*.bla.sub.org, *.*.bla.sub.org, etc., ueber die beim Verein nix anderes
bekannt ist" als verschiedene Domains, fuer die aber gemeinsam ein Antrag
gestellt werden muss (logisch -- Antragsbeispiel siehe unten).


Vorgehensweise:  ("+": Dieser Punkt muss vom Antragsteller erledigt werden.)

+ Formular ausfuellen, mailen.
  Bei Problemen mit dem Formular Mail an mich.
+ Eigenen Rechner auf Akzeptanz der Domainnamen umstellen.
  Die Domain sollte aber noch nicht aktiv in Mailadressen verwendet werden.
- Nach zwei Wochen kommt (spaetestens!) Antwort mit Bestaetigung und
  vorgeschlagener Ergaenzung zum Mapeintrag. Falls diese Antwort nicht kommt,
  meckern.  (Ich verspreche hiermit hoch und (h)eilig, alle Antraege
  innerhalb einer Woche zu bearbeiten.) Wenn keine Antwort ankommt, nachfragen!
- Mapergaenzung erscheint in sub.config.maps, in der Datei u.sub.domains.
+ Eigenen Rechner auf aktive Verwendung der Domainnamen umstellen.
  Siehe dazu auch das Kapitel "Domainadressen im Envelope", weiter unten.
  Der alte Name sollte fuer eine Uebergangszeit (Monate) noch erkannt werden.
+ Eigenen Mapeintrag aendern und an zustaendigen Map-Administrator schicken.
- Geaenderter Mapeintrag erscheint in sub.config.maps.
- Mapergaenzung verschwindet wieder aus u.sub.domains.


Das Erscheinen einer Mapergaenzung in u.sub.domains ist optional. Wenn
es mit einer Ergaenzung maptechnische oder organisatorische Probleme gibt,
wird sie nicht erscheinen. Beispiel: Rechner erscheint noch nicht in der
Submap.


< Formular
Erklaerung.

XX bedeutet Text, 99 Zahl, JN Ja/Nein, JNB Ja/Nein/Beides.

< Name:	 XXX
< Vorname: XXX
< Firma:	 XXX
< Strasse: XXX 99
< Ort:	 9999 XXX

Sollte offensichtlich sein.
<
< Telefon: 0XXX-XXXXX

Die Nummer, unter der der Verantwortliche normalerweise zu erreichen ist.
Sie koennen hier auch mehrere Nummern angeben (Tag, Nacht, Anrufabwimmler,
Fax). Die Nummern werden nicht weitergegeben. Bitte unbedingt die Art
der angegebenen Nummer dazuschreiben -- es bringt nichts, wenn ich wegen
einem dringenden Problem anrufe und nur mit den Anrufabwimmler der Firma
reden kann.

< Zustaendig (administrativ): XXX@YYY.ZZZ
< Zustaendig     (technisch): XXX@YYY.ZZZ
< 
Mailadresse und evtl. Name des fuer die administrative Seite
(Verantwortlichkeit fuer das korrekte Verhalten der Rechner und der Leute in
der Domain) und fuer die technische Seite (Mapeintraege erstellen, Mailer
installieren etc.) verantwortlichen Menschen.

< Vereinsmitglied: JN
< 
Falls nein, kostet jede Domain einmalig DM 10 und es gibt keine inter-
nationale Konnektivitaet. Mitgliedsantraege, Satzungen, etc., gibt's 
via Mail an info@subnet.sub.net.

< Domainname:    XXX.sub.org

Beispielsweise stadt.sub.org fuer Kleinhintermuehlhausen ;-), oder
murks-ag.sub.org fuer die betreffende Firma. (Vorsicht: Firmenanschluesse
sind an besondere Bedingungen gebunden. Vorher bitte nachfragen.)

Domainantraege fuer Unterdomains (kiste.stadt.sub.org) werden an die
Verantwortlichen fuer die Oberdomain weitergeleitet, wenn vorhanden. Wenn
nicht, muessen sich die Betreffenden (Kleinhintermuehlhausener) zusammensetzen
und jemanden bestimmen, der stadt.sub.org beantragt.

< Rechner (Map): XXX
Der fuer die Domain primaer verantwortliche Computer, der weiss, wie er an
saemtliche evtl. Unterdomains per Mail rankommt. (Name so, wie er in der
Sub-Map erscheint/erscheinen soll.) Anhand dieses Eintrags werden die
Eintraege im Mapschnipsel u.sub.domains generiert; naehere Infos zur Map finden Sie in der Newsgroup sub.config.maps.
Falls der Antrag fuer eine Unterdomain ist (zB wegen Mailkosten), koennen Sie
diesen Eintrag weglassen, da fuer das korrekte Routing in diesem Fall der
Inhaber der "Ober"domain zustaendig ist.

< Unterdomains:  JNB
< 
NEIN heisst: Es gibt einen Rechner XXX alias murks-ag.sub.org, aber keine
unterhalb dieser Domain, wie sonstwas.murks-ag.sub.org. Die Domain ist also
"nur" ein anderer Name fuer diesen einen Rechner.

JA heisst: es gibt einen Rechner, beispielsweise kiste.stadt.sub.org, der sich
fuer die Domain verantwortlich fuehlt. Es existiert kein Rechner namens
"stadt.sub.org".

BEIDES heisst: Es existiert der Rechner murks-ag.sub.org, der zusaetzlich noch
andere Rechner unter sich duldet; also beide Moeglichkeiten oben.

Bitte machen Sie hier eine korrekte Angabe. Die Angabe von "Unterdomains: J"
und "user@domain.sub.org" in einer der Mailadressen (als Beispiel dafuer, wie
man es _nicht_ machen sollte) fuehrt im Zweifelsfall zu einer verzoegerten
Bearbeitung des Antrags.

< Intl.erreichbar: JN
< Intl.Mail ueber: XXX.XXX.XXX
< 
Falls der Rechner von ausserhalb des Subnetzes erreichbar sein soll, JA
angeben, sonst NEIN.
Falls der Betreiber eines am Internet direkt(!) angeschlossenen Rechners sich
bereiterklaert hat, Mail fuer die Domain entgegenzunehmen, bitte hier den
Namen dieses Rechners angeben. (Koennen auch mehrere sein.)
"An das Internet angeschlossen" heisst: Von jedem anderen Internet-Rechner
kann eine direkte TCP/IP-Verbindung zu dieser Maschine hergestellt werden.
Dieser Rechner muss derart konfiguriert werden, dass er Mail an die
betreffende Domain korrekt routet!

Bitte tragen Sie hier _nicht_ den Rechner ein, bei dem Sie pollen, es sei
denn er erfuellt die obige Voraussetzung re Erreichbarkeit.

Falls kein solcher Rechner benannt wird, lassen Sie die "Intl.Mail ueber:"-
Zeile bitte ganz weg. Die Mail laeuft in diesem Fall ueber smurf.sub.org,
kostet drei Pfennig pro Kilobyte, und die nachfolgenden drei Zeilen muessen
ausgefuellt werden.

< Account fuer Abrechnungen:  XXX@YYY.ZZZ
Mailadresse, an die die Rechnungen geschickt werden.

< Limit fuer Domainrechner: XXX DM
Nur ausfuellen wenn "Unterdomains" != "J".
Begrenzt die Mailkosten fuer Mails von und nach user@domain.sub.org auf
maximal XXX DM. Dieser Betrag ist der "Kreditrahmen", bis zu dem Mails
durchgelassen werden.

< Limit fuer Unterdomains:  XXX DM
Nur ausfuellen wenn "Unterdomains" != "N".
Begrenzt die gesamten offenen Mailkosten fuer Mails von und an die an der
Domain angeschlossenen Systeme ("user@rechner.domain.sub.org") auf maximal
XXX DM insgesamt.

Die Abrechnerei wird jeweils pro Domain / Unterdomain durchgefuehrt. Bei
Angabe von "B" bei den Unterdomains (es soll also sowohl ein Rechner
domain.sub.org als auch Rechner innerhalb dieser Domain existieren) gibt es
hier also zwei Konten mit eigenen Begrenzungen. Wenn jemand alle Abrech-
nungen auf dasselbe Konto laufen lassen will, moege er/sie/es das mir mit-
teilen; meine Abrechnungssoftware ist darauf vorbereitet.

Die Grenzen gelten fuer alle Mails auf diesem Konto; es wird keine Abrechnung
fuer einzelne Systeme oder gar Benutzer durchgefuehrt. Wenn ein Einzelsystem
eine eigene Abrechnung wuenscht, z.B. weil der "Kreditrahmen" anders sein soll,
brauche ich dafuer einen Extraantrag.

Es gibt ausserdem die Moeglichkeit, pro Mail eine Groessenbegrenzung
anzugeben. Alle Mails, die groesser sind als dieses Limit, werden
abgewiesen.
Diese Begrenzung ist gedacht fuer technische Hindernisse, z.B. beim
Anschluss eines Mailboxnetzes, in dem groessere Mails nicht geroutet
werden koennen.
Im Fall einer solchen Abweisung wird grundsaetzlich die gesamte Mail
an den Absender zurueckgesendet. Dasselbe gilt fuer Mails, deren Ueber-
tragung den Kreditrahmen sprengen wuerde. Aus technischen Gruenden ist
eine Teiluebermittlung zB der ersten 20 Zeilen nicht moeglich.


Domainadressen im Envelope (WICHTIG!!!)
==========================
! Bei Mails ins Subnetz und besonders in den Rest der Welt muss sichergestellt
! sein, dass alle Adressen in Domainform vorliegen. Dies betrifft insbesondere
! die Envelope-From-Adresse, die z.B. beim rmail-Kommando in der ersten Zeile
! auftaucht ("From <User> <Datum> remote from <Fasel>"). <Fasel> muss hier
! entweder eine Domainadresse sein, oder der empfangende Rechner muss in der
! Lage sein, diesen Namen in Domainform umzuwandeln. (Letzteres ist meistens
! nicht der Fall.) <User> kann auch in "user@adresse"-Form auftauchen; dann
! muss diese Adresse ebenfalls in Domainform sein.
! Adressen der Form "bla.uucp" sind _nicht_ in Domainform, weil ".uucp" keine
! registrierte Toplevel-Domain ist.

Wenn Mails mit einer nicht domainisierten Quelladresse ins Internet gelangen
(und das kann auch bei innerdeutschen Mails passieren), kann es sein, dass
die Adresse umgeroutet order als ungueltig angesehen wird. Fehlermeldungen
oder andere automatisierte Mitteilungen finden dann nicht mehr ihren Weg
zum Absender. Die Zuverlaessigkeit des Netzes sinkt und ein paar Postmaster
haben mehr Arbeit. :-(

Diese Aenderung in einen Mailer einzubauen ist leider nicht immer ganz
einfach. Hilfestellung kann evtl. der Postmaster des Systems geben, bei
bei dem man pollt. Eine Anfrage in de.admin.mail kann ebenfalls weiter-
helfen. Bei diesem Problem _nicht_ weiterhelfen kann urlichs@smurf.sub.org.

PS: "Envelope" sind die Adressen, die "aussen" auf der Mail stehen und
die angeben, wer diese Mail ausgeloest hat und wo sie hin soll. Im "Header"
dagegen stehen unter anderem die Adressen des Autors und aller Adressaten.
Diese Unterscheidung ist analog zu den Adressen aussen auf einem Brief und
denen im Briefkopf, die auch nicht unbedingt was miteinander zu tun haben
muessen.
Der Header ist in der Norm RFC 822 beschrieben. Die Envelopeangaben sind
abhaengig vom verwendeten Uebertragungsprotokoll. Im Normalfall sollten
alle Rechneradressen in Envelope und Header in Domainform sein.

Diese Adressproblematik hat in der Vergangenheit immer wieder zu Problemen
bei Mailabrechnungen, Kostenzuordnungen, etc.pp. gefuehrt. Im Zweifelsfall
sende eine kurze Mail an postmaster@subnet.sub.net mit der Bitte um
Ueberpruefung.


Beispiel
========

Es sei "junker" einer von mehreren Rechnern in Kleinmichelshausen. Die
Kleinmichelshausener Leute wollen bzw. brauchen fuer ihre Stadt eine Domain.
Als Verantwortlicher stellt sich Hans Fuzzi (Besitzer des Rechners "junker",
aber das ist nicht Voraussetzung -- nur mit dem Besitzer abgesprochen sollte
das Ganze schon sein ;-) zur Verfuegung, drueckt das Managen des ganzen
Krempels aber seinem kleinen Bruder Peter auf (der auf "junker" einen Account
mit den entsprechenden Berechtigungen hat, und ausserdem gewillt ist, sich
das noetige Wissen anzueignen. Das _ist_ Voraussetzung).

Da Hans ein grosses Modem hat, und sich der Postmaster der Uni Sonstwo, USA,
(Internet: sonstwo.in.amiland.edu) bereiterklaert hat, internationale Mail
fuer diese Rechner zwischenzulagern und Anrufe des Rechners Junker zwecks
Abholung derselben entgegenzunehmen, kann er das so im Antrag angeben und hat
sich damit die internationale Mail-Erreichbarkeit gesichert.
(Obiges funktioniert auch mit jedem anderen Rechner auf der Welt, solange
selbiger per TCP/IP weltweit direkt erreichbar ist.)

Name:	 Fuzzi
Vorname: Hans
Firma:	 ---
Strasse: Grossmichelshausener Strasse 123
Ort:	 1234 Kleinmichelshausen
Telefon: 01234-5678 (Tag)
Telefon: 01234-4321 (Anrufbeantworter)

Zustaendig (administrativ): hans@junker.michel.sub.org
Zustaendig (technisch): peter@junker.michel.sub.org

Vereinsmitglied: Ja

Domainname:    michel.sub.org
Rechner (Map): junker
Unterdomains:  Ja

Intl.erreichbar: Ja
Intl.Mail ueber: sonstwo.in.amiland.edu

(Der Abschnitt re Kostenuebernahme faellt weg; das muss mit der Uni Sonstwo
 abgesprochen werden.)

Peter Fuzzi wird den Mapeintrag des Rechners dann so ergaenzen:

junker = junker.michel.sub.org
junker .michel.sub.org(DAILY*2)

Die erste Zeile besagt, dass junker ab sofort auch junker.michel.sub.org heisst.
Die zweite Zeile sagt allen, dass junker fuer die anderen Kleinmichelshausener
Rechner Mail entgegennimmt, wobei jeder spaetestens alle zwei Tage seine Mail
abholt. (Letzteres ist keine "harte" Voraussetzung, macht aber das Mailrouting
robuster.)

Dem Rechner junker muss gesagt werden, wie er die anderen Kleinmichelshausener
Rechner erreichen kann. Das geht am besten ueber einen lokalen Mapzusatz, der
nicht in der normalen Subnetz-Map erscheint; seien fguw, azu, und fduzgdu die
uebrigen Kleinmichelshausener Kisten, dann lautet dieser Zusatz

fguw = fguw.michel.sub.org
azu = azu.michel.sub.org
fduzgdu = fduzgdu.michel.sub.org

Damit ist dann sichergestellt, dass die Rechner in dieser Domain immer erkannt
werden, auch wenn in der Map fuer den Bereich, in dem Kleinmichelshausen
liegt, mal was schiefgelaufen ist (Mapverwalter hat Plattenueberlauf und
schickt versehentlich eine leere Map raus...).

Zusaetzlich werden natuerlich noch Verbindungsdaten benoetigt. Siehe dazu die
Doku in sub.config.maps, Mapschnipsel u.sub.0.
Die anderen Kleinmichelshausener Rechner, die nur am junker pollen, brauchen
jetzt keinen eigenen Mapeintrag mehr. Sie muessen aber entweder dazu gebracht
werden koennen, selber zu wissen, dass sie jetzt auch nicht nur fduzgdu.uucp,
sondern auch fduzgdu.michel.sub.org heissen, oder der Mailer von junker muss
intelligent genug sein, die Domainnamen beim Senden und Empfangen einzufuegen
bzw. rauszuwerfen.


Rechner frozzel, der auch woanders pollt, wird seinen (subnetz-weiten)
Mapeintrag um

frozzel = frozzel.michel.sub.org

ergaenzen, damit seine Mail direkt zugestellt werden kann und nicht unbedingt
ueber junker laufen muss.


Die Domainnamen koennen auch als "Haupteintraege" verwendet werden, wenn den
beteiligten Rechnern selbiges beigebracht werden kann.
Bei den meisten Rechnern, wie sie von den Herstellern konfiguriert sind, ist
das aber nicht ohne Probleme moeglich.
Der Mapeintrag von "fguw" wuerde dann zB so aussehen:

#X diverse Kommentare, siehe u.sub.0
#
fguw.michel.sub.org   junker.michel.sub.org(DAILY)



Beispiel 2:

Fuer die Domain netz.sub.org werden internationale Mails nicht akzeptiert.
(Aktuelles Beispiel: Zerberus.)
Der Betreiber des Systems test.netz.sub.org moechte aber trotzdem Mails
bekommen und versenden koennen. Fuer diesen Fall fuellt er aus:

Name Vorname Firma Strasse Ort Telefon Zustaendig(administrativ)
Domainname (hier: test.netz.sub.org)
Unterdomains (meist N)
Account fuer Abrechnungen
Limit fuer Domainnamen  (also fuer test.netz.sub.org)
Limit fuer Unterdomains (falls "Unterdomains != "N")

sowie einen Mitgliedsantrag des Vereins.


So. Wer sonst noch was wissen will, ist hiermit herzlich eingeladen, mich zu
nerven. Aber bitte per Mail, nicht per Telefon.
PS: Ergaenzungsvorschlaege sind ebenfalls willkommen!

Newsgroups: de.org.sub