Generische Gateway-DNS-Einträge in der Firmware?

Moin,

was haltet ihr davon, wenn wir in jeder Domäne Domäneinträge wie gateway-domaene-XX.servers.freifunk-muensterland.de in die Firmware eintragen?

Dann könnte man den Server wechseln, ohne eine neue Firmware ausrollen zu müssen. Einfach eine neue VM oder einen neuen Server aufsetzen, den DNS-Eintrag ändern und schon gehen die Verbindungen dorthin, sobald man die alte VM abschaltet.

Dadurch könnte man das vielleicht einfacher ausbalancieren, ohne jedes mal eine neue Firmware bauen zu müssen und ohne jedes mal den Autoupdater zu bemühen.

Adminteam: @kgbvax, @FanLin, @void, @Parad0x, @paulinsche, @descilla, @Fungur, @MPW

Grüße
Matthias

3 Like

Bin dafür.
DNS per Ansible heißt ja, dass wir keinen Mehraufwand haben. (Bis auf das einmalige anpassen)

1 Like

Prinzipiell ja, hätte aber zwei Bedingungen:

  • Server werden weiterhin (zusätzlich) mit IP Adresse aufgeführt, es kann ja mal sein, dass beim Knotenaufsteller das DNS kaputt ist.
  • Bei Gateway-Umstellungen sollte dennoch zeitnah eine aktualisierte Firmware zur Verfügung gestellt werden, sodass immer mindestens ein Gateway (je Domäne) per IP Adresse erreichbar ist. (Wenn ich es richtig überflogen habe, gibt es in Gelsenkirchen ein fuckup, dass die Domain aufgegeben wird und dadurch die Gateways nicht mehr erreichbar sein könnten. Die Probleme sehe ich zwar bei uns nicht, aber man kann sie ja trotzdem strukturell ausschließen.)

Dann sehe ich jedoch einen echten Mehrwert darin und es ermöglicht uns mehr Flexibilität und dadurch eine höhere Verfügbarkeit.

PS: Wir brauchen eine sehr kurze Domain, in der Zeit in der ich gw-name.xy.freifunk-muensterland.de eingetippt habe, habe ich auch schon ein cat auf das hostfile von ansible gemacht. ffms.de ist leider schon vergeben. (Das steht natürlich nicht direkt in Zusammenhang mit diesem Thema.)

1 Like

ffmsl.de scheint frei zu sein

Meine Finger haben sich dran gewöhnt .servers.freifunk-muensterland.de zu tippen ;).

Würde das denn ohne weiteres gehen da eine zweite Domäne auch zu beliefern?

Ja, wir haben ja eh schon die Domains freifunk-muensterland.de und freifunk-muenster.de. Eine mehr ist kein Problem.

2 Like

Sollte sich der ffi klicken, oder?

Für l2tp in Warendorf mache ich das seit längerem. Auf IP in der Firmware würde ich dringend verzichten: da wo DNS kaputt ist, ist DNS kaputt, nicht nur für Freifunk.

Bleibt der Hinweis, das im fastd Fall nicht zwei Server den gleichen Public Key haben können.

Ich habe auch noch die Domäne freifunk-muensterland.net abzugeben.

1 Like

Dem möchte ich widersprechen :wink: Wenn lokal DNS kaputt ist, aber über IP eine Freifunk-Verbindung aufgebaut wird, dann würden Freifunk-Clients Namen auflösen können. Ich möchte IPs gerne drin haben.
DNS ist viel fehleranfälliger als static IP :slight_smile:

2 Like

Wenn irgendwo DNS kaputt ist, dann tut da garnix, und immer noch fast garnix, wenn man alle IP Adressen aus dem Kopf kennt. Höre ich Widerspruch? Wenn weiter mit den IPs in der Firmware gearbeitet wird, dann kann man den ganzen Beitrag hier streichen, denn dann kann man über DNS nichts steuern.

Wann und wo hatte man man den Fall, dass lokal DNS kaputt war?

1 Like

Der Freifunkrouter braucht nur exakt eine IP, nämlich die des Gateways.

Die DNS-Auflösung im Freifunknetz geht dann über den Tunnel und funktioniert. Daher kann es schon hilfreich sein, die IP drin zu haben. Es gab häufiger mal das Problem, dass ein mehr oder weniger bekannter Internetanbieter unsere DNS-Adresse nicht auflösen wollte oder konnte.

Das wird dann eher ein Problem in „unserem“ DNS-Server gewesen sein. Alles andere ist eher eine Verschwörungstheorie. Mir ist schon klar, dass lokale DNS-Auflösung ausschließlich für den Freifunk-Knoten und dann auch nur für die Auflösung des/der Tunnel-Endpunkte nötig ist.

Wenn weiter mit den IPs in der Firmware gearbeitet wird, dann kann man den ganzen Beitrag hier streichen, denn dann kann man über DNS nichts steuern.

1 Like

Wir betreiben die die Namenserver für unsere Domain freifunk-muensterland.de selbst. Hauste da einen Fuckup rein könnte es schon Probleme geben. Auch wenn der Vorteil als sehr gering eingeschätzt wird, sehe ich de facto keinen Nachteil die IPs zusätzlich rein zu werfen.

Ne, es war wirklich so, dass der DNS-Server des Internetanbieters das nicht korrekt aufgelöst hat, Google aber schon. War sicherlich eine Fehlfunktion.

Die DNS-Server der Anbieter laufen oft nicht so gut, trotzdem hat nicht jeder Google drin.

Ich glaub wo @paulinsche drauf hinaus will, ist dass du dann jeder einzelnen Anfrage eine andere IP geben kannst, also so Round-Robin mäßig. Ich weiß aber gar nicht, ob das unser jetziges System überhaupt mitmacht, weil man die Cachezeiten dann sehr kurz einstellen müsste.

Hauste da ein Fuckup rein, gibt es Probleme für die Router die sich gerade verbinden wollen. Außerdem läuft dann dieses Forum und noch so ein paar Sachen nicht. Man sollte also davon ausgehen, dass jemand ziemlich schnell das DNS reparieren würde. Die Einträge broker1.freifunk-muensterland.net und broker2.freifunk-muensterland.net haben deswegen auch extra einen niedrigen TTL von 600s.

Die Steuerung via DNS aufzugeben um einen Fehler bei Aufsteller eines Knotens auszubügeln halte ich für falsch. Gegen Fuckups im eigenen DNS sollte man sich wappnen können.

1 Like

Der Vorteil ist, dass man nicht auf den Firmware-Bau (und Verteilung) warten muss (natürlich muss man immer noch aufs DNS-TTL warten), wenn man spontan ein Gateway umziehen möchte.

Da wie o. G. es durchaus Probleme mit DNS geben kann, erachte ich es für sinnvoll weiterhin IP Adressen mit an die Knoten auszuliefern. Somit verringert man das Zeitfenster, in dem man vom DNS abhängig ist (außerdem werden wohl in den seltensten Fällen beide Gateways umgezogen).

Bzgl. DNS-Cache:

  • Wenn die Adresse im DNS umgestellt wird, gibt es einen Zeitraum in dem verschiedene Knoten unterschiedliche Auflösungen haben (könnten). Wie wollen wir damit umgehen? Neuen Server anknipsen, waren bis DNS “durch” ist und dann erst den alten abdrehen? …
  • Wir sollten (zumindest für diesen Teilbaum) die TTL starkt runter drehen (ist glaube ich derzeit 86400 Sekunden / 1 Tag). Dadurch sind wir natürlich immer noch nicht davor gefeit, dass irgendwelche anderen Stellen das durchaus länger cachen könnten (was aber in der Praxis eher untypisch ist).

Vielleicht auch nur ein Negative Caching of DNS nach einem Fuckup?

600 Sekunden?

ja, genau so. Nach 600 Sekunden ist der Spuk ja um.

ttl kannst du an einzelnen Einträgen machen.

1 Like

Ich möchte an dieser Stelle noch mal auf datensparsamere Namensserver verweisen: https://www.ccc.de/de/censorship/dns-howto


@paulinsche Unsere Antwortzeiten überschneiden sich immer kurz. :stuck_out_tongue:

Aber was spricht dagegen, die IPs zusätzlich mit aufzunehmen? Den einzigen Grund den ich sehe, ist wenn man das alte Gateway für eine andere Domäne verwenden will und die selben Ports (bei l2tp, bei fastd eher unwahrscheinlich, da pub/priv key auth) verwendet. Aber das hätte man bei dns wegen der cache zeiten auch.

Ja, für jedes Gateway einzeln? Dann doch lieber für .gatways.freifunk-muensterland.de. .