RE: Namensauflösung für Router IPv6

[mail at adrianschmutzler.de]

Hallo Jan,

vielen Dank für deine Mühen, auch wenn die Sache jetzt eingestampft ist, habe ich zumindest wieder einiges mehr verstanden.

Muss ich mir das halt wieder selber irgendwie hinbauen, nachdem ich ja jetzt weiß, dass das über normalen public DNS läuft.

Kannst du mir eine primitive DNS-Lösung für Debian empfehlen, die ich auf meinen Server klatschen kann?

Grüße

Adrian

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf
> Of Jan Kraus
> Sent: Montag, 5. März 2018 21:59
> To: Tim Niemeyer <tim at tn-x.org>; franken-dev at freifunk.net; franken-
> gateway at freifunk.net
> Subject: Re: Namensauflösung für Router IPv6
> 
> Hi
> Am Montag, den 05.03.2018, 21:36 +0100 schrieb Tim Niemeyer:
> > Moin
> >
> > Am Montag, den 05.03.2018, 16:13 +0100 schrieb Adrian Schmutzler:
> > > Hallo zusammen,
> > >
> > > ich hatte gerade eine verrückte Idee und würde mich für eure Meinung
> > > interessieren:
> > >
> > > Durch die neuen fd43… Adressen kann man zwar in alle Hoods kommen,
> > > aber man muss immer irgendwoher das Prefix kopieren (ich kann mir
> > > das nicht merken) und die richtige Nummer der Zielhood (bzw. in
> > > welcher Hood der Router ist) kennen.
> >
> > Das Prefix is wirklich ziemlich schwer zu merken. Aber natürlich macht
> > es irgendwie immer Sinn, wenn man weiß in welcher Hood sich sein
> > eigener Knoten so befindet. Theoretisch kann es zwar sein, dass der
> > rumhüpft, aber dann sollte man sich das doch ganz dringend mal
> > angucken.
> >
> > > Mir kam gerade die Idee, ob es nicht einen Mechanismus geben könnte,
> > > nur mit der MAC-Adresse (ohne weitere „Informationen“) auch Hood-
> > > übergreifend den Router anzusprechen.
> > > Routing-technisch sehe ich da keinen Weg, aber man könnte ja
> > > netzINTERN eine Namensauflösung einrichten nach der Art:
> > >
> > > MAC address: aa:99:88:77:66:55
> > >
> > > DNS Name: aa9988776655.fff -> IPv6:
> > > fd43:5602:29bd:21::aa99:8877:6655
> > >
> > > Eine TLD fff gibt es scheinbar nicht, insofern machen wir da auch
> > > nichts kaputt.
> >
> > TLD's zu klauen ist keine gute Idee. Da sind schon Leute bitter auf
> > die Schnauze gefallen, weil die TLD dann doch plötzlich gekauft wurde.
> >
> > Dann lieber auf den Vorschlag von Mayosemmel zurückgreifen.
> >
> > > Über die Idee hinaus kann ich natürlich kaum die technische
> > > Machbarkeit / den Aufwand beurteilen. Von den MS Servern kenne ich
> > > es so, dass die Geräte im Active Directory ihre DNS Einträge
> > > selbstständig aktualisieren. Vll. gibt es bei Linux/LEDE einen
> > > entsprechende Mechanismus. Vll. könnte man auch einfach die
> Gateways
> > > eine MAC-Liste der Router aus Batman generieren lassen und das dann
> > > turnusmäßig an irgendeinen FFF DNS Server weitergeben.
> >
> > Ich würde vorschlagen, dass man einen kleinen DNS Server schreibt, der
> > stumpf aa9988776655.hood.fff -> IPv6: fd43:5602:29bd:${hood-
> > id}::aa99:8877:6655
> > ausgibt. Man müsste nur die Hood-ID irgendwo her bekommen.
> >
> > Der Vorteil wäre, dass man nicht wissen müsste ob der Knoten existiert
> > oder nicht und die Auflösung immer gelingt.
> Nette Ideen, kann man sicher diskutieren. Ist aber mit viel Aufwand
> verbunden und nicht auf die schnelle umsetzbar um Menschen das Leben
> einfacher zu machen.
> >
> > Weiter wäre es ein guter Zeitpunkt nochmal ein wenig rumzugucken. Hat
> > schon mal jemand recherchiert, was es für Lösungen gibt? Mir fällt
> > spontan mdns und kadnode ein. Ob das taugt weiß ich nicht, sollte aber
> > mal betrachtet werden bevor einfach _irgendwas_ umgesetzt wird.
> >
> > > Wie gesagt, alles nur eine verrückte Idee, keine Ahnung ob das
> > > praktikabel ist.
> >
> > Natürlich ist das irgendwie praktikabel.
> >
> > Ich finde es auch sehr gut, dass wir hier gemeinsam eine Idee
> > diskutieren, um dann gemeinsam eine gute Lösung zu finden. Schön, dass
> > du die Diskussion angestoßen hast.
> >
> > Was mir gar nicht gefällt, dass mal eben hinter unser aller Rücken im
> > IRC bereits eine Monitoring-API gebaut wurde und quasi schon alle
> > Knoten in irgendwelche DNS Server geschüttet wurden. Das ist eben
> > genau nicht die Zusammenarbeit, wie ich sie mir hier in der Community
> > vorstelle.
> Was mir gar nicht gefällt ist, gegen eine einfache und funktionierende Lösung
> so sehr zu wettern ohne eine andere funktionsfähig Lösung zu haben. Sicher
> ist das nicht optimal und wir sind und waren uns dessen bewusst!
> Eine schönere Lösung ist dadurch ja nicht ausgeschlossen...
> >
> > Technisch bin ich ziemlich enttäuscht, dass schon wieder weitere
> > Dienste an das Monitoring angebaut werden. Wir haben damals beim
> > Netmon eine ganz bittere Erfahrung gemacht, und gelernt, dass es keine
> > gute Idee ist irgendwelche Dienste von dem Monitoring System abhängig
> > zu machen. Die Argumentation "das ist ja nur Zusatz und alles total
> > unkritisch" lasse ich nicht gelten, weil DNS ein Basis Dienst ist und
> > sich irgendwann Leute darauf verlassen werden. Die Diskussion hier hat
> > nicht mal richtig angefangen und schon wird wieder jegliche wichtige
> > Architektur-Erfahrung über Board geworfen und gute Ideen haben
> > überhaupt keine Chance mehr auf Umsetzung. Das ist Erdbeerkäse!
> Ist jetzt alles wieder eingedampft!
> 
> Gruß Jan
> >
> > Grüße
> > Tim