UUGRN:Services/DNS: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „= DNS = ____ _ _ ____ | _ \| \ | / ___| | | | | \| \___ \ | |_| | |\ |___) | |____/|_| \_|____/ ;Adminkontakt: :Marc 'Zugschlus' Haber ;Mes…“) |
|||
| Zeile 20: | Zeile 20: | ||
== Einleitung == | == Einleitung == | ||
| + | |||
| + | Das Domain Name System (DNS) ist einer der wichtigsten Dienste in vielen IP-basierten Netzwerken. Seine Hauptaufgabe ist die Beantwortung von Anfragen zur Namensauflösung. | ||
| + | |||
| + | Ohne einen funktionierenden DNS-Dienst sind die Domains, allen voran die uugrn.org, nicht auflösbar. | ||
| + | |||
| + | == technische Ziele == | ||
| + | |||
| + | * einfache Änderbarkeit der Daten | ||
| + | * Bereitstellung einer Schnittstelle zur automatischen Erzeugung von Resource Records | ||
| + | ** ermöglicht die Erstellung von letsencrypt-zertifikaten mit DNS-Challenge | ||
| + | * DNSSEC | ||
== aktueller Zustand == | == aktueller Zustand == | ||
| − | == | + | Wir haben den Master-DNS, der die Informationen hält, in einem FreeBSD-Jail auf top. In der Welt delegiert sind die Domains auf die Nameservices von jpru.de, die sich die Daten über AXFR/IXFR vom Master holt. |
| + | |||
| + | === Probleme mit diesem Zustand === | ||
| + | |||
| + | top ist aktuell instabil. Es hat höchste Priorität, den Master-DNS-Dienst von top auf eine Cloud-Maschine umzuziehen. | ||
| + | |||
| + | == leicht erreichbarer Bauzustand == | ||
| + | |||
| + | Als temporärer Bauzustand ist denkbar, die Slave-DNS weiterhin von jpru.de betreiben zu lassen. Hierbei ist externe Unterstützung und zeitliche Koordination durch Jürgen notwendig. Die Delegation der Domain "in der Welt" können wir selbst ändern. | ||
== Ziel-Architektur "einfach" == | == Ziel-Architektur "einfach" == | ||
| + | |||
| + | Eine mögliche Ziel-Architektur wäre, den Master-DNS in einer Hetzner-Cloud-Maschine zu betreiben und als Slave-DNS-Server die von Hetzner angebotenen DNS-Slaves zu verwenden. | ||
| + | |||
| + | Nachteil ist hier eine gewisse Abhängigkeit von Hetzner und die Konzentration der Dienst auf Hetzner. Sollten wir weiterhin so weit auf Hetzner setzen, sind unsere Dienste im Falle einer Hetzner-Störung allerdings sowieso unerreichbar, da kommt es dann auch nicht darauf an, ob die Domain erreichbar ist oder nicht. | ||
== Ziel-Architektur "richtig" == | == Ziel-Architektur "richtig" == | ||
| + | |||
| + | Eine "Hochglanz-Architektur" wäre, auch die Slave-DNS-Server selbst zu administrieren und mindestens einen Slave-DNS bei einem anderen Provider zu haben. | ||
| + | |||
| + | Eine solche Architektur wäre z.B. möglich, wenn ein Slave-DNS-Server bei cksoft in Frankfurt läuft. Zugschlus würde eine entsprechende VM als Dauerspende zur Verfügung stellen. | ||
| + | |||
| + | Ein dritter Server wäre dann entbehrlich, aber z.B. für EUR 5,99 im Monat bei edis.at mit Standort Toronto anmietbar. | ||
| + | |||
| + | == TODO == | ||
| + | |||
| + | * Entscheidung für eine der Ziel-Architekturen treffen | ||
| + | * VM "dns.uugrn.org" in "dns1.uugrn.org" umbenennen | ||
| + | ** vermeidet Namenskonflikte mit dem bestehenden FreeBSD-Jail | ||
| + | ** schafft Flexibilität beim Wechsel der Zielarchitekturen. | ||
| + | * Systeme bauen und in Betrieb nehmen | ||
| + | |||
| + | == Entschlußvorlage == | ||
| + | |||
| + | Der Vorstand möge beschließen: | ||
| + | |||
| + | * den DNS-Dienst mit einer VM bei Hetzner, einer zusätzlich zu mietenden VM am Standort Toronto und einer von Zugschlus gespendeten VM in Frankfurt/M aufzusetzen und zu betreiben. | ||
| + | |||
| + | Hilfweise möge der Vorstand beschließen: | ||
| + | |||
| + | * den DNS-Dienst mit einer VM bei Hetzner und und einer von Zugschlus gespendeten VM in Frankfurt/M aufzusetzen und zu betreiben. | ||
| + | |||
| + | Ebenfalls hilfsweise möge der Vorstand beschließen: | ||
| + | |||
| + | * den DNS-Dienst mit einer VM bei Hetzner und den von Hetzner bereitgestellten DNS-Slaves aufzusetzen und zu betreiben. | ||
Version vom 16. Mai 2020, 14:47 Uhr
DNS
____ _ _ ____ | _ \| \ | / ___| | | | | \| \___ \ | |_| | |\ |___) | |____/|_| \_|____/
- Adminkontakt
- Marc 'Zugschlus' Haber
- Messenger
- siehe https://www.incluesion.de/impressum/
- Phone
- bitte nur wenn es wirklich brennt
- IRC
- Zugschlus auf irc.uugrn.org:6667 und im IRCnet
- Status
- Konzept in Erstellung
Einleitung
Das Domain Name System (DNS) ist einer der wichtigsten Dienste in vielen IP-basierten Netzwerken. Seine Hauptaufgabe ist die Beantwortung von Anfragen zur Namensauflösung.
Ohne einen funktionierenden DNS-Dienst sind die Domains, allen voran die uugrn.org, nicht auflösbar.
technische Ziele
- einfache Änderbarkeit der Daten
- Bereitstellung einer Schnittstelle zur automatischen Erzeugung von Resource Records
- ermöglicht die Erstellung von letsencrypt-zertifikaten mit DNS-Challenge
- DNSSEC
aktueller Zustand
Wir haben den Master-DNS, der die Informationen hält, in einem FreeBSD-Jail auf top. In der Welt delegiert sind die Domains auf die Nameservices von jpru.de, die sich die Daten über AXFR/IXFR vom Master holt.
Probleme mit diesem Zustand
top ist aktuell instabil. Es hat höchste Priorität, den Master-DNS-Dienst von top auf eine Cloud-Maschine umzuziehen.
leicht erreichbarer Bauzustand
Als temporärer Bauzustand ist denkbar, die Slave-DNS weiterhin von jpru.de betreiben zu lassen. Hierbei ist externe Unterstützung und zeitliche Koordination durch Jürgen notwendig. Die Delegation der Domain "in der Welt" können wir selbst ändern.
Ziel-Architektur "einfach"
Eine mögliche Ziel-Architektur wäre, den Master-DNS in einer Hetzner-Cloud-Maschine zu betreiben und als Slave-DNS-Server die von Hetzner angebotenen DNS-Slaves zu verwenden.
Nachteil ist hier eine gewisse Abhängigkeit von Hetzner und die Konzentration der Dienst auf Hetzner. Sollten wir weiterhin so weit auf Hetzner setzen, sind unsere Dienste im Falle einer Hetzner-Störung allerdings sowieso unerreichbar, da kommt es dann auch nicht darauf an, ob die Domain erreichbar ist oder nicht.
Ziel-Architektur "richtig"
Eine "Hochglanz-Architektur" wäre, auch die Slave-DNS-Server selbst zu administrieren und mindestens einen Slave-DNS bei einem anderen Provider zu haben.
Eine solche Architektur wäre z.B. möglich, wenn ein Slave-DNS-Server bei cksoft in Frankfurt läuft. Zugschlus würde eine entsprechende VM als Dauerspende zur Verfügung stellen.
Ein dritter Server wäre dann entbehrlich, aber z.B. für EUR 5,99 im Monat bei edis.at mit Standort Toronto anmietbar.
TODO
- Entscheidung für eine der Ziel-Architekturen treffen
- VM "dns.uugrn.org" in "dns1.uugrn.org" umbenennen
- vermeidet Namenskonflikte mit dem bestehenden FreeBSD-Jail
- schafft Flexibilität beim Wechsel der Zielarchitekturen.
- Systeme bauen und in Betrieb nehmen
Entschlußvorlage
Der Vorstand möge beschließen:
- den DNS-Dienst mit einer VM bei Hetzner, einer zusätzlich zu mietenden VM am Standort Toronto und einer von Zugschlus gespendeten VM in Frankfurt/M aufzusetzen und zu betreiben.
Hilfweise möge der Vorstand beschließen:
- den DNS-Dienst mit einer VM bei Hetzner und und einer von Zugschlus gespendeten VM in Frankfurt/M aufzusetzen und zu betreiben.
Ebenfalls hilfsweise möge der Vorstand beschließen:
- den DNS-Dienst mit einer VM bei Hetzner und den von Hetzner bereitgestellten DNS-Slaves aufzusetzen und zu betreiben.
