Summary

  • RFC 3646 Option 23 orders recursive-server addresses by preference and Option 24 supplies a DNS-only search list; neither option proves installation or use.
  • A defensible operating record joins configuration provenance to the original name, suffix expansion, selected server, answer, validation state and application result without collapsing those facts.

The console says a host received OPTION_DNS_SERVERS. The first address is healthy on a synthetic probe. An application still fails to reach the service. Nothing in those three observations is contradictory. The packet described a preference. The probe tested an endpoint. The application depended on a particular query path at a particular time. A resolver may have used another source, another server, another suffix, a cached answer or no DNS path at all.

RFC 3646 gives DHCPv6 two compact DNS configuration tools. Option 23 contains one or more IPv6 addresses of recursive name servers, in preference order for the client resolver. Its length is a multiple of 16 octets. Option 24 contains a domain search list for DNS hostname resolution and explicitly does not govern other name-resolution mechanisms. The plain-text edition also limits where both options may appear: Solicit, Advertise, Request, Renew, Rebind, Information-Request and Reply.

Those statements are precise but narrow. “First in preference order” is not “selected for this query.” An address in a Reply is not proof that local policy accepted it. Acceptance is not proof that the value reached the active resolver. Active configuration is not proof that a request left the host. A response is not proof that its data passed DNSSEC policy or that the application consumed the intended identity. Each verb belongs to a different evidence layer.

The search list adds a transformation before a query may exist. An incomplete name can be combined with one or more suffixes. RFC 3646 points to RFC 1535 and RFC 1536: search lists should be explicit, and a name containing a dot should be tried as fully qualified before suffixes are appended after failure. That history explains the risk, but this Article's operational question is later: can an investigator recover the original application input and every candidate name the resolver actually tried?

The security section makes a distinction that dashboards often erase. An intruder DHCP server can advertise a recursive server and redirect queries, so the client should require DHCP authentication before installing the list. It can also advertise invalid search domains. RFC 4033 does not make that second problem disappear: DNSSEC may correctly validate records that are legitimately signed inside the wrong domain. Cryptographic validity answers whether data authenticates under the queried name. It does not prove that suffix selection expressed the user's intent.

Local authority matters as much as packet integrity. RFC 3646 says manually configured DNS servers or search lists should not be overridden by DHCP. That creates a policy decision the wire capture cannot settle. The packet can prove an advertisement. Only host-side evidence can prove whether manual configuration existed, which precedence rule ran, whether the option was accepted and which values were installed.

There may also be more than one automatic source. RFC 8106 defines Router Advertisement options for recursive DNS servers and search lists. The same resolver address can therefore arrive through DHCPv6 and RA under different source identities and lifetimes. A configuration inventory that deduplicates on value alone destroys the answer to a crucial question: which authority kept this setting alive?

The protocol lineage reinforces the boundary. RFC 3315 supplied the original DHCPv6 base and encoding context; RFC 8415 now provides the current base specification, including stateful and stateless exchanges. RFC 8504 records IPv6 node requirements. These documents describe interoperability obligations, not a runtime attestation for any named host.

DNS itself supplies further layers. RFC 1034 describes the architecture and RFC 1035 the implementation and message formats. RFC 3397 gives comparative DHCPv4 domain-search context. None can turn an option receipt into the trace of a particular application lookup.

Even the registry has a limited job. The IANA DHCPv6 parameters registry assigns 23 and 24. Registration proves common vocabulary. It does not prove that a server advertised a value, a client trusted the source, a resolver selected it or an answer was correct.

The document's provenance can be checked through the Datatracker record, RFC Editor information page, errata search and history. These surfaces bound the standard and its record; they are not deployment telemetry.

Heng Lu's accounts of running-code primacy, minimum initial specification and reality layers supply the management reading. A small common option format enables interoperability. It should not erase local choice. The running host, query trace and application observation constrain what the packet may truthfully claim.

The useful audit chain is therefore longer than a DHCP log: interface and network context; authenticated DHCP server; exact message and option bytes; manual-setting precedence; acceptance decision; source-specific lifetime; installed resolver state; original application name; generated candidate names; selected server address and transport; cache status; DNS response; DNSSEC verdict; and application result. Missing links are uncertainty, not permission to infer success.