Benutzer:Lars/IPv6 dynamic DNS: Unterschied zwischen den Versionen
Lars (Diskussion | Beiträge) (Gedanken zur Namensauflösung) |
Lars (Diskussion | Beiträge) (Konzept "Registrar"-Dienst hinzugefügt) |
||
(Eine dazwischenliegende Version von einem Benutzer wird nicht angezeigt) | |||
Zeile 7: | Zeile 7: | ||
* wir möchten einen AP mit einem lesbaren Namen ansprechen (DNS-Auflösung) | * wir möchten einen AP mit einem lesbaren Namen ansprechen (DNS-Auflösung) | ||
* wir möchten lesbare AP-Namen aus IPv6-Adressen ableiten (Reverse-DNS-Auflösung) | * wir möchten lesbare AP-Namen aus IPv6-Adressen ableiten (Reverse-DNS-Auflösung) | ||
+ | |||
+ | Damit verwandt ist auch das Thema der Vergabe eindeutiger AP-Nummern (oder Namen) - falls wir das wünschen. | ||
= Variante I: Announcierung via nsupdate = | = Variante I: Announcierung via nsupdate = | ||
Zeile 13: | Zeile 15: | ||
* als Authentifikation wird lediglich der IP-Quellbereich (basierend auf unserem IPv6-Präfix) verwendet | * als Authentifikation wird lediglich der IP-Quellbereich (basierend auf unserem IPv6-Präfix) verwendet | ||
* DNS-Auflösung erfolgt verzögerungsfrei und direkt (ohne weitere Verarbeitungsschritte) | * DNS-Auflösung erfolgt verzögerungsfrei und direkt (ohne weitere Verarbeitungsschritte) | ||
− | * im untenstehenden Beispiel wird <tt>ipv6.on</tt> als symbolischer Namen für die übergeordnete Domain verwendet | + | * im untenstehenden Beispiel wird <tt>.ipv6.on</tt> als symbolischer Namen für die übergeordnete Domain verwendet |
− | ** die finale Domain (vielleicht sogar | + | ** die finale Domain (vielleicht sogar <tt>.aps.on</tt>") ist separat zu entscheiden |
− | Was fehlt: | + | Was fehlt / Probleme: |
* die Vergabe von eindeutigen lesbaren Namen ist getrennt von der DNS-Auflösung | * die Vergabe von eindeutigen lesbaren Namen ist getrennt von der DNS-Auflösung | ||
+ | ** beispielsweise veralten Einträge nicht und werden irgendwann entfernt | ||
+ | * die kleinste "nsupdate"-Implementierung in OpenWrt ("knot-nsupdate") benötigt ca. 600kB Speicherplatz | ||
== Server-Konfiguration (bind9) == | == Server-Konfiguration (bind9) == | ||
Zeile 83: | Zeile 87: | ||
* nsupdate: Paket "bind-client"; 915kB | * nsupdate: Paket "bind-client"; 915kB | ||
− | Leider | + | Leider kennen wir also bisher keine speichersparsame nsupdate-Implementierung. |
== Namensauflösung == | == Namensauflösung == | ||
Zeile 117: | Zeile 121: | ||
* Größe: 800kB | * Größe: 800kB | ||
* wohl keine Abfrage eines spezifischen Nameservers möglich | * wohl keine Abfrage eines spezifischen Nameservers möglich | ||
+ | |||
+ | = Variante II: Registrar-Dienst = | ||
+ | Konzept: | ||
+ | * ein Dienst wird regelmäßig von APs kontaktiert | ||
+ | * der Dienst verknüpft APs (basierend auf deren MAC) mit eindeutigen Nummern und DNS-Namen (inkl. Rückwärtsauflösung) | ||
+ | * der Dienst sorgt für die Pflege der dynamischen DNS-Zonen (vorwärts, rückwärts) für die APs | ||
+ | * auf den APs benötigen wir dafür lediglich "curl" (bereits vorhanden) | ||
+ | |||
+ | Fehler / Mängel: | ||
+ | * wir müssten selbst Software schreiben (oder nach ähnlichen Implementierungen Ausschau halten) | ||
+ | ** Lars schätzt, dass es überschaubare 300 Zeilen in Python werden | ||
+ | * Zusammenhang zwischen Nummern/Namen und Zertifikaten ist unklar | ||
+ | ** durch das Veralten von Leases könnten (im bisherigen Modell) Zertifikate unbrauchbar werden | ||
+ | |||
+ | == Implementierung == | ||
+ | * http-basierter Dienst verarbeitet einen Request mit folgenden Attributen: | ||
+ | ** primäre MAC | ||
+ | ** eventuell zusätzlicher Wunsch-Name (falls vom AP-Besitzer definiert) | ||
+ | * Response: | ||
+ | ** aktuelle AP-Nummer (z.B. "748") | ||
+ | ** AP-Hostname (z.B. "748.aps.on" - oder irgendetwas anderes) | ||
+ | ** Wunsch-Hostname (falls angefragt) - z.B. "erwin12.my.aps.on" | ||
+ | * jeder AP versendet periodisch den obigen Request (z.B. an eine vordefinierte IP oder einen per Namen definierten Host) | ||
+ | * der Dienst verwaltet eine Liste bisheriger "Leases" | ||
+ | ** ungenutzte Leases (keine Requests in definiertem Zeitraum) werden vergessen (Nummern werden wieder frei) | ||
+ | ** Ersatz eines APs durch ein anderes Gerät führt zu neuer AP-Nummer | ||
+ | *** falls wir nicht noch ein Geräte-spezifisches Token (quasi ein privater Schlüssel) hinzufügen wollen, der dem "Lease" zugeordnet ist | ||
+ | * neue/geänderte Leases werden via nsupdate (mit key-Authentifikation) an den zuständigen Nameserver weitergegeben, der diese dynamische Zone verwaltet |
Aktuelle Version vom 11. Februar 2018, 16:37 Uhr
Inhaltsverzeichnis |
[Bearbeiten] Überblick
Aktuell (Anfang 2018) werden die IPv6-Adressen unserer Router in unserem OLSRv2-Mesh (parallel zum bestehenden OLSRv1-Mesh - basierend auf IPv4) aus einem vorgegebenen (per Firmware) Netz-Präfix und einem per EUI-64 aus der MAC-Adresse ermittelten lokalen Adressteil gebildet.
Die Router tragen aufgrund unseres bisherigen manuellen ID-Vergabesystems für Menschen verwendbare Namen, wie beispielsweise "AP2-254". Diese sind vorwärts und rückwärts leicht auf IPv4-Adressen zu übertragen.
Für die IPv6-Adressen wünschen wir folgende Eigenschaften:
- wir möchten einen AP mit einem lesbaren Namen ansprechen (DNS-Auflösung)
- wir möchten lesbare AP-Namen aus IPv6-Adressen ableiten (Reverse-DNS-Auflösung)
Damit verwandt ist auch das Thema der Vergabe eindeutiger AP-Nummern (oder Namen) - falls wir das wünschen.
[Bearbeiten] Variante I: Announcierung via nsupdate
Überblick:
- Clients melden die Vorwärts- (AAAA-Eintrag) und Rückwärtsauflösung (PTR-Eintrag) via "nsupdate" beim DNS-Server an
- als Authentifikation wird lediglich der IP-Quellbereich (basierend auf unserem IPv6-Präfix) verwendet
- DNS-Auflösung erfolgt verzögerungsfrei und direkt (ohne weitere Verarbeitungsschritte)
- im untenstehenden Beispiel wird .ipv6.on als symbolischer Namen für die übergeordnete Domain verwendet
- die finale Domain (vielleicht sogar .aps.on") ist separat zu entscheiden
Was fehlt / Probleme:
- die Vergabe von eindeutigen lesbaren Namen ist getrennt von der DNS-Auflösung
- beispielsweise veralten Einträge nicht und werden irgendwann entfernt
- die kleinste "nsupdate"-Implementierung in OpenWrt ("knot-nsupdate") benötigt ca. 600kB Speicherplatz
[Bearbeiten] Server-Konfiguration (bind9)
Einbindung der Zonen in /etc/bind/named.conf:
zone "ipv6.on." IN { type master; file "/etc/bind/zone/ipv6.on.zone"; allow-update { 192.168.0.0/16; 10.2.0.0/16; }; }; zone "0.0.0.0.a.d.7.8.3.d.8.d.2.3.d.f.ip6.arpa" IN { type master; file "/etc/bind/zone/0.0.0.0.a.d.7.8.3.d.8.d.2.3.d.f.ip6.arpa.zone"; allow-update { 192.168.0.0/16; 10.2.0.0/16; }; };
Definition der Zone für die Vorwärtsauflösung (/etc/bind/zone/ipv6.on.zone):
$ORIGIN . $TTL 3600 ; 1 hour ipv6.on IN SOA gai.on. admin.opennet-initiative.de. ( 2017011503 ; serial 21600 ; refresh (6 hours) 3600 ; retry (1 hour) 1209600 ; expire (2 weeks) 300 ; minimum (5 minutes) ) NS gai.on.
Definition der Zone für die Rückwärtsauflösung (/etc/bind/zone/0.0.0.0.a.d.7.8.3.d.8.d.2.3.d.f.ip6.arpa.zone):
$ORIGIN . $TTL 3600 ; 1 hour 0.0.0.0.a.d.7.8.3.d.8.d.2.3.d.f.ip6.arpa IN SOA gai.on. admin.opennet-initiative.de. ( 2017011505 ; serial 21600 ; refresh (6 hours) 3600 ; retry (1 hour) 1209600 ; expire (2 weeks) 300 ; minimum (5 minutes) ) NS gai.on.
[Bearbeiten] Announcierung von Name und MAC-Adresse (nsupdate)
nsupdate <<EOF server gai.on zone ipv6.on update del 3-254.ipv6.on AAAA update add 3-254.ipv6.on 3600 AAAA fd32:d8d3:87da::16:3eff:fe6a:f0d3 send zone 0.0.0.0.a.d.7.8.3.d.8.d.2.3.d.f.ip6.arpa update del 4.d.0.f.a.6.e.a.f.f.e.3.6.1.0.0.0.0.0.0.a.d.7.8.3.d.8.d.2.3.d.f.ip6.arpa PTR update add 4.d.0.f.a.6.e.a.f.f.e.3.6.1.0.0.0.0.0.0.a.d.7.8.3.d.8.d.2.3.d.f.ip6.arpa 3600 PTR 2-254.ipv6.on send EOF
Folgende Clients sind unter OpenWrt verfügbar:
- knsupdate: Paket "knot-nsupdate"; 600kB (davon 400kB für gnutls)
- nsupdate: Paket "bind-client"; 915kB
Leider kennen wir also bisher keine speichersparsame nsupdate-Implementierung.
[Bearbeiten] Namensauflösung
Für die Auflösung stehen verschiedene Werkzeuge zur Verfügung.
[Bearbeiten] nslookup
- in unserer Standard-Firmware enthalten
- nslookup fd32:d8d3:87da::16:3eff:fe6a:f0d3 gai.on | grep -F "ip6.arpa" | awk '{print $4}'
- nslookup 2-254.ipv6.on gai.on | tail -1 | grep ^Address | cut -f 2- -d : | awk '{print $1}'
[Bearbeiten] dig
- Paket "bind-dig"
- Größe: 935kB
- dig +short -x fd32:d8d3:87da::16:3eff:fe6a:f0d3 @gai.on
- dig +short AAAA 2-254.ipv6.on @gai.on
[Bearbeiten] knot-dig
- Paket "knot-dig"
- Größe: 600kB (davon 400kB für gnutls (knot-libdnssec))
- kdig +short -x fd32:d8d3:87da::16:3eff:fe6a:f0d3 @gai.on
- kdig +short AAAA 2-254.ipv6.on @gai.on
[Bearbeiten] drill
- Paket "drill"
- Größe: 140kB
- keine direkte IPv6-Auflösung in OpenWrt verfügbar
- die Abfrage des passenden PTR-Eintrags der ip6.arpa-Domain ist aber möglich
- drill PTR 3.d.0.f.a.6.e.f.f.f.e.3.6.1.0.0.0.0.0.0.a.d.7.8.3.d.8.d.2.3.d.f.ip6.arpa @gai.on | grep -h -A1 "^;; ANSWER SECTION:$" | tail -1 | awk '{print $5}'
- drill AAAA 2-254.ipv6.on @gai.on | grep -h -A1 "^;; ANSWER SECTION:$" | tail -1 | awk '{print $5}'
[Bearbeiten] unbound-host
- Paket "unbound"
- Größe: 800kB
- wohl keine Abfrage eines spezifischen Nameservers möglich
[Bearbeiten] Variante II: Registrar-Dienst
Konzept:
- ein Dienst wird regelmäßig von APs kontaktiert
- der Dienst verknüpft APs (basierend auf deren MAC) mit eindeutigen Nummern und DNS-Namen (inkl. Rückwärtsauflösung)
- der Dienst sorgt für die Pflege der dynamischen DNS-Zonen (vorwärts, rückwärts) für die APs
- auf den APs benötigen wir dafür lediglich "curl" (bereits vorhanden)
Fehler / Mängel:
- wir müssten selbst Software schreiben (oder nach ähnlichen Implementierungen Ausschau halten)
- Lars schätzt, dass es überschaubare 300 Zeilen in Python werden
- Zusammenhang zwischen Nummern/Namen und Zertifikaten ist unklar
- durch das Veralten von Leases könnten (im bisherigen Modell) Zertifikate unbrauchbar werden
[Bearbeiten] Implementierung
- http-basierter Dienst verarbeitet einen Request mit folgenden Attributen:
- primäre MAC
- eventuell zusätzlicher Wunsch-Name (falls vom AP-Besitzer definiert)
- Response:
- aktuelle AP-Nummer (z.B. "748")
- AP-Hostname (z.B. "748.aps.on" - oder irgendetwas anderes)
- Wunsch-Hostname (falls angefragt) - z.B. "erwin12.my.aps.on"
- jeder AP versendet periodisch den obigen Request (z.B. an eine vordefinierte IP oder einen per Namen definierten Host)
- der Dienst verwaltet eine Liste bisheriger "Leases"
- ungenutzte Leases (keine Requests in definiertem Zeitraum) werden vergessen (Nummern werden wieder frei)
- Ersatz eines APs durch ein anderes Gerät führt zu neuer AP-Nummer
- falls wir nicht noch ein Geräte-spezifisches Token (quasi ein privater Schlüssel) hinzufügen wollen, der dem "Lease" zugeordnet ist
- neue/geänderte Leases werden via nsupdate (mit key-Authentifikation) an den zuständigen Nameserver weitergegeben, der diese dynamische Zone verwaltet