Real DNS From a Browser Tab: DoH, CORS, and What You Genuinely Cannot Scan

TL;DR: A browser tab can resolve real A, MX, TXT and NS records, brute-force subdomains, and grade a domain's mail security, all with no backend. It cannot scan a port, probe an arbitrary HTTP endpoint, or read certificate transparency logs. The dividing line is CORS, and it is worth understanding precisely. Try it in the DNS / SPF/DMARC Inspector.

Most "online DNS lookup" tools are a form on a web page that posts your target to a server, which does the actual resolution and hands back the answer. That server sees every domain you look up, and if you are doing reconnaissance for a client, so does whoever runs it.

Our DNS Inspector and Subdomain Scanner do not work that way. The lookups leave your browser and go straight to a public resolver. There is no Utilora server in the path, because there is no Utilora server at all. That is possible for a narrow and interesting technical reason, and impossible for a broader one.

Why DNS works: two resolvers that send the right header

A browser cannot open a UDP socket to port 53, so classic DNS is off the table. DNS-over-HTTPS changes the transport to something a browser already speaks.

Two public DoH endpoints matter here:

• https://cloudflare-dns.com/dns-query, which returns JSON when you send Accept: application/dns-json
• https://dns.google/resolve, which returns JSON by default

Both respond with Access-Control-Allow-Origin: *.

That single header is the whole story. Without it, the browser would fetch the response and then refuse to let JavaScript read it. With it, any page on any origin can issue a resolution and parse the answer. So fetch() plus a query string is genuinely all it takes:

https://cloudflare-dns.com/dns-query?name=example.com&type=MX

The response is a JSON object with an Answer array, each entry carrying a numeric type. Type 1 is an A record, which is why a subdomain scanner filters on type === 1 rather than trusting that a non-empty answer means a live host. A domain can return CNAME or SOA records in an answer without having a single address.

We query Cloudflare first and fall back to Google, and a failed lookup returns an empty array rather than throwing. On a sweep that issues hundreds of resolutions, one dead record type should not take down the run.

What subdomain enumeration actually is

There is no API that lists a domain's subdomains. Enumeration by DNS is guessing: take a list of likely prefixes, resolve each one against the target, and keep the ones that answer.

That is exactly what our scanner does, with a bounded number of requests in flight so one slow lookup does not stall the rest. The default list ships 51 prefixes, which is enough to demonstrate the technique and nowhere near enough for real work. Serious enumeration means bringing your own list, so the tool takes a pasted wordlist. We deliberately do not bundle a megabyte of prefixes, because every visitor would pay for that download whether they enumerate anything or not.

Two honest caveats about the method itself:

Wildcard DNS defeats it. If *.example.com resolves, every guess "succeeds" and your results are noise. Check whether a deliberately absurd prefix resolves before trusting a list of hits.

It only finds what you guessed. A subdomain named after an internal project will never appear in a generic wordlist. DNS brute force is a floor, not a census.

Where the browser wall actually is

Here is the part most write-ups skip. The same-origin policy that DoH sidesteps blocks everything else, and no amount of cleverness gets around it from a page.

Port scanning: no. You cannot open a TCP connection to an arbitrary host and port. Timing tricks against fetch() or image loads leak a little information and are unreliable, rate-limited by the browser, and not something to build a tool on.

HTTP probing of arbitrary hosts: no. You can send a request, but without a permissive CORS header you cannot read the status or the body. "Does this host serve a login page" is not answerable client-side.

Banner grabbing and service fingerprinting: no. Same reason, and it needs raw sockets besides.

Certificate transparency: no, and this one hurts. CT logs are the single best subdomain source available, far better than any wordlist, because every certificate issued for a hostname is published. crt.sh does not send CORS headers, so a browser cannot read the response. This is the sharpest limit on how thorough browser-only recon can be, and we would rather say so than pretend a 51-word list is equivalent.

Anything past that line needs a server or an agent running on your own machine, which is a different product with a different trust model.

What you get in exchange

The constraint buys something real. A penetration tester will not paste a client's domain list into a stranger's web service, and they should not have to. For the checks that DoH can answer, "the query went from your browser to Cloudflare" is a verifiable claim about the architecture rather than a promise in a privacy policy.

Cloudflare and Google do see your resolutions, and your IP. We are not going to dress that up: browser-side DNS moves the trust from us to a resolver you were probably already using. What it removes is the middleman who had no reason to be there.

Privacy Note: Every lookup described here runs from your browser to a public resolver. Utilora never receives your target domains, because there is no backend to receive them.

Reading the results

Resolution is the easy half. Interpreting a TXT record that starts with v=spf1 and deciding whether it protects anything is where the actual analysis lives, and that is a longer story about SPF mechanisms and DMARC policies.

Inspect a domain's DNS and mail security →