Benutzer:Lars/IPv6 dynamic DNS

Aus Opennet
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Ü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
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge