DNS aus Redeemer: 1 Hauptdevice pro Knoten


#1

Ich fände es toll, wenn man für einen Node EIN device als “Master” markieren kann, sodass es zusätzlich zu device.node.wien.funkfeuer.at auch als node.wien.funkfeuer.at eh getragen wird.


#2

coole idee - wobei mir auch gefallen würde, wenn man für node.wien.funkfeuer.at eine Webseite / Wiki-Eintrag verlinken könnte.


#3

Da es ohnedies kaum noch dem PPA entsprechende Firmwares gibt, wäre so eine Statusseite eine gute Ergänzung und ein guter Ausgangspunkt für eine Node-Dokumentation.


#4

Ad Wiki-Eintrag: das ist eher Sache von den Maps, die einen Link beim Node einblenden müssten.

Ein Template dazu zu erstellen wäre natürlich hilfreich. Und eine einfache/userfreundliche Möglichkeit zum Hinzufügen von Fotos.

Ein Master-DNS-Entry braucht in Redeemer ein neues Feld auf Node Ebene. Oder auf Device-Ebene mit Sicherstellung dass nur 1 device pro Node das sein darf.
Dann die Schnittstelle zum DNS-Server und das GUI.

Kann doch keine Hexerei sein…!


#5

Lese ich da in den ersten beiden Absätzen eine Aufforderung heraus, das Wiki auch gleich als Gallery zu benützen?


#6

Ich schätze den Aufwand auf weniger als 1 Tag für ein wirklich cooles Feature.


#7

Ich find die Idee wirklich cool und es klingt für mich recht simpel.
Weis jemand was es zur Umsetzung braucht?
Wer hat Zugriff auf die Funkfeuer DNS Server bzw. die involvierte Software die aus der Redeemer Datenbank die entsprechenden DNS Einträge generiert?


#8

DNS -> Adi.
Redeemer - siehe Redeemer-Thread im Forum.
Aber darf ich fragen, wofür das Hauptdevice pro Knoten denn nun eigentlich dienen soll?


#9

Aus meiner Sicht: Es Knotenbetreibern zu ermöglichen selbst gehostete Dienste unter einer um ein Segment kürzeren URL ansprechbar machen zu können.

Also z.B. wie wir dieses Forum noch nicht auf Vereinsinfrastruktur hosten konnten hat es @vchrizz auf einem Device namens “www” in einem Knoten namens “forum” gehostet, wodurch die URL https://www.forum.wien.funkfeuer.at war. Gäbe es die Möglichkeit ein Device als Hauptdevice zu markieren, würde dies Knotenbetreibern ermöglichen Dienste unter knoten.wien.funkfeuer.at erreichbar zu machen, also unter einer um ein Segment kürzeren URL.


#10

@kaefert die Frage war nicht, wofür grundsätzlich, sondern für welche Dienste und zu welchem Zweck. Es wäre etwa nicht gut, einen CNAME (Alias) zu verwenden, wenn ein MX darauf lauten soll. Und ein MX ist etwa gar nicht vorgesehen.

Siehe https://de.wikipedia.org/wiki/CNAME_Resource_Record für eine verständliche Erklärung von https://tools.ietf.org/html/rfc2181


#11

Das würd ich gern den Funknetzteilnehmer bzw. Teilnehmer an unserem OLSR Netzwerk überlassen. Ofizielle vom Verein gehostete Dienste haben ohnehin getrennte manuell eingerichtete DNS-Einträge.

Sorry, aber ich versteh leider überhaupt nicht was du damit meinst. Bitte versuch deinen Einwand für weniger erfahrene Netzwerktechniker verständlich umzuformulieren.

So wie ich das sehe, sind derzeit device.node.wien.funkfeuer.at DNS Einträge für Verwendung durch Funknetzteilnehmer bzw. Teilnehmer an unserem OLSR Netzwerk vorgesehen. Und ich sehe keinen Grund der dagegenspricht auch node.wien.funkfeuer.at dafür freizugeben.

Am liebsten wäre mir ja der Wechsel von node.wien.funkfeuer.at auf node.funkfeuer.wien (Was glaub ich letztens im Chat vorgeschlagen wurde, nachdem die funkfeuer.wien auch in vereinsnahen Kreisen existiert und derzeit nicht verwendet wird.)


#12

wien.funkfeuer.at ist eine Zone. In dieser Zone liegen die A-Records für die einzelnen Knoten + Devices drinnen.

Beispiel: bet6 ist der Knoten. omni ist das Device. Der Hostname für den der Eintrag gemacht wird, ist also omni. Für den Knoten gibt es aber keine eigene Zone bet6.wien.funkfeuer.at. Daher wird die „Zone“ an den host „angehängt“, sodass omni.bet6 in der Zone wien.funkfeuer.at eingetragen wird.

omni.bet6 ist ein A-Record, d.h. der Hostname verweist auf eine IPv4-Adresse. Korrespondierend dazu gibt es eine Zone, in der die IPv4-Adresse mittels Pointer (PTR) zurück auf den Hostnamen verweist.

Würde man den Knotennamen bet6 als Alias (=CNAME) eintragen würde bet6 auf omni.bet6 verweisen. Für Statusinfos, Webdienste usw. ist das in Ordnung.

Möchte der User aber einen Mailserver betreiben und den Knotennamen dafür als MX verwenden, steht er vor einem Problem: Denn ein MX-Record darf nicht auf einen CNAME lauten, sondern nur auf einen A-Record.

Wenn Du nun eine eigene Subdomain für Knoten wünscht, umgehst Du zwar das Problem, dass man die automatische Generierung der Hostnames sonst aushebeln würde (siehe oben die Problematik hostname+knotenname…), stehst aber vor dem Problem, dass -etwa wieder beim MX- die PTR-Adresse von der aufgelösten Adresse abweichen würde.

Wenn man also den Knotennamen für MX, NS, … etc verwenden wollte, müsste man es andersherum lösen und den Devicenamen auf den Knotennamen in der anderen Zone zeigen lassen und auch dafür den PTR anlegen. An dieser Stelle wird es für den User einfacher, aber für den Admin komplizierter. Anders ist es zwar technisch einfach zu machen, aber für den User wertlos, da mit Aufwand verbunden.

Das ist vielleicht ein Detailproblem, aber wir wollen die Nutzung der Dienste ja nicht erschweren, sondern vereinfachen.

Ein Ausweg könnte sein, den User den PTR seiner IP ändern zu lassen und die Art des Domaineintrags selbst zu verwalten. Etwa könnte man dem User seine Knotenzone über einen DNS-Editor zu Verfügung stellen - aber wer macht den Support dafür? Obwohl es einfach ausschaut, erfordert es Grundwissen zu DNS.


#13

Ah, okey. Thx für die Erklärung.

Das heißt man müsste beim implementieren des Features in der DNS-Service-Kette aufpassen, dass wenn im Redeemer (oder Nachfolger) für einen Knoten ein “Hauptdevice” angegeben wurde, nicht device.node.wien.funkfeuer.at als A-Record und node.wien.funkfeuer.at als CNAME für diesen A-Record angelegt wird, sondern umgekehrt, um dieses Feature auch möglichst vielfältig (inklusive Mail-Server) verwenden zu können. (Wenn man nen Mailserver unter device.node.wien.funkfeuer.at betreiben wollen würde, muss man dann einfach dieses device eben nicht als Hauptdevice des Knotens markieren.)

Hab ich das richtig verstanden?


#14

Es kommt eben darauf an, wofür es verwendet werden soll. Ist nur eine webbasierte, automatisierte Standardinfo über den Knoten vorgesehen, ist es „gehüpft wie gesprungen“.
Möchte man „höhere“ Dienste verwenden, gibt es Standards und Konventionen, auf die man Rücksicht nehmen sollte. Details nennt der oben gepostete Wikipedia-Eintrag. Wichtig ist dann vor allem für Mail, dass PTR und A des MX übereinstimmen. Mit einem einfachen Hakerl in der Deviceverwaltung ist es dann nicht getan.


#15

Kann man dieses Hackerl (bzw. Drop-Down zur Auswahl?) nicht beim Generator der DNS-Config auf eine Art berücksichtigen, dass es die für Mail-Server notwendigen standards erfüllt?


#16

Es kommt halt immer auf den damit verfolgten Zweck an. Wenn man sich darüber einmal im Klaren ist, geht vieles. Ich wollte darauf hinweisen, damit die Idee besser Gestalt annimmt. Danke für den Vorschlag!