Bericht zum Ausfall von Moodle am 28.10.

Sun Nov 6 15:22:24 CET 2022

Hallo zusammen

Wir wurden gebeten, einen Bericht zum Ausfall von Moodle am
28.10. zu schreiben.

Eigentlich ist die technische Ursache in zwei Worten erklaert
("ISC Transitional"), da das aber so kaum jemand nachvollziehen
kann, brauchts einiges an Erklaerung.. und weil wirs eh machen
muessen, schicken wirs auf diese Liste, dann koennen die dies
interessiert auch mitlesen.

Management Summary
==================

  * aufgrund eines historisch falsch konfigurierten DDNS Update
    Verfikationsverhalten in der Infoblox war es moeglich,
    DNS Records zu ueberschreiben.

  * ein Student hat damit den Record zu moodle.bfh.ch geaendert
    (mit Eintrag auf die IP seines Notebook), so dass Moodle am
    28.10. von 14:24 bis 14:57 nicht erreichbar war.

  * nach der Korrektur des Records und Analyse des Vorfalls, haben
    wir das falsche Update-Verifikationsverhalten in der Infoblox
    entdeckt und am 28.10. um 17 Uhr korrigiert.

  * die neuen DHCP Server von Mitte Oktober, welche seit 5.11. die
    Infoblox abgeloest haben, waren davon nie betroffen/involviert.

Hintergrund
===========

1. technisches Vorwissen
========================

1.1 Was ist DDNS?
-----------------

Geraete welche eine IP Adresse im Netzwerk haben, haben vorzugsweise
auch einen passenden DNS Record, so dass man die Geraete ueber einen
Namen statt einer Nummer ansprechen kann, z.B.
https://www.bfh.ch statt https://94.230.211.117

Fuer Clients die traditionell keine statische Adresse haben waere
das erstmal nicht moeglich, da bei diesen die IP Adresse via DHCP
zugewiesen wird und bei jedem Verbinden mit dem Netzwerk aendern
koennte.

Damit dies trotzdem funktioniert, kann der DHCP Server den Namen des
Clients im DNS eintragen. Das nennt sich "dynamic DNS" oder DDNS
(RFC2136; nicht zu verwechseln mit DynDNS).

1.2 Wie funktioniert DDNS?
--------------------------

DDNS funktioniert in der Implementierung des gaengigen ISC DHCP
Servers (bei uns bis vor kurzem in der Form von Infoblox Appliances
eingesetzt) vereinfacht so:

  * Client macht eine DHCP Anfrage und schickt u.a. seinen Hostname
    sowie eine ein-eindeutige ID (DHCPID) die nur der Client kennt,
    an den DHCP Server.

  * DHCP Server traegt den Hostnamen ein und generiert aus der
    DHCPID einen Hash, den er als zum Record passenden TXT Record im
    DNS "speichert".

Will ein Client einen Eintrag aktualisieren, entweder weil er in der
Zwischenzeit eine neue IP zugewiesen bekommen hat, oder weil der
Record schon belegt ist und der Client ihn auf seine IP aendern
will, funktionierts vereinfacht so:

  * DHCP Server hasht die DHCPID des "neuen" Clients und vergleicht
    ihn mit dem TXT Record:

    - stimmen die TXT Records ueberein ist der "neue" und der "alte"
      Client der gleiche - d.h. die Aenderung ist "berechtigt", der
      DHCP Server aktualisiert den Eintrag im DNS.

    - stimmen die TXT Records nicht ueberein, ist der "neue" und der
      "alte" Client nicht der gleiche und die Aenderung ist "nicht
      berechtigt", der DHCP Server aktualisiert den Eintrag im DNS
      nicht.

Solche Record Updates passieren staendig, bei uns sowieso da je nach
Standort die IP Adressen aus anderen Subnetzen kommen und so die IP
Adresse zwingend aendert.

1.3 Warum eine DHCPID?
----------------------

Um sich gegenueber dem DHCP Server erkennbar zu machen, sendet der
Client wie erwaehnt eine DHCPID. Dass dies eine eigene ID ist und
nicht der MAC Adresse (direkt) enspricht, hat folgende Vorteile,
z.B.:

  * hat ein Client mehrere Interfaces von denen immer nur eines
    gleichzeitig benutzt wird, kann der Client so konfiguriert
    werden, auf allen Interfaces die gleiche DHCPID zu verwenden.

    Dadurch ist der Client aus Sicht des DHCP Servers immer der
    gleiche, auch wenn alle anderen Dinge aendern.

    Das ermoeglich das Ueberschreiben von alten Eintraegen,
    praktisches Beispiel:

    - Andreas Notebook hat ein LAN und WLAN Interface und ist so
      konfiguriert, das nicht pro Interface eine eigene DHCPID
      geschickt wird.

    - Andrea verbindet sich mit LAN, es wird andrea.bfh.ch im DNS
      eingetragen.

    - Andrea stoppt die LAN Verbindung und wechselt auf WLAN.

    - der DHCP Server erkennt an der gleichgebliebenen DHCPID dass
      Andrea neu per WLAN verbunden ist und erlaubt daher das Update
      fuer den Record andrea.bfh.ch, so dass dieser neu auf die IP
      Adresse des WLAN Interfaces zeigt.

Standardmaessig wird bei den gaengigen Betriebssystemen pro
Interface eine eigene DHCPID geschickt (was der richtige Default
ist). Ein entkoppeln der DHCPID von Interface/MAC schafft die
Moeglichkeit zur Konfiguration, je nach Umgebgung das gewuenschte
Verhalten im Netz umzusetzen.

1.4 Clients mit mehreren Netzwerk-Interfaces
--------------------------------------------

Interessanter wird es wenn mehrere Interfaces gleichzeitig benutzt
werden, dazu folgendes Beispiel:

  * Bruno hat ein Notebook mit LAN und WLAN.

  * Bruno verbindet sich per WLAN, es wird bruno.bfh.ch im DNS
    eingetragen.

  * Bruno verbindet sich zusaetzlich per LAN und meldet sich mit
    einer unterschiedlichen DHCPID beim DHCP Server, bruno.bfh.ch
    bleibt unveraendert und zeigt auf die Adresse des WLAN
    Interfaces.

Falls wir moechten, dass eine vorhandene LAN Verbindung einer WLAN
Verbindung vorgezogen wird, ist dies ein suboptimales Resultat, da
alle Verbindungen aufs Notebook bei Ansprache ueber bruno.bfh.ch
weiterhin auf das WLAN Interface gehen werden.

Eine (suboptimale, aber durchaus funktionierende Variante) waere
hier, nur eine DHCPID fuer alle Interfaces zu verwenden. So waere
wenigstens nicht immer der DNS Record auf dem WLAN Interface,
sondern vorallem beim Umstecken (und danach je nach Renewal Interval
der Lease) das LAN Interface zum Zug gekommen.

1.5 Einfluss von DHCP Leasetime, DNS TTL und DNS Caches
-------------------------------------------------------

Wie bei Infrastruktur so ueblich, spielen viele Faktoren zusammen
und eine Infrastruktur ist nur so gut, wie alle Dienste aufeinander
abgestimmt sind:

  * DHCP Leasetime:

    - da die DDNS Records mit Ablaufen resp. nicht-Erneuern der DHCP
      Leastime geloescht werden, ist grundsaetzlich eine kuerzere
      Leastime positiv.

    - im alten DHCP Setup war die Leasetime 1h, also vergleichsweise
      hoch.

    - im neuen DHCP Setup (fuer bfh.ch seit 5.11.) ist die Leastime
      10min, also vergleichsweise tief.

    - dies hat viele Vorteile (bessere Pool Usage, aktuellere Daten
      im DNS, etc.) und nur einen Nachteil: es vertraegt keine
      zuverlaessige oder instabile DHCP Server - die haben wir
      natuerlich im Griff, so dass dies bei uns keine Nachteil ist.

  * DNS TTL:

    - da durch eine tiefe Leasetime so aktuellere Informationen ins
      authoritative DNS kommen, hilft nur dann wenn auch die
      Time-to-live (TTL) auch ensprechend tief ist. Mit einer (zu)
      hohen TTL werden die (in der Zwischenzeit veralteten) DNS
      Records lange auf den Resolvern und/oder den Clients selbst
      gecached, so dass die Clients die aktualisierten DNS Records
      erst mit (viel) Verzoegerung mitbekommen.

    - im alten DNS Setup war die TTL 1h, also vergleichsweise hoch.

    - im neuen DNS Setup (fuer bfh.ch seit Q2/2022) ist die TTL
      10min, also vergleichsweise tief.

    - eine tiefe (aber nicht zu tiefe) TTL hat viele Vorteile
      (Aenderungen gehen schneller zu den Clients) und haben keine
      Nachteile. Eine zu tiefe TTL macht Netzwerkverbindungen
      gefuehlt langsamer, weil bei "jeder" Initialisierung zuerst
      noch eine DNS Abfrage gemacht werden muss, macht mehr Load
      auf den DNS Servern und ist katastrophal bei unzuverlaessigen
      oder instabilen DNS Servern.

  * DNS Caches:

    - bevor wir im Juni 2022 die interne und externe DNS View
      verschmelzen konnten und damit die Linux Nameserver fuer die
      gesamte bfh.ch Zone authoritativ wurden, mussten die internen
      DNS Resolver die interne bfh.ch Zone cachen (laenger als die
      TTL), weil die Infoblox Appliances zu langsam waren, alle Anfragen
      der Resolver beantworten zu koennen.

    - d.h. so war es moeglich, dass bfh.ch Records bis zu
      2x TTL = 2h noch auf nicht mehr existierende oder falsche Systeme
      verwiesen haben.

    - seit Abschalten der unterschiedlichen Views koennen wir
      einerseits auch fuer bfh.ch, wie fuer alle anderen eigenen
      Zonen, die Records auf den DNS Resolvern nicht mehr cachen, so
      dass alte Records nur noch bis zu 1x TTL = 1h auf nicht mehr
      existierende Systeme verweisen koennen.

    - gleichzeitig haben wir auch die TTL gesenkt weil Performance-
      technisch problemlos moeglich mit unseren Systemen, so dass es
      jetzt noch maximal 1x TTL = 10min sind, bis alle Systeme
      zwingend DNS Aenderungen mitbekommen haben muessen.

2. Probleme beim managen von BFH Standard-Clients
=================================================

2.1 Ausgangslage managed Clients
--------------------------------

An der BFH werden die Windows Clients zentral gemanaged via
Microsoft SSCM. Dieser verwendet wie es sich gehoert DNS Namen um
sich mit den Geraeten zu verbinden.

Weil User sich mit ihren Geraeten bewegen, Dockingstations benutzen,
etc. aendern die IP Adressen der Geraete oefters.

Aufgrund der (mindestens damaligen) Voreinstellung auf den Standard
Clients, dass beim Aufbau einer LAN Verbindung das WLAN Interface
heruntergefahren wird, waren DNS Records notorisch falsch weil noch
die IP Adresse des WLAN Interfaces im DNS eingetragen war. Ein
Update via LAN Interface wird wegen unterschiedlicher DHCPID
abgelehnt, so dass man warten muss bis die Lease abgelaufen ist und
der Record automatisch geloescht wird. Daraufhin kann er dann neu
eingetragen werden beim naechsten Lease Renewal auf dem LAN
Interface.

Zusammen mit der Kombinaton aus hoher DHCP Leasetime, hoher DNS TTL
und langem DNS Cachen dauert es lange bis die Aenderung schlussendlich
beim IT-Mitarbeitenden der auf das Client-System zugreifen will,
ankommt. Dadurch waren Clients teilweise nur sehr teilweise nur sehr
muehsam verwaltbar, dazu folgendes Beispiel:

  * Charly ruft ITS an und hat Problem mit xyz.

  * ITS will Update fuer xyz auf das Notebook von Charly pushen um das
    Problem zu loesen.

  * Charly denkt "super, geht sicher besser ueber LAN/mit Strom" und
    steckt Notebook an Dockingstation an:

    - IP wechselt, DNS Record bleibt gleich und zeigt ins Leere.

    - entweder warten jetzt alle mind. 1h bis auf den DNS Namen
      gepusht werden kann..

    - ..oder ITS laesst sich die IP Addresse vom User raussuchen
      und pusht manuell/umstaendlich auf die IP Adresse.

Zusammengefasst: Es bestand seit jeher das Problem, dass die Clients
teilweise/in immer wieder auftretenden Situationen nur sehr muehsam
verwaltbar waren.

2.2 "Problemloesung" fuer managed Clients
-----------------------------------------

Ein ursaechliches Loesen dieses Problems haette einen Umbau und
ein feines aufeinander Abstimmen der Gesamtinfrastruktur bedingt
(das wir in diesem Jahr umgesetzt haben), also grundsaetzlich ein
langes und aufaendiges Unterfangen.

Um trotzdem Linderung fuer das Problem zu bringen, wurde irgendwann
zwischen 2018 und 2019 versucht, dies offenbar durch Aendern des
DHCP Validierungsverfahrens trotzdem hinzutricksen:

  * im Normallfall muss, wie zuvor beschrieben, die DHCPID des
    Clients identisch sein, damit ein DNS Record via DDNS
    aktualisiert werden kann.

  * neben diesem Validierungsverfahren gibt es noch andere, die nur
    kurzfristig waehrend der Migration einer Umgebgung (z.B. wenn von
    einer Hersteller-DHCP-Appliance zu einer anderen, oder von/zu
    Microsoft AD als DHCP Server gewechselt wird).

  * Infoblox implementiert dazu u.a. den Modus "ISC Transitional":

    - dabei werden beim Update von Records via DDNS die TXT Records
      *nicht* beachtet, d.h. jeder Client kann jeden beliebigen
      Namen im DNS aendern.

      vergl.
https://docs.infoblox.com/space/NAG8/22251499/Configuring+DDNS+Update+Verification

  * die Idee, hier "ISC Transitional" zu verwenden war vermutlich,
    durch das (mehr oder weniger bewusste?) nicht-Pruefen der TXT
    Records Updates von Clients bei IP Wechseln "schneller" ins DNS
    zu bekommen, da so das Ablaufen der Lease nicht abgewartet
    werden musste im oben beschrieben Beispiel mit Charly.

  * da damals noch eine Trennung zwischen interner und externer DNS
    View bestand, haette damals "moodle.bfh.ch" extern nicht
    veraendert werden koennen, nur intern (d.h. Moodle waere im
    Internet erreichbar geblieben, nur nicht innerhalb des BFH
    Netzwerks).

    "Trotzdem" ist es keine gute Idee weil ja beliebige Records
    veraendert werden konnten, z.B. "bfh.ch" (das intern aufs
    Microsoft AD zeigt) zu aendern haette auch intern zu einigen
    Komplikationen gefuehrt.

Fairerweise muss man sagen, dass es keine sinnvollen alternativen
gibt als das Problem aufwaendig und richtig zu loesen:

  * grundsaetzlich koennte das Betriebssystem das "richtige" machen
    und kurzzeitig die WLAN Lease zurueckgeben, so wird im
    vorherigen Beispiel bruno.bfh.ch geloescht, und dann via LAN
    Lease neu eingetragen.

    Dies fuehrt aber zu einem kurzen Trennung aller Verbindungen des
    Notebooks und ist aus User Sicht natuerlich unerwuenscht - darum
    macht das ueblicherweise kein Betriebssystem.

    (ein Update-ohne-lease-release ginge auch, unterstuetzen aber nicht
     alle DHCP Server, weshalb es keine generische Loesung aus Client
     Sicht ist)

  * weitere "Hacks" (kann man leider nicht anderst sagen) sind
    Konfigurationen wie "LAN und WLAN haben die gleiche MAC aka
    Passthrough MAC" das manche "Enterprise Notebooks" koennen und
    ist hier genausowenig sinnvoll/erfolgreich.

3. Vorfall am 28.10.
====================

Ein Student hat um 14:24 via DHCP eine IP Adresse bezogen und den
Hostname "moodle.bfh.ch" fuer sein Geraet geschickt. Grundsaetzlich
voellig legitim.

Infoblox im Modus "ISC Transitional" hat den Record brav
eingetragen, so dass moodle.bfh.ch auf eine interne Adresse aus
147.87.0.0/16 gezeigt hat, statt auf den extern betriebenen Dienst
wo Moodle laeuft.

Nach manueller Korrektur des Records um 14:57 dauerte es dank tiefer
TTL (= 10min) maximal bis 15:07 bis moodle.bfh.ch wieder fuer alle
und ueberall funktioniert hat.

Der Student hat sich vorbildlich verhalten und sich selber umgehend
gemeldet (kurz nachdem wir gerade nachgeschaut hatten, wers war :).

Ihm ist in keinster Weise ein Vorwurf zu machen - er hat die relevanten
Dienste voellig korrekt verwendet - fuer Fehler in unserer veralteten
Infrastruktur kann er nichts und muss auch nicht davon ausgehen.

Dass in den letzen Jahren offenbar noch niemand anderes auf die Idee
gekommen ist, seinem Notebook/Handy/$wasauchimmer einen kreativen Namen
eines bereits existierenden Dienstes zu geben, ist, leider, reine
Glueckssache.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
Services / IT-Services
Daniel Baumann
Teamleiter Linux & Infrastructure Services
___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science