Loading
Loading
Enter a CNAME target to list every hostname observed aliasing it, with the TTL and the date each record was last seen. Exact, partial and wildcard matching.
A free account is required, and a lookup that returns records uses credits. See pricing.
A reverse CNAME lookup starts from the target and works backwards: enter a hostname and the tool lists every hostname whose CNAME record was observed pointing at it, with the record's TTL and the date it was last seen. Tick Exact to confirm who aliases a hostname you control, leave it unticked to catch regional variants, or add a wildcard to cover every label a provider hands out.
www.example.com points at example.com, or shop.example.com points at the hostname a SaaS platform assigned you (RFC 1034, section 3.6.2). A normal lookup follows that arrow forwards, from the alias to its target; this tool runs it in reverse.DNS cannot answer the reverse question on its own. A name server only knows the records in its own zones, the CNAME record lives at the alias rather than at the target, and nothing in the protocol tells a hostname's owner who has aliased it. The only way to find out which hostnames point a CNAME at this target is a set of records observed across many zones, which is what this tool searches. That is also why every row carries a Last Seen date: it is a record that was observed on that date, not a live answer from the domain's name server.
ghs.googlehosted.com, a CDN or load-balancer hostname, or a server you run. Case, surrounding spaces and a trailing dot don't change the result.Three ways to search the same target, and what each one returns.
| Mode | How to run it | What it returns | Use it when |
|---|---|---|---|
| Exact | Tick Exact and enter the full hostname, such as www.google.com | Only records whose target is exactly www.google.com | You own the hostname, or you want a precise list to act on |
| Partial | Leave Exact unticked (the default) and enter the hostname | Records whose target contains the text anywhere: www.google.com also returns hostnames aliasing www.google.com.hk, and herokuapp.com returns every hostname aliasing va05.ingress.herokuapp.com, ie02.ingress.herokuapp.com and the rest of that family | You want a provider's whole family of targets, or a target's regional variants, in one list |
| Wildcard | Leave Exact unticked and use * for any run of characters, such as c*.g*.com | Every target that fits the pattern. The pattern is not anchored, so c*.g*.com also matches paylinks.commerce.godaddy.com and cname.greatpages.com.br | You know only part of the hostname, or the part you know sits in the middle of it |
Exact and wildcards don't combine: a pattern with Exact ticked comes back as No Record Found, so untick Exact before you use one. The more literal text a pattern carries, the tighter the list.
What each column in a reverse CNAME lookup result means.
Three rows from a partial lookup on herokuapp.com
| Num | Domain Name | DNS Type | CNAME Target Host | TTL | Last Seen |
|---|---|---|---|---|---|
| 1 | direwolf-9ff6fed1b0-952f2cafbc97.herokuapp.com | CNAME | va05.ingress.herokuapp.com. | 300s | 2026-07-22 |
| 2 | direwolf-1ee7fd0d27-f2451d71f4fd.herokuapp.com | CNAME | va04.ingress.herokuapp.com. | 300s | 2026-03-29 |
| 3 | direwolf-2ef4a4f20a-a44f8a48fae0.herokuapp.com | CNAME | ie02.ingress.herokuapp.com. | 300s | 2026-10-04 |
A missing row doesn't prove nothing points at a hostname: the tool shows records that were observed, not every record that exists. No match at all shows as "No data to display" with the hostname you entered.
Platforms hand every customer the same target, such as shops.myshopify.com or ghs.googlehosted.com. A reverse CNAME lookup on that target lists the hostnames built on it, as a market read or a prospect list.
Two lookups with similar names that answer opposite questions.
| Lookup | You enter | You get | Where to run it |
|---|---|---|---|
| Reverse CNAME lookup | A target hostname | Every hostname observed with a CNAME pointing at it | This tool, or the Reverse DNS Lookup API with type=CNAME |
| CNAME lookup (forward) | A hostname | The CNAME target that hostname points at right now | dig CNAME hostname, or the DNS Lookup API |
If your question is "who points at this hostname?", a reverse CNAME lookup is the right one. If it is "where does this hostname point?", you want the forward lookup.
Enter your hostname with Exact ticked and run the lookup. Every hostname observed aliasing that exact target comes back with its TTL and Last Seen date. Check the variants you serve as well: www.yourhost.com and yourhost.com are different targets, and a partial match on the bare hostname catches both at once.
No. dig and nslookup ask a name server about one name, and dig -x only runs a reverse DNS lookup, which turns an IP address into the PTR hostname its owner published. No DNS query lists the names pointing at a target, so a reverse CNAME lookup has to search records observed across many zones, which is what this tool does.
That is the forward direction. dig CNAME hostname or nslookup -type=CNAME hostname prints the target the hostname points at right now, and the DNS Lookup API returns the same record with its TTL from your own code. Use this page when you already know the target and want the hostnames behind it.
Yes to both. The lookup runs on the Reverse DNS Lookup API with your own key, so it needs a free APIFreaks account. A lookup that returns records uses credits from that account, and opening another page of results runs a new lookup; a lookup that finds no records costs nothing. The current plans and what a lookup costs are on the pricing page.
Yes. The Reverse DNS Lookup API returns the same records as this tool with the same exact and wildcard options, and the same endpoint also runs reverse NS, MX, A, AAAA, SOA, SPF and TXT lookups. The API reference lists every parameter and every field in the response.