NS Fast & Secure Lookup · no signup · nothing stored
Look up a domain.
Records, propagation
and DNSSEC, in one screen.
F.S. Fast & Secure Lookup·Fast, private, and secure DNS intelligence.
A / AAAA / MX / TXT / NS listed in one pass, public resolvers compared against your authoritative servers, DNSSEC delegation chains checked segment by segment. Don't want a browser? curl ns.fs.kg/api/dns?name=example.com returns the record list directly.
Waiting for input. Your connection details were already read into the card next door.
Your connection check
readingReading your public address…
- Location
- …
- ISP
- …
- ASN
- …
- IP version
- …
- Connection / TLS
- …
- Edge colo
- …
Read from the connection at the nearest edge node — no third-party lookups, and unrelated to the domain queries below.
Sister siteip.fs.kg Where is that IP and what runs behind it? Geolocation, ASN, hosting & proxy risk signals — pinned on a dot-matrix world map. geolocationrisk signalsbatch of 20curl API Check your IP →Resolution path
waitingThe query travels left to right: your request goes to a recursive resolver, which walks root → TLD → authoritative NS for the answer. Each segment lights up once checked, annotated with the key facts (DS delegation, AA bit and SOA serial, resolver agreement); whatever stays dark is where the problem lives.
DNS records
No domain queried yet. Type example.com, or an underscore hostname like _dmarc.example.com.
| Type | Name | Value | TTL |
|---|
Propagation matrix
The same type is asked of public resolvers and your authoritative servers, to see who already has the new answer.
After a query, each resolver's answer and round-trip time are listed here.
Timing is measured from the edge node to each resolver, not your local resolver speed; current queries go over TCP so the number includes one handshake — good for side-by-side comparison, not absolute latency. For the local picture use dig +trace in a terminal.
DNSSEC chain
What is checked here is record presence and delegation-chain completeness: whether each level publishes a DS, whether the zone carries DNSKEY and RRSIG, and whether validating resolvers set the AD bit. This site does not verify signatures — a 'complete chain' is not the same as 'valid signatures'; use a real validator to call something bogus.
Nameservers & SOA
—After a query this lists the domain's NS, their addresses, per-server SOA serials, and a consistency check between the parent delegation and the child's own NS set.
Which panel answers which question
- Just changed a record
- Propagation matrix + SOA serials
- Mail not going out
- MX / TXT(_dmarc) / SPF
- Certificate issuance failing
- TXT _acme-challenge
- Suspected hijacking
- DNSSEC chain + AD bit
- Mid-NS migration
- SOA per authoritative server
Underscore hostnames (_dmarc., _acme-challenge., _domainkey.) can be typed directly — no escaping needed.
Data & privacy
- Record source
- Public DoH + direct authoritative queries
- Storage
- No database, no logs
- Signup
- None — free, no ads
- Caching
- Responses always no-store
- Sister site
- ip.fs.kg
The domain you type is sent as a DNS query to the chosen resolvers (that is inherent to the lookup); this site keeps nothing beyond that.
Use it from the terminal
Command-line clients get plain text automatically, browsers get JSON; point server= at any public resolver or your own authoritative server.
# look up records (default: 8.8.8.8) curl ns.fs.kg/api/dns?name=example.com&type=MX # ask an authoritative server for the zone truth (rd=0 by default, DO bit on for DNSSEC) curl 'ns.fs.kg/api/dns?name=example.com&type=A&server=199.43.135.53&dnssec=1' # ask a public resolver for its cached answer (rd=1, or you get SERVFAIL / REFUSED) curl 'ns.fs.kg/api/dns?name=example.com&type=A&server=223.5.5.5&rd=1' # JSON output (this is what a browser gets) curl -H 'Accept: application/json' 'ns.fs.kg/api/dns?name=example.com&type=A'
Parameters: name (required), type, server (public IP literal, default 8.8.8.8), dnssec=0/1, rd=0/1, timeout=ms. Truncated responses automatically fall back to TCP.
FAQ
How do I look up the DNS records of a domain?
Type a domain into the search box (example.com, underscore hostnames like _dmarc.example.com work too, no escaping), pick A / AAAA / CNAME / MX / TXT / NS / SOA / CAA / SRV / PTR from the chips, hit enter. The record list goes over the browser's own DNS-over-HTTPS connection and never touches this site's server; the propagation matrix, DNSSEC chain and authoritative SOA are queried by the edge, which sends raw DNS packets.
I just changed a record and it doesn't show up — is this site broken?
Separate two things: what the authoritative server has, and what resolvers have cached. If the authoritative row in the propagation matrix already shows the new value, it is a caching issue — wait out the TTL or ask the resolver to refresh. If the authoritative row still shows the old value, your change never reached the zone file.
Why do the authoritative row and the public resolvers disagree?
Authoritative servers hold the answer you are supposed to see right now; public resolvers may still be serving their previous cache (bounded by the original TTL). A mismatch usually means the cache has not expired yet, not that resolution is broken. Resolvers are asked with rd=1 (for their cached answer), authoritative servers with rd=0 (for the truth in the zone) — asked the other way around you get SERVFAIL, which is not a failure.
Why must the SOA serial match on every nameserver?
A zone's authoritative servers sync via AXFR/IXFR, and the serial is the version number. A server whose serial lags failed its zone transfer — records will look flappy ("sometimes new, sometimes old"), the most annoying failure mode there is.
Does a "complete chain" in DNSSEC mean it's safe?
No. This site checks whether the DS delegation exists, whether the zone publishes DNSKEY and RRSIG, and whether validating resolvers set the AD bit; it does not verify signatures. To judge secure / bogus use a local validator (dig +dnssec or unbound).
Why isn't 1.1.1.1 in the matrix?
The direct queries run on Cloudflare's edge, and Cloudflare does not allow Workers to connect to its own IPs (connecting to 1.1.1.1 gets cancelled immediately). Listing it would only ever show failure, so the matrix uses Google / OpenDNS / AliDNS / DNSPod / Quad9 as observation points. The same applies when your domain's authoritative NS are hosted on Cloudflare — that row is labelled "Cloudflare-owned address, cannot connect directly". A platform limitation, not a resolution failure.
Why is the timing slower than my local dig?
The measurement point is an edge node, not your home router, and current queries go over TCP so the number includes one handshake. It reflects how these resolvers answer for visitors worldwide; use it for the relative freshness and consistency across resolvers, and use local dig for absolute latency.
Does it support reverse lookups (IP → domain)?
Yes — type the IP and it is converted to the standard PTR form automatically (1.1.1.1 becomes 1.1.1.1.in-addr.arpa), with the type switched to PTR.