Quelltext der Seite Benutzer:Lars/IPv6 dynamic DNS

= Ü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.

= 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 <tt>.ipv6.on</tt> als symbolischer Namen für die übergeordnete Domain verwendet
** die finale Domain (vielleicht sogar <tt>.aps.on</tt>") 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

== Server-Konfiguration (bind9) ==
Einbindung der Zonen in /etc/bind/named.conf:
<pre>
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; };
};
</pre>

Definition der Zone für die Vorwärtsauflösung (<tt>/etc/bind/zone/ipv6.on.zone</tt>):
<pre>
$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.
</pre>

Definition der Zone für die Rückwärtsauflösung (<tt>/etc/bind/zone/0.0.0.0.a.d.7.8.3.d.8.d.2.3.d.f.ip6.arpa.zone</tt>):
<pre>
$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.
</pre>

== Announcierung von Name und MAC-Adresse (nsupdate) ==
<pre>
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
</pre>

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.

== Namensauflösung ==
Für die Auflösung stehen verschiedene Werkzeuge zur Verfügung.

=== nslookup ===
* in unserer Standard-Firmware enthalten
* <tt>nslookup fd32:d8d3:87da::16:3eff:fe6a:f0d3 gai.on | grep -F "ip6.arpa" | awk '{print $4}'</tt>
* <tt>nslookup 2-254.ipv6.on gai.on | tail -1 | grep ^Address | cut -f 2- -d : | awk '{print $1}'</tt>

=== dig ===
* Paket "bind-dig"
* Größe: 935kB
* <tt>dig +short -x fd32:d8d3:87da::16:3eff:fe6a:f0d3 @gai.on</tt>
* <tt>dig +short AAAA 2-254.ipv6.on @gai.on</tt>

=== knot-dig ===
* Paket "knot-dig"
* Größe: 600kB (davon 400kB für gnutls (knot-libdnssec))
* <tt>kdig +short -x fd32:d8d3:87da::16:3eff:fe6a:f0d3 @gai.on</tt>
* <tt>kdig +short AAAA 2-254.ipv6.on @gai.on</tt>

=== drill ===
* Paket "drill"
* Größe: 140kB
* keine direkte IPv6-Auflösung in OpenWrt verfügbar
** die Abfrage des passenden PTR-Eintrags der <tt>ip6.arpa</tt>-Domain ist aber möglich
* <tt>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}'</tt>
* <tt>drill AAAA 2-254.ipv6.on @gai.on | grep -h -A1 "^;; ANSWER SECTION:$" | tail -1 | awk '{print $5}'</tt>

=== unbound-host ===
* Paket "unbound"
* Größe: 800kB
* 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