Optionen und Vererbung

Aufbau und Bedeutung

Viele Optionen sind TLV-kodiert: Type (Code), Length (Bytezahl), Value (Daten). Pad 0 und End 255 sind Sonderfälle ohne gewöhnliches Längenfeld. IPv4-Werte benötigen vier Bytes; Listen enthalten mehrere solcher Werte. Eine fehlerhafte Länge kann die Interpretation des restlichen Optionsbereichs verhindern.

Vom Konfigurationswert zum Clientverhalten

Windows kann Werte unter anderem auf Server-, Scope- und Reservierungsebene halten; Policies können weitere Auswahlentscheidungen hinzufügen. Spezifische Einstellungen können allgemeinere übersteuern. Prüfe deshalb den für genau diesen Client effektiv ausgewählten Wert, nicht nur den globalen Dialog.

Kea hat eigene Konfigurationshierarchien, Klassen und Ausgabeentscheidungen. Eine Parameter Request List ist eine Anfrage, keine Zusicherung, dass jeder gewünschte Wert gesendet oder verwendet wird. Nicht jeder Client unterstützt jede Option; lokale Richtlinien können Einstellungen beeinflussen. Maßgeblich sind das ACK und die aktive Clientkonfiguration.

Eine DNS-Option von Hand dekodieren

Option 6 enthält eine Liste von DNS-Serveradressen. Für zwei IPv4-Resolver beträgt die Datenlänge acht Bytes, weil jede Adresse vier Bytes benötigt. Die Bytefolge 06 08 c0 a8 14 0a c0 a8 14 0b bedeutet: Code 6, Länge 8, anschließend 192.168.20.10 und 192.168.20.11. Die beiden ersten Bytes gehören zur Optionsstruktur, nicht zur ersten IP-Adresse.

Eine Länge von sieben wäre für diese Adressliste nicht plausibel. Ein Decoder muss innerhalb der tatsächlichen Paketgrenze bleiben und darf die folgende Option nicht einfach als fehlendes Adressbyte vereinnahmen. Solche Prüfungen sind besonders wichtig bei handgeschriebenen Konfigurationen und Rohdatenanalysen. Bei Zeichenkettenoptionen gelten wiederum andere Regeln; jede Option besitzt ihren eigenen Datentyp.

Überschreibungen durch eine Beweiskette verfolgen

Nehmen wir an, global steht DNS .20.10, im Bürobereich .20.11 und für einen reservierten Testclient .20.12. Welche Einstellung gewinnt, hängt von den dokumentierten Auswahl- und Vererbungsregeln des eingesetzten Produkts sowie weiteren Policies ab. Die Reihenfolge der Dialoge, die du zuletzt geöffnet hast, hat keine Bedeutung. Untersuche zuerst, welcher Scope und welche Clientzuordnung tatsächlich verwendet werden.

Danach kontrollierst du das gesendete ACK und schließlich den aktiven Resolver am Client. Zeigt das ACK .20.12, der Client aber .20.99, liegt der Unterschied nach der Serverauswahl, etwa in einer lokalen Einstellung. Enthält bereits das ACK .20.11, muss dagegen die serverseitige Auswahl geprüft werden. Diese Trennung spart wahllose Änderungen auf beiden Seiten.