• Glossary
  • What is TSIG (Transaction Signature)?

DNS glossary

What is TSIG (Transaction Signature)?

TSIG (Transaction Signature) is a DNS security mechanism that authenticates DNS messages using a shared secret key and a keyed hash. It is commonly used to protect zone transfers and dynamic updates, so a server accepts those requests only from parties that hold the same key.

Let's simplify your DDI
Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.

TSIG (Transaction Signature) is a DNS security mechanism that authenticates DNS messages between two known parties using a shared secret key and keyed hash, primarily protecting zone transfers and dynamic updates. It replaces weak source IP-based validation with cryptographic authentication, ensuring that only parties holding the correct key can perform sensitive DNS operations. Proper implementation requires synchronized clocks, careful key management, secure key distribution, and explicit binding of keys to access rules to avoid operational failures and security exposure.

  • TSIG is defined in RFC 8945 and uses a shared secret key with keyed-hash computation to authenticate DNS messages while protecting message integrity, though it does not encrypt the content itself.
  • Clock drift between servers causes TSIG-signed requests to fail with bad time errors even when the key is correct, making NTP synchronization essential for reliable zone transfers and dynamic updates.
  • Poor key management practices such as sharing keys across multiple servers, storing secrets in plain text, or failing to rotate credentials significantly widen the operational and security risk if a key is compromised.

TSIG at a glance

AttributeValue
Full nameTransaction Signature
CategoryDNS security mechanism
Defined inRFC 8945, which obsoletes the original specification in RFC 2845
Primary useAuthenticating zone transfers, dynamic updates and other DNS messages between parties that share a key
Related termsDNS, Dynamic DNS, Zone transfer, DNSSEC, Secondary DNS

How TSIG works

TSIG uses a shared secret key and a keyed hash to prove that a DNS message came from a party holding the key and was not altered in transit. Both sides must be configured with the same key name, algorithm and secret beforehand.

  1. Share a key: An administrator generates a secret key and configures the same key name, algorithm and secret on both servers, or on the client and the server.
  2. Sign the message: The sender computes a keyed hash over the DNS message plus certain TSIG fields, including a timestamp, and appends the result to the message as a TSIG record.
  3. Verify the signature: The receiver looks up the key by name, recomputes the hash and compares it with the one received. A mismatch causes the message to be rejected.
  4. Check the time: The receiver also checks that the signed timestamp falls within an allowed time window, which limits replay of captured messages.
  5. Sign the response: The receiver signs its reply with the same key, so the requester can confirm the answer came from the expected server.

TSIG authenticates and protects the integrity of messages but does not encrypt them. Because it relies on a shared secret, it fits communication between known parties, not public resolution, and clocks on both sides need to stay reasonably synchronized.

Why TSIG matters in enterprise networks

Zone transfers and dynamic updates change the data that a DNS server publishes. If a server accepts these requests based only on source IP address, anyone who can spoof or share that address can copy a zone or alter records. TSIG replaces that weak check with a cryptographic one, so each request must be signed with a key that only authorized parties hold.

TSIG is defined in RFC 8945, which replaced the original specification in RFC 2845. It is widely supported in DNS server software and is a common way to secure communication between primary and secondary servers and between DHCP servers and DNS servers that perform dynamic updates. It protects message integrity between two endpoints and is separate from DNSSEC, which signs zone data for validation by resolvers.

Poor key management is the main operational risk. A key that is shared across many servers, never rotated or stored in plain text in configuration files widens the impact of a single leak. Clock drift between servers causes valid messages to be rejected, which can silently stop zone transfers and leave secondary servers serving stale data. Documenting key ownership, rotating secrets and monitoring for failed transfers keeps TSIG dependable.

TSIG vs DNSSEC

TSIG authenticates messages between two parties that share a secret key, while DNSSEC uses public-key signatures to let any resolver verify the authenticity of DNS data. What is DNSSEC?

AttributeTSIGDNSSEC
CryptographyShared secret key and keyed hashPublic-key signatures
What it protectsThe transaction between two DNS partiesThe DNS data in the zone itself
Typical useZone transfers and dynamic updatesValidating answers from authoritative servers
Key distributionConfigured manually on both sidesPublished in the DNS and anchored in the chain of trust
Who verifiesOnly the party holding the shared keyAny validating resolver

Common TSIG issues

TSIG includes a timestamp, and the receiver rejects messages outside an allowed time window. If server clocks drift, transfers or updates fail with a bad time error even though the key is correct. Synchronizing both sides with NTP usually resolves it.

The key name, algorithm and secret must all match on both sides. A typo in the secret, a different algorithm or a differently spelled key name causes a bad signature or unknown key error, and the request is refused.

Defining a key does not by itself require it. If the zone still allows transfers or updates by source IP address, unsigned requests can succeed. The access rule must name the key explicitly.

Secrets pasted into tickets, shared across many zones or never rotated widen the exposure if one is leaked. Using a separate key per relationship and rotating it on a schedule limits the damage.

TSIG signs messages but does not encrypt them. Zone contents sent during a transfer can still be read on the wire unless the transport is also protected, for example with TLS.

See how unified DDI simplifies network operations

Manage DNS, DHCP and IP addresses from one platform with automation, visibility and control built in.

Talk to us

TSIG FAQ

Related terms

Article

DNSSEC (Domain Name Service Security Extension)

A mechanism that uses cryptography to provide authentication and integrity for DNS queries.

Learn more
Article

DNS zone

A distinct, contiguous portion of the domain name space for which administrative responsibility has been delegated to a single manager.

Learn more
Article

BIND

Widely-used software that allows you to publish your DNS information on the internet, and to resolve DNS queries for your users. Learn More

Learn more
Article

NTP (network time protocol)

A networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks.

Learn more
Article

Transport layer security (TLS)

A cryptographic protocol to provide communications security over a computer network.

Learn more
Article

Authoritative DNS server / Authoritative name server

Provides original and definitive answers to DNS queries.

Learn more
Article

DNS record

Tells servers precisely how to respond to a DNS query.

Learn more
Browse the full glossary