Learn

PacStac Stewardship

TXT Records in Practice

TXT records store arbitrary text at a DNS name. Because they are easy to add and globally visible, Internet protocols use them to prove control of domains—think SPF, DKIM, ACME (Let’s Encrypt), and PacStac. Here’s how to work with TXT records safely.

Quick anatomy

Name: the host label ("@" for apex, "pacstac" for subdomains).

Type: TXT.

Value: one or more strings enclosed in quotes. PacStac expects two TXT entries with pacstac_msg=... and pacstac_verify=..., exactly as generated.

TTL: number of seconds caches should retain the record.

Publishing workflow

1. Prepare the values. Copy both TXT entries from PacStac (message + signature).
2. Add the records. In your DNS provider, create two TXT entries at pacstac (or @ for apex).
3. Verify locally. Use dig example.com TXT and/or dig pacstac.example.com TXT and confirm both keys appear.
4. Wait one TTL. Remote resolvers may take up to the TTL to refresh. PacStac’s scheduler respects TTLs before re-checking.

Common pitfalls

Propagation vs. TTL

Resolvers cache responses for the TTL you publish. Lowering a TTL right before a change does not immediately force caches to expire; schedule edits at least one TTL in advance when possible.

Provider UI quirks

Some control panels silently append the domain to the host you enter. Others require quoting the value and will strip the quotes for you. Always verify the rendered record with `dig` or `nslookup`.

Character limits

RFC 1035 caps character strings at 255 characters. DNS servers split longer values into multiple quoted chunks, but clients should concatenate them. PacStac keys typically fit well within one chunk.

Multiple TXT records

A single name can host many TXT records (SPF, DKIM, PacStac). Order is undefined. PacStac looks for an exact match; keep your value distinct and avoid noisy concatenations.

Rollbacks and rotations

When rotating wallets, publish the new pacstac_msg + pacstac_verify TXT entries before removing the old ones.