DNS TSIG, defined by RFC 8945, lets two DNS parties that already share a secret authenticate an individual DNS transaction with a keyed message authentication code. A properly validated signature can tell a DNS server that a dynamic-update request came from a party possessing an agreed secret, and it can bind a server’s response to the signed request. It does not encrypt DNS traffic, establish public trust for everyone who looks up a domain, or make a proposed DNS change safe merely because the signer is authorised.
For an automated agent, the useful design is narrow and practical: decide which DNS change is permitted, construct the correct DNS message, sign it under a specifically authorised TSIG key, validate any response, then independently confirm the intended DNS state before reporting completion. The signed transaction and the application’s permission policy are different controls. A future form of superintelligence is not necessary for this mechanism; it is an existing protocol that current DNS automation can use responsibly.
This specialist guide follows the 2020 RFC 8945 specification and related DNS UPDATE and zone-transfer standards. All characters, organisations, DNS names, timestamps, record counts and incident examples are illustrative unless explicitly described as protocol requirements. Numerical checks show what a five-minute signature window, a truncated MAC, a changed update policy and a multi-message transfer do and do not establish.
Contents and learning pathways
Why a DNS automation needs authenticated transactions · Understand the participants before adding cryptography · What TSIG authenticates and what it leaves outside · Read the TSIG record as protocol metadata, not zone content · The MAC binds precise wire bytes, not a convenient JSON rendering · Use a named algorithm whose deployment policy is defensible · Hand-checked time example: the signed interval matters · Time-bound MACs reduce replay exposure but do not eliminate it
Why a signed answer must belong to the original request · Read BADKEY, BADSIG, BADTIME and BADTRUNC separately · An unauthenticated error cannot authorise corrective action · MAC truncation is a policy decision with a precise floor · A signed DNS UPDATE still needs a narrow change policy · A constructed record-change example with authorisation checks · A zone transfer can contain multiple signed and unsigned packets · MAC chaining prevents a false story of independent transfer messages
TSIG, TLS and DNSSEC solve different trust questions · Shared secrets make lifecycle management unavoidable · Time synchronisation is part of the security boundary · Byte accounting and integrity strength are different metrics · A diagnostic decision tree for real TSIG failures · A bounded agent workflow that does not confuse intention with authority · Worked recovery example with distinct failure states · Measure the failures that would actually change the decision
Independent transfer exercise: clock skew and privilege mismatch · Limits that remain even when all TSIG fields are valid
Frequently asked questions · Primary standards · Relevant eduKate learning guides.
Why a DNS automation needs authenticated transactions
DNS answers help software locate services, send mail and discover network endpoints. Many DNS questions are ordinary public lookups: a client asks for a name and a resolver returns records. Other operations are administrative. A controlled client may request that an authoritative server modify an address record or transfer part of a zone’s contents. An open request path for those operations would give strangers influence over infrastructure they do not administer.
An IP-address allowlist can limit where requests appear to originate, but a source address is not itself cryptographic proof of the sender’s identity. Network paths, proxies, shared hosts and changes in routing complicate any assumption that an address uniquely identifies an authorised actor. RFC 8945 adds transaction authentication using a secret known to the relevant client and server, producing a MAC over specified wire-format bytes.
This solves a defined portion of the problem. A successful cryptographic check makes arbitrary off-path forgery materially harder without the secret and lets the server recognise a party that possesses the expected key. It does not mean the party’s instruction should be carried out. The server still needs a policy answering which names, record types and zones the key may change.
Think of TSIG as an authenticated envelope on a DNS protocol operation. The envelope can protect the transaction’s integrity and validate its origin with respect to a shared key. A separate approval system decides whether the enclosed instruction is sensible, a separate transport may protect confidentiality, and post-operation verification shows whether the intended state was actually reached.
Understand the participants before adding cryptography
In the simplest example, an authorised updating client wants an address record for an application service changed. It sends a DNS UPDATE to the authoritative server for the relevant zone. A secondary name server may also request an AXFR or IXFR transfer from a primary, using TSIG to authenticate the exchange. Those are different operations with different authorisation policies, even though both can use the same general transaction-signing mechanism.
The resolver used by a student’s laptop to answer ordinary web-browsing questions is not automatically the client that may update an authoritative zone. A recursive resolver, authoritative primary, authoritative secondary and administrative update service have distinct responsibilities. Calling them all DNS agents obscures where the secret belongs and who is permitted to modify records.
RFC 8945 assumes an out-of-band way to establish a shared secret. It does not mandate a secure secret distribution service or automatically create identities for software components. A site administrator must provision keys, limit who can read them, configure both endpoints consistently and establish the relevant security permissions. If every unrelated automation worker holds the same key, attribution and revocation become harder.
A practical inventory records the zone owner, approved client identity, key name, selected algorithm, creation date, intended privileges, authorised receiving servers and revocation plan. The key name is an identifier, not the secret itself. A readable identifier can help operations, but its presence in a message is not evidence that the attached MAC is correct.
What TSIG authenticates and what it leaves outside
A transaction MAC is computed from a shared secret and a carefully defined sequence of DNS message fields. The receiver independently computes the expected result and compares it with the transmitted MAC under the appropriate algorithm and local truncation policy. If the protected bytes are modified without the shared secret, the verification should fail under the assumed cryptographic security of the algorithm.
TSIG covers an individual transaction between participants that have agreed upon a secret. It is not a general DNS data-authenticity proof that can be passed to strangers and validated without a secret. DNSSEC uses public-key-related signatures and chain-of-trust validation to answer a different question about DNS data. An authenticated server could still send an incorrect address if its underlying zone data are wrong.
TSIG also does not conceal the contents of a packet. Anyone with suitable network visibility may still learn queries, responses and transferred zone records when ordinary unencrypted DNS transport is used. Where confidentiality matters, the DNS Zone Transfer over TLS specification describes the relevant additional layer, including proper server authentication and access controls.
The most dangerous operational misunderstanding is to equate correct MAC verification with permission to do anything. Cryptographic verification recognises possession of keying material; authorisation must still scope the key to permitted operations. Logging can also record who initiated the authorised workflow, because a single shared key may not distinguish two humans or services that both legitimately possess it.
Read the TSIG record as protocol metadata, not zone content
RFC 8945 defines TSIG as DNS resource-record type 250, but calls it a meta-resource-record rather than normal cacheable DNS data. The TSIG record is attached to a DNS message to authenticate that transaction. The record uses class ANY and a time-to-live of zero. Receivers must not put it into a DNS cache as though it were an address or mail record.
The record’s name identifies the shared key. Within its data appear an algorithm name, a 48-bit Time Signed value, a 16-bit Fudge value, the MAC size and MAC bytes, an Original ID, an Error value, and length and contents of Other Data. Most readers need to understand those fields’ jobs before attempting to read raw hex dumps.
Time Signed expresses a clock time in seconds under the protocol’s defined representation. Fudge gives a permitted time difference for receipt and protects against some replay conditions. MAC Size tells the verifier how many authentication bytes were transmitted. Original ID preserves the initiating DNS request identifier, which matters if a forwarding step changes the visible DNS header ID.
The TSIG record belongs last in the additional section of a signed DNS message, and only one such record is allowed there. A malformed placement is a format problem, not a harmless variation that an agent may ignore. Correct parsing should precede any decision to trust, retry or change authoritative data.
The MAC binds precise wire bytes, not a convenient JSON rendering
The protocol authenticates DNS wire-format bytes and selected TSIG variables, not an informal text summary. RFC 8945 describes how the outgoing message is hashed before appending the TSIG record, and how the receiving side reconstructs that input by removing the TSIG from the additional section and correcting the record count. A one-byte difference in the authenticated input can produce a different MAC.
The inputs include the DNS message and canonical representations of particular TSIG fields such as key name, algorithm, Time Signed, Fudge, Error and Other Data. Correct network-byte-order handling and canonical domain-name encodings matter. The verifier must not simply hash the packet exactly as received with the TSIG still inside, because the protocol’s MAC calculation is defined over a reconstructed message.
Responses also involve the MAC of the validated request. This links the signed response to the transaction that provoked it, rather than merely authenticating an unrelated packet from a server possessing the secret. If a proxy legitimately changes the visible DNS transaction ID, the Original ID handling exists to preserve the intended calculation. These details are easy to get wrong in home-grown implementations.
For an automated client, the sensible practice is to use a maintained DNS library implementing RFC 8945 and to test known interoperability fixtures. Writing an independent signing routine can be appropriate for a protocol implementation project, but should never be the unexamined first step of an operational DNS-update script. A successful HMAC call alone does not prove the surrounding DNS message was canonicalised correctly.
Use a named algorithm whose deployment policy is defensible
The shared secret feeds an HMAC algorithm. RFC 8945 requires implementations that support TSIG to implement HMAC-SHA1 and HMAC-SHA256 for interoperability, but its algorithm table recommends hmac-sha256 for use and does not recommend hmac-sha1. The old HMAC-MD5 identifier remains an implementation option for history, while its use is prohibited by the table.
This distinction between implementation support and operational choice is critical. A product may parse a legacy algorithm for compatibility without allowing operators to configure it for a fresh zone-update workflow. The selected key, key name and algorithm must agree at both endpoints. The RFC recommends associating only one algorithm with a given key name to avoid confusion between cryptographic contexts.
The strength of the algorithm does not compensate for weak secret management. A secure MAC built from a secret copied into an accessible log, published script or shared learning notebook is not secure in practice. Access control, secret generation, secure storage, rotation and timely revocation remain independent tasks. If a key leaks, the verifier may see perfectly valid MACs from a malicious holder.
A responsible operational report lists the agreed key identifier and algorithm while excluding secret bytes from ordinary logs. If a failure begins after an algorithm rotation, compare configurations on both endpoints before making network or DNSSEC changes. A mismatch in algorithm identifiers can look like a generic authentication failure even when the network path is completely healthy.
Hand-checked time example: the signed interval matters
Consider an illustrative client that signs an update at 12:00:00 UTC with Fudge equal to 300 seconds. The nominal acceptable window around that signed timestamp runs from 11:55:00 to 12:05:00 on the verifier’s clock. A request checked at 12:04:50 differs by 290 seconds, which is within the window. The same unchanged request checked at 12:05:01 differs by 301 seconds, which exceeds it.
The arithmetic is |server time minus signed time| no greater than Fudge. The unit is seconds. A six-second network delay generally falls well inside a 300-second tolerance, but a clock error of seven minutes does not. A valid cryptographic MAC cannot override an expired or badly skewed time interval. The server’s protocol behaviour in that case is a time-related TSIG error rather than permission to proceed.
The RFC recommends a Fudge of 300 seconds for most situations because the permitted interval must accommodate expected clock differences and transmission delays without needlessly expanding the replay window. An operator should not multiply the value by ten simply because intermittent failures appear; doing so increases the time span in which a captured valid transaction may be considered fresh.
Investigate the sender’s and verifier’s time sources first. Check whether their clocks use a reliable time service, whether virtual machines are paused or resumed with stale clocks, and whether time measurements are in UTC seconds. The example timestamps are illustrative and not measurements of any running DNS service.
Time-bound MACs reduce replay exposure but do not eliminate it
A signed timestamp and Fudge bound the period during which a captured request may remain timely. They do not constitute a globally unique one-time token. A captured signed message may be replayed while it is still inside the accepted window unless other controls detect or neutralise that repetition. The protocol also recommends caching the most recent Time Signed value per key and treating older later-arriving messages with care.
The caching idea itself creates a trade-off. UDP messages may arrive out of order. If a newer signed request arrives first and an earlier legitimate one follows, strict rejection of older timestamps could reject genuine traffic. RFC 8945 discusses such conditions and advises bounded handling rather than an unthinking retry loop. Correct engineering must account for delivery patterns and operation semantics.
For a DNS UPDATE workflow, replay impact also depends on what the update does. Reapplying an operation that sets an RRset to the same value may have a different effect from repeatedly adding or deleting records. Do not assume that authenticated means idempotent. The application should use available DNS UPDATE prerequisites, inspect the final zone state and avoid blind repeated writes when an acknowledgement is ambiguous.
A stronger replay strategy often combines a short reasonable Fudge with tight key privileges and application-level state checks. An administrator should record suspected repeated transaction IDs, timestamp anomalies and update attempts that failed prerequisites. These signals do not replace protocol verification, but help distinguish benign retransmissions, clock problems and unauthorised activity.
Why a signed answer must belong to the original request
When a server accepts a properly signed request, it replies under the agreed key and algorithm. The response MAC calculation incorporates the validated request MAC along with the response message and relevant TSIG variables. This relationship matters because an authentic-looking response detached from the initiating request should not be treated as evidence that the specific operation completed.
An update client should retain its request identifier, key name and request MAC while awaiting the answer. Upon receiving a response, it must verify the expected signature in the appropriate protocol context and then interpret the DNS operation’s status. A valid signature can authenticate a negative answer too; it does not imply that an update was accepted.
This distinction is familiar in any reliable automation. A job may submit a command, see a cryptographically verifiable response and still learn that a prerequisite failed. Conversely, a transport timeout does not prove that the server performed nothing. The safe response to ambiguity is reconciliation against authoritative state under a bounded retry policy, not immediate unverified repetition.
A misleading implementation might display success whenever a TSIG verification function returns true. A correct status report records separately the request signature validity, response signature validity, DNS status or error, and independently observed target RRset. This gives the reader evidence for the actual claim instead of a single green tick covering several independent conditions.
Read BADKEY, BADSIG, BADTIME and BADTRUNC separately
RFC 8945 defines TSIG-related error values 17 for BADKEY, 16 for BADSIG, 18 for BADTIME and 22 for BADTRUNC. They are not interchangeable ways of saying the Internet is down. The surrounding DNS response can carry NOTAUTH, RCODE 9, while the TSIG Error field supplies the more specific reason. Diagnose the appropriate layer before changing configuration.
BADKEY indicates that the receiving side does not recognise the key name or algorithm under relevant conditions. BADSIG indicates that a MAC failed verification. Either can arise from mismatched configuration, an incorrect secret, a bad wire representation or a deliberately forged message. Do not interpret an unauthenticated error payload as definitive proof of which of those causes occurred.
BADTIME means that clock-time validation fails even though the protocol can recognise the relevant request context. A proper signed BADTIME response has special time fields that allow diagnosis without recursively rejecting it for its own clock difference. BADTRUNC instead means the MAC length, though not intrinsically malformed, fails the receiver’s local minimum-strength policy.
A good monitoring system counts these error classes separately and links them to the key identifier and receiving endpoint without disclosing secret material. An engineer investigating clock skew needs different evidence from one investigating an unexpectedly shortened MAC. Changing the Fudge value in response to BADKEY is a distraction, and enabling a weaker algorithm because of BADTIME is a serious misdiagnosis.
An unauthenticated error cannot authorise corrective action
For certain key and MAC failures, RFC 8945 requires an unsigned error response because the receiving server cannot safely authenticate a reply using an unknown key or an invalid request MAC. Such a response is diagnostic data, but it has not established the sender’s identity under the expected transaction key. It may be spoofed by an adversary or corrupted in transit.
That is why a client should not accept a key rotation instruction, new endpoint or privilege change merely because an unsigned error names a different key. Even when error handling offers useful hints, the client must preserve its established trust policy and wait for a verifiable response or use an approved administrative channel to investigate.
For validity-window failures after a good request MAC, the specification calls for a signed BADTIME response containing the server’s current time in the Other Data field. The presence of a signed diagnostic is more meaningful than an unauthenticated hint, but an application should still consider its policy before modifying system clocks or retrying a destructive update.
A general rule follows: error messages can explain what the server thinks failed, but they are not themselves a permit to lower verification standards. Retrying with signature verification disabled would defeat the very boundary that TSIG was added to protect. A bounded, independently diagnosed repair is safer than silent automatic downgrade.
MAC truncation is a policy decision with a precise floor
A full HMAC-SHA256 digest contains 32 bytes, or 256 bits. Some TSIG deployments can send a shorter prefix of a MAC under the RFC’s truncation rules. The minimum permitted length is not an arbitrary two-byte checksum: the RFC specifies restrictions tied to ten octets and half the hash output length, and a local receiving policy can demand a stronger minimum.
For HMAC-SHA256, half of the full 32-byte output is 16 bytes. A transmitted 16-byte prefix is 128 bits, which meets that general protocol floor, though a particular receiver may insist on all 32 bytes. A 12-byte prefix does not meet the HMAC-SHA256 minimum described in the specification, even if a developer thinks 96 bits looks large.
To check dimensions, 16 bytes multiplied by eight bits per byte equals 128 bits; 32 bytes equals 256 bits. These are MAC lengths, not key lengths. In an idealised uniform-MAC guessing model, any single independent guess for a fresh 128-bit tag succeeds with probability about one in 2^128; this illustration does not describe the risk from a stolen key or faulty implementation.
If a message’s MAC is shorter than the RFC allows, it triggers format-related rejection. If the length is allowed in principle but below a receiving organisation’s stricter policy, BADTRUNC is appropriate. Those two error paths should not be collapsed into a generic bad signature. Logging the observed MAC length, never the key, makes such mismatches diagnosable.
A signed DNS UPDATE still needs a narrow change policy
RFC 2136 defines dynamic DNS UPDATE, including prerequisites and changes to resource-record sets. A workflow might change api.example.test from a test address to another address. TSIG authenticates the sending party; the authoritative server must still decide whether that party may modify the api name, whether it may touch only A records and which zone is in scope.
A common administrative mistake is to grant a key that can update every record in a zone even though the automation changes only one service name. If that secret is compromised or the agent is tricked into sending a harmful request, the authority exposed is much broader than the legitimate job. Use a limited key and a server-side update policy that can be audited independently of the client.
Dynamic UPDATE prerequisites create a useful form of conditional change. In an illustrative test zone, a client can request that a specific existing RRset condition hold before applying its changes. If the prerequisite is false, the update can fail without mutating the zone. This can prevent a stale automation from overwriting a newer administrator’s decision, although exact prerequisite syntax and conflict rules must follow RFC 2136 and server policy.
The post-write workflow should examine the actual zone records and any serial or propagation considerations rather than treating packet delivery as successful state change. Signed network communication is one layer; validated business intent, conditional update semantics and observed authoritative state are the other layers needed for trustworthy automation.
A constructed record-change example with authorisation checks
Assume a fictitious zone example.test with an authorised service updater named updater-a and a separate secondary transfer service named replica-b. The update key is allowed to change one A record for api.example.test but not the zone’s NS or MX records. Both parties use a mutually configured HMAC-SHA256 TSIG secret. These names and controls are invented to illustrate an operational policy.
Suppose the current A record is 192.0.2.10 and the approved new test address is 192.0.2.20. Both addresses come from documentation-only IPv4 space. A safe client reads the current value, checks that the change has been approved, encodes the appropriate update prerequisites and uses the specific update key. The server verifies the MAC and then independently checks the update policy and prerequisites.
If everything is valid, the authoritative server can commit the change. The client validates the signed response and then queries the authoritative source to confirm that the intended A record now contains 192.0.2.20. The client can distinguish that direct authoritative observation from slower recursive-cache visibility, which depends on other DNS behaviour.
Now imagine the same key attempts to change example.test’s MX record. MAC verification could still succeed, because possession of the secret has not changed. The server’s narrow authorisation policy should reject the requested operation. This is the proof that authentication and permission are distinct, and it is why a specialist article about TSIG must discuss more than how to calculate an HMAC.
A zone transfer can contain multiple signed and unsigned packets
Authoritative DNS servers often share a zone using AXFR or IXFR. A transfer can consist of multiple DNS messages over one TCP session, unlike a small ordinary one-message answer. RFC 8945 has special handling for TSIG on multi-message responses: it chains a prior MAC and relevant intervening message bytes so that messages are not treated as unrelated fragments.
The specification calls for TSIG on all response messages, but requires interoperable receivers to accept as many as 99 intermediary messages without a TSIG for backward compatibility, provided the first and last are signed and the chain verifies as required. An application should not invent its own shortcut such as checking only the first packet and assuming the rest of a transfer must be valid.
Imagine a transfer containing twelve DNS messages. With a signing mode in which each is signed, there are twelve authentication points. With a compatible stream including unsigned intermediates, the receiver still has to account for intervening bytes in the running authentication state and verify the required final signature. This arithmetic counts message positions only; it is not evidence of a specific wire packet size.
If the receiver detects a failed TSIG verification during a transfer, it must treat the connection as compromised for that purpose and close it, rather than continuing to apply records on the assumption that transport sequencing is enough. Safe recovery includes checking whether the local zone database was partially staged and relying on the DNS server’s transfer consistency safeguards.
MAC chaining prevents a false story of independent transfer messages
The first signed response uses the validated request MAC, response message and ordinary relevant TSIG fields. For later messages in a multi-message answer, RFC 8945 defines a different running input containing the prior MAC, intervening DNS message bytes and current TSIG timer values. This makes authentication depend on the sequence of messages instead of only on each isolated reply.
That dependence changes how implementation tests should be written. A test that successfully verifies one isolated TSIG record says little about the logic required for a full transfer. The client must maintain the authenticated chain across successive messages and detect an omitted or altered message even when a later packet has the expected DNS transaction identifier.
To build a safe test fixture, record three simple response messages A, B and C in order and compute valid chained MAC material with a known test secret. Verification should accept the legitimate sequence. It should reject a deliberately altered B, an unexpected replacement C or a broken MAC chain. Never use a live production key in such unit tests.
The transport connection itself does not define authorisation. TCP preserves a byte stream between endpoints, but neither possession of a TCP socket nor receipt of plausible DNS records proves that the transfer requester is allowed to receive the zone. TSIG and per-query policy address transaction authenticity, while separate transport controls may protect confidentiality.
TSIG, TLS and DNSSEC solve different trust questions
DNS TSIG supplies transaction authentication under a shared secret. DNSSEC addresses the authenticity of signed DNS data for validating resolvers through a different trust model. TLS protects a network connection, including confidentiality where correctly negotiated and authenticated. These mechanisms may be used together because none is a blanket substitute for the others.
RFC 9103 specifies DNS Zone Transfer over TLS, often called XoT. It describes a way to encrypt transfers that TSIG alone leaves readable to on-path observers. Its security model uses strict TLS server authentication and appropriate client authorisation through mutual TLS or a supported combination of access controls and signed requests. Applying TSIG to a cleartext transfer does not conceal the zone contents.
For a multi-primary system, one unencrypted transfer path can undermine a confidentiality policy even when other servers use TLS. The transfer-group concept in RFC 9103 therefore matters: administrators must examine the complete set of parties exchanging a zone. Cryptographic settings on one well-configured server do not describe the protection of every replication path.
A useful comparison asks four separate questions: is the sender authenticated under an appropriate key, is the particular operation authorised, can a network observer read the transferred content, and can consumers validate the DNS data independently? TSIG contributes primarily to the first and part of the second through key-based identity; server policy, TLS and DNSSEC answer the others in their respective contexts.
Shared secrets make lifecycle management unavoidable
The protocol does not prescribe a universal secret-distribution channel. Administrators may use an approved key-management system, a secure administrative provisioning process or another mutually trusted method. What matters is that both DNS endpoints possess the appropriate secret and that unauthorised programs cannot read it. A key written to a publicly accessible configuration file defeats protocol correctness.
Rotation should be treated as a coordinated change. The sending service and receiving server need to agree on the new key identifier and algorithm, while legitimate outstanding traffic may still reference the old key. A carefully staged overlap can allow migration without giving both keys unnecessarily broad powers for an indefinite period. The precise mechanism depends on software capabilities and policy.
Revocation must be possible after staff turnover, suspicious logging or a compromised service. If many unrelated agents share one secret, turning it off may disrupt all of them. More narrowly scoped keys allow the operator to remove one worker’s privilege with less collateral impact. A design that values least privilege plans this before the first incident, not after the secret has leaked.
Avoid exposing keys in diagnostics and support tickets. Recording the key name, algorithm, signing time, MAC length and result code usually supplies enough evidence for troubleshooting without publishing the secret. A log of successful authenticated requests can support accountability, but a shared secret cannot prove which individual person initiated a command if several people legitimately had access to it.
Time synchronisation is part of the security boundary
Because TSIG includes a signed clock time and permitted Fudge, the application depends on an adequate time source at both parties. Clock misconfiguration can cause valid messages to be rejected. A too-generous window can enlarge replay exposure. Neither problem is solved by increasing HMAC key length or by switching transport protocols.
A useful thought experiment has the client clock four minutes ahead of the server and a network delay of twenty seconds. If the signed timestamp corresponds to client time at dispatch, the receiving server sees a difference close to three minutes and forty seconds, still within a 300-second Fudge. If the clock is seven minutes ahead, the same delay leaves a mismatch far outside that recommended window.
The exact difference depends on which instant each machine measures and how the clock error is defined. Production diagnosis should compute the actual signed timestamp and the verifier’s observed time using logged UTC seconds, not guess from wall-clock displays in different time zones. A time zone display problem and a machine clock drift problem are not identical.
System time corrections must be handled carefully by the operating environment. An agent should not obtain permission to change a fleet’s clocks merely because a DNS error says BADTIME. Confirm the source of divergence independently and use the organisation’s time-service maintenance process, then retry only a safe transaction after clocks and authorisation are restored.
Byte accounting and integrity strength are different metrics
Consider a hypothetical full HMAC-SHA256 tag of 32 bytes and an allowed 16-byte truncated tag. The transmitted authentication bytes differ by 16 bytes per signature. Across one thousand signed DNS messages, the simple tag-byte difference is 1,000×16=16,000 bytes, approximately 16 kilobytes in decimal units. This excludes all DNS record framing and is not a measured network saving.
Reducing the authentication bytes also reduces the transmitted tag length from 256 to 128 bits. Under ideal cryptographic assumptions, the brute-force resistance of the transmitted authenticator differs. A local policy may rationally reject the 16-byte prefix despite protocol support. Those decisions depend on the threat model, interoperability and implementation constraints.
The apparent network saving is not a justification for silently weakening every server. A large zone transfer’s data content may dominate total traffic; for a small control packet, other fields and network overhead may dominate. Measure the actual share of transferred bytes before changing cryptographic settings to save an amount that might be operationally irrelevant.
Always specify denominators: one thousand messages, sixteen saved tag bytes per message and zero assumed changes elsewhere. A vague claim that truncation halves DNS traffic would be false, because it halves only one 32-byte field in this particular illustration. Clear unit accounting is a useful habit in any security and performance discussion.
A diagnostic decision tree for real TSIG failures
When a request fails, first confirm what the authoritative server actually returned and whether the response itself was authenticated. For BADKEY, inspect the configured key name and algorithm association at both ends, then verify whether the client was expected to use that key at all. Do not export the secret into ordinary logs to make a visual comparison.
For BADSIG, verify that the correct secret and algorithm are configured, that wire-message construction is standards-compliant and that intermediaries have not changed protected bytes unexpectedly. A raw packet capture can contain operationally sensitive DNS information; collect it only under an appropriate support policy. A signature mismatch is not proof of an attacker when a deterministic serialization bug can produce the same symptom.
For BADTIME, calculate the absolute difference between the signed and verifier time, compare it to Fudge and examine synchronisation. For BADTRUNC, compare the transmitted MAC length against both the RFC minimum and the server’s stricter local threshold. For a simple unsigned or missing TSIG response, do not promote it to verified success.
If all authentication checks pass but the DNS change does not occur, investigate the dynamic-update policy, prerequisites, zone authority and record state. Those are not HMAC problems. A reliable incident record keeps authentication, policy, operation status and final state in separate fields, letting a second engineer locate the first failing condition without dismantling unrelated controls.
A bounded agent workflow that does not confuse intention with authority
Imagine a legitimate maintenance instruction to move a test API endpoint. A careful agent begins by confirming an authorised change ticket or human-approved plan, checking the zone and intended record, and looking up the specific key permitted for that operation. It should reject attempts to change unrelated zones, widen the allowed record types or exfiltrate the secret as outside the job.
The agent next reads existing authoritative state, constructs RFC 2136 prerequisites and requested changes, signs the complete wire message using a maintained TSIG implementation, and sends it to the configured authoritative endpoint. The request’s timestamp, Fudge and algorithm follow approved configuration. It records a transaction identifier and a fingerprint of the intended change, never the secret itself.
On reply, it validates the expected authentication and checks the DNS operation status. If the response is unauthenticated, late or ambiguous, it does not declare a successful change or silently attempt an unbounded series of mutations. Instead it reconciles the current authoritative record and applies a bounded recovery path appropriate to the update’s idempotency and prerequisite semantics.
Only after independent authoritative readback matches the approved target does the agent report completion. Even then, it can state that recursive-cache visibility may lag until relevant TTLs expire. This is a concrete operational use of protocol authentication and verification; it does not imply an autonomous system is entitled to make arbitrary infrastructure decisions.
Worked recovery example with distinct failure states
Suppose a test workflow expects one A record to change from 192.0.2.10 to 192.0.2.20. Its signed request is accepted by the network, but the client loses the response before verification. The agent now knows only that a message was sent; it does not know whether the authoritative server applied it. A retry may be unnecessary or could conflict with a later administrator’s edit.
The agent first reads the authoritative value. If it is already 192.0.2.20, the intended end state exists, though the agent should still record that the original response was not verified. If it remains 192.0.2.10, an approved conditional retry may be warranted. If it has become 192.0.2.30, a third party may have made a newer change and the agent should not overwrite that without renewed authorisation.
These three cases have distinct meanings: observed desired state, unchanged original state and conflicting unexpected state. A single retry rule applied to all three would be poor engineering. The DNS UPDATE prerequisite mechanism helps define permitted transitions, while TSIG authenticates each new attempt. Neither feature replaces deliberate conflict resolution.
The test uses documentation addresses and does not touch a live DNS zone. It illustrates why a successful request MAC cannot settle an ambiguous write, just as a failed network acknowledgement does not prove an operation failed. Reconciliation protects both correctness and the human administrator’s control over the zone.
Measure the failures that would actually change the decision
A useful DNS administration dashboard records counts of requests by authorised key identifier, destination server and operation class, plus authenticated successes, rejected updates, signature failures, time failures, truncation failures and policy refusals. Aggregating every non-success result into a single percentage prevents diagnosis. Logs should be access-controlled because even non-secret operational metadata can reveal zone structure or maintenance activity.
Suppose a constructed daily audit records 240 approved update attempts, including 228 completed and independently verified state changes, six time errors, four policy denials and two unresolved transport outcomes. The verified-completion share is 228/240=95 percent. The count of cryptographic failures is not necessarily the same as the count of changes lacking confirmed completion.
The six time errors represent 6/240=2.5 percent of attempts, while the two unresolved outcomes represent 2/240≈0.83 percent. Neither figure says anything about the actual availability of a live organisation. Their point is to show that denominators and outcome categories must be explicit when discussing DNS automation reliability.
Operational thresholds should be chosen based on real service requirements and monitored separately for key compromise, clock synchronisation and change authorisation. A sudden increase in validly signed but policy-denied requests could be more important than a stable low network error rate, because it may indicate an agent attempting operations outside its intended role.
Independent transfer exercise: clock skew and privilege mismatch
Test the mechanism in a changed context. A client signs at 09:30:00 UTC with Fudge 180 seconds and submits a request to change api.example.test. The server verifies it at 09:32:40, 160 seconds after signing, and the MAC is correct. The server also finds that the key permits only the test-api.example.test name, not api.example.test. Should the server apply the update?
The time difference of 160 seconds is within the permitted 180-second interval, so the time test passes. The MAC check also passes by stipulation. Yet the requested name lies outside the key’s permitted update scope, so server-side policy must reject the operation. A passing signature and timestamp demonstrate authentication, not authorisation for that specific name.
Now change only the receipt time to 09:33:20, 200 seconds after signing. The time test fails because 200 exceeds the permitted 180 seconds, independently of the name-policy mismatch. A correct implementation should not apply the update in either scenario, but the earliest failing diagnostic and its remedy differ. Enlarging Fudge cannot legitimately grant permission for an unauthorised DNS name.
Finally change the key policy so that the name is allowed, but remove the shared secret from the receiving server’s configuration. The server now cannot verify the expected key, so the operation again fails for a different reason. This transfer exercise forces a clear distinction among cryptographic identity, time validity and operation authorisation.
Limits that remain even when all TSIG fields are valid
TSIG cannot stop an authorised signer from deliberately or accidentally sending a harmful but permitted update. An agent compromised through an application bug may generate perfectly valid MACs under a stolen or legitimately held key. Narrow privileges, approvals, monitoring and revocation limit the consequence of that possibility.
It cannot provide public authentication to arbitrary DNS resolvers because those resolvers do not possess the private shared secret. It cannot conceal zone contents from an observer on a cleartext transfer. Its time window narrows some replay possibilities but does not, by itself, guarantee exactly-once execution of every possible update operation.
Key management also has a human dimension. Staff may misunderstand which service owns a key, forget to rotate a credential after a migration or leave a shared secret in an old backup. Those failures do not contradict the mathematics of HMAC, but they determine how useful the mechanism is in practice. Access reviews and retirement procedures belong in the security model.
The final standard for success is therefore evidence at each boundary: correct MAC verification, time checks, accepted algorithm and length, independently enforced permissions, valid operation semantics and confirmed resulting DNS state. That is a rigorous contemporary automation standard, not an assertion that future artificial superintelligence already exists.
Frequently asked questions about DNS TSIG
Is a TSIG key the same as a DNSSEC signing key?
No. TSIG uses a shared secret between DNS transaction participants to authenticate specified requests and responses. DNSSEC uses a different public verification model for DNS data. A TSIG-validated reply is not automatically a DNSSEC validation proof for a third-party resolver.
Does TSIG encrypt DNS queries or a zone transfer?
No. A MAC does not hide message contents. For confidential zone transfers, inspect the applicable DNS Zone Transfer over TLS requirements in RFC 9103, including strict server authentication and an appropriate requester-authorisation mechanism.
Which RFC should an implementer use?
RFC 8945 is the current core TSIG protocol source referenced here; it obsoletes RFCs 2845 and 4635. RFC 2136 covers DNS dynamic updates, while RFC 9103 covers encrypted zone transfers. Check current errata and implementation guidance before changing production infrastructure.
Does a valid MAC authorise every DNS update?
No. It authenticates possession of an agreed key under its protocol context. The authoritative server must separately enforce which zone, name, record types and operations that key is allowed to affect. A cryptographically valid unauthorised request should be refused.
Why does TSIG have a Fudge field?
It permits a bounded difference, measured in seconds, between the signed timestamp and the verifier’s current time. RFC 8945 recommends 300 seconds for many circumstances. The field helps tolerate clock skew but enlarging it also increases potential replay exposure.
What does BADKEY mean compared with BADSIG?
BADKEY indicates a key or algorithm recognition problem; BADSIG means the provided MAC failed verification. They require different checks. Unsigned error messages must not be promoted into authenticated permission to switch secrets or disable verification.
Can a full HMAC-SHA256 tag be truncated?
Yes, under explicit RFC constraints and local policy. A 16-byte prefix meets the general half-output minimum for a 32-byte HMAC-SHA256 output, but a receiving server can require more. Shortening a tag is not the same as shortening the secret key.
What if a signed DNS UPDATE times out?
Do not blindly infer that the authoritative server performed no change. Inspect authoritative state, reconcile against intended output and consider safe prerequisites and a bounded retry. Authenticated transport and exactly-once application semantics are different problems.
Can an AI agent safely hold the TSIG secret?
An agent-controlled service can use a narrowly scoped credential if the organisation authorises that workflow and properly protects the secret. Reduce privileges, keep keys out of logs and arbitrary prompts, and retain human control for sensitive zone changes. The protocol does not grant broad agency on its own.
What should be verified before announcing success?
The authenticated response, the DNS operation result and independently read authoritative state. For a dynamic update, also inspect prerequisites and permitted name scope. For a multi-message transfer, verify the required MAC chain and complete consistent zone processing.
Primary specifications and current technical sources
RFC 8945 — Secret Key Transaction Authentication for DNS (TSIG), November 2020. The normative source for the TSIG record, MAC calculation, key and time verification, error codes, algorithms, truncation and multi-message authentication. It obsoletes RFCs 2845 and 4635.
RFC 2136 — Dynamic Updates in the Domain Name System. Read this for zone-update requests and conditional prerequisites; it does not by itself make an arbitrary TSIG key a valid authoriser for every record.
RFC 5936 — DNS Zone Transfer Protocol (AXFR). Supplies the authoritative transfer context for the multi-message examples and consistent zone replication.
RFC 9103 — DNS Zone Transfer over TLS, August 2021. Explains why transaction authentication alone does not provide confidentiality, and how transport confidentiality and transfer-group policies fit alongside TSIG.
Verified eduKate specialist reading routes
Begin with How Super Intelligence Works for the wider question of how present-day agent systems use tools and maintain human control. This TSIG chapter describes an existing DNS protocol and makes no claim that artificial superintelligence is already available.
Compare with Agent DNS Cookies — Off-Path Spoofing, Anycast Secrets and Safe Resolver Fallback. DNS Cookies offers a different limited defence for some resolver interactions; it is not a substitute for TSIG authentication of administrative DNS transactions.
Read DNSSEC Aggressive Caching — NSEC Proofs, TTL Limits and Safe Fallback to understand authenticated DNS denial-of-existence proofs in a different trust model. Keeping the two mechanisms distinct prevents a false sense of security from a correctly signed but incorrectly authorised update.
Final independent check: describe an approved update, calculate its time-window validity, identify its key and authorisation scope, interpret an error without trusting an unsigned hint and verify the resulting authoritative records. A careful answer should explain why authenticated communication and permitted changes are related but not identical.