Summary

  • RFC 2845 made a signed DNS response include the request MAC, binding the response to the request that elicited it.
  • For a multi-message DNS/TCP exchange, a running MAC covered the prior MAC and intervening messages, with TSIG checkpoints at the first, last and at least every hundredth message.
  • RFC 8945 later changed the sender rule to require TSIG on every response message while preserving limited unsigned-message acceptance for compatibility; neither version turns transaction authentication into confidentiality, source-data truth or local authorization.

A reply was not an unrelated packet

DNS already had message identifiers and response codes, but those fields did not authenticate the peer or protect a transaction from alteration. RFC 2845, published in May 2000, added TSIG: a meta-resource record appended to a DNS message and verified with a shared secret. Its scope was deliberately point-to-point. The parties had to possess the same configured key; distributing that key was outside the specification.

The important design choice appears in the MAC input. A client first authenticated its request. When the server returned a signed answer, the response calculation included that request MAC, the answer and the response’s TSIG variables. A verifier therefore did not assess the answer as a fresh, context-free object: its cryptographic check reached back to the request. The time-signed and fudge fields were also covered, so an intermediary could not simply edit the time window and leave the MAC valid.

That link was a claim about covered bytes and a key relationship. Because both peers shared the secret, successful verification showed that the message checked under the configured key; it did not identify which person or process held the key. TSIG did not encrypt DNS contents, and it did not decide whether a local server should permit a particular update. RFC 2136 defined DNS UPDATE; local policy still had to answer whether an authenticated peer could change a zone.

A transfer became a transcript

The harder case was a response that did not fit in one DNS message, such as a TCP zone transfer. If every packet stood alone, the verifier would lose the ordered relationship between packets. RFC 2845 instead made the first and last message carry TSIG and required a signed checkpoint at least every hundred messages. Between checkpoints, each DNS message joined the next MAC calculation in order, together with the preceding MAC and the applicable timer fields.

The verifier was therefore checking continuity across a bounded stretch of a stream, not treating each intermediate message as independently signed. If verification failed, the RFC required the TCP connection to close and the transfer to be treated as interrupted; it did not prescribe an exact retry procedure. This is a useful limit on what a successful checkpoint proves: it covers a segment of a received transcript, not what a server later committed or what a secondary served.

The rule changed, the boundary did not

RFC 4635 added HMAC-SHA algorithm identifiers beyond the original HMAC-MD5 design. In 2020, RFC 8945 replaced RFC 2845 and RFC 4635 as STD 93. It tightened the sending rule: response messages should carry TSIG, and a conforming sender signs every message in the response. Its compatibility rule is different: a verifier must tolerate up to 99 unsigned intermediate messages while still requiring the first and last messages to be signed. The 99-message allowance is not permission for a modern sender to omit signatures.

RFC 8945 is equally explicit about the epistemic boundary: TSIG authenticates transmission between two peers with a shared secret, not the origin or correctness of source data. It is distinct from DNSSEC, which authenticates data through a different trust model. TKEY can establish keys in some deployments, but key distribution is not a property supplied by TSIG itself. The standards trace a carefully bounded mechanism, not an all-purpose trust stamp.

Sources: RFC 1035; RFC 2104; RFC 2845; RFC 8945; RFC 4635; RFC 2136; RFC 2930.