An exact-name TXT record can stop a wildcard A answer. Learn which DNS evidence to check before changing records during a domain handoff.
You add a TXT record to verify a service. Soon afterward, a hostname that relied on a wildcard no longer returns its expected IP address. The wildcard record is still in the dashboard. What changed? An explicit record can make a name exist in DNS, even when that record is a different type from the one being requested. A wildcard is not a spare answer for every missing record type at an existing name.
That distinction can matter when you take control of a domain and start connecting services. This is a focused diagnostic checklist, not a claim that every DNS failure after a TXT change has the same cause. Start with the exact hostname, the requested record type and the authoritative answer. Do not delete a verification record just to see whether the site comes back.
A simple example: one name, two different questions The following is an illustrative example only, not a live DNS configuration or a command to apply. It assumes one zone, no intervening delegation, no other relevant records and authoritative lookups rather than a cached response. The address is reserved for documentation.
Before: *.example.com A 192.0.2.1 After: *.example.com A 192.0.2.1 abc.example.com TXT "illustrative-verification-text" Before the TXT record exists, an A query for abc.example.com can receive an answer synthesized from *.example.com . After the explicit TXT record is added, the queried name exists. The server does not fill its missing A record from that wildcard.
In this simple example, a TXT query can return the new text while an A query has no A data. The TXT record has not turned into an address, and the wildcard has not been deleted. The name-matching decision changed. Saying that the hostname has vanished entirely would miss that distinction. Cloudflare documents this exact-name pattern with a wildcard A record and a TXT record at abc .
RFC 4592 explains the underlying rule: DNS label matching is independent of the query type. Once the lookup takes the exact-name branch, it does not try the wildcard branch just because the requested type is absent. Why a different record type can affect the website It is tempting to think of A, AAAA and TXT records as separate lists with separate fallbacks. Wildcard selection does not work that way.
DNS first determines how the requested name fits in the zone. The requested type matters within that lookup path. That is why the question is not only, "Did someone change the A record?" It is also, "Did an explicit record or delegation appear at this name, or did the surrounding DNS tree change?" A saved wildcard entry proves that the entry exists.
It does not prove that a particular query will use it. Adding a record at one name is not evidence that every hostname in the zone is broken. In Cloudflare's explicit abc example, the original wildcard no longer supplies names at or below that branch, but it can still apply elsewhere. Review the actual names and zone structure rather than assuming a domain-wide outage.