fff-dhcp: add anycast dns server #29
No reviewers
fbl
Labels
No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
No Milestone
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: freifunk-franken/firmware#29
Loading…
Reference in New Issue
No description provided.
Delete Branch "jkimmel/firmware:dns-anycast"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add the dns anycast address to the list of servers. Ideally this should
find the closest (by babel metric) dns server available and provide
fallback should this server not be reachable anymore.
Signed-off-by: Johannes Kimmel fff@bareminimum.eu
Also ich hab 2 Standorte, die nutzen den ausschliesslich und habe keine Probleme bemerkt. Eventuell sollte man auch eine IPv4 Anycast Adresse definieren und dort das gleiche machen. Dann könnte man die Config auf die 2 Anycast Adressen reduzieren.
Ich finde es nicht gut, fest definierte Adressen in der Firmware zu haben.
Lieber die Adressen im Wiki sammeln und in der Anleitung darauf verweisen. Das ist mMn Userentscheidung welche er nutzen will.
Wir sollten eher überlegen die aktuellen v4 Adressen (wo zum Teufel kommen die her? Seh ich gerade zum ersten mal) da raus zu werfen.
Also genau aus dem Grund fände ich eben ein wechsel zu Anycast Adressen schon mal sinnvoll. User definierte DNS Server reihen sich dann denke ich eh weiter oben in der liste ein. Wenn man dann noch strict-order definiert hat man denke ich eine gute Mischung. User kann definieren, was er will, aber solide defaults.
Ich könnte mir aber z.b. vorstellen, wenn der Patch #24 in die Firmware kommt, das man den DNS per mqtt zugeteilt bekommt (auf explizieten Wunsch des Users wenn er einen Haken setzt, keinesfalls default). Somit ist die Adresse nicht fest in der Firmware sondern wird von außen übergeben und jeder der einen DNS Server betreibt (dieser Anycast DHCP ist ja kein offizieller Freifunk Franken DNS sondern haben einfach ein paar User sich zusammen getan und rein geklickt) kann den da rein pushen und der User kann entscheiden welchen er nutzen will (oder das komplett automatisch machen lassen wenn er will)
wenn ich das uci richtig verstehe, werden beim ersten durchlauf von configure-layer3 diese defaults sowieso gelöscht:
https://git.freifunk-franken.de/freifunk-franken/firmware/src/branch/master/src/packages/fff/fff-dhcp/files/etc/layer3.d/35-dns#L3
Sie machen also eigentlich gar keinen Sinn. Kann das wer bestätigen?
Ist das nicht gerade das was Freifunk ist?
Was sind denn dann die offiziellen DNS und in wie fern sind die anders entstanden?
Ich preferiere auch die Anycast Lösung, als ersten DNS im default (eventuell als fallback noch ein zwei weitere).
Userfreundlich wäre es einen default zu haben, der funktioniert ohne dass der User was einstellen muss.
Das, was Blackyfff sagt. Solange für den User die Möglichkeit besteht, den DNS zu ändern, ist ja alles super. Umso funktionsfähiger die Firmware ohne extra Einstellungen ist, umso besser.
Christian hat aber korrekt festgestellt, dass die Defaults überhaupt nicht funktionieren. Ich dachte eigentlich, wir hätten die rausgeworfen. Ist vielleicht beim Mergen verloren gegangen.
Ich würde für die Zukunft, wenn wir dann hoffentlich eine gerätespezifische Default-Config anlegen können, die Anycast DNS Adressen dort rein setzen.
Dann wärs doch vielleicht das schlauste wir haben gute defaults, die werden dann benutzt, wenn der nutzer nichts anderes in seiner config angibt, oder?
Die Adressen aus dem uci-defaults werden immer gelöscht, wenn configure-layer3 ausgeführt wird, auch wenn dort keine Ersatzadressen angegeben werden. Ohne configure-layer3 geht eh nichts, dann brauche ich die Adressen dort auch nicht. Ich bin auch tendenziell dagegen, hier plötzlich mit einem verborgenen Default-Setup daherzukommen, wo man sonst alles konfigurieren muss.
Insbesondere dagegen bin ich aber, wenn es hierbei um Adressen geht, die auf einer manuellen Auswahl beruhen. Ich würde hier eher den Weg gehen, eine solche Auswahl von Adressen in einer example-gateway-config festzuhalten, sodass der Erst-User eine Vorauswahl hat, und diese dann ändern kann.
nein, einen "offiziellen" DNS sollte es gar nicht geben. Es gibt Leute die betreiben "da was" und das kann man nutzen. Sonst kommt der nächste mit einen "offiziellen public v6 prefix", der nächste mit einen "offiziellen wireguard peering" daher usw.
Ich finde "offiziell" passt einfach nicht zu Freifunk. Man kann Dinge anbieten die Leute nutzen können und dürfen, viele Nutzen vermutlich das gleiche weil es Sinn macht aber das fest in einer Firmware hinterlegen finde ich falsch.
Also der Patch ist eh hinfaellig. Sollen wir den PR als diskussion hernehmen, oder lieber nochmal nen separates Issue aufmachen?
Ich finde eine seperatue Diskussion richtiger vllt. auch auf die Idee aufbauend meiner autol3 Idee die bereits im Wiki steht:
https://wiki.freifunk-franken.de/w/Mqtt/autol3
Weil am Ende läuft das etwa aufs gleiche hinaus nur anders umgesetzt.
Also was das alles mit dem Auto-L3 zu tun hat, weiss ich nicht. Bei so einer einfachen Änderung würde ich auch nur ungern auf dieses riessen Feature warten, sofern es denn kommt.
Ich verstehe auch die Gegenargumente nicht so 100%ig. Es wird niemand zu irgendwas gezwungen. Man kann sogar seinen eigenen DNS Server betreiben und diese IP verwenden, falls man das will. Ich finde es nach wie vor einen sinnvollen default, statt droelfzig Server in der Liste zu haben.
Ich lass das jetzt noch einmal kurz offen, bis ich das Issue angelegt habe, das passiert aber vermutlich nicht mehr heute.
Im Moment ist es ja kein default, sondern nur ein totes Setting das nie verwendet wird (außer jemand konfiguriert alles andere von Hand.)
Da habe ich dich dann falsch verstanden, so macht das natürlich Sinn.
Ist es dann ein Relikt oder erfüllt es noch einen beabsichtigten Zweck (Information und Absicht für Selbstkonfiguration z.B.)
0693495fbbto2ee53d71a1So.. bevor ich jetzt nochmal lesen muss, dass die Einträge ja eh nicht verwendet werden und bis ich erklärt habe, was ich eigentlich will hier die neuen Änderungen:
Ich hoffe damit sind auch die Bedenken etwas gedaempft. Es soll halt helfen schnell was funktionierendes hochziehen zu können.
2ee53d71a1tod9a7753f18Hi
ich geh die Commits mal eben einzeln durch:
fff-dhcp: remove unused dns server entries:
Bin ich prinzipiell voll dafür. Nur eine Frage wurde das mal getestet? Weiß nicht wie der dnsmasq beim first boot reagiert wenn er keine Einträge hat, nicht das wir uns da irgendwelche Probleme einhandeln (die ich zwar aktuell nicht sehe aber man weiß ja nie...) und die Einträge vllt. doch irgendeinen aktuell von uns nicht gesehen Grund haben.
fff-dhcp: add fallback dns server:
Bin ich wie bereits gesagt dagegen sowas in die Firmware zu bauen, für mich gehören keine (vielleicht) funktionierenden default Werte da rein. Der nächste will eine default IPv6 (wenn keine v6 konfiguriert), der nächste eine default IPv4 (wenn nicht konfiguriert) und der nächste ein default wireguardpeering (wenn keins konfiguriert). Wo fängt man an, wo hört man auf?
fff-dhcp: PKG_RELEASE bump:
Macht vllt. Sinn mit irgendwas zusammen zu fügen? Dafür ein einzelner Patch muss mMn nicht sein und haben wir so auch noch nie gemacht wenn ich mich recht erinnere.
Ich würde diesbezüglich gern eine andere Sichtweise anbringen.
Es handelt sich ja hierbei um Anycast Adressen, das sind zwar 'feste' Adressen, aber keine festen Server, sondern der via Babel-Vektor nächstgelegene DNS-Server (sofern sich dieser mit der Anycast announced).
Die Subnetze (10.50.0.0/16, 10.83.0.0/16 und fd43:5602:29bd::/48) sind auch 'fest' und gehören zu fff und sind auch in der Firmware enthalten (z.B. bei den Babel-Filtern). Eine Anycast-Adresse funktioniert auch nur im gegenseitigen Einverständnis oder zumindest Toleranz der anderen.
Man kann auch so argumentieren, dass Anycast-Adressen zur Definition des Netzwerks gehören. Also quasi ein Teil des definierten Subnetz sind.
Die Commits wurden aufgeteilt, damit man den Anycast Fallback gemütlich rausschneiden kann, sollten wir da keinen Konsens finden. Ansonsten hätte sicher nur einen Commit raus gemacht.
Dann gehört das mMn auch mal "repariert". Die einzigen festen Adressen die wirklich rein müssen sind fdff::/64 weil die dem Router gehören (und er daraus auch RAs macht) und als erster Zugriffspunkt wichtig sind. Alles andere ist Konfiguration und gehört mMn nicht "fest" in der Firmware hinterlegt.
ok, warten wir auf nen Consens und dann kann man es entsprechend machen.
Das sehe ich überhaupt gar nicht. Die Firmware heißt nicht umsonst "Freifunk Franken Firmware". Die ist dazu da, dass wir sie möglichst optimal auf unser Netz zuschneiden können und die Teilnahme daran möglichst einfach gestalten können.
Sonst können wir es auch bleiben lassen und n OpenWrt + Konfigurationsanleitung anbieten (Was ich an sich auch gar keine schlechte Idee fände, aber parallel zur Firmware).
In unsere Firmware gehören imho - wo das möglich ist - sinnvolle Defaults. Wenn es eine definierte Anycast-Adresse gibt, dann sollte diese auch in unsere Firmware. Genauso wie schon ein babeld-Paket vorinstalliert ist, weil das eben ein sinnvoller Default ist. Die (einfache!) Möglichkeit sich andere DNS-Server hinzukonfigurieren bleibt dem Nutzer ja dennoch.
In Zukunft möchte ich die Gateway-Config noch so erweitern, dass diese beim ersten Boot mit sinnvollen Voreinstellungen ausgeliefert wird, sofern sie noch nicht existiert. Dazu zählt vor allem die Portkonfiguration, ich könnte mir aber auch vorstellen, dass die Firmware dann direkt den Anycast-DNS in die Gatewaykonfiguration schreibt, in der der Nutzer sie direkt anpassen kann.
Ist technisch nicht umsetzbar, weil Freifunk keine öffentlichen v6 Adressen hat.
Für fd43 könnte man tatsächlich überlegen, ob man diese aus der MAC o.ä. ableitet.
Ist technisch nicht umsetzbar, da Adressraum zu klein
Wie weit weg ist deine L3-autoconfig Idee davon? Ich habs mir noch nicht genau angesehen, aber ist das nicht sowas ähnliches?
Auch hier kann man (ohne Kommunikation) keine sinnvollen Defaults setzen, weil diese mit $Entität ausgehandelt werden müssen und für jeden Nutzer individuell sind.
#2 hier schon vorbereitet und da es Routerspezifisch ist, bin ich da auch voll bei dir.
Wenn dann würde ich überlegen ob sich nicht jeder Router gleich selbst ein ULA Netz generiert (per RFC 4193 geht fast nicht wegen Uhrzeit, aber OpenWRT pfuscht da auch ganz böse ;) vllt. übernimmt man diesen "Pfusch" einfach). Das fd43 ist ja auch "nur" ein ULA Netz, hält ja keinen davon ab sich selbst ein ULA Netz zu generieren und ich glaube es ist groß genug, das Kollisionen nahezu ausgeschlossen sind, vorallem wenn man dann nur ein (random) /64 aus dem generierten /48 nutzt wäre selbst bei einer /48 Kollision nochmal viel Spielraum.
Meilenweit, am anderen Ende der Welt oder so. Ich weiß aktuell nicht mal genau wie ich das sinnvoll umsetzen soll, erste Versuche sind krachend gescheitert weil 1000 Randfälle (das lief dann auf sowas wie damals v2 hinaus und das wollte ich eigentlich vermeiden). Dazu fehlen sowieso noch die kompletten Vorbereitungspatches die aktuell alle offene PRs sind, die aber auch alleine ohne autol3 sinnvoll sind und selbst wenn man kein autol3 haben will, mMn mit in die FW sollten.
Prinzipiell könnte ich mir aber vorstellen das deine default config sich der Router selbst holt (aber eben nicht fest auf den Router hinterlegt ist), was dann wieder in Richtung autol3 läuft.
https://wiki.freifunk-franken.de/w/Mqtt/autol3
Speziell auch Punkt 5 läuft dann wieder auf das eigene ULA Netz hinaus, was mMn die sauberste Lösung wäre.
Und genau diesen DNS könnte man dann auch über mqtt beziehen und bräuchte keinen default in der Firmware hinterlegen.
verstehe ich gerade nicht auf was sich das bezieht bzw. wie das gemeint ist.
Nochmal zurück zum eigentlichen Problem:
Wenn man den MQTT Patch veröffentlichen würde, was spricht dafür dann ein Patch zu machen das ca. folgendes macht:
Ist kein DNS angegeben aber es existiert ein MQTT Server (dieser muss User manuell eingeben, weil auch da wollte ich keine default IP in der Firmware haben, ich hatte also schon den gleichen Fall auch bei mir) wird eine Frage an /dns/ask gestellt, hier können nun verschiedene User antworten an /dns/nimmdenscheiss (sry mir ist auf die schnelle grad nichts besseres eingefallen ;)) mit einer IP und dann kann... keine Ahnung es wird der erste genommen oder der User frei entscheiden oder... muss man sich Gedanken machen ;) Ich stell mir im Endausbau einen Knopf im WebUI vor:
"DNS laden"
dann wird /DNS/ask an den mqtt geschickt, dann kommen auf /dns/nimmdenscheiss die ganzen DNS Server rein (hier kann jeder DNS Server rein pushen => dezentral) und User kann sich dann einen (oder mehrere) auswählen die dann in der config landen.
Dann ist nichts fest in der Firmware hinterlegt und der User kann dennoch eine Art default Konfiguration laden wenn er sich nicht selbst durchs Wiki klicken will (je nachdem wie man das genau baut, die oberen Ideen waren jetzt mal in 2 Minuten überlegt, vllt. geht das auch noch elleganter).
Mir kam gerade noch eine andere Idee:
Ich seh wenig Sinn darin eine so einfache Änderung zu blockieren, weil wir irgendwann mal was viel besseres haben könnten. Sich jetzt für diese Änderungen entscheiden heisst ja nicht, diese für immer behalten zu müssen.
Ich bin jedenfalls der festen Überzeugung, dass die Änderungen unsere Firmware für den Moment definitiv besser als vorher machen. Ich hoffe, dass das auch jeder so sieht, auch wenn langfristig andere Ziele angestrebt sind.
d9a7753f18toea5694f243Reviewed-by: Fabian Bläse <fabian@blaese.de>ea60dede2dtoa4fea5022eApplied.
Pull request closed