Establish DNS shared keys only through an explicit TKEY exchange mode

Frame this document as a source-led configuration and assurance check: Establish DNS shared keys only through an explicit TKEY exchange mode. Only the official source and traced locations below supply facts. Confirm applicability before acting.

Source fact:

The official RFC 2930 — Secret Key Establishment for DNS (TKEY RR) from RFC Editor / Internet Engineering Task Force supports the following bounded statements:

• A TKEY record carries the key algorithm, inception and expiration times, exchange mode, error, key data, and optional other data. The research record locates this support at Section 2 (The TKEY Resource Record).
• A TKEY query places its TKEY record in the additional-information section and uses the mode field to select the key-agreement procedure. The research record locates this support at Section 3 (General TKEY Considerations).
• The defined TKEY modes cover server assignment, Diffie-Hellman exchange, GSS negotiation, resolver assignment, and key deletion. The research record locates this support at Section 2.5 (Modes).

Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers and the conditions the source actually describes.

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. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates.

Applicability questions

• For source statement 1 at Section 2 (The TKEY Resource Record), which observable configuration, record, or test can confirm applicability here?
• For source statement 2 at Section 3 (General TKEY Considerations), which observable configuration, record, or test can confirm applicability here?
• For source statement 3 at Section 2.5 (Modes), 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. Use a two-person review for the source interpretation and the resulting operational decision. 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.

Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, while excluding secrets and sensitive personal or topology data from ordinary tickets.

Verification and evidence

Tie each conclusion back to Section 2 (The TKEY Resource Record); Section 3 (General TKEY Considerations); Section 2.5 (Modes) and to observable material such as zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Preserve provenance and stable identifiers without copying secrets into the evidence set.

Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes.

Official references

• RFC 2930 — Secret Key Establishment for DNS (TKEY RR) — RFC Editor / Internet Engineering Task Force