Simple Zonefile Howto: Unterschied zwischen den Versionen

Aus Hostsharing Wiki
Zur Navigation springen Zur Suche springen
KKeine Bearbeitungszusammenfassung
KKeine Bearbeitungszusammenfassung
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 11: Zeile 11:
Das komplette Zonefile sieht so aus:
Das komplette Zonefile sieht so aus:


<pre>
<syntaxhighlight lang=apache line>
{HEADER}
{HEADER}
{SOA_RR}
{SOA_RR}
Zeile 23: Zeile 23:
*.{DOM_HOSTNAME}.  IN  A  1.2.3.4
*.{DOM_HOSTNAME}.  IN  A  1.2.3.4
*.{DOM_HOSTNAME}.    IN  AAAA  1.2.3.4.....
*.{DOM_HOSTNAME}.    IN  AAAA  1.2.3.4.....
</pre>
</syntaxhighlight>


1.2.3.4 ist durch die externe IPV4-Adresse zu ersetzten, 1.2.3.4... durch die externe IPv6-Adresse.
1.2.3.4 ist durch die externe IPV4-Adresse zu ersetzten, 1.2.3.4... durch die externe IPv6-Adresse.
Zeile 31: Zeile 31:
Die Subdomain zuhause.example.com soll über einen Anbieter à la dyndns laufen. Das komplette Zonefile sieht so aus:
Die Subdomain zuhause.example.com soll über einen Anbieter à la dyndns laufen. Das komplette Zonefile sieht so aus:


<pre>
<syntaxhighlight lang=apache line>
{DEFAULT_ZONEFILE}
{DEFAULT_ZONEFILE}
zuhause.{DOM_HOSTNAME}. IN CNAME example.dyndns.org.
zuhause.{DOM_HOSTNAME}. IN CNAME example.dyndns.org.
</pre>
</syntaxhighlight>


== Externer Mailserver ==
== Externer Mailserver ==
Zeile 40: Zeile 40:
Wir wollen einen Mailserver extern betreiben, z.B. bei einem Cloud-Anbieter (Mails, Kontakte und Termine schon gecloudt?) oder im Büro. Wir übernehmen also erstmal alles, was {DEFAULT_ZONFILE} liefern würde, außer den MX Resource Records:
Wir wollen einen Mailserver extern betreiben, z.B. bei einem Cloud-Anbieter (Mails, Kontakte und Termine schon gecloudt?) oder im Büro. Wir übernehmen also erstmal alles, was {DEFAULT_ZONFILE} liefern würde, außer den MX Resource Records:


<pre>
<syntaxhighlight lang=apache line>
{HEADER}
{HEADER}
{SOA_RR}
{SOA_RR}
Zeile 50: Zeile 50:
{WILDCARD_AAAA_RR}
{WILDCARD_AAAA_RR}
{WILDCARD_SPF_RR}
{WILDCARD_SPF_RR}
</pre>
</syntaxhighlight>


Nun definieren wir den Mailserver, d.h., wir fügen diese Zeile hinzu:
Nun definieren wir den Mailserver, d.h., wir fügen diese Zeile hinzu:


<pre>
<syntaxhighlight lang=apache line>
mail.{DOM_HOSTNAME}. IN MX 30 my.cloud.provider.example.com.
mail.{DOM_HOSTNAME}. IN MX 30 my.cloud.provider.example.com.
</pre>
</syntaxhighlight>


Oder per fester IP, d.h., wir fügen alternativ diese Zeile hinzu:
Oder per fester IP, d.h., wir fügen alternativ diese Zeile hinzu:


<pre>
<syntaxhighlight lang=apache line>
mail.{DOM_HOSTNAME}. IN A 1.2.3.4
mail.{DOM_HOSTNAME}. IN A 1.2.3.4
</pre>
</syntaxhighlight>


Dann legen wir die MX-Konfiguration fest, die besagt, welcher Mailserver für diese Domain zuständig ist (weitere Zeile wird hinzugefügt):
Dann legen wir die MX-Konfiguration fest, die besagt, welcher Mailserver für diese Domain zuständig ist (weitere Zeile wird hinzugefügt):


<pre>
<syntaxhighlight lang=apache line>
{DOM_HOSTNAME}. IN MX 30 mail.{DOM_HOSTNAME}.
{DOM_HOSTNAME}. IN MX 30 mail.{DOM_HOSTNAME}.
</pre>
</syntaxhighlight>


Wenn wir Mails auch für Subdomains wollen, brauchen wir zusätzlich:
Wenn wir Mails auch für Subdomains wollen, brauchen wir zusätzlich:


<pre>
<syntaxhighlight lang=apache line>
*.{DOM_HOSTNAME}. IN MX 30 mail.{DOM_HOSTNAME}.
*.{DOM_HOSTNAME}. IN MX 30 mail.{DOM_HOSTNAME}.
</pre>
</syntaxhighlight>


;Achtung
;Achtung
Damit das interne {{lang|en|mailrouting}} innerhalb des Pakets für die Domain so funktioniert, daß keine lokal eingelieferten {{lang|en|e-mails}} an Mailboxen im Paket zugestellt werden, muß darauf geachtet werden, daß im Paket selber keine {{lang|en|e-mail}}-Adressen für die Domain defniert sind. Standardmäßig werden beim Einrichten einer Domain die Adressen:
Damit das interne {{lang|en|mailrouting}} innerhalb des Pakets für die Domain so funktioniert, daß keine lokal eingelieferten {{lang|en|e-mails}} an Mailboxen im Paket zugestellt werden, muß darauf geachtet werden, daß im Paket selber keine {{lang|en|e-mail}}-Adressen für die Domain defniert sind. Standardmäßig werden beim Einrichten einer Domain die Adressen:
abuse@...
<syntaxhighlight lang=output line>
postmaster@...
abuse@...
webmaster@...
postmaster@...
webmaster@...
</syntaxhighlight>
[https://doc.hostsharing.net/users/administration/domain/index.html Domain]. Bei der oben angeführten MX-Konfiguration müssen diese mit [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin] wieder gelöscht werden.
[https://doc.hostsharing.net/users/administration/domain/index.html Domain]. Bei der oben angeführten MX-Konfiguration müssen diese mit [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin] wieder gelöscht werden.



Aktuelle Version vom 20. Juni 2024, 13:21 Uhr

In diesem Howto werden einfachere Standardanwendungen für eigene Zonefiles behandelt. Tiefer gehende Erläuterungen finden sich in Verwalten der Zonendaten.

Normalerweise wird von Hostsharing die Konfiguration der Nameserver automatisch erledigt. Das ist einer angepassten Lösung grundsätzlich vorzuziehen. Es entlastet den Anwender von der Pflicht, sein Zonefile bei technischen Änderungen zu überprüfen. Sollte dennoch ein benutzerspezifisches Zonefile erforderlich sein, so verringert der Einsatz möglichst mächtiger Platzhalter den späteren Anpassungsbedarf. In vielen Fällen genügt es, den Platzhalter für das Standardzonefile um eigene Einträge zu ergänzen.

Ist die Verwendung eines angepassten Zonefiles erforderlich, z.B. zur Realisation von DNS-Verweisen auf extern gelagerte Subdomains, der Anbindung externer Server oder der Verwendung eigener Mailserver, kann pro Domain ein eigenes Zonefile erstellt werden. Dieses befindet sich im Verzeichnis ~/doms/example.com/etc und trägt den Namen pri.example.com (example.com steht hier als Beispiel für den wahren Domainnamen). Das Neuanlegen oder eine Änderung dieser Datei führt zu einer baldigen Änderung der Nameservereinträge für die Domain.

Warnung!

Das nicht sachgemäße Erstellen eines eigenen Zonefiles kann zur Nichterreichbarkeit der eigenen Domain und zum Verlust von Mails führen! Insbesondere sei auf die Fehlerquelle gesetzter bzw. nicht gesetzter abschließender Punkte hingewiesen.


alle Web-Inhalte soll auf externe IP-Adresse verweisen

Das komplette Zonefile sieht so aus:

{HEADER}
{SOA_RR}
{NS_RR}
{MX_RR}
{SPF_RR}
{WILDCARD_MX_RR}
{WILDCARD_SPF_RR}
{DOM_HOSTNAME}.    IN  A  1.2.3.4
{DOM_HOSTNAME}.    IN  AAAA  1.2.3.4.....
*.{DOM_HOSTNAME}.  IN  A  1.2.3.4
*.{DOM_HOSTNAME}.    IN  AAAA  1.2.3.4.....

1.2.3.4 ist durch die externe IPV4-Adresse zu ersetzten, 1.2.3.4... durch die externe IPv6-Adresse.

Subdomain zuhause.example.com über Anbieter wie dyndns

Die Subdomain zuhause.example.com soll über einen Anbieter à la dyndns laufen. Das komplette Zonefile sieht so aus:

{DEFAULT_ZONEFILE}
zuhause.{DOM_HOSTNAME}.	IN	CNAME	example.dyndns.org.

Externer Mailserver

Wir wollen einen Mailserver extern betreiben, z.B. bei einem Cloud-Anbieter (Mails, Kontakte und Termine schon gecloudt?) oder im Büro. Wir übernehmen also erstmal alles, was {DEFAULT_ZONFILE} liefern würde, außer den MX Resource Records:

{HEADER}
{SOA_RR}
{NS_RR}
{A_RR}
{AAAA_RR}
{SPF_RR} 
{WILDCARD_A_RR}
{WILDCARD_AAAA_RR}
{WILDCARD_SPF_RR}

Nun definieren wir den Mailserver, d.h., wir fügen diese Zeile hinzu:

mail.{DOM_HOSTNAME}.	IN	MX 30 my.cloud.provider.example.com.

Oder per fester IP, d.h., wir fügen alternativ diese Zeile hinzu:

mail.{DOM_HOSTNAME}.	IN	A	1.2.3.4

Dann legen wir die MX-Konfiguration fest, die besagt, welcher Mailserver für diese Domain zuständig ist (weitere Zeile wird hinzugefügt):

{DOM_HOSTNAME}.		IN	MX	30 mail.{DOM_HOSTNAME}.

Wenn wir Mails auch für Subdomains wollen, brauchen wir zusätzlich:

*.{DOM_HOSTNAME}.	IN	MX	30 mail.{DOM_HOSTNAME}.
Achtung

Damit das interne mailrouting innerhalb des Pakets für die Domain so funktioniert, daß keine lokal eingelieferten e-mails an Mailboxen im Paket zugestellt werden, muß darauf geachtet werden, daß im Paket selber keine e-mail-Adressen für die Domain defniert sind. Standardmäßig werden beim Einrichten einer Domain die Adressen:

abuse@...
postmaster@...
webmaster@...

Domain. Bei der oben angeführten MX-Konfiguration müssen diese mit hsadmin wieder gelöscht werden.