Verifying a DNS change actually published
After editing a zone, query the record directly. If the authoritative answer is correct but users still see the old value, you are waiting out a TTL, not debugging a broken change.
Queries DNS records (A, AAAA, MX, TXT, NS, CNAME, SOA) for any domain.
—Queries DNS records (A, AAAA, MX, TXT, NS, CNAME, SOA) for any domain.
example.com
A 93.184.216.34 · AAAA 2606:2800:... · MX 0 . · NS a.iana-servers.net · TXT v=spf1 -all
Each record type is listed with its value.
Records show how the domain is configured globally.
Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.
curl -X POST "https://yas.sh/api/v1/tools/dns-lookup" \
-H "Content-Type: application/json" \
-d '{"input":"yas.sh"}'const res = await fetch("https://yas.sh/api/v1/tools/dns-lookup", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
"input": "yas.sh"
}),
});
const data = await res.json();import requests
r = requests.post("https://yas.sh/api/v1/tools/dns-lookup", json={"input":"yas.sh"})
data = r.json()| Field | Type | Required | Description |
|---|---|---|---|
| input | string | Yes | Domain, e.g. example.com (no scheme, no IP literals) |
| type | string | No (default "all") | all | A | AAAA | MX | TXT | NS | CNAME | SOA |
{ "result": { "domain": "yas.sh", "A": [{ "address": "93.184.216.34", "ttl": 300 }], "MX": [{ "priority": 10, "exchange": "mx1.example.com" }], ... } }Resolve A, AAAA, MX, TXT, NS, CNAME, SOA records for a domain (TTLs included).
400 VALIDATION_ERROR — invalid input or unsupported option.413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).A lookup asks a resolver for a specific record type at a specific name. The query travels from a recursive resolver to the root servers, to the TLD servers for the zone, and finally to the domain's authoritative nameservers, which return the answer with a TTL. This tool queries over DNS-over-HTTPS, so the result reflects what a modern client resolver sees rather than what your local network's resolver has cached.
Record types answer different questions. A and AAAA map a name to IPv4 and IPv6 addresses; CNAME aliases one name to another (and may not coexist with other records at the same name); MX lists mail exchangers with priorities; TXT carries free-form strings used by SPF, DKIM, DMARC and domain-verification tokens; NS delegates a zone; SOA holds the zone's serial and timing parameters.
The TTL is the contract for caching. Until it expires, resolvers worldwide may serve the previous answer regardless of what your authoritative zone now says. This is why a record change appears instantly here and not for a colleague — and why you lower the TTL before a planned migration, not during it.
After editing a zone, query the record directly. If the authoritative answer is correct but users still see the old value, you are waiting out a TTL, not debugging a broken change.
Check MX, then the SPF TXT record, then DMARC at _dmarc.<domain>. A missing MX means nothing can be delivered; a broken SPF record means mail is delivered and then rejected. The MX Health and SPF Inspector tools evaluate the policy semantics.
Verification usually requires a TXT record at the apex or a subdomain. Querying it shows whether the record published, whether the provider silently appended the domain to the host field, and whether quoting split it into two strings.
A CNAME pointing at a deprovisioned cloud resource can be claimed by anyone. Resolve the CNAME chain, then run the Dangling CNAME Checker for the vulnerability classification.
What this tool deliberately does not do, and where it will disagree with other implementations.