Domains und Sitenamen

Jeder User beim IN-Berlin hat eine Domain sitename.in-berlin.de, wobei sitename der anfangs gewählte Sitename ist. Allerdings kann man auch unterschiedliche zusätzliche Domains dazuhaben mit folgenden Auswirkungen:

• E-Mails, die an einen Benutzer in der Domain geschickt wird (beispielsweise b.nutzer@meine-domain.tld), landet bei b.nutzer@sitename.in-berlin.de, sofern man im Service-Interface nichts anderes definiert hat.
• Man kann unter https://www.meine-domain.tld/ und https://meine-domain.tld/ eigene Webseiten anbieten. Dies sind entweder die gleichen Seiten, die auch unter https://www.sitename.in-berlin.de/ angeboten werden, oder andere.
• Man kann verschiedene Dienste unter diesen neuen Domains anbieten. Z.B. Jabber-Accounts kann man auch als username@meine-domain.tld anlegen.

Zusätzlich zum gewählten Sitenamen kann man noch zusätzliche Domains rechnername.in-berlin.de haben (rechnername ist wählbar). Diese ersetzen zwar nicht den ersten, aber sind wie beschriebene eine zusätzliche Domain, mit der man verschiedene Dinge machen kann. Sie können allerdings nicht den primären Sitenamen ersetzen, denn dieser ist das eindeutige Erkennungsmerkmal eines Nutzers.

Falls man zusätzliche Sitenamen haben will, dann einfach mit Angabe, wofür man sie braucht (also wohin die Webseiten weiterleiten sollen, etc.), eine Mail an den Support senden.

Um eine eigene Domain zu registrieren, muss man Teilnehmer beim IN-Berlin sein. Die Registrierung ist kostenlos, es fallen nur monatliche Kosten an. Die Domain ist monatlich kündbar, wir benötigen aber (vom Registrar verlangt) eine schriftliche Kündigung.

Einige Preise findet man auf der IN-Berlin-Webseite, für exotischere Domains bitte per Mail an den support wenden, dann können wir mit den Preisen antworten.

Wenn man sich vergewissert hat, dass die Domain frei ist (dies kann man z.B. unter whois.in-berlin.de machen), schreibt man eine E-Mail an den Support, dass man diese Domain registriert haben möchte. Hierfür sind Angaben zum Namen des Domaininhabers, eine Telefonnummer und eine E-Mail-Adresse notwendig, da sie so von vielen TLD-Betreibern verlangt werden. Auch im eigenen Interesse sollte man diese Daten vollständig und aktuell halten, falls jemand von außerhalb Kontakt aufnehmen will oder es Probleme mit dieser Domain gibt.

Nach Registrierung ist die Domain allerdings nicht sofort sichtbar. Durch Negativ-Caching im Falle von Abfragen, und da die großen TLD-Hoster (wie die DeNIC) ihre Nameserver nicht sofortig updaten, kann es bis zu einem Tag dauern, bis eine Domain weltweit sichtbar ist.

Derzeit können DNS-Einträge nur über den IN-Berlin-Support vorgenommen werden.

Es sind quasi beliebige Einträge möglich, auch SPF- oder SRV-Records. Einfach eine Mail an support schicken, welche Subdomains man haben will und welche Records sie haben sollen.

Wenn Ihr eure eigene Domain auf eine Dynamische IP auflösen wollt, gibt es die Möglichkeit einen CNAME auf den DynDNS FQDN zu setzen. Beispiel:
eure.eigene-domain.net -CNAME- sitename.in-butter/dyn-berlin.de -Dynamischer A-Record- Dynamische IP

Das geht natürlich auch, wenn euer DNS/DynDNS Provider nicht der IN-Berlin ist.

Weitere Infos findet Ihr auch hier: DynDNS

Für XMPP gibt es ebenfalls die Option seine eigene Domain zu nutzen, dafür ist es notwendig, ähnlich wie bei Email auch, im DNS zu veröffentlichen welche Server für die Annahme der Nachrichten an deine Domain verantwortlich sind. Dazu werden Records vom Typ SRV genutzt. Da Client-zu-Server Kommunikation über andere Ports läuft, als Server-zu-Server Kommunikation, gibt es für beide Arten jeweiige Einträge.
Hinweis: Wenn deine Domain auf unseren Nameserven liegt, kümmern wir uns um die Eintragung der Records, sobald du eine Anfrage an uns schickst das du XMPP nutzen willst.

Client-zu-Server:
Name: _xmpp-client._tcp.eure-domain.tld
Wert: 5 0 5222 jabber.in-berlin.de
Server-zu-Server:
Name: _xmpp-server._tcp.eure-domain.tld
Wert: 5 0 5269 jabber.in-berlin.de

Für Gruppenunterhaltungen gibt es noch folgende Einträge zu ergänzen:
Client-zu-Server:
Name: _xmpp-client._tcp.conference.eure-domain.tld
Wert: 5 0 5222 jabber.in-berlin.de
Server-zu-Server:
Name: _xmpp-server._tcp.conference.eure-domain.tld
Wert: 5 0 5269 jabber.in-berlin.de

Optional kann es für ältere Clients noch notwendig sein, einen SRV nach folgendem Format zu erstellen:
Name: _jabber._tcp.eure-domain.tld
Wert: 5 0 5269 jabber.in-berlin.de
Unsere Empfehlung ist allerdings, es erstmal ohne diesen Eintrag zu versuchen, da er deprecated ist.

Die ersten beiden Ziffern des SRV Wertes haben etwas mit der Priorisierung zu tun, diese können je nach Bedarf gesetzt werden.
Die darauffolgende Portnummer und Hostname sollten wie hier in der Beschreibung gesetzt werden, sofern du planst unsere XMPP-Server zu nutzen.

Aktuell unterstützen wir XEP-0368 nicht, somit ist es aktuell nicht möglich über „_xmpps“ Namen eine direkte TLS Verbindung aufzubauen. Wir unterstützen TLS als Transportverschlüsselung für XMPP, die Verbindung muss allerdings erst darauf geupgradet werden. Dies passiert in der Regel automatisch und wird vom Client gesteuert.

Weitere Infos gibt es auf unserem Jabber/XMPP Wiki Artikel.

Um eine Domain vom IN-Berlin wegzuziehen, brauchen wir, wie beschrieben, eine schriftliche Kündigung. Danach senden wir euch den sogenannten Auth-Code zu. Dies ist ein kleiner Code, dem ihr dann dem neuen Hoster übergebt, und dieser wird mit diesem Code den Umzug veranlassen.

Genauso andersherum: Wenn ihr eine Domain zum IN-Berlin ziehen wollt, müsst ihr bei eurem alten Provider nach dem Auth-Code und der Freigabe fragen. Sowie ihr beides habt, schickt ihr den Auth-Code an den Support und wir veranlassen den Umzug und richten die Domains so ein, wie ausgemacht.

Wenn auf der Domain schon Inhalte liegen, muss das mit dem Support abgesprochen werden. Es gibt vor allem drei Inhalte, die meist umgezogen werden müssen:

• Mailaccounts: Die Mailaccounts können schon vorher angelegt werden, wie unter E-Mail beschrieben. Sowie die Domain umgezogen ist, empfangen dann auch alle E-Mail-Accounts für diese Domain E-Mails, wenn keine Blacklist eingetragen ist.
• Mailinglisten: Hierfür muss uns vorher Bescheid gegeben werden. Dann erstellen wir schon die Domain „intern“, d.h. unser Mailserver denkt nun, er sei für diese Mails verantwortlich. Danach könnt ihr die Mailinglisten anlegen, dann machen wir den Umzug. Das ganze muss schnell vonstatten gehen, da während dieser Zeit unser Mailserver keine ausgehenden Mails mehr für die umzuziehende Domain verschickt! Er denkt ab dann, er sei selber verantwortlich.
• Webseiten: Hierfür sagt ihr uns vorher Bescheid, dann erstellen wir schon die Webseite. Die könnt ihr dann temporär unter einer anderen Domain erreichen, um alles zu testen, und wenn das ok ist, wird die Domain umgezogen und der Webserver liefert die Inhalte auch mit der neuen Domain aus. Einfacher könnt ihr das machen, indem ihr ein Unterverzeichnis eures bisherigen Webspace zum Testen benutzt und danach alle Dateien in das Verzeichnis der neuen Domain schiebt. Das gleiche gilt auch, wenn ihr nichts testen müsst. Dann legen wir schon das Verzeichnis an, ihr kopiert eure Dateien, und wenn alles vorbereitet ist, wird die Domain umgezogen.

Seit Ende 2013 gibt es seitens der ICANN neue Vorschriften, dass Domaininhaber über das Auslaufen ihrer Domain informiert werden müssen (ERRP-Vorschrift). Die ICANN ist die Behörde, der im wesentlichen alles im Internet untersteht, und deren Vorschriften greifen auch für die Registrare, die wir benutzen.

Daher bekommen Inhaber von Domains jährlich zwei Mails mit dem Betreff Verlängerung Ihrer Domain - Renewal of your domain, eine ca. einen Monat, eine ca. eine Woche vor Ablauf der Domain. Dadrin wird aber darauf hingewiesen, dass die Domains automatisch verlängert werden, falls nichts unternommen wird. Das machen wir beim IN-Berlin, daher sind diese Mails für IN-Berlin-User nicht wichtig, man kann sie getrost ignorieren.

Warnung: Es gehen auch Phishing-Versuche um, um mit diesen Mails Nutzern Geld aus der Tasche zu ziehen. Die richtigen Benachrichtigungen informieren einen immer nur über die automatische Verlängerung, es ist nichts weiter zu tun. Wenn einen eine Mail zum Handeln auffordert, ist das eine Fälschung und muss ignoriert werden!