Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repariere Routing für DNS vom ffvX-Netzwerk #107

Merged
merged 1 commit into from Feb 20, 2020

Conversation

citronalco
Copy link
Contributor

Beschreibung folgt

@citronalco citronalco changed the title DNS-Beschleunigung Repariere Routing für DNS vom ffvX-Netzwerk Jan 29, 2020
@oakey-dev
Copy link

Routing für DNS sollte nicht explizit gesetzt werden sondern das routing anhand der source addresse entschieden werden.

Mit der Änderung werden jetzt alle Verbindungen die vom {{ ffv4_network }} oder {{ ffv6_network }} kommen bzw. die source Addresse daraus haben über den Freifunk Uplink gerouted.

@MPW1412
Copy link
Contributor

MPW1412 commented Feb 19, 2020

@citronalco, kannst du bitte nochmal erläutern, was du genau mit dieser Änderung bezweckst? Mir ist das Ziel noch nicht klar.

@citronalco
Copy link
Contributor Author

Ich habe den PR für oakey-dev gestellt und kann die Frage leider auch nicht wirklich beantworten. So weit ich es verstanden habe werden DNS-Abfragen damit schneller beantwortet.

@oakey-dev Kannst du das beantworten? Ich habe zu wenig Ahnung von dem Thema.

@oakey-dev
Copy link

Hi,
es geht darum, wenn ein service der auf dem Gateway läuft und eine IP aus dem {{ ffv4_network }} oder {{ ffv6_network }} verwendet, dass er die requests dann richtig über die GRE tunnel routet

Sollte man keine andere NAT Regel haben würde er sonst versuchen die requests auf seine default route zu natten oder dann halt auch nicht und der anbieter verwirft dann alle ausgehenden Verbindungen.
Damit braucht man auch nicht mehr den (ich würde ihn als "dirty hack" betiteln) mit dem DNS

@MPW1412
Copy link
Contributor

MPW1412 commented Feb 20, 2020

Also gehen wir das doch mal durch:

bird6.conf.j2: Scheinbar haben wir die Suchdomäne einfach für V6 vergessen. Sicherlich eine gute Sache das aufzunehmen.

batman.j2: Die Regeln sind nicht falsch, ich frage mich nur, wozu man sie braucht. Die vorherigen sollten dasselbe schon abdecken. Meiner Meinung nach sind sie redundant.

named.conf.ffnet.j2:
Ich weiß nicht genau was query-source address macht.

rules.v4.j2: Die Optionalisierung erscheit mir sinnvoll. Unklar ist mir, warum die Zeilen 32-48 entfernt wurden. Soweit ich das sehe, werden die gebraucht, wenn man nicht lokal ausleiten möchte. Ich glaube den Hunk wollen wir nicht im Upstream, oder übersehe ich etwas? Man könnte es aber auch optional an die Variable ipv4_direkt_ausleiten koppeln.

rules.v6.j2: Selbe Argumentation, kann optionalisiert werden, einfach entfernen würde DNS immer lokal ausleiten, auch wenn das auf dem Gateway nicht gewünscht ist.

Nochmal zum Hintergrund: Wir haben teilweise Gateways auf von Privatpersonen gemieteten Hetzner-Kisten. Da sollen DNS-Anfragen alla wie-tue-ich-boese-Dinge.to nicht lokal abgekippt werden, sondern über den Resolver über das Backbone verschickt werden.

Entschuldigung, jetzt erst den letzten Beitrag von oakey-dev gelesen.

Habt ihr das getestet?

@oakey-dev
Copy link

ist bei uns (Freifunk Ingolstadt) in betrieb

@MPW1412
Copy link
Contributor

MPW1412 commented Feb 20, 2020

@HellMar, wolletma des märgen? Wäre dafür.

@HellMar HellMar merged commit 5d9c21d into FreiFunkMuenster:master Feb 20, 2020
@citronalco citronalco deleted the DNS branch February 26, 2020 20:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants