[Berlin-wireless] Überlegungen zu DNS in unserem Mesh
Bastian
fly
Sa Mär 14 16:05:37 CET 2015
Hallo Berlin,
wir haben einen gemeinsamen Anspruch an unser Mesh, und der lautet
Dezentralität. Aber wie ist das mit DNS? Zwar sieht der RFC eine
hierarchische Struktur vor, aber letztendlich gibt es zentrale Wurzeln.
Welchen Anspruch haben wir momentan an DNS in unserem Mesh? Also was
muss wie funktionieren, und was hätten wir evtl. gerne zusätzlich?
Ich versuche mal ein paar Punkte zu sammeln:
* Resolving von Internet-Namen. Und zwar ohne Zensur
* Am Besten schnelle und geographisch sinnvolle Antworten
* Dezentrales Node-Name / Mesh-IP Mapping innerhalb des OLSR-Mesh
* OLSR Nameservice-Plugin FTW
* Selbstbestimmungsmöglichkeit für die lokal verwendeten Resolver
* Knotenbetreiber können selbst bestimmen, welche public-Resolver
verwendet werden
* Auflösen der Node-Names anderer Communities
* Dienste im ICVPN einfach nutzbar machen
* Unsere Node-Names auch anderen Communities verfügbar machen
* .olsr TLD sucks
* IPv6 endlich sinnvoll nutzen!
* Namen von Nodes, Servern und evtl sogar DHCP-Clients aus dem Internet
auflösen
* Selbiges für verwendete IPv6-Adressen -> reverse-DNS
Für die letzten Punkte kommen wir wahrscheinlich um eine zentralistische
Nameserver-Struktur nicht herum. Wie ist eigentlich der Stand von
P2P-basierten Zonen und Resolvern? Macht KadNode im kontext ICVPN Sinn?
tl;dr
Es gibt diese tolle Domain "freifunk.berlin". Die nutzen wir quasi fast
gar nicht. Was haltet ihr davon, wenn wir diese Domain als neue
Mesh-Domain anstatt .olsr verwenden?
Anstatt externe authorative Nameserver für diese Domain zu verwenden,
könnten wir sie selbst hosten. Platz für kleine bind9-VMs haben wir.
Wir hatten vor einiger Zeit - als wir auf der Suche nach
default-Resolvern für unsere Firmware waren - mal überlegt eigene
zensurfreie public Resolver zu betreiben. Die Idee ist schön, aber
mangels administrativem Aufwand wegen DNS-Amplification DoS machen wir
das eher ungern.
Brauchen wir überhaupt gänzlich öffentlich erreichbare Resolver? Aus
Sicht der Firmware reicht es aus wenn über das Internet die Namen
unserer VPN-Server auflösbar sind. Sobald VPN steht, kann ein von uns
betriebener Resolver innerhalb des VPN/Mesh verwendet werden.
Überlegung:
Unser Nameserver mit einem Bein im Internet und einem Bein im Mesh löst
auf Anfragen aus dem Internet nur für Subdomains wie
vpn03.freifunk.berlin auf. Gleichzeitig wird aber eine Anfrage aus dem
Mesh nach der IP von google.de beantwortet. Also public auth. Nameserver
vs. private Resolver.
Dank dem Bein im Mesh können die vom Nameservice-Plugin gesammelten
Namen/Adressen in die freifunk.berlin Zone geschoben werden. Aus dem
Internet würde sich der AAAA-Record von sama-core.freifunk.berlin
auflösen lassen. Aus dem ICVPN würde zusätzlich noch der A-Record dazu
kommen.
Eine Anfrage aus dem Internet nach "Welchen Namen hat die IP
2001:bf7:830:ff00::1" würde zwingli-core.freifunk.berlin als Antwort
liefern.
Das ICVPN ist inzwischen soweit strukturiert und automatisiert, dass
sich die Nameserver und TLDs der anderen Communities praktisch
konfigurieren lassen. Dann könnten unsere Clients auch endlich mal den
Hamburger jabber-Server jabber.ffhh auflösen:
root at Zwingli-Core:~# host jabber.ffhh 10.112.1.1
jabber.ffhh has address 10.112.0.6
jabber.ffhh has IPv6 address 2a03:2267::227:eff:fe06:23fc
Wenn du es bis hier her geschafft hast interessiert mitzulesen, würde
ich mich freuen in Form von einer kritischen Mail auf der Liste von dir
zu hören!
Grüße
Bastian
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : signature.asc
Dateityp : application/pgp-signature
Dateigröße : 473 bytes
Beschreibung: OpenPGP digital signature
URL : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20150314/06db8261/attachment.pgp>
Mehr Informationen über die Mailingliste Berlin