Zusammenfassung

  • RFC 3646 Option 23 listet rekursive DNS-Server nach Präferenz, Option 24 liefert eine ausschließlich für DNS bestimmte Suchliste; beides ist noch kein Nutzungsnachweis.
  • Eine belastbare Prüfung verknüpft die Herkunft der Konfiguration mit lokaler Vorrangregel, Namensbildung, tatsächlich gewähltem Server, Antwort, DNSSEC-Urteil und Anwendungseffekt.

Ein Prüfer sieht zwei Adressen: Server A steht vor Server B. Später zeigt ein Verfügbarkeitstest, dass A erreichbar war. Trotzdem beantwortet diese Kombination nicht, welcher Server eine bestimmte Anwendungssuche verarbeitet hat. Der Resolver kann B gewählt, nach einem Fehler umgeschaltet, aus dem Cache geantwortet oder eine Konfiguration aus einer anderen Quelle bevorzugt haben. Die Reihenfolge ist ein Input, kein Laufzeitprotokoll.

RFC 3646 definiert OPTION_DNS_SERVERS mit Code 23. Die Option enthält eine oder mehrere IPv6-Adressen rekursiver Nameserver in der Präferenzreihenfolge des Client-Resolvers; ihre Länge ist ein Vielfaches von 16 Oktetten. OPTION_DOMAIN_LIST mit Code 24 trägt eine Domänensuchliste für DNS-Hostnamen und gilt ausdrücklich nicht für andere Verfahren der Namensauflösung. Die Textfassung lässt beide Optionen nur in Solicit, Advertise, Request, Renew, Rebind, Information-Request und Reply zu.

Aus der korrekten Darstellung folgt keine Installation. Der Host kann die Nachricht empfangen und wegen lokaler Richtlinie verwerfen. Er kann die Werte installieren und später durch eine andere Quelle ergänzen. Selbst der aktive Zustand beweist keine einzelne Anfrage. Der Auditpfad braucht deshalb mindestens Ereignisse für Empfang, Annahme, Installation und tatsächliche Resolverentscheidung.

Die Suchliste verschiebt die Prüfung noch vor die Serverwahl. Ein unvollständiger Name kann zu mehreren Kandidaten werden. RFC 1535 und RFC 1536 behandeln Risiken impliziter Listen und die Behandlung punktierter Namen. Für eine heutige Nachvollziehbarkeit müssen ursprüngliche Anwendungseingabe, Suffixfolge, erzeugte Kandidaten und akzeptierte Antwort erhalten bleiben.

RFC 3646 empfiehlt DHCP-Authentisierung, bevor eine Serverliste installiert oder eine Suchliste angenommen wird. Das begrenzt Angriffe durch einen fremden DHCP-Server, bestätigt aber nicht die Gesundheit eines beworbenen Resolvers. Ebenso ist RFC 4033 kein Beleg für die richtige Namensabsicht: In einer durch die falsche Suchdomäne erreichten Zone können Datensätze legitim signiert sein. DNSSEC kann die Daten unter dem abgefragten Namen validieren, ohne die Auswahl dieses Namens zu legitimieren.

Die lokale Vorrangregel ist ausdrücklich relevant. Manuell konfigurierte DNS-Server und Suchlisten sollen nicht durch DHCP überschrieben werden. Ein Netzwerkmitschnitt zeigt somit ein Angebot, nicht zwingend den Soll- oder Istzustand. Die Prüfung muss vorhandene manuelle Werte, die angewandte Regel und den nachher ausgelesenen Resolverzustand einbeziehen.

Mit RFC 8106 existiert zudem ein zweiter automatischer Pfad über Router Advertisements. Eine Adresse kann aus DHCPv6 und RA stammen, aber je Quelle eine andere Gültigkeit besitzen. Wer nur gleiche Werte zusammenführt, verliert die Herkunft und kann später weder Fortbestand noch Entzug sauber erklären.

Die Standardschichten begrenzen die Aussage. RFC 3315 war die ursprüngliche DHCPv6-Basis; RFC 8415 hat sie ersetzt. RFC 8504 beschreibt Anforderungen an IPv6-Knoten. Konformitätsanforderungen sind jedoch keine Zustandsnachweise für einen einzelnen Rechner.

RFC 1034 liefert die DNS-Architektur, RFC 1035 Nachrichten und Implementierungsgrundlagen. RFC 3397 bietet den DHCPv4-Vergleich für Suchdomänen. Diese Quellen erklären Mechanismen, ersetzen aber keine beobachtete Anfrage.

Das IANA-Register für DHCPv6-Parameter weist 23 und 24 zu. Es beweist gemeinsame Benennung, nicht Werbung, Annahme, Installation oder Wirkung. Auch Datatracker, RFC-Editor-Information, Errata und Dokumenthistorie belegen die Herkunft des Standards, nicht seine gegenwärtige Ausführung.

Heng Lus Überlegungen zum Vorrang laufenden Codes, zur minimalen Anfangsspezifikation und zu Realitätsschichten ergeben eine passende Prüfregel. Das gemeinsame Format ermöglicht Koordination. Die lokale Richtlinie behält Entscheidungsraum. Erst der laufende Zustand und die konkrete Beobachtung tragen eine Aussage über das Ergebnis.

Der vollständige Beleg umfasst Schnittstelle und Netz, DHCP-Serveridentität und Authentisierung, Optionsbytes, manuellen Vorrang, Annahmeentscheidung, quellenspezifische Lebensdauer, installierten Zustand, ursprünglichen Namen, Kandidaten, ausgewählten Server und Transport, Cache, Antwort, DNSSEC-Urteil sowie Anwendungsergebnis. Unverbundene Datenpunkte bleiben offene Fragen.