skip to content

How does publishing a DNS TXT record prove to a third-party service that you control a domain, and what makes that proof weak or slow?

level: middleimportance: should knowfreq 34%

answer

  1. a random string only you can place
  2. meaning set by where it is found
  3. many records, one RRset
  4. an earlier miss can be cached

basics

~20 s

The service issues a random token and checks that the domain serves it in a TXT record, which only an editor of the authoritative zone could publish. It proves control only when checked, and a cached earlier miss can delay it.

solid answer

~50 s

The service generates an unguessable token and asks you to publish it as a `TXT` record at the apex or at a name it specifies, often one with an underscore-prefixed label. It then queries that name and compares the strings. Publishing works as proof because only whoever can change the domain's authoritative zone data can make that string appear. RFC 1035 defines `TXT` as descriptive text whose meaning depends on where it is found, so the token scheme is a convention of each service, not a DNS rule. Many `TXT` records can share a name as one RRset, so a token sits beside existing mail-policy strings. The weak points: it proves control only when checked, anyone with zone access or a hijacked DNS account can pass it, and an unsigned answer can be forged on the path. It is slow when the verifier's resolver cached a negative answer from an earlier check.

go deeper

for a junior

Recall that TXT records hold arbitrary strings and that a service verifies ownership by asking you to publish a token it gave you.

for a middle

Explain why only a zone editor can pass the check, how several TXT records coexist as one RRset, and why an early failed check can keep failing for a while.

for a senior

Treat verification tokens as standing credentials: inventory and remove stale ones, lock down DNS hosting access, and prefer dedicated names over an ever-growing apex TXT set.

for a principal

Weigh DNS-based proof against its trust model: every verification rests on whoever controls the zone, so zone-access governance becomes an identity control for many services.

## The mechanism A **TXT** record (type 16) carries one or more **character-strings**. RFC 1035 §3.3.14 gives it no fixed meaning: "The semantics of the text depends on the domain where it is found." That openness is what makes TXT the universal carrier for things the DNS was never designed around, including domain-ownership proofs. A verification flow usually runs like this: 1. The service generates an **unguessable token** tied to your account. 2. It tells you **where** to publish it: the apex `example.com`, or a dedicated name such as `_example-verify.example.com`. 3. You add a `TXT` record with the token at that name in your zone. 4. The service queries that name for `TXT` through a resolver and compares the returned strings with the token. 5. On a match it records the domain as verified; some services re-check periodically. ## Why it counts as proof The only party who can make a string appear in the authoritative answer for `example.com` is someone who can change that zone's data, normally the domain owner or whoever runs its DNS. The token proves that this party cooperated with the account that requested verification. Nothing about the record is special: no signature, no type-specific validation, just a string at a name. ## Encoding details worth knowing - Each **character-string** is a length octet followed by up to 255 octets of data (RFC 1035 §3.3). A long value is split into several strings in one record; how they are joined is up to the application that reads them. - Several `TXT` records at one name form an **RRset** (RFC 2181 §5). A verification token can sit beside an existing SPF string at the apex; each is its own record, and the SPF value's meaning is a separate subject. - A **dedicated name** keeps the apex TXT RRset small. Large TXT sets make responses bigger, and RFC 8482 names TXT among the RRsets that often make responses large. A dedicated name can also be a `CNAME` into a zone the service controls, which the apex never can. | Placement | Benefit | Cost | |---|---|---| | Apex `TXT` | simple; the service needs no extra name | grows the apex RRset every verification adds to | | Underscore-prefixed name | isolated, removable, can be delegated by `CNAME` | the service must define and document the name | ## Where the proof is weak - **It proves control at one moment.** A token left in the zone keeps verifying anyone who reuses it. Remove tokens when the service relationship ends. - **It proves zone access, not identity.** Anyone who can edit the zone, including an attacker holding the DNS hosting account, can pass the check. - **Answers can be forged on the path** unless the zone is signed and the verifier validates; signing is the DNSSEC branch's subject. - **Delegated subdomains** can be verified by whoever runs the delegated zone, which may not be the parent's owner. ## Why verification can lag - A **negative answer is cached.** If the service checked before you published, its resolver may keep that NXDOMAIN or NODATA answer for the negative-caching TTL, bounded by the SOA's `MINIMUM` field and the SOA's own TTL (RFC 2308). Caching behaviour is the caching-and-TTL subject. - **Secondary servers may not have the change yet** if the zone's secondaries have not refreshed, which is a zone-transfer question. - A record that was **never cached** needs no expiry: the positive TTL governs how long an answer is kept, not when a new one becomes visible. ## What interviewers probe They want the reason TXT works (only a zone editor can publish it), the fact that DNS gives TXT no meaning of its own, coexistence of multiple TXT records, and the operational traps: stale tokens, negative caching after an early check, and a compromised DNS account passing every verification at once.

  • Why do many services ask for the token at an underscore-prefixed name instead of the apex?
    A dedicated name keeps the apex `TXT` RRset from growing with every service, can be removed without touching other records, and, unlike the apex, may hold a `CNAME` into a zone the service operates. That last point lets an owner delegate repeated verification without granting edit access to the whole zone.
  • You published the token, the service still reports it missing, and a direct query to your authoritative server shows the record. What is the likeliest cause?
    The service checked before the record existed and its resolver cached that negative answer; RFC 2308 bounds that cache time by the SOA `MINIMUM` field and the SOA record's TTL. Waiting out that window, or having published before triggering the check, resolves it.

saying these in an interview costs you the question

  • A domain can hold only one TXT record, so adding a token removes SPF.
  • TXT verification is secure because DNS answers are always signed.
  • The DNS protocol defines a standard format for verification TXT values.
  • A new TXT record cannot be seen until its own TTL has expired.
  • A verification token can be deleted without risk once the service has checked it.