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

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.

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.

Namensauflösung

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

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}'

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

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

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}'

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