Refuse to treat a DNS name as a stable or trustworthy identifier

Use this document to connect an official requirement or behavior to observable evidence: Refuse to treat a DNS name as a stable or trustworthy identifier. Only the official source and traced locations below supply facts. Confirm applicability before acting.

Source fact:

The official RFC 4367 — What’s in a Name: False Assumptions about DNS Names from RFC Editor / Internet Architecture Board supports the following bounded statements:

• Client and server protocol behavior should not change merely because of the other endpoint’s domain name. The research record locates this support at Section 7 (Recommendations), follow the specifications.
• When a protocol offers capability negotiation, endpoints should negotiate supported features instead of inferring them from a domain name. The research record locates this support at Section 7 (Recommendations), use capability negotiation.
• Implementations should accept the full range permitted by the protocol rather than narrowing input based on assumptions about a named domain. The research record locates this support at Section 7 (Recommendations), protocol acceptance.

Only the traced statements above are asserted as source facts. Apply the review to authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers after confirming that the source and deployed context match.

What the source does not establish

This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults.

Applicability questions

• For source statement 1 at Section 7 (Recommendations), follow the specifications, which observable configuration, record, or test can confirm applicability here?
• For source statement 2 at Section 7 (Recommendations), use capability negotiation, which observable configuration, record, or test can confirm applicability here?
• For source statement 3 at Section 7 (Recommendations), protocol acceptance, which observable configuration, record, or test can confirm applicability here?
• Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population?
• Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability?
• Who owns the decision, and which observation requires stopping, escalation, or rollback?

DSE recommendation:

DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation.

Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state. Handle credentials, keys, recovery data, and personal information through approved secure channels.

Verification and evidence

Build a reproducible chain from Section 7 (Recommendations), follow the specifications; Section 7 (Recommendations), use capability negotiation; Section 7 (Recommendations), protocol acceptance to the observed environment. Useful domain evidence includes zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior; label every item with scope, timestamp, collector, and stable identifier.

Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed.

Official references

• RFC 4367 — What’s in a Name: False Assumptions about DNS Names — RFC Editor / Internet Architecture Board